标签：开发 简单 决策 会议 根据 积极性 避免 nbsp 系统
根据前面学习到的知识，红细胞的目标管理体系如何打造，四代已经有了基本的思路了，三个部分：
第一部分：目标设定
经典OKRs的做法，我们前面已经讨论了，非常的科学，但却不能拿到红细胞来直接使用，因为目前不适用。
不过OKR有一点四代是非常认可的，那就是有一部分目标来自于个人。
对于红细胞来说，软件的很多功能都已经积压在功能列表中很多年了，需求已经很多，所以目标主要来自这个部分，但不是全部，四代还是要保留来自个人的目标。之所以在这种的情况下还这么做，是因为四代想让团队先适应这种模式，并养成参与到决策中来的习惯。对于“互联网+”时代的团队，个人的创造力是毋庸置疑的，任何压抑个人创造力的做法都是极其愚蠢的。
对于目标组成的占比，四代综合考虑后，确定的比例是：三七开，三成目标来自个人，七成来自公司和团队，是不是合理四代不知道，不过这个事总得有个开始，这样才能去试探更加合适的值，而且在四代的计划中，这个值也必然会随着团队和项目的进化不断调整。
第二部分：360反馈，考核内容
对于360反馈考核，四代之前的公司都是秘密的，他都不知道公司的标准是什么，所以就算考核下来，四代也只是得到了一个单薄的分数，虽然他心里对自己也有一个数，但是他不知道该怎么做。确实，程序猿的考核不能像工厂那样定量的给出一些数字，但是还是可以定性描述的。有了定性的描述，团队就会知道应该怎么去努力。
综合各种设计绩效考核的思路，四代觉得用“3W2H”来解决它最为贴切。
第一个W - Why
这个W要回答为什么要绩效考核，这个不用说了吧，主要是为团队的努力指明方向，辅助的作用是核定一定阶段内的努力成果。
第二个W - What
这个W要回答绩效考核要考核的内容，这个内容就是团队的努力方向的细节。不是有一句话是这么说的吗：“如果方向错了，那么跑的越快，就垮的越快”，所以这个“W”很重要。
大家知道，对于员工来说，公司考核什么，他们就会表现什么。正因为知道这一点，很多聪明的朋友对考核的细节秘而不宣，或者是模棱两可。这么做，一方面，觉得可以激发员工无限的创造力，因为没有标准，所以就没有限制；另一方面，只需要按照自己主观的判断操作一下就可以了，非常省事，反正别人又不知道考核的到底是什么，这个时候随便找个高大上的理由，性格上的缺点解释一下就可以了，怎么都不会错。
实际情况是，一旦如此实施，很多人就漫无目标，流于混日子了，或者是他自己想努力，却不知道该怎么做。
四代认为，一般组织，就像现在四代的公司，需要的做法可能是满足：有限的约束，无限的可能。有限的约束来保证最低的输出，无限的可能来培养创造的可能性。有时候最优的方案就是避免出现极小值的方案。
考核中还有一件非常常见事就是，管理者会从上帝的角度出发，希望把每个人都当做圣人来培养，对于这种做法，四代一直不怎么认同。
在四代看来，考核不是要打造“三好学生”，“全能战士”。在“互联网+”时代，团队需要的是“互补”和“特长”。
比如有的人技术很强，但是沟通和展示能力不是那么好，有的人特别擅长规划与安排，但是技术能力又稍微偏弱，有的人技术能力与管理能力都不错，但是没有特别亮眼的技能。所有这些人都有可能出现在同一个团队中，如何兼容闭包，最大的发挥每一类人的长处，尽可能的避开每一个人的短板，也是一个绩效考核系统设计要考虑的重要方面。
所以考核的内容一方面要求覆盖所有的可能，但是又不是要求所有人都必须要做到。
综合上面的两点，四代根据按照如下步骤选择了考核的内容：
首先，四代从团队目前的表现中收集所有的备选项，然后再加上四代参考的那些公司对于“优秀”所定义的行为，这样经过整理，四代得到了一个的可供讨论的提案。
其次，四代组织大家一起头脑风暴，补充更多大家认为好的行为。
再次，合并整理分类，得到一份大家同意的版本。得到大家的认同，推进就不会有太大问题。
最后，回顾全部考核内容，宣布开始实施，制定每年修订的计划。
最终的考核的内容分四大类，每大类有数个权重不等的加分项：
1. 项目研发
这一类包括Release发布是否成功，功能质量、代码质量、违反代码规范次数、重要重构次数、违反研发流程次数，引入提高效率的新技术和工具几个主要的加分项。
2. 团队合作
这一类包括帮助别人解决问题次数、接受别人帮助次数、主动性、积极性、跨团队服务态度几个主要的加分项。
3. 学习分享
这一类包括分享的工具、资料和知识的数量，参与部门分享的次数，学习的内容，需要掌握的模块的熟练程度增加情况几个主要的加分项。
4. 额外的情况
这一类指的是不属于上述三类、但是有益于公司或团队的其他事例。
在后面公司引入价值观考核之后，第二类和第三类全部合并到价值观考核中去了。
第三个W - When
这个W要回答什么时候绩效考核。
这个大多数公司都是一年一次，或者是一年两次，四代觉得针对红细胞的现状，这样是不够的，因为反馈周期太长。
绩效考核主要的作用就指明方向和核定努力成果，如果时间拖的太长，那么容易被忽略，或者遗忘。
但是四代也清楚，考核是有成本的，在下面我们会看到执行考核的成本，那也是很多公司一年只做一次的原因，实在是劳民伤财哈。
综合考虑了这些因素和成本，四代把考核分成了两类：
一类详细一点，是Release考核，每个Release结束后的第一周开始考核，考核内容就是上面的那些内容。
另一类简单一点，是年中或年终考核，这个取决于公司执行的时间，这个主要是汇总时间段内的各次Release考核的成绩即可，非常简单。
第一个H - How to do
这个H要回答考核的形式是怎么样的。
由于年终考评是以Release考评为依据的，所以如何进行Release考评就成了关键的一步。
在这个方面，四代全盘接受了360反馈的做法，那句广告词是怎么说来的，“我们只看事实，不讲道理”。
Release考评分两步走：自评和他评，内容是举事实，也就是列举在当前考评的Release阶段发生的任何的事件，正面或反面的。
自评是被考评员工列举自己的事例，他评则是被考评员工直属经理（也就是四代）、被考评员工自愿指定的团队内2个伙伴和团队外的2个伙伴，共5个人为被考评员工列举事例。
当四代收到所有事例后，再根据事例所属的考评内容加分项来给被考评员工加分，最终根据总分给员工划定一个等级，这就是Release考评的全过程。
第二个H - How to improve
这个H要回答对于反馈的处理，以及整个流程演化的过程。
经过上面三步，考核的内容和方式就确定了，那么是不是每次这么执行一下就可以了呢？很显然不是这么简单。
就像前面说的那样，前面确定的那些内容和形式只不过是一个并不知道是否正确的种子，也仅仅是个起点而已，能否让绩效考核这个小不点随着团队的发展成长为一棵参天大树，还需要不断的演化和调整。
在每个Release结束，四代不仅会组织绩效考核，还有一件事也是四代无论如何都不会掉以轻心的，这就是团队对于考核流程本身的反馈和建议，包括考核内容和形式在内一切考核相关的事情。
四代会提前发出这些内容，然后组织一次会议专门讨论这个议题。四代对所有反馈的内容无比重视，因为四代知道，任何流程要发展壮大都离不开每个人的参与与反馈。任何东西一旦停止演化和调整，就表明它已经死了。四代收集到反馈以后，会在下个Release研发的过程中整理并调整考评流程，然后大家一起讨论并在Release结束时立即开始执行。
所谓的敏捷开发流程，也就是快速的开发，快速的测试，快速的发布，快速的反馈，以及快速的调整吧，环环相扣，缺一不可。
而在这个快速迭代的过程中，完成一切的粘合剂，就是沟通。沟通是一个团队最重要的事，在考评流程也非常正确。
第三部分：沟通管理
对于沟通在团队中的作用，无比重要，生死攸关，无论怎么强调都不为过，这个前面已经讨论过了。
在团队中，四代采用了“实时沟通”与“一对一沟通”，它们一正一辅相结合，可以解决目标管理和绩效考核中大部分的问题。
“实时沟通”一般发生在事件发生后的第一时间，不管是安抚、解决问题，还是鼓励、奖励，第一时间最有效，最高效。
“一对一沟通”每个人每月一次，稍微正式一点，用于解决那种不是很紧急，或者平时不太好开口的问题。
无时不在的沟通、鼓励、培训和陪练，使得敏捷开发的流程顺利的向前运作，这也使得目标管理和绩效考核这个系统随着团队的不断磨合而不断茁壮成长。
标签：开发 简单 决策 会议 根据 积极性 避免 nbsp 系统
原文地址：https://www.cnblogs.com/dxy1982/p/13423132.html
