阿里腾讯如何进行研发管理和绩效考核Word文件下载.docx
《阿里腾讯如何进行研发管理和绩效考核Word文件下载.docx》由会员分享，可在线阅读，更多相关《阿里腾讯如何进行研发管理和绩效考核Word文件下载.docx（8页珍藏版）》请在冰点文库上搜索。
一句话表达清楚要做什么;
2。
分析市场机会和趋势，决定当前策略；
3。
确定目标用户的特征和核心需求；
4.现存的解决方案和各自的优劣势;
5。
该项目对豌豆荚的利益点；
如果不做该项目，哪些竞争对手会做，对竞争对手的利益点；
6。
需要哪些技术的支持和驱动，哪些技术是豌豆荚的弱项;
7.人力需求;
8.项目的紧急程度，是否需要快速推进；
9。
发布策略;
10.核心衡量指标，用来衡量成功的指标。
第二步，OKR体系——定目标
对一个项目来说，设定目标是非常重要的，因为这决定了如何去做,以及能做到何种程度。
豌豆荚采纳的目标管理是从Google引进的OKR体系（Objectives＆amp;
KeyResults，目标与关键成果），这跟传统的KPI（KeyPerformanceIndicator，关键绩效考核）稍微有些区别：
1。
OKR首先是沟通工具：
豌豆荚共有300多人,每个人都要写OKR。
为了便于沟通，所有这些OKR都会放在一个文档里。
任何员工都可以看到CEO的这个季度最重要的目标是什么,HR团队这个季度的目标是什么。
2.OKR是努力的方向和目标：
OKR代表你到底要去哪里，而不是你要去的地方具体在哪里.
OKR必须可量化。
比如健身时设定锻炼目标，如果只是定义成「我们要努力提高身体素质」,肯定不是一个好的OKR，因为无法衡量,好的OKR是「今年的跑步时间较去年增加一倍」.
4。
目标必须一致：
制定者和执行者目标一致、团队和个人的目标一致。
首先，制定公司的OKR；
其次，每个团队定自己的OKR;
第三,每个工程师或设计师写各自的OKR。
这三步各自独立完成，然后对照协调这三者的OKR。
在豌豆荚,OKR跟个人绩效没有关系，因为OKR系统的结果和每个人并不直接挂钩.
通过月度会议Review，时时跟进OKR：
在月度会议上需要确定如何去达到目标，是一个帮助达到目标的过程。
6.通过季度会议Review,及时调整OKR：
互联网的变化非常快，所以豌豆荚每季度有一个OKR的review,调整的原则是目标（Objectives）不变，只允许调整关键成果（KeyResults）。
为了更好的理解如何制定OKR体系,我们看个例子：
●目标（Objectives）：
发布有影响力的新功能，将XXX产品做成用户可以每日使用的产品.
●关键成果（KeyResults）：
日活跃用户量为XX;
使用XX方式，提高XXX核心指标；
第三步,项目管理——控进度：
目标设定以后，非常重要的就是执行，一般的项目管理实际上就是控制进度。
任务/进度勤同步。
整个公司所有人的calender，包括会议、要做的事情、项目的时间节点都需要及时同步.在整个战略布局上,如果某个项目工期非常紧，就必须进行更多的沟通，确保每一个环节都没有问题。
2.站立会议（DailySync）:
每天进行站立会议，一般控制在十分钟之内，每个人说明自己今天要做的工作,需要什么帮助，有谁可以帮忙，可以更有效的调节资源和公关.
多方位沟通（GoogleDocs/Gmail/Hangouts）：
对非紧急的事情，两个团队或者是两个人一起讨论所有的设计。
Hangouts用于做快速响应。
4.周会（WeeklyReport）：
每周总结。
豌豆荚的团队产品经理要做周报，汇报这周的工作、发布、取得效果以及数据。
数据系统：
MUCE是豌豆荚的数据系统，上面有全公司所有的产品数据和运营数据。
MUCE的数据能够用来验证产品的假设、方向等。
第四步,人员管理-—带团队：
项目是由一个个具体的人来执行的，所以带团队非常重要,在人员管理上,豌豆荚有三个基本原则：
1、Re—Organization&
amp；
换组：
公司鼓励员工换组，每个人都有机会到喜爱的团队做更有趣的事情。
只要在原团队的绩效合格,每季度都可申请换团队或换工作内容。
员工的绩效不与OKR挂钩,公司鼓励员工挑战难度、超越优秀，低Level的事情做不到优秀会被惩罚,做事不及格也会被惩罚。
2、OneonOne：
在带人方面，OneonOne非常重要。
OneonOne指的是每个团队的manager需要定期（最佳间隔是每周一次）与自己团队中的每个成员进行一对一讨论或者对话。
在豌豆荚，manager首先是一个教练，应该帮助自己团队的成员成长。
通过OneonOne，manager需要了解每个团队成员现阶段的状态和遭遇的困扰，分享职业规划，帮助他们正确地处理问题,更好地实现个人成长。
3、个人OKR和Performance体系：
每个员工在每个季度初需要确定自己本季度的OKR,在一个季度结束后需要根据自己这个季度的工作完成情况给OKR打分。
每半年公司会进行一次PerformanceReview，主要是review员工过去半年的绩效，并根据PerformanceReview的结果变更JobLadder（业务职级）和薪酬。
值得一提的是，在豌豆荚，所有的个人PerformanceReview的成就内容及级别都是全公司共享公开的，如下图所示。
这个对于很多公司来说是不可想象的，豌豆荚为什么要这么做？
因为一方面对于豌豆荚来说可以做到更为公平和透明，另一方面也给每位豌豆提供了更好学习和成长自己的样本，激励大家在产品研发中更高质量的挑战和要求自己。
第五步，兴趣管理——排干扰：
1、激发兴趣:
HackDay,是豌豆荚一个特殊的节日,开始于2010年,类似黑客马拉松.通常在春节假期回来的那一周，产品设计师和工程师们3—5人组成一队，在连续48小时的时间里，充分展现工程团队的创意和想像力，完成一些比日常开发更geek、更有趣的东西.
豌豆荚为了鼓励大家更好的完成挑战，也会设计一些特别有特色的奖品,历史上2012年提供的是苹果刚出MacbookRetina，2013年是GoogleGlass，2014年则是程序员最爱的HermanMiller顶级座椅。
在历史的Hackday中，有不少作品最终都成了重要产品对外发布，比如MUCE、豌豆洗白白和IAS（应用内搜索）,都成为了豌豆荚极具特色的产品。
2、控制兴趣:
PolishWeek，让公司慢下来，对已有产品的细节进行精细化的过程.在大量开发和新产品上线的过程中，我们会担心因为走得太快而对产品的细节关注不够。
在连续3个工作周后，第4周通常是PolishWeek.在PolishWeek的这一周,豌豆荚内部不会进行新产品或新功能的开发,而主要是对现有的产品和服务进行打磨，解决一些细节问题和小bug，譬如产品内一些字体的统一等等。
平均每个PolishWeek会解决产品中各种Bug大约200个。
二、高效研发的流程和工具
过去几年豌豆荚做Windows版的时候，尝试过一个月、两个月、一个星期、两个星期的发布节奏，整个模式跟Chrome比较像，有功能发布就希望尽早的发.我们在服务端上每天都有更新，客户端会慢一点，现在大概是两周一个版本，如下图所示：
在开发节奏上,前两周的时间用于开发，然后截取分支准备发布，接下来两周进行测试，同时进行另一个开发，每一个迭代都控制在两周之内。
相对而言，服务端的发布比较好操作，可以做很多的回归测试和自动化测试,不太需要手工的测试来做发布,但是Windows和Android都会有一些Beta的发布，在内部很难模拟用户的使用场景和用户的环境，所以在release之后的过程中一般会抽样1％、5%、10％这样一个节奏来做验证，主要是看某些指标是否达标。
这个流程刚开始执行的时候问题特别多。
比如在这周开发完成以后，测试发现根本测试不了，有很多很多的Bug，工程师只好利用第二个研发周期去修Bug，然后又会影响第二周期的开发,这样问题越来越多,就会导致流程很难进行，然后进入恶性循环。
为了解决这个问题，首先在操作层面上一开始先用一个月的迭代来让大家适应，同时要求Master分支必须是可用的（比如某人提交了代码跑不起来，或者没有经过测试，给其他同事带来了阻碍,就会被要求请全团队喝咖啡）。
其次加强单元测试和回归测试，确保每个迭代的研发质量是可控的，后面的测试主要是回归和校验,减轻相互重叠的压力问题。
一个月的迭代跑顺了之后，再跑到两周、一周的节奏，整体来看，差不多用了半年的时间,豌豆荚就完全跑顺了这个流程,想快可以快，想慢也可以慢.
工欲善其事必先利其器，为了提升产品研发效率,豌豆荚内部开发了一款项目管理工具Wandoulabs。
作为内部的沟通工具，它主要用来做跨团队沟通，全公司所有员工都会使用。
重要的roadmaps必须在这里登记,登记了以后，一个项目需要多少设计师、需要多少marketing、每个阶段是什么样以及工程师的发布状态都可以在这里看得到。
这就是前面提到的Wandoulabs，大概逻辑如下:
不同的标记分别代表研发状态、发布状态、负责的团队及这个事情的重要级别。
对于重要的发布，豌豆荚有三个最基本的要求：
第一要获得Product／DesignReview的批准。
一个功能开发以后，无论是界面还是整个UI，如果会影响到用户的操作，或者影响到商户的收入，比如我们的广告系统或者和合作伙伴的一些策略调整，这就需要做DesignReview.DesignReview在豌豆荚里面的时间大概是每周的周一、周三和周六，每次持续1—2个小时,包括Product（Review）、Design（Review）或Business（Review）。
ProductDesign指的就是PD,主要的视觉设计师或产品设计师必须全员参加。
第二要获得EngineeringTechReview的批准.这更接近于传统上的技术设计，主要是看某个功能在工程设计上是怎么做的.做这个设计的团队和所有工程师必须全员参加，也会有一个人来host，还需要几个指标的review。
这个过程是帮助相关的工程师把设计考虑更全面,包括流量、游戏的带宽压力的需求等等.
第三要获得MarketingReview的批准，主要是看产品上需要如何引入marketing团队的配合，需不需要做一些传播,需不需要注意公关策略等等.
同时对于更小的一些Beta测试则不强制要求。
这些Review实际上是帮助整个团队、整个公司去理解当前最重要是什么，其实也是建立一个高标准的过程.
2014-06-05
现在的it项目管理和绩效考核就是扯淡,居然将一个创造性的劳动当做流水线劳动一样管理.见过哪个真正的艺术家说计划未来一周要完成多少多少任务的吗？
这也就是为什么活力往往只存在于小型团队甚至个人之中。
好的管理应该是首先要保护团队的创造性的,如果做不到，那么谢谢，还不如不要管理.
广联达（glodon）国际事业部副总经理
好久不来知乎了，简要介绍广联达的研发管理的做法，希望可以给你一些启示吧广联达研发管理使用的是IPD+敏捷的方式进行研发管理，IPD是一级层面的研发管理，多产品多项目管理,敏捷是微观层面的研发管理.详细的可以上网查找一下IPD的资料
绩效考核，形式比较多，我带团队这些年使用的绩效共采用过三种模式：
主基二元法、PBC、平衡计分卡，这三种模式分别适用于中小团队（15人以内）,中型团队（30～100左右），大团队（多部门管理）的方式.
要做好绩效考核,建立一个健康的绩效管理文化很关键,绩效并不是简单的考核使用，也肩负着人员能力提升和工作改进作用的。
我以往经常和我的主管们说，能有效和进行绩效管理是一个想成为管理者的人必须在刚刚成为管理者的时候就优先直面和解决的问题，否则以后还会在相同的问题上困扰.
什么都略懂，什么都不懂
我们的绩效考核方式主要是KPI。
KPI是层层分解的:
公司需求→部门KPI→个人KPI
所有的KPI制定都是员工和上级一同制定而成，在KPI实施的周期里，如果你有更多的想法,都可以体现在KPI中。
所以我不明白为什么很多人说绩效管理只能针对劳动制造企业。
KPI的评分分为月度和年度。
月度评分和年度评分分别作为月度奖金和年度奖金发放的依据.
以下是两个技术人员的KPI截图：
（第一个是第二个的考核上级）我们看这位员工的KPI，包括了开发、建设、日常维护及其他KPI项目.这些项目都是直接分解他的领导的。
在开发项目上,有些项目有时间限制,因此KPI的评分标准有时限的评分标准.这是上面员工的助理。
助理的活就相对简单，维护和服务职能占了多数。
如果没有绩效评价，不知道各位的公司是如何发工资?
-———————
重新回到绩效本身。
绩效是员工在岗期间行为、态度和结果的一个综合.其实所有企业都有绩效考核，只不过考核的方式五花八门而已。
有的企业喜欢流程化，有的企业老板说了算，有的企业看似没有,实际真的没有嘛？
没有的话老板怎么发工资？
大家发一样的工资么？
工资的不同，实际上就是绩效结果的不同体现。
————-—
绩效考核仅仅只适用流水线工人吗?
技术人员其实并不比流水线工人高端,大家都是替人打工的,嗨什么劲呀.说绩效考核遏制了员工的创造性是因为绩效考核的方法方式用错了。
谷歌公司也有绩效考核,可人家的创新精神照样遥遥领先。
-———-—
绩效考核会造成唯老板是从么?
是的,其实在企业干活，就从来没有什么自由独立的说法。
你对你的老板负责，你的老板对你的大老板负责.既然你的老板的考评标准是“心情和人品”,那又何妨?
人家只要能让他的上级开心就好了啊.怎么样能让上级开心？
通俗意义上的“资本家”的开心原则当然是盈利。
所以,你还操啥心？
专注互联网行业，IT服务管理体系、信息安…
简单引入PMP管理思维，对于一些需要创新的企业是个灾难.。
码农/严重拖延症患者
腾讯主要看你组长和总监看你爽不爽
交互设计师
赞同
国内好多公司太注重所谓的这些外来理论,反而忽视了真正的核心实质。
.。
我觉得国内公司逼格都高死,拿来一堆堆理论学术用语出来，其实并不能很好的应用他们，
太多形式上的东西我觉得物极必反＝－＝
旁观、思考、实践是我的乐趣
做研发个人感觉一定要有个人空间和讨论空间。
死板的报告流程制度只会浪费大量的注意力。
我见过真正有效率的研发就是产品的开发者收入与市场反应匹配，不要过于控制过程,研发的人可能10个月都在冥思苦想，但1天豁然开朗，两天就完成了项目。
，让购物变得简单快乐
卓有成效的管理是非常不容易的事情。
KPI在一些公司把员工累的半死。
我个人认为要从企业文化上下功夫。
引进一些PMP管理人员，拿一个部门先试水！
照抄别人,要想超过别人是一件不容易的事情.在另外一些方面超过腾讯、阿里还是可能的。
慢慢的
在企鹅和创业公司待过一段时间但是从未听过绩效这东西。
你的升职加薪和狗屁绩效一点关系没得，说得难听点这些天天为绩效奋斗的工程师一辈子都在被绩效奋斗。
要想钱拿得多升得快首先得让领导爽，要会吹嘘自己的工作，比如说你1天能完成的工作必须要5天完成并且让领导对你的工作认可。
工作是混出来的不是做出来了.
互联网产品
作为豌豆荚最早的一批用户，早就改用360了。
只想说一句，看看现在各种对豌豆荚的评论,踏踏实实把产品功能和用户体验弄好不行吗?
功能越来越差，各种bug导致不能用,扯淡的功夫日渐增长，有这时间好好学学360不行么
自然而然，乐而为之。
只有相对的公正，没有绝对的公平，绩效考核需要很全面的内控支撑,否则就是大杀器，被老板玩弄于股掌之间，永远如税法一样，搞你了，拿你的绩效说事,否则，一切都可以掩盖,照样飞黄腾达。
绩效考核变相的剥夺员工的时间!
夜里会饿管理就像赶羊群的汉子虽然羊群很多但只要管好领头羊其他的羊都会跟着它走
点滴积累，坚持不懈绩效考核如果单纯的寄于考核条目和文档,这样是否太生搬硬套了？
对被考核的人是一种累赘，而且达不到好的效果。
绩效考核前,需要让大家理解考核的目的，接受考核这个事情。
然后考核的时候,更主要的是需要反馈，面对面的反馈，也可以说成是绩效面谈。
由直接上级做比较好.不拘于形式，目的就一个,让成员发现自己的优势和不足,后续能够做得更好。
以前老师时不时给你分析现状、鼓励。
现在给团队成员激励，共同做好。
互联网，技术，灰豆，上班族开发人员是需要灵感和心情的,硬来可能好几天都弄不出来。
虽然很难做到绝对公平，最起码相对公平，这是绩效考核的前提和精髓，否则就是“hehe”
收到底还是看什么人执行，很的情况下就是看领导心情和人品,当然对大部分人来说也必须有个考评标准，只能说没有绝对公平的事情
眼动研究，可用性研究，互联网用户体验研究研发管理靠一帮或者一组专门的项目经理协调资源和控制进度，做（cui）排（gan）期（huo）。
绩效考核就更科（he）学（he）了,研究的业绩更不好评定你比别人多好，（真混的除外）还是看老大面前的曝光量和认可度,绩效什么的早就商量好了。
所有绩效考核的前提是工作内容能够公平合理的划分，工厂生产产品采用绩效考核是比较合适的，大公司有足够人力和资本能够承担管理成本也可以执行，小公司就算了吧.
2014—06—13
升级会员 