开发任务分配的双向选择(转)

问题

在InfoQ 的这份报告 中，两个失败案例都明显在 'daily' scrum 和任务分配 上犯了常见的错误。

一种情况是，管理 者“热心”过度，天天盯着任务分配，结果让软件开发工作变得索然无味，甚至令人恶心。

每个员工都要在早上固定时间开Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。这个把弹性工作制直接给破坏了，引起很多人反感；另一点就是很多人认为这样的Daily Report太频繁太低效，而且还有压榨员工的嫌疑。

第二种情况是，管理者热度不够，恣意放羊，结果让项目开发偏离正轨，一撒不可收拾。

在 第一次使用ScrumWorks的时候，好歹Product Owner还能来设置优先级，我们估算时间，最后决定哪些故事放到下一个Sprint里面。到后来就只要是人，就能往Scrumworks上扔任务，也不 知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个Sprint里面去。

以上两种情况，恰好形成两个极端，名义上号称敏捷，实则背离了敏捷的基本原则。由外行“专家”来领导敏捷实施，必然是这种结果。

当今的西式敏捷方法非常强调员工的自愿工作，主动性不受干扰，同时提倡团队文化和集体主义精神（whole-team）。那么，咱本土的中式敏捷 又是如何做的呢？以下仅举一例。

具体做法

作为管理者和架构师，我把周任务根据难易程度，分别打上不同的分值（比方 1-10 分），把任务表贴在开发现场 open space 的白板上，在开周例会的时候，由团队成员自主选择。

这些每周的开发任务是由大家 brainstorming 共同讨论出来的，当然主要部分由架构师建议，最后由管理者综合大家的意见定夺。

为了防止出现任务分配上的不均、不合理情况，在员工自主选择的基础上，我们还设定了一些指定任务，由管理者根据员工的实际情况和项目需要分配给员工。

因而这实际上是一种员工任务分配的“双向选择”。

考核

员工每月完成任务的数量和质量情况，是绩效 考核的基础和主要指标。

有了员工任务的自主选择，月末考核就方便多了，有了更公平、公开和客观的依据。我们把员工每月完成的有效任务分值累加起来，就是他完成的月总工作量。这一结果是完全公开、透明的，谁完成的任务数多，质量好，谁的总分就高。

为了在任务考核中反映质量要素，计算有效任务分值，我们加上了质量因子。设原任务分值为 5 分，如果完成得好，达到了质量要求，那么质量因子为 1，有效任务分还是 5 分；如果完成效果不好，质量因子只有 0.7，那么有效任务就只有 3.5 分。

管 理者还可以根据需要，添加其他的权重因子和灵活措施。比方，为了鼓励员工之间的紧密合作，互帮互助，我们还约定，任务分值可以赠送，别人帮助你完成工作， 你可以把相应的分值送给他，记在他名下。另外，根据团队文化建设的需要，我们还设立了一些额外的奖励分。在实践中，赠送分、奖励分应用得也较为普遍。

当然，最重要的一点，这整套任务分配和考核办法是由管理者提议，所有团队成员大家共同协商讨论，认为公平、合理之后，一致通过和支持的，这样就有了良好的群众基础，并且在实施中得到了不断改进和完善。

效果

您可能很关心我们实施的效果怎么样，回答是：出奇的好！

有了这样一种机制，必然会在员工中间形成一种攀比，比谁完成的任务分值高，而这种攀比恰恰符合团队的整体利益，也是管理者所乐见的。

与其他采取传统措施的团队相比，张恂团队的同事们参加计划会议的热情非常高，每次都是抢着要任务，而且往往勇于挑战分值较高的任务，每个人都生怕自己的任务不饱和，影响了个人月底考核的总成绩（间接地影响 bonus）。

关键一点，我们把原本看似枯燥乏味的软件开发工作，变成了一种近似体育竞赛的团体合作游戏，结果导致每个人在工作时都热情饱满，兴致勃勃，这也算是实施此方法后的一种意外收获。

显然，这与过去由经理们主观生硬地（尤其是根据 WBS）设计任务，向员工指派任务，而月末考核客观依据又不足的局面大不相同，可以说是一种彻底的转变。

我想这种措施的成功，由项目管理 者绞尽脑汁生硬地把任务指派给员工，到员工积极地想任务、要任务、抢任务（这一现象真的就发生在张恂的团队中），其实也是一种逆向思维驱使下，管理方法创新的成功。