目录
2、我们采用的估算技术隐含的假设人和月都可以互换,错误的将进度与工作量相互混淆。
3、由于对自己的估算缺乏信心,软件经理通常不会有耐心持续的估算这项工作。
在众多的项目软件中,缺乏合理的进度安排是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。
1、首先,没有一个很有效的估算方法。
在项目安排的初期,项目管理人员大多数都会秉持一种乐观的态度:一切都将运作良好,每一项任务仅花费它所“应该”花费的时间。但在很多时候这只是一个错误的假设,毕竟项目初期的安排是在信息比较缺乏的时候做出的,带有严重的主观主义色彩。导致项目计划变更的因素有很多。在单个的任务中,“一切都将运转正常”的假设具有可实现性,因为所遇到的延迟是一个概率分布曲线,“不会延迟”具有限定的概率,所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作,或多或少包含了很多任务,某些任务间还有前后的次序,从而一切正常的概率变得非常小,甚至接近于零。
2、我们采用的估算技术隐含的假设人和月都可以互换,错误的将进度与工作量相互混淆。
第二种谬误的思考方式是:用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量很时间是可以互相替换的。 人员和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之间不需要相互的交流。比如CRUD等一些简单重复的工作。
绝大部分情况下,任务之间是需要协作的,所以我们需要考虑沟通成本。沟通所增加的负担有两部分组成:培训和相互的交流。如果使用成熟的微服务技术,那么业务培训相对于技术培训会花费较多的时间,而从需求梳理到概念设计,再到系统设计,再到编码,再到测试,这整个流程在沟通上花费的时间更多,并很快会消耗任务分解所节省下来的个人时间。这时项目管理人员会考虑添加更多的人手,但实际上有可能会延长了而不是缩短了时间进度。
对于测试人员而言, 由于系统的复杂程度不断增加,以及我们的乐观主义,每迭代一个大的版本(小版本更容易控制,所以提倡敏捷开发),通常实际出现的缺陷数量比预料的要多得多,因此,测试进度的安排常常是编程中最不合理的部分。
3、由于对自己的估算缺乏信心,软件经理通常不会有耐心持续的估算这项工作。
受限于客户的需求紧迫程度,会不断的调整任务的优先级(尤其是纯外包类的项目,公司内部平台类型项目相对变化较小),导致项目计划不断变更。
这时有两种解决方案。
(1)开发并推行生产率图表、缺陷率图表、估算规则等,而整个组织最终会从这些数据的共享上获益。
(2)或者,在基于可靠的基础的估算出现之前,项目经理需要挺直腰杆,坚持他们的估计,确信自己的经验和直觉总比从期望派生出的结果要强的多。
但是无论怎样项目经理都会疲于应对,需要极强的耐心和勇气。
4、对进度缺少跟踪和监督。
5、当意识到进度的偏移时,下意识的反应是增加人力。
项目进度严重落后的情况下,增加人手需要慎重。很多时候向进度落后的项目中增加人手,只会使进度更加落后。首先应该考虑的解决方法是
(1)重新安排进度。在新的进度中分配充分的时间(通常加班是一个选项)以确保工作能仔细、彻底完成,从而无需重新确定时间进度表,这要求项目经理有非常丰富经验的项目管理经验。
(2)消减任务。根据优先级或者重要程度调整项目计划,是一个简单且可操作性非常强的选项。
最后 ,如果项目进度严重落后是因为需求增加,任务模块变多,那么就非常需要添加响应的人手。