任务管理(项目计划与控制)

    项目计划的关键之一是进度控制。

    项目首先划分研发阶段、关键里程碑点(每个研发阶段结束点都是里程碑点，需要评审）。

    比如下面每个阶段都有任务管理的活动在内。

        1-2月：立项阶段（有时这个阶段不属于项目范围内，但我认为：这个阶段需要收集关键的用户需求并进行初步分析，同时对系统基本架构、市场时间点也作了初步明确。也有任务管理的活动在内）

        2-4月：需求分析阶段：完成所有用户需求分析，产品需求说明书，系统方案，系统组件的需求、方案、概要设计，版本规划。初始时就确定完整的项目团队。这个阶段完成时，需求、版本、对应文档的基线化完成。

      4-8月：开发阶段。这个阶段初始，开发经理针对基线化需求下达开发任务（可能一次下达所有任务，也可能按版本下达任务）。

                              在第一个版本完成后，测试任务启动。

              一般会有需求变更、版本规划变更的过程，所以开发任务、测试任务也会随之调整。

              这个阶段完成后，需求、版本规划、代码一般应冻结。后续紧急需求安排紧急任务、紧急版本。

              大部分新的需求会被规划到下个项目大版本解决。

      9月之后：产品生产、版本发布、市场维护阶段。

 

        每个阶段都会有任务计划、下达、跟踪监控（跟踪的目的之一是监控）、变更、度量、配置项归档、质量保证、里程碑评审 等过程。

        本文关注的是开发阶段的开发任务。

 

任务分解

          任务的要素包括：任务名称或标识、一个负责人（多个参与人）、完成时间点、目前进展（或完成率）。。。

        WBS表（Work Breakdown Structure）一般按产品需求分解，每条任务一般与产品需求对齐。

            可以将复杂的需求分解为更细的子需求，带来的缺陷是增加沟通协调的成本，好处是每个任务参与人的工作更明确，工作量评估会更准确。

            在涉及多模块或多项目协调的任务中，负责人有组织、协调的责任，为任务的总体进度负责。

          实际上也经常出现内部优化任务，同样纳入产品需求范围进行管理、或归开发经理自行管理。

 

任务估算与关键路径

              甘特图

            所有任务工作量估算时间之和加起来，加上一定预留，即为开发阶段总工作量（人/天)。

              虽然所有任务本身的估算可能不准确，但 任务本身工作量的预留+任务工作量总和+总和的预留+加班，能尽量趋向准确值。即使对于需求变更非常频繁的项目中，也可以说：有估算比不估算，对于项目进度控制来说，会有质的区别。

              按版本规划要求，对每个任务何时开始、任务安排的先后顺序进行规划。考虑多个版本并行情况。

              对于数十人参与的大项目来说，任务安排是一个很复杂的工作。

 

              需要考虑关键路径，原因是某些关键人员可能同时参与2个任务甚至非开发任务、非本项目的任务，可能无法分身。 “向关键工作要时间，向非关键工作要资源”。通过向关键路径投入资源等方式，缩短开发进度；在发生突发任务等情况时，可以从非关键路径上抽调人员。

              实际操作中，这是一个比较难解决的问题，因为这些关键员工无法准确估算各任务的投入时间，只能在估算时提供预留时间比例，在某些关键时间点上就会发生任务冲突。    一般只能尽量按 任务负责人 排关键路径。

              在执行力较强的公司中，可能会非常重视任务工作量估算，这不但保证了进度的准确达成（目标是：项目进度完全可控），也避免了后期 员工在工作冲突 时的推卸事情的发生。这也要求对上游工作的审查必须严格，比如需求分析非常准确、全面。

              如果在任务安排时较匆忙，又不能让员工通过加班完成任务，员工本身也会因为工作冲突而理直气壮的推迟任务。

 

          可采用的办法如：

                              每周跟踪关键路径、人员（尤其是关键人员） 的任务情况。避免出现某人等任务、等版本 的情况。

                              需求评审 把关严格。

                              减少对开发人员的干扰，比如开发经理本人多关注测试部提交故障单，准确安排合适开发人员、对应模块人员处理。安排专门的集成测试人员。

                              每周、每天的例会时间固定化。

                              规范过程，比如详细设计的准确性。

                              有问题及时反馈到项目例会讨论。敏捷晨会就是很好的交流手段，此外还有周报、日报。。。

                              控制需求变更。需求基线化之后的需求变更相比原需求应该占少数，否则只能预留较多余量、员工加班来抵挡需求变更。

                            项目间实际工作量负荷不均时，想法进行 跨项目协调人力。

 

项目进度保证措施

      项目计划（规划）合理，事先完成工作量估算

      工作量估算要准确，并保留一定余量。尤其是测试时间。

      计划分解做细，明确关键资源、关键路径，关键人员保留更多余量或安排一些容易调整的任务。

      开发经理及时跟踪各人任务执行情况，及时调整。并反馈进度给版本经理、各CCB成员。

      版本经理根据需求变更情况、开发任务执行情况、上游文档评审情况，考虑是否调整任务。

      关键需求的审核、开发进度，请CCB各成员都参加。

      需求分析、评审阶段就能分析出关键资源，有关风险，比如是否需要安排测试仪器，用于测试的产品资源，是否需要其它项目的人力支持，是否需要与其它项目联调，测试环境的安装是否会出现问题。

      部分紧急需求处于一边开发，一边等前方确认需求细节问题，应重点跟踪。

      最后则是：项目成员及时加班。

 

任务监控

          需求->开发->测试。 每个环节都有工作成果的交接。

      项目交付产品需求、方案，并要得到开发的认可（之后也可能由开发或项目提出对需求、方案的变更）。

      开发交付版本功能清单及新功能指导书，并得到测试的认可。否则测试拒绝测试。

      测试完成后交付 版本发布说明 给现场。

 

      下面都是 开发经理、测试经理 的日常工作，非常繁琐。

      最终任务目标是：在资源有限的情况，完成对上游的承诺（承诺是一个复杂的过程，完成主要是指质量目标、时间进度目标），工作成果得到下游的认可。

 

      开发经理下开发任务给员工，任务经常调整（推迟、提前、停止）。开发经理需要知道任务是否能按时完成。

      开发经理有多种跟踪管理手段：每周科室例会对 每条需求、任务 都检查当前进度。员工每天填任务进度。任务负责人都填写任务日报、周报。日常沟通。有异常的话，有多种反馈方式，然后再调整任务。这是一个闭环操作。

      如开发任务没有按时完成，每半年QA会检查任务及时完成率。对于未及时完成的任务，项目上会检查。

      对上游也应有同样的管理手段：产品需求是否评审完成，需求对应方案、开发任务 的关联关系、任务是否规划版本及承诺时间点 等。

 

其它相关人等也有对于任务的控制手段：

      上游：项目线规划 需求\功能 入库版本，指定发布时间点。定期跟踪各任务的进度是否正常，是否要调整。

                  版本经理对于每个版本制作前，应该入版本的功能是否已经已提单入库。 他可以在上游规划需求的版本与时间点之后，提单并指派开发经理或科长处理（后者再指派给员工）。版本制作前检查这些单子的状态是否完成即可：确定某版本所需新功能、故障均已入库。

 

      下游：测试经理会保证在版本要求的发布时间点前完成版本的测试：新功能测试、回归测试、性能测试。。。应预留时间给开发人员解决故障。

                  如对于新功能指定测试完成时间点（一轮或二轮）。一轮测试中发现有故障，解决后再经过二轮测试，无故障则认为此功能可发布。

                  某版本中所有新功能、故障均测试通过后，即变为 可发布状态。

 

任务的质量管理

              上述提到的措施都是进度控制的手段，不是质量控制的手段。

注：很多项目中质量控制更多是依靠员工的熟练程度，有时做做代码抽查、PCLint检查、自动测试代码。。。

 

            测试只能发现故障，度量只能统计故障的个数、评估结果。平时各研发活动都进行一定的质量控制才是质量管理的重点，从源头(需求分析的质量)和活动（各种开发活动）中控制故障的产生。

            在流程的各个关键节点，进行有效监控和评估，给出方法和实施细则。通过细化阶段计划，强调协调汇报机制，执行针对性的检查和评估方式，以及通过阶段总结与复盘，解决研发过程中缺乏风险和质量监控的问题，并从中获得相关统计数据以利于后续研发任务的改进和完善。

                  开发过程的产品包括：文档与代码。

                许多项目缺乏对文档质量的控制，可采用的办法如每种文档提供检查单、每个模块定制自己的检查单。

                  故障产生后，经常组织复盘。