项目经理 Workflow
一、项目准备工作
1. 需求确认
需求确认是整个项目经理工作流的核心部分，也是整个项目的基石，接下来的设计研发流程都是基于既定需求展开的。一个合格的项目经理需要充分了解项目需求和业务逻辑，并确定需求边界和需求中的模糊点。
1.1 需求评估会
参会人员：客户需求发起人或客户经理、项目经理、产品经理、技术经理
会议流程：
- 与产品经理一起了解客户一手需求。
- 记录需求模糊点和疑问与客户确认。
- 充分了解需求后与客户最后确认一次，看双方理解是否清晰无偏差。
- 与产品经理商讨项目方案。
- 与技术经理讨论方案的技术可行性，如不可行回到上一步，可行进入下一步。
- 与技术经理确认项目技术路线，确定需求中的难点和风险点，再次确定方案的可执行性。
- 向客户表述我方给出的方案，如客户不接受，回到第4步，如客户接受该方案，进入下一步。
- 主动向客户表诉我方验收流程以及验收输出的文档，如客户提出有自己的验收流程和要求，则需在人天排期中记录此部分额外工作量。
1.2 需求人天初步评估
在了解需求以及确认具体方案后，我们需要给到一份初步评估的人天报价表，这份评估表会给到客户，客户如果觉得评估合理，确认可以接受，则会进入设计确认环节。具体步骤总结如下：
- 协调公司人力资源，确定参与该项目的研发人员。
- 根据参与人员、方案和技术路线初步进行评估，输出一份人天报价表。
- 如客户不能接受该报价，需通知商务进行协商。
- 如客户最终认同并接受该报价表，必须邮件与客户确认，并抄送相关干系人，随后进入设计确认环节。
2. 设计确认
客户确认方案及人天评估后进入该流程，步骤总结如下：
- 确定客户设计风格以及定制要求。
- 根据客户需求给出多个设计方案。
- 客户确定设计方案后，设计出图。
- 设计完毕后，与客户确认设计稿是否符合客户需要。
- 客户确定设计满意无误后，必须邮件与客户确认，并抄送相关干系人，随后进入排期确认环节。
3. 排期确认
设计邮件确认后，进入排期确认环节，此时需要根据确认的设计稿给出准确的排期，排期注意点如下
- 排期表的人天可以和之前的初估人天有出入，但需说明每个人天变化的原因，有理有据，让人信服。
- 排期表应根据设计稿准确排期，排期的每个功能点应拆分的足够细，颗粒越粗的人天排期风险会越大。
- 排期表如客户有异议或疑问，应积极主动的和客户沟通，协调排期，让双方达成共识。
- 排期表双方确认后，应将排期表发与负责人或商务，接收到开发通知后即可开始开发。
二、项目研发工作
4. 每日进度把控
4.1 每日站会
站会意义：了解团队成员的工作情况和工作状态，识别出问题和风险，并及时协调和解决。
参会人员：项目经理、项目开发人员
站会主题：
昨天我们为本项目做了什么？
今天我们计划为本项目做什么？
各成员是否需要什么帮助以更高效的工作？
昨天遇到了什么阻碍或问题？
站会要求：
- 准时开始，强调时间观念。
- 控制站会时间，一般15分钟以内，不要讨论站会主题之外的内容。
- 站会氛围尽量轻松活泼。
- 项目负责人记录站会问题，并会后及时跟进解决。
4.2 下班前进度 check
每日下班前15分钟由项目负责人 check 一下团队成员的当日任务完成情况，并总结自己的任务分配是否有不合理的地方，并为第二天的站会工作分发做好准备。
5. 每周进度汇报
积极的沟通有利于维护客户关系，作为项目管理者，我们应每周与客户方进行一次进度汇报，汇报总体思路如下：
- 本周我们完成了什么工作？
- 下一周我们要进行什么工作？
- 本周工作中是否有风险点？（如有风险点应与客户说明原因并积极寻找解决方案）
6. 里程碑验收
在排期中，我们会把整个项目拆分成粒度较小的功能点，这些功能点我们可以理解为是一个里程碑，每个里程碑功能的完成都应和该需求的提出人进行功能演示和验收。
里程碑验收的意义：快速迭代，有利于提早发现风险点。如果最后交付时才发现有一些需求有出入，这时再去修改不仅容易牵一发动全身，还会大大增加整体项目的按时交付风险。
7. 需求变更确认
在里程碑验收的期间，如客户发现实际研发的功能不能满足需求，想要做一些额外的修改时，则会引发需求变更，需求变更确认步骤如下：
- 客户提出需求与理想不同，要求修改功能。
- 项目经理识别该修改是属于我方开发问题还是需求变更。
- 如是我方原因导致的应主动修改，并总结记录原因。
- 如确认为需求变更，应和客户积极沟通，有理有据的说明该需求是属于需求变更。
- 如客户承认并接受该需求属于变更，则与客户协调排期，追加报价，与客户、商务邮件确认后进行开发。
- 如客户拒绝承认该部分属于变更需求，或无法接收排期变动时，应联系商务进行协商处理。
三、项目收尾工作
8. 项目正式验收
项目全部开发完毕后进入正式验收环节，验收标准与规范参考验收标准与规范。
验收流程：
- 确认功能全部开发完毕，测试通过无 bug。
- 通知客户进行远程验收演示并记录验收过程。
- 客户确认验收验收无误后，发送验收邮件，同时附件包含验收材料。
- 积极推动客户查验无误后回复验收邮件。
- 客户回复验收邮件后，通知商务进行后续尾款回收流程。
9. 项目交付文档编撰
完整的验收交付需要配合交付文档，详情参见文档材料合集验收材料部分，文档编撰注意事项如下：
- 格式规范，可读性强。
- 注意措辞文笔，清晰有条理，。
- 如客户有额外文档需求，应严格按照客户文档规范去编撰。
10. 项目总结
每次结项后针对本次项目开展一次项目总结会，氛围尽量轻宽松自由，全 team 成员参与，畅所欲言，一起分析总结经验和不足。
意义：
分享好的经验， 促进团队不断进步
总结本次项目的不足之处，避免同样的错误再次发生
有利于团队建设
主题：
- 这个项目哪些地方我们做的好？
- 这个项目中哪些地方我们可以做得更好？
- 下个项目准备在哪些地方改进？
11. 项目后期运维
项目结项后，可能会涉及到后期运维的情况，这里需要区分是本身软件 bug 引起的还是由客户方引起的，例如：客户服务器迁移、功能需要变动等都属于客户原因，这时需要额外走商务报价流程后进行后续开发，如果是本身软件 bug 则需由我们负责修复。