扫码阅读

手机扫码阅读

软件项目进度管理悖论：九个女人一个月内也生不出一个孩子

375 2023-07-20

↑ 点击上方“亮哥圆桌派”关注我们

感谢阅读，本文共3609字，预计阅读时间大约需要9分钟。

如您无法一次性看完，可以点击上方蓝字“亮哥圆桌派”关注我们，也可以点击右上角的●●●收藏此文章。

为了方便您的阅读提前列出本文的章节：

1.没有估算

2.人月神话

3.没有耐心

4.缺少跟踪监督

5.人多力量小

“9个女人一个月内也生不出1个孩子” ，这是弗雷德里克·布鲁克斯在《人月神话》中写的的一句话。

沃伦巴菲特也说过类似的话，并且他还说过：“无论你多有天分，也不论你多么努力，有些事情就是需要时间。”

发现规律，并且利用好规律，才是成事的基础。

所以，马斯克推崇的“第一性原理”才能帮助他改变世界。

就像《人月神话》中说的那样，在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，没有之一，甚至很多时候，比其他所有因素加起来的影响还要大，特别是在软件项目开发当中。

为什么会这样呢？

为什么这这种情况会如此普遍？

01

没有估算

首先就是我们对于估算技术缺乏有效的研究，或者更加准确的来说，我们在很多时候，可能就从来就没有估算准确过。

为什么这么说，我们都知道估算常用的方法有哪些？

没错，就是类比估算法、参数估算法、三点估算法和自上而下估算法。

我们最常用也是最准确的自上而下估算法，也就是通过从下到上逐层汇总 WBS 组成部分的估算而得到项目估算。

光看到这个名称就知道这个估算工作既复杂又繁琐，而且还要基于范围管理当中分解合理的WBS。

而WBS是基于什么？是基于范围说明书。而范围说明书又预计项目需求文件，而项目需求文件又基于项目章程、合同、相关方的期望等等。

是不是感觉到非常复杂，这个逻辑关系太长了，但凡中间有那一点出了错，那后面的偏差就会越来越大，可以说是差之毫厘，谬以千里。

项目范围历来就是项目经理碰到的第一个也是一个最大的拦路虎，项目进度计划的准确与否就与项目范围息息相关。

所以说，这个就是造成进度安排缺乏合理性，造成项目滞后的第一个原因。

02

人月神话

其次，我们采用的估算技术通常都是假设人是通用的，在软件当中就是简单的把人和月当做可以互换的单位，这样就极易的造成进度与工作量相互混淆。

我们通常用来制定项目进度计划时常用的关键路径法，就是在不考虑资源限制的前提下的，这个当然能得出理论上的最短路径，也就是项目最快的完成时间。

但是，软件开发他不是简单的体力劳动，他不是简单的工作堆叠。

他是拥有复杂逻辑的系统性的工作，而其中的人是最重要也是最核心的因素，特别是随着技术的发展，分工越来越细，岗位要求也越来越高。

现实情况是，很少有人能够同时具备两个细分领域的专业知识并且把事情做好。

而我们估算的时候，通常就是把人月或是人天简单的等同起来。

打个比方，比如我们要开发一个WMS（仓库管理软件），经过确定范围、WBS分解、定义活动、排列活动顺序后，就开始估算时间了，一般情况下会怎么去估算呢？

比如需求分析张三去做需要1个月，设计李四去做需要1个月，开发王五赵六去需要需要2个月，测试孙七周八去做需要1个月，那么我这个项目就是需要8个人月，最快完成时间是5个月。

那么在很多项目经理眼里，这个开发需要8个人月，那么我投入16个人，是不是不到3个月就能完了？或者我让做开发和测试也投入到需求分析和设计工作当中去，是不是就能压缩需求分析和设计的时间了？

这种想法在软件开发领域看上去似乎极度可笑，这根本就是无稽之谈。

但是请不要笑，这种事情在软件项目当中每时每刻都在发生着！

在我十几年的软件项目生涯过程当中，几乎就没有中断过。

包括我现在所在的组织也在不停的犯这种错误。

项目经理或者发起人，甚至利益相关方，从来就没有考虑过开发人员根本就不具备设计的技能？或者说他们其实知道，只不过他们选择忽视，当做不知道，只想逼着项目团队越快交付越好？

除了没有考虑的团队成员的专业技能之外，我们在估算时经常会犯的第二个错误就是忽略沟通的时间和成本。

一旦某项工作被分解且需要相互协作，那么必然就会需要沟通交流，这是不可能避免的事情，只要还是人来承担这些工作。

人数和时间的简单互换仅仅适用在工地搬砖或者田里割稻子的情况下，这些极其简单的工作能够被分解且人们之间不需要交流沟通。但是这在系统性的软件开发项目当中几乎不能。

而且，当任务因为逻辑上的先后顺序的限制不能分解或者并行是，增加人手对于进度没有任何帮助。就像每一位母亲，孕育一个生命都需要10个月。无论如何，你都改变不了这个时间进程。

所以，我们就必须要把沟通的工作量和时间加入到我们的估算当中，而沟通又分为两部分。

第一部分就是培训，每个成员都需要进行技术、项目目标、总体计划以及工作计划的培训，每加入一位成员，都必须要重复这项工作，且无法避免。

第二部分就是相互之间的交流，我们知道交流沟通的通道就是成员人数来计算的，具体公式是n（n-1）/2，也就是说，3个人的沟通的工作量是2个人的3倍，4个人是2个人的6倍。往往增加人手以后带来分担任务的帮助被所增加的沟通工作量完全抵消，甚至还会产生很大的负作用。

所以，增加更多的人手，实际上是延长了而不是缩短了时间进度。

03

没有耐心

第三，软件项目经理通常不会有耐心的自下而上，持续地有耐心的进行估算这项工作，越没有耐心，估算出来的持续时间以及以此为基础的进度计划就会越不准确，越不准确就对自己的估算越缺乏信心，越缺乏信心就越没有耐心去估算，这就是是一个恶性循环。

事实上，项目经理的这种缺乏耐心，很大程度不是来自项目经理的不专业。

大部分的时候是来自发起人或者关键相关方也就是甲方的无休止的催促和不合理的要求。

就像去餐厅吃饭，客人要求两分钟内吃到一个煎蛋，要不然就要去别的餐厅了，厨师表示无法在两分钟之内完成一个煎蛋。

但是老板不仅收了客人的钱，还亲自来厨房催促厨师。

这时候厨师怎么办，没有办法，他只能选择把火开开到最大，去做一件完全超出他的经验和把握的事情，但是结果往往就是这个蛋一面已经焦了，而另一面却还是生的。

结果客人不仅没有在两分钟之内吃到煎蛋，甚至还浪费了很多成本。

就像项目经理一样，往往会为了满足甲方的期望和发起人的要求，计划了不合理的进度安排。

这不能说软件项目经理缺乏勇气和坚定，这只能说是现实的情况和软件项目经理缺乏足够的方法、技能、策略去制定更优的进度计划。

或者，在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持自己的估计，确信自己的经验和直觉总比其他非专业人士从各自利益角度出发而派生出来的结果要强

04

缺少跟踪和监督

第四，对进度缺少跟踪和监督。

我们都知道在其他工程领域中，有非常完整的质量保证体系和跟踪体系，比如汽车制造、建筑业等，而在软件项目当中，质量是非常容易被忽略的一个因素，很多人认为软件不像制造汽车，建一栋那楼那样，错了就不能改了，总不能把楼拆了重新建吧，所以中间会设置很多个检查点，由专门的人员进行检查和监督，甚至还有第三方的监理公司。

而在软件开发项目当中，常见的现象就是在开发阶段，配置那么一两个测试人员而已，甚至很多时候，连专职的测试人员都没有。

因为大家普遍的概念就是：反正是软件吗，不就是几行代码，发现不对了，随时可以改嘛。

问题就是软件项目当中，关于质量并不是由一个测试人员就能够保证，这是一整个体系，具体内存可我之前发布文章中的“质量内建七步法”。