项目管理（一）任务分配

做自己的女王ヽ

管理一般说来，就三件事：管人，管事，还有管钱。而这三者其实又是联系起来的，比如，我们可以说：
让合适的人做合适的事，并给他合适的钱。那么，问题就转化为：怎么才算“合适”呢？



困境



有一些人的管理工作随意散漫，但他们振振有词，“管理是一门艺术”。我觉得，他们应该仔细区别一下，
错落有致和杂乱无章，简约清爽和粗枝大叶……



或许他们还信奉权谋之道，用人嘛，“打个巴掌，给个枣吃”。你在用驴呢？稍微有点想法的就会不服，凭
什么打我一巴掌？稀罕你这颗枣子呢？把爷当傻子耍？去你妈的！

利益面前谁都不傻，靠阴谋算计小心思，只会造成管理者和被管理者之间的复杂博弈。简单点说，就是勾
心斗角阳奉阴违。你以为你在玩他，他其实悄悄在玩你，搞成了宫斗权谋，一片乌烟瘴气。



我们从一个最简单的例子说起。一件功能，交给张三去完成，给他三天时间。提前完成了有奖，超时
罚钱扣工资。任务布置得清晰明了，而且赏罚分明，是不是？管理就这么简单。

凡是这么想的人，一定是没有搞过管理工作的。

中间可能出现的突发情况太多了。三天过后，任务还没有完成。你火了，问为什么？一堆的理由：任务
难度太大，工作量太多，李四不配合，理解错了你的意思，中间出现了什么突发情况……反正都不是他
的责任。他说得这么有道理，你处罚试试看？没过几天你就孤家寡人光杆司令一个。所以，最可能的
情况是，问一下原因，埋怨两句，给他擦干净屁股，然后照样稀里糊涂的过日子吧！



胸有成竹



上述管理者困境的一个重要原因，就是管理者自己都不清楚：分配下去的任务，难度有多大，工作量
有多少，可能出现的情况有哪些……自己都是一本糊涂账，怎么可能管好别人？

我们常常说管理人员要有威信。威信是怎么建立起来的？工作起来要胸有成竹，而不是稀里糊涂的把
任务布置下去之后，遇到问题一问三不知，瞎指挥穷折腾。这样次数多了，下面的人自然不服，“聪明
”点的就开始动心思糊弄了……



话是这么说，但具体到我们软件开发中的项目管理，胸有成竹就不那么容易了。



以项目预算为例，我从来没看到过一份清清爽爽的软件项目预算表。

先看报价。都是做工程，比如建筑工程，根据图纸，材料人工，一项一项的清单报价，不管多大的工
程，价格算出来都是精确到分的，比如1080732.76元；但软件开发，合同能精确到百，都不错了，
一般都是20万、 3500之类的，感觉在价格就是随口喊出来的一样。

再说工期。建筑工程，误了工期，时间稍微长一点，违约金都赔不起。软件开发，延期延期再延期，
才是常态，是吧？即使勉强交货，那都是蒙人的，里面bug一大堆，先交了货，再慢慢“维护”吧！



想来主要有两点原因：
开发工作本身是一种创造性劳动。不像流水线上的工人拧螺丝钉，或者建筑工地上的工人砌墙搬砖，
都是重复性劳动。虽然我们很多同学自嘲其工作为搬砖，但我们搬砖过来之后还是要砌成不同形状花
样的，而不是千遍一律的一堵墙。所以，很多问题，只能在开发过程中才会暴露出来，解决的难度工
作量都是一个未知数。
不断的需求变更。这个就不多说了，大家都懂的。
所以项目负责人对项目的细节没有切实的把控，只能凭着“经验”或者“想象”来大致的“估算”项目的工
作量。而事实证明，这种估算是相当不靠谱的。


切分



处理一个复杂的事物，最常用的手段，就是把他切分成一个一个简单的部分。针对项目管理而言，我
们推荐的，就是做任务切分。



这其实是一个必须得做的工作！区别只在于你是主动还是被动，是认认真真还是敷衍了事的在做。别
说是一个团队，必须得分工配合；就算是你一个开发，先做什么再做什么，你心里也得有个数吧？

只是很少有人专门花时间和精力，有意识的来做这件事。因为我们对于项目管理中“计划安排”的理解
还不够深刻。



根据我的项目实践经验，深入细致的任务切分，能够帮助我们：

真正的厘清需求。在“切”任务的过程中，以前朦朦胧胧的概念，才会一点点的清晰起来。
能够“纠错”。清晰过后，一些疏漏错误也就自然而然的暴露出来了。就应该相应的调整进度计划等。
合理的安排人手。团队中每个人的水平都是参差不齐的。任务切分之后，简单的重复性工作分配给新手，
复杂的有挑战性的给大神，大家都满意，开发成本也能随之降低。但如果没有有效切分，难的和简单的
混在一起，是区分不出来的。
对开发人员有指导作用。我用的都不是高手大牛，但他们新人也可以顺着这个路子一步一步的做下去，
至少其中一些简单的部分可以做起来，复杂的帮帮忙就行了。
总之，切分完任务，对这个项目，基本上就心中有数啦。如果说“管理艺术”，游刃有余的分配安排任务，
像庖丁解牛一样，“以无厚入有间”，游刃有余，这才能给人一种愉快的艺术享受！



精细化



我极力主张：把任务要切分到尽量小的的粒度，比如一个任务20分钟左右，最多不超过60分钟。当然，
很多同学担心这样做的成本太高，是不是项目经理一天到晚就切任务去了，不用干别的了？

这是一个值得讨论的问题。粒度越细，可控性越高；但是也要考虑成本，过犹不及。这个应该是根据项
目具体情况，灵活掌握。



这里我只分享一下我的一个变通处理实践：你也可以让开发人员自己进行任务切分，你在任务验收时
同时核查任务的难度、工作量等。（如果你需要考核的话，因为这时候代码都已经提交review了，算是
水落石出，做复核工作量其实很少了，所以开发人员一般也不会乱来）

但这里有一个小问题，就是开发人员开始可能会抵触这种做法。他们会认为切 分任务和写文档、写注释
、写日报周报一样，是无用的工作。

道理当然要讲，但最好还是事实说话。

我随你的便，但只有一个要求， 你先把你要花多少时间告诉我。他说行，比如一个功能点，他信心满满
的说，“2小时够了”。结果够个屁！哈哈，他两天都搞不出来。我就要找他说为什么了呀？东一榔头西一
棒，他怎么说得清楚？焦头烂额之后，他自己去体会。多尝试几次之后，外加他技术水平的逐步提高（
切任务不是个简单活，很考功力的），最后他也养成了习惯：敲代码之前，先切任务。其实这就是一个
理思路的过程，哪怕是纯coding，做之前思路清晰了，也能事半功倍。“磨刀不误砍柴工”，说的就是这
个道理。


应对变化



有人觉得这样做不值得。你辛辛苦苦的分任务，做计划，需求变了呢？或者出现了其他情况呢？计划是不
是就白费了？越完善详尽的计划越不可能实现……



这些倒都是经验之谈。现实确实如此，“计划永远没有变化快”！但是不是就可以证明，我们不需要计划了
呢？让我们静下心来仔细分析一下。



首先，无论如何，首先肯定要有一个计划。公司要签合同要有金额工期，项目经理要报项目安排，程序员
也要在deadline之前完成手头的工作……无论你愿不愿意，这是一个客观要求，很难逃避的东西，是不是？



那么，为什么我们很多人提起计划就头痛，特别反感计划呢？我觉得，很大一个原因是因为：计划被滥用。

比如被要求写这些日计划周计划月计划，写的时候就不情愿，感觉多此一举；更何况要是没能按计划完成，
还要被要求说为什么！太多为什么了，怎么说得完？真要说呢，又会被批评“为失败找借口”，烦死啦！所
以就做个假计划大计划空计划之类的东西敷衍一下完事……

这种做法有几个问题：

僵化的看待计划。管理者认为计划一旦指定，就一成不变的、必须丝丝入扣的完成；甚至把计划当成了监
督鞭策员工努力工作的东西。这肯定是行不通的，其实，既然是计划，就意味着它还没有被实现；需要制
定计划，就说明实现是有不确定性的。很确定性的东西，比如明天早上8点钟我要到公司上班，这种事情根
本不需要计划；下周我要去海南岛环岛游，从来没去过，可能有很多突发情况，这才需要计划！这个计划
就可能受天气、自己的身体状况等一系列的因素影响而无法百分百实现；但无论有无突发情况，我有机会
肯定比没计划强。为什么就大家自己想一想吧？
计划制定者指定不当。让能力一般的底层工作者指定计划，实在是有 些强人所难。计划不是那么好制定的，
让你制定一个攀登珠穆朗玛峰的计划靠谱么？虽然说coding是程序员的工作，但他们很多时候，编码还是
在摸着石头过 河，走一步看一步而已。所以，制定计划这种走一步看三步的工作，还是项目经理，或者
经验丰富的程序员来做更贴切一些。


所以，我们必须明白：计划制定出来，就是被破坏的。计划没能按预期执行，并不说明他们没有用。实际
情况发生了变化，计划就应该相应的调整；但这种调整应该是有序的可控的，而不是胡乱的调整。有序的
调整能够最终保证大任务的顺利完成；而无序的调整，只会把事情搞得一团糟。怎么样才能够有序？还是
要有计划！一份计划，就像一张图纸一样，出了情况，铺开图纸，圈出出相应的部分，结合周围的情况，
考虑一个妥善的解决的办法……而不是一堆人你一句我一句，天马行空，公说公有理婆说婆有理，乱哄哄的
不可开交。



任务管理系统就能够帮助我们及时迅速的应对各种变化。除了可以提供自动化的统计分析以外，更因为项
目已经被有效的切分。

如果你的计划是一个不可分割的整体，犬牙交错，牵一发而动全身的那种，那么当然，每一次改动必然都
是一次伤筋动骨的大折腾。

但通过良好组织的任务切分，改动就可以被有效的对应到相应的计划部分。这时候，每一次的改动就是一
个局部的改动， 是非常容易被重新计量评估的。比如，某次改动，会影响原任务3098-4012，原任务3876
-3879，任务量共计480分钟；改动新增任务 5678-5894，任务量共计300分钟；所以任务总量减少180分钟，
非常清晰。



结论



总之，任务的切分/分配能帮助项目管理人员深入的了解项目，并在此基础上合理的计划安排开发工作，应
对项目实施中的各种变化，是任务管理系统的基石。