《人月神话》阅读笔记02

Posted 2020-07-23 怎么能忘了！！！

人月神话02

         今天这篇阅读笔记主要讨论一下《人月神话》中巴比伦塔失败的原因，以及如何组织一个队伍才能保证一个项目或系统能够正常的运行。

    古巴比伦塔是《创世纪》中记载的一个建筑。他是人类继诺亚方舟之后的第二大工程壮举，但是它失败了。那么他为什么会失败呢？在这项工程中，它具有所有资源：清晰的目标、人力、材料、足够的时间、足够的技术。所有的这些足以支持他完成这一人类工程上的壮举，但是他失败了，因为在这项工程中没有很好的交流！这样导致了每个人都在干自己的事情，他们无法合作，这样他们当然不可能完成这样一项巨大的工程。

    根据上述工程的分析和总结，我们可以推断出在软件工程领域存在同样的问题：当人们面临一个巨大的系统工程时，很可能由于因为没有足够的的交流导致这项工程的失败。那么我们应该如何避免这种失败情况的发生呢？这就需要我们首先得有充分的交流，这也就导致我们必须有一个好的组织管理模式。

    首先我们先来谈一下关于交流的问题。交流的方式有很多种：会议、工作手册、非正式途径（电话交流沟通）。其中的工作手册是一个非常好的方式。项目工作手册是对项目必须产出的一系列文档进行组织的一种结构。项目工作手册中的备忘录对产品提出建议或者进行解释。未来产品的质量手册也是出自于现如今的项目工作手册。同时他还能够控制信息发布，确保信息能够达到所有需要他的人的手中。

    项目工作手册的目的是加强团队之间的交流沟通，那么首要的工作就是确保每个办公室都能够有一份手册。其次，为体现企交流功能，要对其进行实时的更新，这就需要采取一种合适的方式来组织更新，和宜采用活页夹的方式，这样就减少了重复打印完整手册的工作。其次，在每次更新时要确保每个人都明确的知道在什么地方进行了修改，并使每个人都能够理解所做的修改。

    通过上述的方式，我们能够有效的加强团队成员之间的交流，同时因为使用的是纸质介质，这样更加便于人员的理解和标注，这是一种很好的工作方式，同时这也在一定程度上能够比其他的交流方式减少更多的交流时间。

      下面我们来介绍一下大型编程项目的组织结构。在此一共介绍三种模式。

     首先我们必须明确团队组织的目的减少不必要交流和合作的数量。减少交流的方法是人力划分（ division of labor）和限定职责范围。我们可以考虑使用树形组织结构。在这种结构中需要有以下几点要素：任务、产品负责人、技术主管和结构师、进度、人力的划分、各部分之间的接口的定义。其中产品负责人和技术主管是非常重要的两个角色。简单来说产品负责人负责所有和技术编程无关的事物，比如向上的交流，人员的管理、资金的问题等等；而技术主管的任务是负责系统的整体架构和所有关于技术的问题的解决。根据这两个角色的不同组合，我们就能够得到三种组织模式：产品负责人和技术主管是同一个人、产品负责人作为总指挥， 技术主管充当其左右手、技术主管作为总指挥， 产品负责人充当其左右手。

    产品负责人和技术主管是同一个人。在小型项目中，这是一种比较好的组织模式，在小型项目中一个人能够有足够的精力来处理这两种不同的事物，但是在大型项目中这种模式是不可能存在的，所以出现了以下两种不同的组织模式。

     产品负责人作为总指挥， 技术主管充当其左右手。这种方式很有效但是在实际应用中似乎不太多。因为使用这种模式的话，技术主管很难在团队中建立起来威信，如果这种现象存在的话，那么这将会对一个项目产生很严重的不良影响。不过，它至少有一个好处， 即
项目经理可以使用并不很擅长管理的技术天才来完成工作。

     技术主管作为总指挥， 产品负责人充当其左右手。采用这种方式的话，技术主管的权威性不言而喻，在团队中团队主管具有绝对的权威性。而产品负责人是为技术主管服务的，他主要解决所有和技术无关的问题。这样的话，团队的效率也会非常高，而且这种模式在实际应用中是非常广泛的。

    通过以上的叙述，总的来说，第一、二种是比较适合小中型项目的。对于大型项目来说，还是第三种方式比较适合，因为在大型项目中交流是非常重要的，在大型项目中技术大牛非常多，这就涉及到处理他们之间的问题的困境，那么这是产品负责人将会发挥巨大的作用从而保证项目进度能够正常的进行下去，此时所有的技术问题都是可以解决的，最重要的是团队成员之间的关系的平衡。