项目管理：计划与跟踪过程
项目管理：计划与跟踪过程原作者:夏清风
摘要
这是我们的项目计划与跟踪的内容，在项目实施中使用得很好，我拿出来与大家分享，希望大家多提意见，谢谢！ 最初的项目计划不够精确和准确，不能直接拿来指导我们的日常工作，也不易跟踪。我们采用三层计划机制将计划中的任务拆分成可跟踪的小的任务来执行。另外，采用不同周期不同规模的review活动来跟踪计划的执行，并不断地调整我们的计划。在跟踪的过程中，由项目经理来负责将每个任务的实际工作量记录下来，以便最后的统计。
总过程图
注：
1． 根据项目进度定期地（或事件驱动地）进行peer review和progress review.
2． 偏差包括实际情况与原计划不相符的任何地方，例如时间安排，人力资源，设备，任务安排，等各方面。
3. Review不仅是查找已执行工作与原计划的偏差。有时候，根据现阶段工作的情况很容易判断后续工作原定计划的不合理性，这部分计划也需要及时修订。
第一部分 不同层次的计划
项目计划的目的是为实施软件工程和管理软件项目制定合理的计划。三层计划机制是艾思普公司项目计划的主要内容。
高层计划：设计师和项目经理根据用户需求制定高层计划，给出项目进行的主要阶段和各种需求。此计划需要经过审核通过后方可执行。为了便于理解，高层计划也可以称为月计划。
中层计划：项目经理，设计师，以及所有的参与人员共同制定中层计划。中层计划是高层计划的任务分解。中层计划也可称为周计划。
低层计划：根据中层计划中的任务安排，每个人制定自己的低层计划。低层计划也称为天计划。
1 高层计划
在各种估算的基础上，根据用户需求给出项目进行的主要阶段和进度计划，就是高层计划。
进入标准：用户提出的各方面需求（如成本需求和交付时间要求，等）和软件项目的开发策略。
人员：设计师，项目经理
内容：
1） 阶段：项目总体分为哪几个阶段来进行？标准软件过程是：发现、定义、概念、设计、和实现。根据具体的项目情况，可以将其裁剪和细化。
2） 时间：各个阶段要求在多长时间内完成？或严格要求什么时候完成？
3） 资源：按阶段阐明需要的资源，包括人力资源和关键的设备资源。人力资源说明角色和数量。设备只需提出特殊的或关键的设备资源，如需要一个特殊配置的服务器，在系统测试中要搭建模拟环境，等等。
4） 退出标准：每阶段要达到什么要求才可以退出，即阶段完成的要求是什么？
承诺与认可：高层计划需要客户和高层管理者的认可，并且有关人员必须被告知高层计划中与其相关的内容，并得到他们的承诺和认可。比如，通知人力资源部门人员需求，通知财务部门设备要求和经费需求，等等。
注：1）计划的依据：用户提出的项目要求，公司采用的软件工程过程，以及自己的经验。
2）需要考虑公司的一些实际情况：比如人员调配，员工的技术能力，等因素。
2 中层计划
将高层计划的任务进一步细化为每个人或每个小组在大约一周时间的工作，就成为中层计划。
进入标准：高层计划已制定且通过审核。
时间：在进入每个大的阶段之前，本阶段的中层计划一定要明确，并取得团队的认可。本阶段的中层计划是开始本阶段的主要输入。
人员：项目经理及设计师领导项目团队共同制定中层计划。中层计划将把任务具体到团队的每个人。
内容：
1） 任务：项目的每个阶段可以拆分为哪些任务？
2） 人：每项任务的责任人是谁？一项任务可能不止一个人完成，但必须指明一个负责人（Owner）。
3） 设备资源：什么时候需要什么样的设备资源，需要给出设备的具体要求。如性能要求，配置要求等。
4） 时间：每项任务要求在多长时间内完成？或严格要求什么时候完成？
5） 任务之间的依赖关系：各项任务之间有无依赖关系？是什么样的依赖关系？
6） 里程碑：阐明一些关键的事件点，如关键人员或设备的到位期限，什么时候审核，等等
承诺与认可：保持与高层计划的一致性，每项任务的估算得到执行者的认同，有依赖关系的任务安排要得到相关人员的认可。
注：1）需要邀请有测试经验和部署经验的人分别参与测试和部署的工作计划，他们会帮助团队制定出较合理的中层计划。
2）当中层计划与高层计划不一致时，将中层计划重新估算一遍。如果还是与高层计划不一致，则以中层计划为准，要求修改高层计划
3 低层计划
每项任务的执行者根据中层计划将自己的任务细化到每一天，即低层计划。
进入标准：中层计划已制定且项目团队整体认可。
时间：在每周周一的早会之前，制定出本周本周或两周内每天的计划。
人员：低层计划一般由具体执行任务的每个人来制定。这将是每天Team meeting的依据。
内容：每天的任务和需要提交的文档。
承诺与认可：要求每个人计划中特定时间所要求的支持得到支持提供者的认可。另外，要求每个人的计划符合中层计划，与其他人的计划进度没有冲突。
注：在实际开发过程中，往往有些工作不能拆分到每一天。就是说，一件事情需要几天来完成。如果本任务不在关键路径上，而且与其他人员的工作关系比较独立，可以不拆分此任务，由执行者本人掌握进度。否则，需要将任务尽量拆分开来，按内容划分为几部分，或用百分比来划分，以便更好地掌握整个项目的进度。
4 三个计划的关系
计划更改的时候，一定要保持各层计划的一致性。高层计划会因中层计划的更改而调整，低层计划会受中层计划的影响。
第二部分 不同周期的Review
项目跟踪的任务是对照计划评审和跟踪软件完成的情况和结果，根据实际完成的情况和结果调整这些计划。艾思普公司的Review工具是项目跟踪的主要内容。
根据目的和周期的不同，项目跟踪中用到3种Review工具：daily review, Peer review, 和Progress review。
1 Daily review
目的：跟踪团队成员每天的任务完成情况，给团队提供一个交流的机会。
时间：在每个工作日的开始。一次Daily review一般持续10"15分钟。
形式：以team meeting 的形式进行。
参加人：团队所有人员（包括项目经理和设计师）。
活动：
1） 跟踪团队成员每天的任务完成情况
2） 交流相关问题
2 Peer review
目的：跟踪项目每周的任务完成情况，交流相关问题。
时间：每周进行一次。Peer review一般不超过1小时。
形式：会议形式。由项目经理来主持。一般要求项目经理提前将会议邀请发给大家。
参加人：团队的所有人员。
准备：会议开始之前，项目经理和设计师必须安排好会议的议程。
活动：
1） 审核项目计划，审核每个组员在项目计划中的对应工作；
2） 讨论项目的任何有关问题；
3） 共享知识；
会议的记录：由项目经理在当天将会议的内容整理出来并放置到CVS中，命名规则为Peer review_date_contents.doc。会议的整理文档必须使用公司统一规定的文档模板。
3 Progress review
目的：跟踪项目是否在向原定目标进展，提出并沟通项目中的任何相关问题，使得每个人都了解整体项目的进展情况。
时间：每四周进行一次。项目的第一次Progress Review应该在项目启动的两周内进行。有时也可以由项目经理临时组织（比如发现项目现状明显偏离了原定目标，需要及时采取措施）。Progress Review通常持续1-3小时。
形式：会议形式。由项目经理来主持，一般要求项目经理提前将会议邀请发给大家。
参加人：团队所有人员。
准备：会议开始之前，项目经理和设计师必须安排好会议的议程。
活动：
1） 确认团队理解客户对项目的要求；
2） 审核项目计划，审核每个组员在项目计划中的对应工作；
3） 就项目的现状，粗略地对项目进行估算；
4） 讨论客户提出的重要问题；
5） 识别项目的风险，并产生减缓策略；
6） 讨论并安排合适的Quality Review；
7） 审核项目过程（如，信息传递方式是否合适，团队的职责，等）；
会议记录：由项目经理在当天将会议的内容整理出来并放置到CVS中，命名规则为Progress review_date_contents.doc。会议的整理文档必须使用公司统一规定的文档模板。
4 Review的记录
一、Daily review
Daily review的记录内容包括每个人的计划和To do。
To do：用来记录将要做的事情。这些事情不属于计划中的任务，但需要在一个特定的时间之前完成才能保证项目有关事件的顺利进行。
二、Peer review和Progress review
Peer review和Progress review的记录内容一致，包括：参加人及角色；风险；新的问题；下一步工作；上次Review留下来的问题和工作；下次Review的时间安排。
第三部分 职责 顶！"" :)在职能型组织架构中，各个功能开发从各组找人，每个人早上有各自团队的晨会，项目管理部再来个Daily review 没实施过，感觉可行性不高啊
页:
[1]