- 我们对估算技术缺乏有效的研究。即有的时候，我们既无法准确估算某一个项目或者某一项工作需要多少工作量，也无法估算该项工作量需要多少人力才能够完成。更有甚者，对于估算技术缺乏有效的研究，是因为对于项目本身缺乏研究。不知道如果需要完成项目应当完成多少个“小目标”，更不知道这些“小目标”应该由谁依赖哪些工具来完成。所谓“将不识战”、“将不知兵”便是如此，工作总量尚且无法预估，何况分解乎？
- 我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。文初的那一个孕妇的搞笑例子已经足以说明这一想法在非线性、非无限可分解的多里程碑（节点）任务下，简单地进行人月互换有多么的荒谬。
- 由于对自己的估算缺乏信心，通常不会有耐心持续地进行估算这项工作。很多时候，估算只是为了估算，或者通过估算证明一些什么，而非解决一些什么，因此即使估算出现错误，明知道多估或者少估，也不能、不想或者不愿进行调整了。
- 对进度缺少跟踪和监督。实际工作中，不少人对于项目的跟踪和监督就是在开始下达任务和在最后等待结果汇报，这一做法是否正确，将会在后两篇中提及。
- 当意识到进度的偏移时，下意识的反应是增加人力或者催促加班。实际上，这两种方式都是饮鸩止渴——增加人力的话，并不意味着更多人加入解决原先的工作量，增加人力本身就会导致工作量的增加。具体来说，有三个方面：任务重新分配本身和所造成的工作中断；培训新人员以及额外的相互沟通。而催促加班的结果往往只能够得到一些低质乃至无效的回馈，返工和修订同样会造成劳动总量的上升。
那么或许就要有人问了，“人月”难道真的无法换算吗？添加人手对于项目的进展难道一点作用都没有吗？对此，书中也是予以了解答“人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。”上述的条件在编程领域几乎是不可能的，可以想见，在实际的工作中也极少存在有这些既可以分解，又不需要交流的工作。因此“人月”神话可以实现的场景其实非常有限。而当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。由于调试、测试的次序特性，许多软件都具有这种特征。坦率的讲，以上两种“人月”可以自由兑换或者完全不能兑换的情况，对于我们目前大部分的工作而言显得过于极端，实际工作中，我们遇到的大部分是第三种情况——可以分解，但子任务之间需要相互沟通和交流的任务。此类任务必须在计划工作中考虑沟通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些（简单的说，3个人10个月完成的量，如果换做10个人来做，需要的时间比3个月要长）。与此同时，团队内的沟通其实非常重要，如果任务的每个部分必须分别和其他部分单独协作，则沟通工作量按照n(n-1)/2递增。一对一交流的情况下，三个人的沟通工作量是两个人的三倍，四个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的问题，情况会更加恶劣。因此建立定期的，高效的沟通机制是决定人员增加任务分解后是否能够相较于原先的预估时间产生优化的重要因素，否则就会产生“三个和尚没水吃”的尴尬局面。
标签：估算,读书笔记,工作,任务,分解,工作量,沟通,神话 来源： https://www.cnblogs.com/duanzheng/p/16374304.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。