作为项目经理，如何在满足客户需求，并在人力资源不足（员工成熟度不够、队伍不稳定、工程师工作积极性不高）、工期紧的情况下，有效的制定和执行项目计划，是项目经理一个重要的能力，而要完成这一进度人员的组织非常重要。
　
　　本文作者通过项目经理培训，并结合多年软件行业从业之经验，来研究和探讨项目执行过程中任务的分解和执行中人员组织方面的思路，希望与正从事软件项目管理的同行分享与共勉，力图对后续的工作提供一些指导。
　
　　一个软件项目必须满足：目标、时间进度和预算的要求。要完成这个项目而建立的软件开发组织是一个复杂系统。表面上看起来目标、时间进度和预算，三者好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，特别是在实际工作中团队的行动就会变得越来越慢，往往可能导致项目进度的不可控制，使成本上升，甚至导致项目的失败。
　
　　在项目经理培训中，涉及的内容很广泛。本文试图仅仅从项目的任务分解和执行中人员的组织来进行一些讨论。主要有下面几个方面来谈我的理解。
　
　　1.问题的提出：项目的进度度量
　
　　1.1进度不可控的原因
　
　　在实际的项目执行过程中 ，缺乏合理的时间进度是造成项目滞后的最主要原因，原因是什么呢？
　
　　首先，对估算技术缺乏有效的研究，很多项目经理对项目进度过分乐观的估计，它反映了不真实的假设——一切都将运作良好。
　
　　第二，采用的估算技术隐含地假设人力和工作量可以互换，错误地将进度与工作量相互混淆。
　
　　第三，对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
　
　　第四，对进度缺少跟踪和监督。跟踪技术和常规监督程序。
　
　　第五，当意识到进度的偏移时，下意识的反应是增加人力。只会使事情更糟。
　
　　对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性。在估计和进度安排中，某个任务可以分解给参与人员，他们之间需要相互的交流。子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。
　
　　沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。因此工作量随人员的数量呈线性变化：按照n（n-1）/2递增。
　
　　1.2进度的经验性安排

　　项目进度和工作量的不同：工作量只是子任务的数量的简单分解。项目进度依赖于顺序上的限制，以及资源制约、培训时间、管理成本等。

　　这里有一个基于经验的时间安排尺度。假设以一个项目的总体执行项目周期为1。对于软件任务的进度安排的经验法则：

　　·1/3计划

　　·1/6编码

　　·1/4构件测试和早期系统测试

　　·1/4系统测试，所有的构件已完成

　　除了系统测试，进度基本能保证。不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候，问题才出现在客户和项目经理面前。延误发布，将付出相当高的商业代价。上述的二次成本远远高于其他开销。

　　因此，在早期进度策划时，允许充分的系统测试时间是非常重要的。开发并推行生产率图表、缺陷率、估算规则等等，而整个组织最终会从这些数据的共享上获益。项目经理需要挺直腰杆，坚持他们的估计。 

　　当一个软件项目落后于进度时，加派人手可能产生的进度灾难。
·要及时聘请到多么能干的新员工；

　　·新员工需要接受培训。有经验的职员将投入到原有进度安排以外的工作中；

　　·原先划分为三个部分的工作，会重新分解成五个部分；

　　·更多的交流成本、管理的工作；

　　·某些已经完成的工作必定会丢失，系统测试必须被延长。
 
　　2.团队的组织

　　大型项目的每一个部分由一个团队解决，而并非一拥而上。由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。

　　2.1协作成本

　　需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。所以并不是人越多越好，系统应该由尽可能少的人员来开发。

　　2.2成员差异
　
　　程序员最好的和最差的表现在生产率上平均为10：1；在运行速度和空间上具有5：1的惊人差异。
　
　　2.3团队组织关系
　
　　一个项目中的两种角色安排的三种可能的关系，他们是：
　
　　1 产品负责人和技术主管是同一个人。这种方式非常容易应用在很小型的队伍中，可能是三个或六个开发人员。在大型的项目中则不容易得到应用。
 
　　原因有两个：
 
　　第一，同时具有管理技能和技术技能的人很难找到。思考者很少，实干家更少，思考者－实干家太少了。
 
　　第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来说，很难在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设计的概念完整性，没有任何妥协的前提下，担任管理工作。
　
　　2 产品负责人作为总指挥，技术主管充当其左右手。这种方法有一些困难。很难在技术主管不参与任何管理工作的同时，建立在技术决策上的权威。显然，产品负责人必须预先声明技术主管的技术权威，在即将出现的绝大部分测试用例中，他必须支持后者的技术决定。要达到这一点，产品责任人和技术主管必须在基本的技术理论上具有相似观点；他们必须在主要的技术问题出现之前，私下讨论它们；产品责任人必须对技术主管的技术才能表现出尊重。 
　
　　3 技术主管作为总指挥，产品负责人充当其左右手。这种组合可以使工作很有效。不幸的是它很少被应用。不过，它至少有一个好处，即项目经理可以使用并不很擅长管理的技术天才来完成工作。
　
　　2.4团队组成
　
　　在一个大型项目中，软件项目经理必须为成员良好的分工，组成有层次的结构。
　
　　系统结构师，从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。
　
　　首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。
　
　　程序职员。他负责维护编程产品库中所有团队的技术记录。
　
　　编辑、秘书。首席程序员负责产生文档。而编辑进行分析和重新组织，提供各种参考信息和书目，对文档多个版本进行维护以及监督文档生成的机制。
　
　　工具维护人员。测试人员。
 
3.团队交流 　
 
　　3.1手册、或者书面规格说明
　
　　手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
　
　　随着用户和实现人员反馈的增加，规格说明中难以使用和难以构建实现的地方不断被指出，规格说明也不断地被重复准备和修改。然而对实现人员而言，修改的阶段化是很重要的——在进度表上应该有带日期的版本信息。
　
　　手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。
　
　　规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。
　
　　3.2周例会
　
　　周例会由所有的结构师，加上硬件和软件实现人员代表和市场计划人员参与，由首席系统结构师主持。
　
　　会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面形式，在会议之前分发。新问题通常会被讨论一些时间。重点是创新，而不仅仅是结论。该小组试图发现解决问题的新方法，然后少数解决方案会被传递给一个和几个结构师，详细地记录到书面的变更建议说明书中。
　
　　接着会对详细的变更建议做出决策。这会经历几个反复过程，实现人员和用户会仔细地进行考虑，正面和负面的意见都会被很好地描述。如果达成了共识，非常好；如果没有，则由首席结构师来决定。这需要花费时间，最终所发布的结论是正式和果断的。
　
　　这种会议的卓有成效是由于：
　
　　1.每周交流一次。因此，大家对项目相关的内容比较了解，不需要额外培训。
　
　　2.上述小组十分睿智和敏锐，深刻理解所面对的问题，每个人都要承担义务。
　
　　3.当问题出现时，在界线的内部和外部同时寻求解决方案。
　
　　4.正式的书面建议强制了决策的制订，避免了会议草稿纪要方式的不一致。
　
　　5.清晰地授予首席结构师决策的权力，避免了妥协和拖延。
　
　　3.3电话日志（交流日志，BBS等记录）
　
　　随着实现的推进，无论规格说明已经多么精确，还是会出现无数结构理解和解释方面的问题。显然有很多问题需要文字澄清和解释，还有一些仅仅是因为理解不当。讨论和解决，在BBS上做出记录。问题的答案（对问题的认识或者想法记录下来）必须是可以告知每个人的权威性结论。
　
　　3.4质量会议
　
　　项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。该小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。
　
　　4.为变化组织架构
　
　　每个人被分派的工作必须是多样的、富有拓展性的工作，从技术角度而言，整个团队可以灵活地安排。
　
　　当系统发生变化时，管理结构也需要进行调整。管理人员和技术人才的能力给予培养，使管理人员和技术人才具有互换性。
　
　　管理人员需要参与技术课程，高级技术人才需要进行管理培训。项目目标、进展、管理问题必须在人员整体中得到共享。