工程理论其实是包含组织学的。然而我在上面的那张图中，将组织与工程分离开来，并在二者之间画下了一道纵向的线，如图所示。

工程关心的是“需求”、“配置”和“文档”等这样一些要素，那么这样的工程还是停留在技术层面的：关注的还是工程的实现细节，而非目标。从角色的角度来看，这是项目经理和技术经理所共同关注的那一部分。

作为那个解结的人，你应该知道这个图例上的需求管理决定了你的阶段性目标，配置管理决定了你检测的方法，相关的文档化工作是沟通的渠道，以及协调团队矛盾的手段。“需求”、“配置”和“文档”等不仅仅是你每日一成不变的、模式化的工作步骤，而且也是解结的工具与方法，或者是你实施管理思想的道具。

此外，你（项目经理）还必须关注于人力资源、项目资金及多个项目之间的协调等。这些与工程本身并没有直接关系，而是“组织”方面的内容。

所以在工程环节中，“文档管理”和“配置管理”等中的那个词汇“管理”，是管理的具体技术和方法；而在“组织”这个环节中的这个“管理”，才是真正的管理学上的用词。

作为项目经理，你必须有一部分的工作是非技术性的。甚至，你可能绝大部分的工作是非技术性的——因为与技术相关的管理技能（需求、配置、过程管理等）可以由开发经理来做，或者公司对于这一方面有较统一且成熟的规范，因而无须投入过多的精力。

你必须更关注于对这个（或这些）工程的组织与计划。站在“组织者”这个角色上，你现在要考虑的内容可能会是：

• 为项目的各个阶段建立计划，并逐渐地细化计划的内容，以及确立项目过程中每一个环节、每一个计划阶段的优先级和复杂度；
• 确立项目或者产品阶段目标，成果的准确描述、定位，以及整个项目的质量目标及其评核办法；
• 对团队中的不同角色展开培训，以指导并协调角色间的工作，从而消除因为工作习惯的差异带来的影响；
• 为每一个人准备他所需要的资源，这不单单是把一套shareware变成正式版或者把512MB内存变成2GB，还包括准确地评估他的工作量，以及决定是否为他增加一个（能协同工作的）副手；
• 决定在哪些环节上反复审核和回顾，而在哪些环节上采用较为宽松的方式以加快进度；
• 习惯于开会、组织更短而有效的会议，以及建立激励机制，当然也不要忘记让每一个成员意识到这一项目的风险；
• 不要乐观。

即使你做好这一切，可能项目的结果仍然不够理想。但是你应该知道，好的项目经理并不是不犯错误的人，而是以尽可能少的失败来获得成功的那个人。

无论是你的团队成员，还是你的老板，对重复的错误以及可预料的错误都是不会宽容的。——在一个团队中，失去了组员的信任比失去老板的信任更可怕。

所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。

软件工程-第七章第七节 组织