人月神话

https://github.com/youngqqcn/expert_readed_books/blob/master/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B/%E4%BA%BA%E6%9C%88%E7%A5%9E%E8%AF%9D.pdf

• 开发成本随着人数和时间的不同，有很大的变化。

• 用人月来衡量工作是非常危险的，因为它建立在人与人之间不需要相互交流的前提

• 在错综复杂的任务中，沟通和交流的工作量非常大，如果添加更多的人手，实际会延长进度

• 不要进度一落后，就想着加人

• 少数人思考确定系统的方向，多数人来解决实际实现问题

• 巴比伦塔为什么失败？

  • 两个方面——交流，以及交流的结果——组织
  • 鼓励网形交流，而不是树形

• 团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。 减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）

• 每棵子树所必须具备的基本要素:

  • 任务（a mission）
  • 产品负责人（a producer）
  • 技术主管和结构师（a technical director or architect）
  • 进度（a schedule）
  • 人力的划分（a division of labor）
  • 各部分之间的接口定义（interface definitions among the parts）

• 产品负责人的角色是什么？

  • 他组建团队，划分工作及制订进度表。他要求，并一直要 求必要的资源。这意味着他主要的工作是与团队外部，向上和水平地沟通。他建立团队内部 的沟通和报告方式。最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架。

• 技术主管的角色是什么？

  • 他对设计进行构思，识别系统的子部分，指明从外部看 上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复 杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。用 Al Capp 所喜欢的一句谚语，他是“攻坚小组中的独行侠”（inside-man at the skunk works.）。 他的沟通交流在团队中是首要的。他的工作几乎完全是技术性的。

• 产品负责人和技术主管是同一个人

  • 这种方式非常容易应用在很小型的队伍中，可能 是三个或六个开发人员。在大型的项目中则不容易得到应用。原因有两个：
    • 第一，同时具有 管理技能和技术技能的人很难找到。思考者很少，实干家更少，既是思考者又是实干家的太少了。
    • 第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来说，很难在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设 计的概念完整性，没有任何妥协的前提下，担任管理工作。

• 如何根据一个严格的进度表来控制项目?

  • 第一个步骤是制订进度表。进度表上的每一件事,被称为“里程碑”,它们都有一个日期。
    • 里程碑的选择只有一个原则,那就是,里程碑必须是具体的、特定的、可度量的事件,能够进行清晰定义。
  • 保持进取心, 必须关心每一天的滞后,它们是大灾祸的基本组成元素
  • 及时反馈问题
    • 减少角色冲突: 老板只了解信息，不越俎代庖，避免经理失去权威；经理及时上报，并且提出解决方案，让老板安心。
    • 有了解真相的评审机制。通过关键路径图、明确里程碑、周会多方面来评审是否存在问题。

• 项目管理主要是对人的关注和管理