物理量纲失效了-论《人月神话》

转自知乎2016-06-19  https://zhuanlan.zhihu.com/p/21381297

本书的主要思想，归纳起来主要是以下几点：
1.“人月”的工作量，完全并不是想象中的指标，随着“人”的成倍增加，并不代表着“月”的减少，甚至可能是“月”的增加。进度无论如何不可能被压缩到3/4以内。
2.架构师是最重要的，以确保概念的完整性，合理的切分工作，制定接口。行政领导应当尊重架构师的权威。
3.不存在一个神奇的方法或技术“银弹”，实现数量级以上的程序员的工作效率的提升。

作为一名客户与需求方。我对书中所描写的种种，深表同意。“人月”这一量纲，总会给我们一种错觉，那就是只要10人*1月=1人*10月。然而，这完全是一个错误。

我自认为是一名还算合格的需求方，需求明确，没有变更，然而，外界条件总是迫使我们一改再改。就拿我目前正在负责的某数据分析系统项目为例吧，目前是6月中旬，系统开发的截止时间是9月底，还有3个半月。

开发方反馈：数据接口A存在问题。原因是数据接口侧表示7月底要上新的数据格式，目前格式的数据仅供参考。而且7月底这个时间点有风险（该项工作由外部因素决定，无法改变）
我只能要求开发方同步进行两套方案的开发：即老数据接口的对接，以及新数据格式的对接（依照规范文档—我相信大家都知道规范文档和实际数据的差距能有多大）
同样是此项目的系统建设需求，我和开发方多次沟通，5月份开了5次当面会，但我自觉已经写的非常清楚的需求文档，依旧会有N多需要澄清的需求点。既包括厂家未正确理解我的需求的情况；也包括实际协调的困难，当然也包括开发方不给力的情况。

然后，我们最常说的一句话是:”一期时间比较紧张，因此，这个需求放到二期吧“。如果你也看了”人月神话“，相信你们明白我在说什么。那就是”开发第二个系统所引起的后果“—将在第一个系统中因为小心谨慎或预算原因所未添加的功能全部加入。鉴于此，我计划从现在就开始起草第二期的需求文档，并评估其必要性。
我相信看完“人月神话”对我是有益的，就从这个项目开始发挥作用。尽管我不是一个真正意义上的项目经理或者架构师。

后记：看书很舒适，很happy，写笔记真的很不舒适，进入了“强迫区”，不过，这也是一种提升自己的能力的机会。不管是系统性审视阅读的文章，还是对相关知识的思考。
所以，目前的todolist累计到了《美的历程》《解忧杂货铺》两本。但不知道什么时候会真的动笔。