开发时人越多效率越低！
昨天看《人月神话》，看到第五章，合上书就睡觉了。
今天回忆一下，做个阶段性的读书笔记：
- 开发人员越多，工作量就越大，效率越低——因为人员的沟通和协调要花费很大的成本——基本是双曲线的关系；
- 如果一个项目进度落后，那么增加新手反而会起到反效果。
- 作者认为man-month是虚无缥缈的神话，用人月来估算工作量是荒谬的，因为这隐喻着人与月可以互换——实际上大错特错。我想这就是书名的来源。
- 第五章作者就提出了解决办法：组件“外科手术团队”，通过人员的有机搭配实现一个中心管理模式，这样的团队具有很高的效率。
- 作者通篇强调着程序开发的“概念一致性”，强调前期设计的重要性，强调——这些经验都有具体的惨痛经历来验证。
- 这本书写于1975年，作者brooks曾经担任IBM OS/360项目经理。本书的观点已被业界广泛传播。
我认为这取决于项目负责人的能力和项目的具体情况。如果软件能被合理的划分成N个独立模块，那么由N个人负责独立实现就是最快的；进一步而言，如果能够架 构良好的软件体系，设计好了100个接口和相关文档，那么就可以召集100人来同时工作。韩信点兵、多多益善。软件设计是关键。
项目边界问题：
多大的东西能被称之为一个项目？我的看法是用业务延续性和关联度来划分。接到一个需求，如果它的业务背景和现有项目有较大的重叠，那么就不太好独立立项。譬如项目组的网上登记，应该算是联合办证的子项目，由联合办证负责人持续开发比较好。
合格的项目经理？
理想的项目经理是什么样子的？整个小组的工作能被他一个人扛下来，这样的超人最好。而合格就容易多了，我觉得只要一个要求：能够掌控项目。这种掌控的某种 体现是他清楚的了解各个环节的来龙去脉、规划、难度和可能的实现方式；能够大致准确的估算出进度；能够预先估计到困难和需要的帮助，并调配资源。
【2007-10 bbs讨论帖】
后记：现在我们改用“人月”来报价了。