项目经理手册Word下载.docx

项目经理手册Word下载.docx

《项目经理手册Word下载.docx》由会员分享，可在线阅读，更多相关《项目经理手册Word下载.docx（14页珍藏版）》请在冰豆网上搜索。

　　从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。

只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。

从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。

　　在具体项目中，一般的做法有两种：

一是请该领域内专家参与到系统开发的早期阶段；

二是开发系统原型，原型包括功能性的原型和用户界面性的原型，也可以是二者混合的原型，用这些原型确认用户的需求。

监督计划

　　按照监督计划分配相应的资源来保证某阶段的开发质量。

分析阶段的监督计划会在分析任务之前被项目经理、项目负责人、系统分析员以及技术支持所了解。

为保证分析工作高质量进行，同时又不被过分打扰，质量监督组则主要针对《系统分析报告》进行复审，并在认为确实有必要的情况下才召开质量复审会议。

质量复审会议的主要参与者是项目经理、项目负责人、分析人员和质量监督组组长。

会议主要是对质量质疑，给出改进建议即可。

具体是否存在质量问题、是否需要改进，不在会议中进行讨论，以此保证了会议参与的人数较少，会议的时间尽可能短。

　　系统实现，实现也就是代码的生产过程。

生产的类别有组件的生产，构件的生产，应用系统的整合，以及各种测试用例的生产。

为了能够提高生产的质量，应将生产的程序人员按职能分成两组，也就是说如果某个程序员生产了某个组件，则不能再由该程序员来生产，但他可以生产其他组件。

这样交叉生产更容易发现组件存在的问题。

测试指标

　　测试人员按照各项指标提出测试报告。

指标分别包括如下几点：

软件的正确性，正确性测试主要是测试软件的功能是否被正确地实现。

测试的方式主要是按照功能的要求按照给定的输入，看是否有给定的输出，在非标称输入时，输出是否异常等。

同时也可以测试软件的功能是否实现或完整实现。

　　性能指标：

该项目对性能的要求非同一般的软件项目。

性能测试往往包含了压力测试、攻击性测试等测试，软件所能承受的极限是多少，一般来说，软件的极限应当高出用户要求的性能，各种指标也应当为用户所了解。

　　易用性：

软件的使用界面在设计时，应当设法使之与功能的实现相脱离。

脱离的原因在于易用性是通过友好的界面实现的。

然而让开发人员以使用者的角度，来确定软件是否易用是件非常困难的事情，在确定使用界面时，往往需要多次反复修改，甚至只能在软件的最后交付之前或用户使用一段时间之后才被提出来。

需求变更管理

需求变更管理是web项目管理中最重要的一个环节，需求变更管理的有效性直接影响项目的成功与否。

对待变更的态度：

1、变更是不可避免的。

2、变更必须被管理。

3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。

需求变更管理的目标：

1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。

需求变更流程：

1、确定需求的基准线。

通常我们会以UserCase作为需求基准线，在UserCase确认之后的任何需求改变，都需要走需求变更流程。

没有走需求变更流程的需求将不被认可。

2、首先项目经理接收到需求变更的要求。

需求变更的提出者可以是项目中的任何人包括产品经理、客服、开发人员、测试人员等。

3、项目经理评估该需求变更。

项目经理可以召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。

项目经理作为项目的负责人，对项目的成功负有主要的责任。

所以需求变更的决策者应该由项目经理承担。

4、需求变更确认后由专人将需求变更记录下来（格式如下），通知给项目中所有成员。

其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。

包括（客户方代表，需求分析师，测试人员，相关开发人员）。

需求变更表的格式：

序号

变更提出时间

变更描述

变更类型（是对原有需求的修改还是新增需求）

原因

变更提出者

开发人员

对进度的影响（工作量）

5、相关人员接收到确认的需求变更后，做以下事情。

需求分析人员修改需求说明书和UserCase的相关内容。

测试人员修改测试用例的相关内容。

开发人员修改代码中的相关部分。

6、需求冻结

项目越到后期，需求变更对项目的影响就越大，所以在一定时候我们会进入需求冻结阶段，不再接收需求的变更。

1是否需要变更，做出判断

我的文章中提到：

项目经理收到变更申请后，项目经理可以召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。

2如果需要变更，会产生那些影响，做出相应的变更计划，包括可能影响的项目范围，进度，费用，质量等计划

对于确认的变更，会有需求变更记录表来描述该变更，当然你说的变更计划应该是非常全面，但对于web项目要求的时间性考虑，我觉得一张表格也可以说明问题，简单明了。

3确定变更的负责人

需求变更的决策者应该由项目经理承担，具体的操作者是SQA来承担，比如基线控制，变更记录，通知相关人员。

我的文章中有遗漏，没有明确这个人的角色。

5按照变更后的计划实施项目，并进行检查

对，变更后的实施反馈没有在我的变更流程中，这一点我是有考虑，但想到大部分需求的变更最终都要经过测试环节，所以我就没专门提到。

变更后的实施反馈还是比较重要的，我想还是根据项目的实际情况对这块裁剪比较好。

web项目经理手册-项目经理需要铭记在心的话

1、项目经理不是来管人的，而是来支持人的。

解析：

不光是项目经理，任何经理的职位都是如此。

但现实中很多人并不是那么做，这也是为什么他们没能把项目做成功的原因。

作为项目经理首先要端正态度，认识到这份工作职责的本质。

2、好的开始是成功的一半。

一个好项目的失败，往往是由于前期的准备不足、计划不周密。

所以在项目初期要舍得花时间做前期的需求收集、讨论、技术准备等工作。

尽管前期的工作看起来并没有直接产生效益，但这块工作做好了，后面的工作往往会事半功倍。

否则前期准备不足，很可能导致项目出现各种各样的问题（比如大量的需求变更等）。

3、什么样的项目最可能成功？

答案是：

项目越小成功的可能性越大。

项目经理和相关人员要仔细评估项目中feature的成本/价值比，尽可能缩小产品的规模。

有时候项目经理可能改变不了整个项目规模，但是项目经理可以采用各种手段来“缩小”项目，比如分期进行、迭代开发等。

4、任何对项目的改善无关的工作都是浪费时间。

在项目过程中项目经理不要做表面工作，或者对项目本身无意义的工作。

比如无休止的会议；

要求编写详细而最终没有用处的文档。

5、使用者的参与是项目成功的重要保证。

使用者可以是：

产品经理、需求方代表、或者客户。

在项目的各个阶段，项目经理要积极要求使用者参与到项目过程中。

通过这种与使用者不断的沟通、反馈，使得最终做出来的产品是客户真正想要的。

6、不要认为把任务交给团队成员，期间你可以不闻不问，到了完成的时间他自然会把任务交上来。

这种想法是非常错误。

这样做无疑会增加项目的风险，很容易出现该完成的任务没有按时完成，有些延误，这样项目后续的工作都会收到牵制。

正确的做法是：

当把任务安排下去后，你要定期和成员沟通完成的情况，询问是否需要支持，这样我们才能保证任务能按时保质的完成。

7、沟通要诀：

项目过程中与相关人员沟通时，不要总认为对方的出发点都是从项目利益考虑，他/她一定先考虑个人利益或部门利益，所以项目经理要做的是：

如何把对方的个人利益（部门利益）引导到和项目利益一致。

8、“加班”是一个危险的信号，表明一定是某个地方出现了问题，要找出进度落后的原因。

9、项目开始前，项目经理一定要找出项目的决策者是谁，谁对项目的产品有最终的发言权。

10、我们交付的不是程序，而是产品和服务。

web项目经理手册-风险管理

风险管理是web项目中项目经理最重要的工作之一。

风险管理是一个持续的过程，贯穿于整个项目过程中，风险管理包括风险识别、风险估计、风险解决以及风险管理策略。

在实际web项目中，项目风险主要表现为以下情况。

了解这些有助于项目经理在项目初期就识别出这些风险，并采取措施避免或者减少它们的发生。

一、web项目风险列表：

1：

需求变更风险：

需求已经打上了基线，但此后仍然有变更发生，对项目造成影响。

如何减少此类风险的发生？

（1）前期的需求讨论要详细、充分。

需求文档中需求的范围要明确、功能描述要清楚。

（2）需求文档中要有demo。

对于web项目，图片比文字更能说明问题。

（3）找出项目中需求的决策者（通常会是产品经理、相关职能主管、客服），所有的需求要经过他们的认可。

（4）客户在项目过程中的全程参与有助于降低此类风险。

需求讨论、需求确认、UserCase确认、测试阶段的客户验收等环节，都要要求客户参与。

（5）发生需求变更时，严格按照需求变更流程执行。

2、技术风险：

开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。

在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。

如果在可预期的时间内无法解决，可以要求需求方变更需求。

3、质量风险：

对于web项目而言，质量风险主要指开发代码的质量。

如何提高开发人员开发的质量？

（1）、制定项目计划时，对开发时间的评估要尽可能的合适。

合理的开发时间对开发质量的影响很大。

开发时间评估可参考【web项目经理手册-开发时间估算】。

（2）、有一套严格可行的代码规范，编码时严格遵守，codereview时严格考核。

（3）、在编码前，开发人员要对框架熟练掌握。

（4）、一份好的系统设计文档对指导开发非常重要。

4、资源风险：

项目所需人力资源无法按时到位，导致资源风险。

如何减少此类风险的发生？

这个就需要在项目计划制定的时候提前申请确认资源，并在项目过程中不断沟通协调。

二、项目风险管理的要点：

1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生的风险不属于风险管理的范畴。

这也说明项目经理的经验和知识对能否管理好风险至关重要。

2、详细明确的项目计划、以及项目执行过程中每个要点的质量保证是降低项目风险的必要条件。

3、风险报告是项目团队以及领导了解项目风险的一个有效手段。

风险报告的格式通常是：

web项目中有很多项目涉及到跨部门、跨公司的合作。

这类项目往往比其他项目更有挑战。

对于项目经理如何做好这些项目呢？

首先让我们看看这类项目都有哪些共同的特点。

1、合作双方工作在不同地方，对项目沟通造成一定影响。

2、合作双方隶属于不同的公司或