项目经理日常工作手册

项目经理日常工作指导手册
文档版本号：V1.0 文档编号：1809001-NBSC 编写人：-LEO- 编写日期：20180905
xxxxxxxxxx有限公司
年月
目录
一、概述 (4)
二、工作要求与职责 (4)
三、项目管理三角 (4)
项目范围管理 (5)
项目进度管理 (5)
项目成本管理 (5)
四、项目过程管理 (6)
1.项目立项 (6)
2.项目实施组织准备 (7)
3.项目需求分析、整理 (7)
4.项目范围确认 (8)
5.团队需求澄清会 (10)
6.关键流程研讨 (12)
7.关键算法研讨 (13)
8.项目开发进度计划研讨 (13)
9.项目开工会议 (14)
10.每日早会 (15)
11.日清日结 (15)
12.代码审查 (16)
13.操作手册审查 (17)
14.项目环境部署 (17)
15.项目上线 (18)
16.操作培训确认 (18)
17.需求跟踪管理 (19)
18.项目风险报告 (20)
19.阶段验收组织 (20)
20.项目总结 (21)
五、沟通管理 (21)
项目沟通的对象 (21)
项目沟通的方式 (21)
六、多项目管理 (22)
时间管理 (22)
资源配置 (23)
七、项目管理工具 (23)
一、概述
项目经理工作手册是用来指导项目经理对实施过程进行有效管理的重要参考文档与工作规范。

公司要求合同金额在五万以上项目，必须建立项目经理负责制进行项目管理。

本手册以项目管理过程中的“关键二十项”，“项目管理三角”，“项目沟通管理”以及“多项目人力资源配置管理”，为重点内容进行工作规范与指导。

优秀的项目管理将在管理信息化领域内形成公司自身的核心竞争力。

二、工作要求与职责
获取商务阶段形成的合同、协议或各种口头承诺等与项目实施有关资料，归集整理并形成书面的项目实施确认单；及时与客户进行沟通，调研、分析、确认需求范围；制定并执行项目实施计划，组织项目团队完成项目任务，保证项目完成时间和完成质量。

三、项目管理三角
任何项目都会在范围、时间及成本三个方面受到约束。

项目管理，就是以科学的方法和工具，在范围、时间、成本三者之间寻找到一个合适的平衡点，以便项目所有干系人都尽可能的满意。

项目是一次性的，旨在产生独特的产品或服务，但不能孤立地看待和运行项目。

这要求项目经理要用系统的观念来对待项目，认清项目在更大的环境中所处的位置，这样在考虑项目范围、时间及成本时，就会有更为适当的协调原则。

项目范围管理
项目的范围管理就是规定项目的任务是什么？作为项目经理，首先必须搞清楚项目的商业利润核心，明确把握项目发起人期望通过项目获得什么样的产品或服务。

对于项目的范围约束，容易忽视项目的商业目标，而偏向技术目标，导致项目最终结果与项目干系人期望值之间的差异。

因为项目的范围可能会随着项目的进展而发生变化，从而与时间和成本等约束条件之间产生冲突，因此面对项目的范围约束，主要是根据项目的商业利润核心做好项目范围的变更管理。

既要避免无原则的变更项目的范围，也要根据时间与成本的约束，在取得项目干系人的一致意见的情况下，合理的按程序变更项目的范围。

项目进度管理
项目的进度管理就是规定项目需要多长时间完成，项目的进度应该怎样安排，项目的活动在时间上的要求，各活动在时间安排上的先后顺序。

当进度与计划之间发生差异时，如何重新调整项目的活动历时，以保证项目按期完成，或者通过调整项目的总体完成工期，以保证活动的时间与质量。

在考虑时间约束时，一方面要研究因为项目范围的变化对项目时间的影响，另一方面要研究因为项目历时的变化，对项目成本产生的影响。

并及时跟踪项目的进展情况，通过对实际项目进展情况的分析，提供给项目干系人一个准确的报告。

项目成本管理
项目的成本管理就是规定完成项目需要花多少钱。

对项目成本的计量，一般用花费多少
资金来衡量，但也可以根据项目的特点，采用特定的计量单位来表示。

关键是通过成本核算，能让项目干系人了解在当前成本约束之下，所能完成的项目范围及时间要求。

当项目的范围与时间发生变化时，会产生多大的成本变化，以决定是否变更项目的范围，改变项目的进度，或者扩大项目的投资。

在我们实际完成的许多项目中，多数只重视项目的进度，而不重视项目的成本管理。

一般只是在项目结束时，才交给财务或计划管理部门的预算人员进行项目结算。

对内部消耗资源性的项目，往往不做项目的成本估算与分析，使得项目干系人根本认识不到项目所造成的资源浪费。

因此，对内部开展的一些项目，也要进行成本管理。

由于项目是独特的，每个项目都具有很多不确定性的因素，项目资源使用之间存在竞争性，除了极小的项目，项目很难最终完全按照预期的范围、时间和成本三大约束条件完成。

因为项目干系人总是期望用最低的成本、最短的时间，来完成最大的项目范围。

这三个期望之间是互相矛盾、互相制约的。

项目范围的扩大，会导致项目工期的延长或需要增加加班资源，会进一步导致项目成本的增加；同样，项目成本的减少，也会导致项目范围的限制。

作为项目经理，就是要运用项目管理的九大领域知识，在项目的五个过程组中，科学合理的分配各种资源，来尽可能的实现项目干系人的期望，使他们获得最大的满意度。

四、项目过程管理
项目过程管理以过程控制的二十个关键事项进行规范。

对于项目经理考核基本以该二十项工作执行情况作为评价依据。

1.项目立项
在接到销售部门的项目移交之时，应该立即确认在商务阶段形成的合同、协议，以及各
种口头承诺，归集整理形成书面的《项目立项书》，确保项目做且只做所需的全部工作。

01.项目立项书.do
cx
2. 项目实施组织准备
项目实施组织准备是指确定双方的项目实施工作成员构成、角色工作职责、联系方式，建立《项目干系人登记表》，为项目实施提供组织资源的保障。

对外，确定对于项目需求起决定性作用的高层人员、甲方项目总体负责人、业务需求负责人，双方商务对接人。

对内，确定项目开发组各岗位技术骨干、开发人员、测试人员、项目交付责任人。

找准项目干系人，特别是潜在的支持者和反对者，对项目干系人的沟通进行管理，以满足项目干系人的需求并与项目干系人一起解决问题。

对项目干系人进行积极管理，可促使项目沿预期轨道行进，而不会因未解决的项目干系人问题而脱轨。

同时进行项目干系人管理可以提高团队成员协同工作的能力，并限制对项目产生的任何干扰。

对于在本项目中利益程度高，对项目影响程度高的项目干系人应进行重点沟通管理，项目最终的成功是以满足干系人期望为唯一标准。

04.项目干系人登记表.doc 项目干系人案例分
析.doc
3. 项目需求分析、整理
项目需求的分析整理，包括客户方业务需求的细化明确和实施工作量的评估。

与甲方项目关键干系人就需求一层一层展开并进行细节确认。

1)抓住关键业务流程主线，再扩展支线逐步完善，避免遗漏；
2)通过可视化原型展示探讨界面交互体验并达成一致；
3)获取初始化组织结构、角色、用户、编码规则、算法公式等数据并进行整理；
4)排列业务场景优先级。

项目经理需要把客户的业务需求按照优先级的顺序进行整理，超过一个月工作量的项目必须整理成为多个迭代。

然后把一个个的迭代拆成一个个可验收的story。

story是一个个独立的，可验收的功能，一个业务需求可以拆分为多个story。

比如：我们常见的账号管理需求，需要对账号进行增、删，改、查。

因为添加、修改、删除、查询都是一个个可单独验收的场景，我们可以把账号管理需求拆分为四个story。

需求拆分的原则是：
1)story是可以独立验收的场景
2)story包含的工作量点数应该尽量小，一般划分为1、3、5个点，如果超过了应该
重新拆分该story。

给story工作量评估的标准是什么了？我们可以按照一个查询完成的工作量是1
个点，然后衡量该story的工作量而适量的评点。

3)注意story完成的工作量中包括自我测试和联调的时间。

而不是单独的只是开发完
成。

4.项目范围确认
项目需求调研应该产出项目原型、《项目需求范围说明书》。

项目需求范围说明书是对前期客户的调研理解、需求分析与实现等形成的方向性指导文件，对于后期的项目开发进度计划与目标范围进行了基本的界定。

需求确认后，将确定的需求录入《项目需求跟踪表》，以便在项目实施过程中对需求的变更进行持续的管理。

项目范围确定主要是确认项目功能点、业务场景、业务逻辑交互（原型）等，有助于项目双方在项目看法上达成一致，形成基本规约，避免项目范围与项目计划不明确、进度不可控的局面出现。

项目需求范围说明书和项目原型必须经过双方项目经理组织项目组成员讨论，并经审核与签字确认生效。

项目范围确认可以在项目需求确认会议召开时一起完成，较小项目（5万以下）也可以单独组织，最终以双方签字确认的文件作为项目实施的指导性文件。

项目需求确认会一旦召开通常具有很重要的意义，《项目需求确认会会议纪要》是经过需求详细分析后对合同的补充说明，通常与合同具有同等效力，切记。

项目需求确认会由项目经理发起，参会人包括甲方项目关键干系人、双方商务负责人、开发团队骨干代表等，标志着项目正式进入开发阶段。

项目经理要准备以下内容：
1)与甲方确定会议时间、地点、会议议程
2)合同范围讨论：仔细研究合同及合同附件，合同范围与招标要求是否有不符合项？
己方是否有漏报？需要在会上讨论清楚。

3)建立双方沟通渠道（技术、商务等）。

准备初步进度表，在开工会讨论后定稿。

4)双方互提的文件清单及提交进度。

5)一些主要技术问题的框架性讨论，比如：技术方案，设备材质、品牌、产地等。

6)甲方需提供的资料准备要求，如：域名、服务器选型、微信，小程序的申请准备等。

就以上讨论内容形成会议纪要，双方签字。

08.会议纪要.doc
02.需求范围说明
书.docx
5.团队需求澄清会
需求澄清是与开发团队成员采取面对面的方式进行需求的讲解、分析、评价，最终达成一致理解。

需求澄清在向团队成员解析需求时，需要做到以下几点，防止价值点的丢失。

1)功能点：需求包含了几个功能点
2)约束条件：每个功能点有什么约束条件
3)流程图：功能点的业务流程是怎样的
4)如果有界面需要有页面元素图以及说明
5)验收场景：验收不同于测试用例（测试用例更细，包括数据边界、性能等），验收
主要用来模拟用户的行为以及期望的响应
Example:以简单的登录描述一个story需求
功能点：
1)用户可输入用户名、密码。

可选择勾选自动登录、记住密码。

响应登录按钮。

2)当点击登录时：
a)判断用户名、密码是否为空，有则提示用户。

提示语为：用户名/密码不能为空
b)记录用户名、密码的自动登录以及记住密码状态。

c)发起登录请求，并响应登录状态。

成功则跳转到系统主页，失败这停留在登录页并
提示用户失败原因。

3)启动登录界面时，读取配置文件，访问自动登录和记住密码的状态。

如果记住密码为真，
自动登录为假，则启动登录界面时用户名和密码为上次登录退出时的用户名和密码，用户点击登录按钮，系统响应登录状态；如果自动登录为真，则直接执行登录事件
约束条件：
1)用户名必须以字母开头，并且包含字母、数字，长度不小于6位不大于12位，当输入
框焦点切换到密码输入框时，系统自动验证输入的用户名合法性。

2)密码必须包含字母、数字，长度不小于3位不大于12位，当点击登录按钮时，响应登
录事件前，系统自动验证输入的密码合法性。

3)密码以*隐藏。

流程图
界面(低保真，如果UI已出应采用高保真)
验收
作为我想期望
登录用户输入用户名可以输入
输入密码可以输入，并*代替
选择记住密码、自动登录可以选择、取消
点击登录
成功，跳转到工作台主页
失败，停留在登录页面，并提示失败原因验证记住密码效果重新登录时，不用重新输入用户名，密码验证自动登录效果进入登录页面时，自动执行登录事件
6.关键流程研讨
在项目实施中，首先要对客户的业务流程进行梳理，规范管理，然后固化到软件应用的流程中去。

在流程梳理中，经常遇到一些特殊的业务流程，可能是原来不合理的习惯做法，也可能是一些行业个性，这个时候必须项目经理介入讨论，坚持原则，寻找合适的解决方案，而不
是一味的迁求对方，以顺利推进项目实施。

7.关键算法研讨
在项目规划中，除编码规范、流程梳理外，很多决策信息与管理材料需要输出，而输出内容的算法规则也就成为其中的关键。

要保证项目合理成功的推进，对于关键算法的理解，将直接影响系统的配置与运作思路。

如薪资的核算方法、成本的核算方法、配货的排序与分配方法。

8.项目开发进度计划研讨
项目开发进度计划的安排，要根据甲方合同要求，按照项目实施指导原则“总体规划、分步迭代实施、突出重点、尽快见效”进行计划开展。

项目开发进度计划的制定一定要进行双方项目组成员的充分研讨后确定，千万要避免主观与不切实际。

项目开发进度计划可以以甘特图进行描述，标明每一个里程碑节点和验收标准，并提交双方领导签字确认。

项目开发进度计划一旦确定，具有相当的法定约束力。

《项目开发进度计划》应该尽快通报所有关键干系人，以指导双方工作安排。

项目进度计划在规划阶段的制定往往都是初步的，在项目实施执行过程中，项目经理要根据实际情况进行及时的调整与更新，留下变更痕迹，并同步通报所有相关干系人。

05.项目开发进度
计划v1.0.mpp
9.项目开工会议
项目开工会议在项目实施过程中是一件很重要的事情！开工会举行的好坏会影响整个项目在执行阶段的顺畅度。

项目开工会议是规划阶段结束时召开的会议，召开前，应该已经确定了项目组的组织结构，并已经对团队成员的角色与职责进行定义；应该已经有客户签字确认了的项目范围说明书和原型、项目开发进度计划、项目风险分析等文件。

会议结束后，项目经理需要完成几件重要的事情，
明确达成共识，形成《会议纪要》以邮件或其它书面形式同步所有项目关键干系人。

明确后续工作，以邮件或其它书面形式同步所有项目关键干系人。

进行会议总结，包括会议目的是否达成、组织是否良好，需要改进的方面等。

开工会议的召开完成，意味着项目开始进入执行阶段。

开工会议的召开是为了和项目的关键干系人（甲方项目负责人-可选、商务-可选、开发团队成员等）来一起审查和澄清项目目标和项目执行计划。

审查和澄清是为了把项目的范围、进度、预算、风险和项目的执行方面采用面对面的方式与干系人来沟通，以确保大家对于项目的实施有共同的认知。

1)宣布团队成立
2)跟干系人同步项目背景、目标、进展、计划
3)确定项目里程碑，项目各岗位负责工作授权，统一思想，鼓舞士气
公司五万以上项目必须召开开工会议，十万以上项目必须邀请甲方项目负责人和商务负责人参加。

10.每日早会
开发团队通过每日早会来确认他们仍然可以实现迭代周期的目标。

这个会议每天在同样的时间和同样的地点召开。

每一个开发团队成员需要提供以下三点信息:
1. 从上一个早会到现在,我完成了什么; 从现在到下一个早会,我计划完成什么; 有什么阻碍了我的进展。

2.每日会议中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。

通常，许多团队会在每日会议之后马上开会处理他们遇到的任何问题。

3.每日早会既不是向任何人汇报。

它是一个开发团队内部的沟通会议,来保证他们对现状有一致的了解。

只有开发团队的成员,包括产品、测试可以在会议中发言。

其他感兴趣的人可以来旁听。

在必要时, 开发团队会基于会议中的发现重新组织他们的工作来完成本次迭代的目标。

11.日清日结
日清日结在于对今日事，今日毕做一个工作机制上的约束，为绩效考核提供合理的工作方式和公平的工作机制环境，有利于激励贡献者。

以项目开发进度计划为基础，通过早会跟踪计划中每日各团队成员应完成工作任务（加上临时调整工作任务），每日早会对当天工作进行细化安排，并与团队成员达成一致。

每日下班前30分钟，项目经理应检查每一个团队成员一天的工作情况，对早会布置工作的情况进行判断，并对已经完成或者正在进行的工作进行评价、改进讨论。

项目进入测试阶段后，日清日结的定义时必须完成截止到今天16点前所有的bug修复，项目经理要进行复查修复情况。

没有特殊原因的情况下，项目经理应坚持日清日结的原则，督促团队成员完成当天工作
后方可离岗。

12.代码审查
代码可读性高与不高没有统一的标准。

我们不能说一个抽象性极好，灵活度极高却让人十天半个月都难以搞清楚的代码的可读性高，也不能说一个长达几千行却从头至尾逻辑性比较好的代码的可读性差。

那么怎样的代码才算是合理的，才算是可读性高的呢？不同之中必有共性，那就是经过审查的、能够被项目组其他成员接受并能尽快看懂的代码就是可读性好的。

软件开发的主要时间是花费在调试上，然而调试中花费的大部分时间又在于读代码。

倘若之前开发该模块的人员已远在天边，面对几千行混乱无序的代码任谁都难以承受。

因而花费成本在代码走查上是值得的，而且是必须的。

代码审查视项目大小和周期长短由项目经理决定审查周期。

从参加人员来说，应该是项目的整体参与者，如果项目太大，整体参加的成本很高，那么可以以模块为组进行走查。

从走查时间来说，建议在每个模块开发完成之后进行，便于开发人员之间交流问题以及体会，并且每个人的讲解时间不要超过30分钟，因为模块的业务复杂度不会那么复杂，30分钟都讲不清的业务逻辑如何保证代码是清晰的。

从走查的结果来说，经过走查的代码应该是参加成员大部分能认同的，并且参加者每个人都能读懂的逻辑清晰的代码，并且通过交流提高项目成员的凝聚力，提高其业务认知度，最好能形成项目之间可以共同使用的产品。

代码审查的主要问题分类：
1)注释没写，或者格式不对，或者毫无意义
2)没遵守代码规范要求
3)重复现成的代码，或者开源项目，或者公司已有代码
4)代码有更好的写法
5)代码存在性能瓶颈，可以有提高方法
6)代码逻辑错误
7)业务逻辑错误
每次代码审查完成，整理成代码审查报告，记录审查出的问题，相关责任人，整改方案，整改完成时间，审核人等。

在下一次代码审查时再对有问题的代码进行审查确认。

13.操作手册审查
操作手册是根据项目实施方案的指导要求，再根据客户的需求进行全面的软件配置与系统测试基础之上，编写而成的操作人员工作指南。

操作手册的编写质量将会直接影响项目的应用执行效果，以及一线操作人员对于实施方的满意度。

操作手册必须经过项目经理审查简单易懂、无操作技术门槛，业务逻辑正确，由项目经理签字后才能正式发送给客户。

14.项目环境部署
项目环境主要分为开发环境（DEV）、测试环境(UAT)、生产环境(PROD)。

在项目开发阶段，项目经理应部署开发环境用于开发人员代码整合、运行、调试。

开发环境通常打开全部错误报告。

在项目测试阶段，一般克隆一份生产环境配置建立测试环境，对项目进行整体测试。

内部测试通过后，测试环境作为用户验收测试环境提供给用户做接受度测试。

客户测试验收后，项目达到上线交付要求，项目部署到客户提供的生产环境。

项目在生产环境需要关闭错误打印输出，打开错误日志管理。

15.项目上线
项目经过测试达到合同约定条件，符合需求范围说明书要求，经客户确认而进入生产环境或试运行的项目阶段。

项目上线应保证客户代表及项目经理对上线的完成进行确认并形成文件备查。

项目集成测试（必要时要包含性能和负载测试）完成后，在模拟生产环境部署并邀请客户进行上线前验收。

客户签署验收确认单后，项目经理及主要项目成员要与业务部门或客户一起进行上线前的准备工作，并完成《用户操作手册》、相关账号资料、数据初始化等上线必备文档的确认工作。

项目上线前必须要完成客户验收和财务结款。

上线准备工作完成后，应取得业务部门或客户允许上线通知，技术部门负责人签字同意后，方能进行上线实施工作。

在客户生产部署后，项目组要对生产环境系统进行上线验证，确保生产环境版本正常使用。

16.操作培训确认
在组织操作人员培训后，应该对培训人员进行相应的考核，以确认操作人员的操作能力，作为以后需要再培训与重点辅导的依据。

在个别项目中，操作培训完成也可能是项目收款的里程碑事项，需要项目经理进行重点关注。

另外，在很多客户单位中，在培训应用后不久，客户单位出现岗位人员变更，对于没有培训进行操作而导致问题产生的，可以作为明确责任的依据。

17.需求跟踪管理
新需求的产生是在项目实施过程中必然发生的，一意地回避需求只会产生项目实施过程的紧张。

项目经理必须全面管理项目过程中提出的需求，需求的分析报告，是否提交客户，获得的答复，以及现在所处的阶段，对需求的状态进行管理（已提交、已计划、已开发、已解决等）。

需求管理的目标是明确需求的紧迫程度、实现难度，进行分类管理与全过程跟踪，因此需求归集、需求谈判与需求跟踪是需求管理中的几大关键环节。

需求归集，是根据客户提出的需求进行及时的收集整理，用《用户需求跟踪矩阵》进行结构化的梳理，以便于跟踪。

需求谈判，不是客户提出的需求都是必须做的，可能是客户的硬件与操作系统配置等方面的原因，也可能是实施顾问的培训与配置没有到位引起的。

需求谈判就是要与客户建立一种需求实现时间的约束规则：
什么需求是由甲方通过硬件与操作系统升级或改进等方面解决；
什么需求是通过实施顾问的培训与配置解决；
什么需求是通过研发解决。

对于确实是研发解决的需求，应该根据客户的紧急程度与实现难度，进行多次与研发沟通获得需求的时间分类如：
第一类，如错误等立即解决（或几天内解决）；。