《敏捷开发绩效管理之1-11.doc》由会员分享，可在线阅读，更多相关《敏捷开发绩效管理之1-11.doc（29页珍藏版）》请在金锄头文库上搜索。
1、敏捷开发绩效管理之一：序言及“敏捷开发是否考核个人”（绩效考核）“敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C+绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理方法是有原因的：更高的交付保障，更高的生产率，更高的质量这和人们选择C+（而不是C）的原因还是很接近的：都是为了更高的绩效。在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发中如何做绩效管理”，而是“如何利用敏捷开发提高绩效”。何为绩效管理绩效管理常常被片面理解为绩效考核，即如何确定个人的绩效，如何提工资和发奖金的问题。实际上绩效管理还包含制定绩效目标，制定绩效计划，制定配套的制度推动绩效
2、等等，当然也包括最后的绩效考核，以最终达到绩效持续提升的目的。上述内容在本系列中都有考虑，并根据笔者以往的经验和经历给出一些实际的案例供研讨使用。 从一个经典问题看绩效管理的出发点绩效管理不是敏捷开发的要求如果能理解敏捷开发也不是瀑布模型的要求，敏捷开发爱好者们或许就会释然了绩效管理是企业管理的要求，是企业为了持续提升自己的绩效而采取的措施。从这个角度我们来看一个由来已久的问题：“敏捷开发是否考核个人？”很多人会脱口而出：“敏捷开发不考核个人。”但是如果再问“企业管理要求必须考核个人怎么办？毕竟工资和奖金不是发到团队总账户上的”估计再下去的回答，就只能说是闪烁其辞了。其实这也是一个伪命题，所以
3、才导致很难回答。下面一点点分析。企业绩效管理的目的不是为了考核个人，而是为了提升企业绩效，所以尝试考核个人的企业实际上在“利用考核个人提升企业绩效”（尽管提升个人绩效会提升企业绩效，但勿入此牛角，因为前面有个尖）。因此这个问题从原始出发点来看，应该是：“企业是否应该通过考核个人来提升绩效？”，那么答案就是：“敏捷开发有比考核个人更能提升绩效的方法”。不是因为用了敏捷开发就不能考核个人，而是选择了敏捷开发，就意味着已经选择了比考核个人更有效的提升绩效的方法，因此没有必要让企业管理和敏捷开发较劲，它们打不起来的。不过这个或者这些更有效的方法是什么呢？这就是本系列博文的主要内容。本系列博文将较多涉及
4、团队级别的绩效管理，内容包括团队管理的策略，个体管理，团队的外部目标设定，如何分解到个人，不同团队绩效管理的差异，非物质激励等。另外一个高级话题则是产品级别的绩效管理，包括产品发布计划，产品版本计划，产品线管理，产品负责人及产品负责人团队，不同产品类型的搭配等等。但这个话题以另外一个主线组织会更顺畅：敏捷开发产品管理，因此会形成另外一个系列，但其核心内容仍是“如何通过敏捷开发管理产品提高绩效”，如果您觉得本系列所涉及的范围太窄，敬请关注 http:/ 对团队管理的启示团队也无时不处于众多“病菌”的围困之中，其中一个病菌似乎是“个体懒惰”，而对症下的药自然就是“考核个体”。很可惜，这个病菌不是致
5、命菌，看下面几个问题就知道了：“个体差异主要来自于哪里？”懒惰是一个方面，能力是另外一个方面。能力相同的人中，最懒的和最勤奋的程序员的工作产出相差多少？估计能相差30%就算不错了。那么同是懒惰或勤奋的人，能力最差的和最强的程序员工作产出相差多少？10倍！所以，这里有一个大得多的病菌。“最近M公司和N公司业绩下滑了50%，原因何在？”因为大家变懒一倍？或者能力下降50%？显然不是，他们的产品管理出了问题。这个病菌大得致命。那为什么多数软件公司都简单地通过考核个人来提升绩效呢？因为那样虽然无效，但是却简单。其实以往的很多处理策略，都有这个倾向，比如：需求变更频繁，客户说不清楚需求，工期紧，人员流动
6、对每件事情单个而言，似乎都有几种“青霉素”一针见效：需求变更频繁？就走需求变更流程，统计变更数量，向客户递交变更工作量；客户说不清楚需求嘛？我们写需求让他们签字，需求不签字不开工，签了字就不准变更了；工期紧？加人加班！人员流动？多写文档，不怕流动等等不一而足。然而到用的时候就会知道：几乎所有这些青霉素都导致过敏！敏捷开发的“不考核个体”的思路，其实和中医理论很相近：尝试打造一个能自组织自更新的团队，来消除各种问题，而不是就问题论问题地处理。自组织团队何为自组织团队？“领导放权了，让我们管自己，自己估算，自己领取任务，所以我们现在是自组织团队。”这个认识太浅。不是简单地去掉领导和流程后就能剩下一
7、个“自组织团队”，这样得到的多半是一个无组织团队否则这也太简单了，我们的先人和领导们简直是傻子。事实是：自组织团队，是一个依靠团队的自组织能力，自我管理自我更新，消除各种有害因素，来达到提升绩效的团队。仔细分析一下，导致团队或公司绩效差的有害因素有很多：团队级别的也就是本系列希望讨论的包括（大致由小至大）：个体懒惰个体能力差个体懒惰导致团队懒惰个体能力差导致整个产品的质量差/进度慢如果领导放权了，我们自己估算，自己领取任务，但这些有害因素仍然在，那么我们就不是一个自组织团队。我们只是一个生病了不打针不吃药的病人而已。本文提到了敏捷开发对于提升绩效的主要机制：不是依靠一个有强大控制能力的领导，或
8、一个固定的流程，而是一种能自我适应和改进的机制，进而让团队进入自组织状态，以自己的方法解决问题。下一章节将会提到用于取代“个体考核”来激励个体的敏捷因素：同行压力。附：导致团队或公司绩效差的有害因素产品级别的包括（大致由小至大）：功能定义错误产品版本定义错误产品概念/用户群定位错误产品线组合错误这些将在敏捷开发产品管理的系列中涉及，敬请关注（尚未开发，作者2011-08-21注）。敏捷开发绩效管理之三：个体动力之源同行压力（松结对编程，师徒制度，跨职能团队，绩效考核）如果有10个程序员，笔者相信至少有9个是勤奋的。但是如果有一个10人的程序员团队，其中1个人不是勤奋的，而且仍然拿到与其他人完全
9、相同的报酬大家猜这个团队会以90%的生产率运行，还是更低的生产率？不管大家信不信，我是相信后者的。这个是敏捷开发中对个体管理的出发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要打造一个共进退的团队。本文的部分内容在之前的若干博文中提到过，因符合本系列的内容，在此处从另外一个角度加以说明。 领导压力领导压力指那种直接由领导监督产生的压力，在“每个毛孔都流着血和肮脏的东西”的时代或企业非常普遍。特征表现为：领导深度过问过程而不只是结果，领导现场监督（在计算机时代，则有人发明了一种软件可让领导直接监控员工屏幕）等等。领导压力的问题在于：领导很难无处不在无时不在；领导很可能是外行；领导就算不是
10、外行，对单个任务而言，了解程度也一般低于任务承担者。领导压力一般是面向个体的，因为团队不会帮助领导管理个体，相反其整体上处于帮助个体而疏远领导的状态。如果你所在的企业越来越关注大家的考勤，已经在办公室安装了摄像头，正在调研一款屏幕监控软件那么，代打卡现象一定很普遍，坐在电脑前什么也不做的人一定很多，定期切换屏幕的习惯正在大家中间养成办公室是一个团队合力解决问题的场所，而不是内部博弈的场所，因此领导压力是一个不明智的选择。同行压力同行压力是一种由员工管理员工的方法，因而解决了时间、空间、知识差异的问题。不过这种管理不是通过授权某人管理另外某人，而是通过为团队指明一个共同利益，从而使其在获取共同利
11、益的时候互相管理。典型的同行管理行为发生在敏捷开发中的“（每月）计划会议”和“（每日）站立会议”。在计划会议中，团队在确认谁负责哪个任务之前，先共同估算每个任务的预计工时，之后才自由领取或指派负责人；而在站立会议中，任务的负责人则报告进展情况，如果和计划有大的偏差，需要说明遇到的困难，以便大家进行帮助。其中所使用的共同估计和共同跟踪是实施成功的关键活动。同行压力的外在条件不过有时一些应用敏捷开发很久的开发团队并没有真实感觉到“同行压力”的作用，原因是同行压力的实现需要一些先决条件来支持。1. 跨职能团队如果分工过于细化，技术壁垒太高，很难展开共同估计。有些团队本身是跨职能团队（如10个都是开发
12、人员），但却往往因为过度进行模块分工而导致工作无法胡同。跨职能团队底线是：任何任务至少有两个人可以完成。2. 先估计后分配原因显而易见：若任务已经分配，多数“无关人员”的兴趣和注意力将大大降低。3. 匿名估计即使是一个跨职能团队，如果第一个人首先说出估计结果时，其他人可能因为各种心理问题而导致无法客观地表达自己的意见，尤其当第一个人是最强或最弱一员的时候。宽带Delphi和估算扑克是两种常见的匿名估算方法，其中后者因为简单快捷在敏捷开发中广为使用。4. 挑战和优化估计为了防止计划会变成一个无聊的监督行为，在匿名估计中数值相差较大的组员要进行“挑战（Challege）”，寻求最优化的估计。之所以称之为挑战，是因为团队不能简单地进行求均值、投票，而是大家分别说出理由（一般估计最低的先说），尝试确认是否有可重用的组件、额外的测试要求等诸多可能影响估计结果的因素，重新投票直至结果接近。优化估计的过程借助团队的知识和智慧澄清了很多个体似是而非的猜测，结果不但为大家所接受，也更客观。5. 共同跟踪共同估计是共同跟踪的前提。只有这样，在跟踪时（
