我们已经习惯了用“人月”这个工作量单位来预估工期和估算成本。在软件工程中，用人月来估算，似乎很合理。因为如果用其他量来估算，要么无法量度，要么适用面太窄。比如你告诉客户“做完这个活需要一年”，人家很可能想“你都没告诉我几个人做，就出来一年的工期了”，显然让别人觉得你是一副很业余的样子，不合适。但是，用人月来润色谈话，那就不一样了，对着别人张嘴说出来“我初步估计要完成这个工作需要20人月”，客户第一次听到基本不会懂，就显得自己很专业、很不同。
但以人月为工期的计量单位，是非常危险的一件事情，是一个带有欺骗性的神话。它在无时无刻不在暗示着你，时间和投入的人员数量是成正比的，这简直不能用糟糕来形容。领导嘴中说出的每一个带有人月的词，都可能准确撩到程序员的痛点上。
大家正常的思维都是这样的，举个栗子：老汉我今年种了10亩小麦，雇一个人收麦子，一天收1亩，需要10天；那么我干脆雇佣10个人，一天就收完了，真好。根据这个人类淬炼了几千年的经验，软件工程肯定也是这样，老总我今年承包了一个项目共需要10人月干完，雇一个程序员，十个月完成；那么干脆我雇佣10个人，一个月就完成了，真香。这个例子中，如果一个项目工作分成的10份，相互之间不需要协助和从属，那么这么想完全没毛病。遗憾的是，这种事越来越难以发生了。
现在的项目，已经严重依赖于配合和沟通；产品等着销售、设计等着产品需求、研发等着产品需求和设计、测试等着研发……，而且研发和产品还有很多功课要撕；测试和研发还有很多疑点要争；相安无事，各干各的，几乎不存在的。
软件开发的本质是一项精密合作的系统工作，拥有错综复杂的关系，沟通、交流的工作量十分之大，大到轻易能消耗掉技能熟练度所节省下来的个人时间。对于增加的人手，首先，你要先让新加入的人了解和熟悉已经做了的工作，每进来一个，都要重新进行一遍这个过程。然后，本来的一个任务被拆成了多个，协作的工作量以n(n-1)/2的速度递增（就是渠道的个数）。也就是说，一对一交流的情况下，三个人的工作量是两个人的三倍，四个人的是两个人的六倍。这就产生了这样的场景：某天某个程序员幽怨的告诉你“还不如我一个人干这个活快呢”。
更何况，很多人对人月的概念，就是知道了这个概念，仅此而已。至于多一点深入的思考，也是太费脑子的事情，比如一人月等于多少人天？为什么要去想它呢。于是产生了这样的场景：“给你加人了，怎么还这么慢”，“怎么又要人”……
更不要提关键路径，活动时间，资源平滑；我们知道的赶工的方式永远都只有一种——加班！
閱讀更多 靜靜水流 的文章
