读《人月神话》

翻译很迷，阅读过程痛苦。但确实经典，总会蹦出金句——那种读来万分感同身受，自身却从未做过总结归纳的观点。例如为何总存在需求变更？因为“产品自身易于掌握和不可见性”。又如“数据的表现形式是编程的根本”。作者所描述的软件工程面临的“焦油坑”，放到今日仍然试用。软件产品最大的特点，在于其复杂性，从本书提出这个概念至今四十多年，仍没有本质的改变，这也是作者提及的，“银弹没有出现”，甚至可能永不存在。

本书另一个魅力，在于结合工科思维与管理科学。就像作者提及的，软件项目管理，是“社会学”，而非“科学技术”。软件编程最主要的问题，在于组织与沟通，而非工具与技术层面。因为软件工程重协作，但又难以协作（不可见、不易描述、不易理解）。作者工程师出身，但结合管理与心理学，来分析软件工程的特点。

读后惭愧，作为互联网PM，总会认为这是个新兴行业的新兴职位，在创造新的职业方向。其实只停留在表层。就像前几年的2C产品，人人都是产品经理，只要有逻辑，没有任何门槛。随着潮水退去，显露了底层知识结构的极度缺失。学习下软件工程、信息管理系统、需求分析、项目管理，比开口商业画布、价值分析，更加重要。或者说目前行业背景下，先把拧螺丝的底子打好，再谈互联网那一套概念。

 

---

 

1. 行为——被淘汰之后留下的那一套生活方式。不论行为者对于这套方式怎样说法 

2. 软件开发本质上是一项系统工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

3. 对于软件任务的进度安排，以下是我使用了很多年的经验法则： 1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试，所有的构件已完成     //简化些，对于开发团队。三分之一做技术方案，三分之一编程，三分之一测试。总之，前期的方案与计划需投入更多的时间。

4. 向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later） //项目管理提到赶进度有两种方式，赶工与加资源，但其实加资源的目的，是为了该产品的后续需求。对于正在进行的需求，除非加班，不存在其他方法来缩减进度。而且，结果上进度不延期，怎么证明团队确实资源不足呢？

5. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。  //这句话是有问题的，不存在“合理的”时间进度，或者说合理的标准是什么？项目永远是制定一个timeline，然后尽可能缩短延期时间。如果能按时完成，说明时间估的buffer太多了，资源太充足了。

6. 效率高和效率低的实施者之间具体差别非常大，经常达到了数量级的水平。 //软件工程，是一个极度依赖个人英雄主义的团队协作任务。

7. 我常常重复这样的一个观点，需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。这一点，也暗示系统应该由尽可能少的人员来开发   //类似回归测试。增加一个功能，有一半时间在解决因新增功能导致已有功能受影响。多少时间花在沟通上，就至少有那么多时间，花在沟通前期沟通不一致的内容。

8. 概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。  //这不就是互