经典软件工程著作《人月神话》经典语录摘抄和笔记

1、一切都将运作良好,每项任务仅花费它所“应该”花费的时间

 

        我常想,每个人都有良好的希望,或者说有梦想,但是梦想归梦想,现实归现实。脚踏实地,认清现实,是做好任何事情的基本要求。

 

2、用“人月”来衡量一项工作的规模,是一个危险和带有欺骗性的神话。

 

       想来惭愧,之前拿微软的project做工作量评估,可不都是用人月来报告工作量的?可是想想,在一个公司、一个团队,A的一个人月和B的一个人月是等同的吗?再有,一个人做四个星期,和4个人做一个星期,又怎么能等同呢?之所以Brooks博士说“带有欺骗性”就是从具体的工作时间安排中提取工作量的“人月”数时,实际上忽略了其它重要信息,如果略去这些,仅看“人月”,可能会受到蒙蔽,被欺骗。

     

       还有一个领导意愿的问题,领导当然希望能够按照预期的人月数来开展工作,一是可以根据需要,通过增加人手提高速度(这个问题后续再细说);二是与不同的人之间可以呼唤(忽略了人员个体的差异)。从哪个角度来看,这样当然都很好很理想,但又是不现实的,所以叫“神话”。

 

3、在落后的项目中增加人手,只会使进度更加落后。

 

我认为,加上前后的语境,这句话应该这么理解:“(试图简单的通过)在落后的项目中增加人手的方法(来追赶进度),(通常反而)只会使进度更加落后”。这句话,就是第2条的一个补充。

 

原因很简单,就是临时加入人,培训和沟通需要代价;当然,某些特殊的项目,无需培训,加入的人又超强,自然是另外一回事。之所以领导会有向落后项目增加人手的打算,也是因为认为“人月”中,人和月可以互换,3个人5个月等同与5个人3个月。

 

所以最好是在一开始,对工作的量进行仔细的评估(包括认真分析隐形需求和额外工作量等),对工作量有清晰的认识,对工作时间,取得相关人等的同意,来开展工作。

 

当然,如果一定要提高进度,除了增加人手外又没有别的方法,那么晚加不如早加,虽然不能达到预期追赶和提高进度的目标,长远来看,也会比不加人好,另外,总比项目里中途有成员被调离要好多了吧!

 

4、在系统设计中,概念完整性应该是最重要的考虑因素,为了反映一系列连贯的设计思路,宁可舍弃一些不规则的改进和特性,也不提倡独立和无法整合的系统,哪怕它们包含了许多很好的设计。概念完整性的缺乏,将导致系统开发和修改上付出更昂贵的代价。

 

这里我的体会,就是产品和项目不能变成大杂烩。萝卜白菜、牛羊鱼肉都在其中。一道菜是水煮鱼,就别放牛肉在里边。产品经理们,请慎之慎之!

 

 

 

 5、管理人员要参加技术课程,高级技术人员要进行管理培训。项目目标必须在高级人员整体中得到共享。只要管理人员和技术人员的天赋许可,老板必须对他们的能力培养给予极大的关注,使管理和技术人才具有互换性。

 

我的理解:

管理人员如果不懂技术,那么对工作量评估、可行性分析都会带来极大的不便,没有威信和个人魅力使团队有很强的凝聚力和战斗力,和技术人员的沟通也会不是很畅通;

技术人员不懂管理,就不能从整体上考虑问题,因为对高级技术人员(例如架构师)来讲,技术问题也有很大一部的是人的问题,需要把技术和设计交给后面的环节来进行后续的工作,评价其它环节人的工作,能否做好这些,有没有良好的管理意识,能否顺畅沟通是关键。

 

6、系统软件开发是减少混乱度(减少熵)的过程,因此,它本身是处于亚稳态的。

 

7、系统各个组成部分的开发者都会做出一些假设,而这些假设之间的不匹配是大多数致命和难以察觉bug的主要来源。

 

我的理解,所以要有正规的需求分析过程、需求文档、设计过程、设计文档和设计评审,很大程度上是为了使参与人员都有一致的假设,这样避免错误。质量保证人员要测试一个产品或项目,在这些地方多花点时间,下点功夫是最有价值的。

 

8、项目的进度,经常以一种难以察觉,但是残酷无情的方式慢慢延后。必须关注每一天的滞后,它们都是大灾祸的基本组成元素。

 

9、软件开发中最困难的部分是规格说明,设计和测试这些概念上的结构,而不是对概念进行表达和对实现逼真程度的验证。

 

10、人们通常希望项目接近结束时,能收敛得快一些,然而情况确实越接近完成,收敛得越慢。

 

古语:行百里者半九十,真是非常有道理啊。

 

 

 

     

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(项目管理,软件工程,产品管理,经典语录,人月神话)