假设人月可以互换，则为了缩减周期需要投入更多的人，为了让更多的人都有事可做就需要细分任务，细分任务自然增加了系统分解和后期集成的工作量，细分任务间无法避免的依赖和关联自然增加了沟通的成本和工作量。而且由于任务的细分需要引入文档等重量级的沟通工具，原始的需求信息在需求，设计，开发，测试等多个环节传递很难真正保证我们需要的概念完整性。如果一个系统按功能点估算有200个功能点，按一个功能点200-300行代码计算，整个系统规模在5万行代码左右。这是一个中小型的项目或系统。如果按照总生产率80行/天计算，则总工作量在20人月左右。根据非线性关系我们可以估计理想情况或者说性价比最好的情况是投入5人4个月完成，当人数增加一倍时候进度只能压缩到3个月。当人数再增加到15个人的时候，进度压缩到2个月，这个时候增加再多的人就已经没有用了，对于这种规模的的系统，2个月可能就是进度极限了。我们讲当规模增长的时候，工作量并不是非线性增长，周期也不是非线性缩短。其中工作量的增加前面已经讲了第一个重点增加在了系统分析设计，需要将复杂的系统进行分解；其二在后期集成和测试，需要将分解的各个功能模块集成和组装。对于产品规模增加的时候，对于详细设计和编码阶段工作量可以任务是一种线性的增加，非线性部分指数增加的工作量都体现到了前期的分析设计和后期的集成和测试上面。当我们假设是线性的时候，我们主观的去缩减了这两头的工作量。如何缩减了系统分析和总体设计的工作量，则可能带来整个产品结构的不稳定，后果往往是整个产品推倒重来；如果缩减了后期集成和测试的工作量，则不可避免的是导致项目延期。乐观主义者喜欢假设我们开发的是零缺陷的系统，但对复杂的软件系统而言这仅仅是个神话。
感受：
一个大项目例如一个大型游戏就需要很多人进行长期开发。在这个过程中我们不可对他产生抵触情绪，因为工作量是递减的，这在我们软件团队开发中也是同样的。所以我们应该在过程开始前做好准备，提前对软件项目做好规划，，最好做一个“燃尽图”，他可以展示我们的工作量。