在高级产品经理眼中，好的项目管理流程是怎样的（中）

                                                在完成了项目计划阶段，进行了项目计划的任务分解、优先级排序、计划呈现和风险控制之后，就到了项目的执行和监控阶段了。这个阶段主要是针对项目执行的情况进行沟通，对整个项目的执行进度进行监控，使其在时间、质量、成本之间取得一定的平衡。

项目执行和监控

主要来说，这个阶段会包含下面这么几件事情：

过程跟踪：主要是对项目执行过程中的跟踪和监控，防止团队成员对计划理解产生偏差，导致执行阶段出现一些问题，跟踪的事物包含团队成员、任务、开支情况等；

例行项目会议：所谓的例行会议，其实就是要给一个项目制定一个固定的沟通渠道，这样才能让团队成员沟通效率变高；

阶段性交付物的审核：对于一个长期的项目计划，一定是会拆解为好几个实施阶段的，那么对于阶段性的交付物就有必要进行审核了，这也是非常重要的一个监控手段；

里程碑报告：项目达到了一个里程碑，那么就可以来一次里程碑的报告；

变更管理：为了适应项目运行过程中与项目相关的各种因素的变化，保证项目目标的实现而对项目计划进行的一些调整，我们称之为变更管理；

第一件事情，过程跟踪

产品经理为了掌握项目的进展，掌握各项工作的状况，就不得不进行项目过程的一个监控和跟踪。只有这样，出现了问题，我们才能进行适当的资源调整和进度计划调整，重新规划某一个任务的开始时间和结束时间，并记录实际的进度情况。
那么，产品经理在实际的工作过程中，到底如何进行项目跟踪呢，主要可以从以下三个方面进行考虑：
1、管事——监控项目的任务
有很多产品经理都有一个习惯，那就是在每天来到公司的第一件事情，就是跑到项目开发组那边去溜达一圈，把大家召集到一个地方进行项目站立会的召开，例会花不了多长时间，但是在监控项目任务进展方面起的作用却很大。一方面可以避免有些同事在项目过程中沉浸在自己的世界里，方向走偏了自己没有发现。另外一方面是能帮助大家克服人性上的懒惰因素，在每天汇报工作进度中给大家形成适度的压力。
每日站立会在同样的时间和同样的地点召开，会议准时开始，最好不要超过15分钟，每一个开发团队的成员都必须发言，会议中不进行讨论，发言内容需提供以下信息：

昨天完成了什么

今天即将做什么

遇到了什么困难

很多团队在召开每日站会的时候，还会结合看板来进行任务梳理，如下图这样的：

每日站会看板
通过这样一种简单的会议形式，就可以让项目组的所有成员知晓各任务的最新进展。这样才能监控哪些任务的进度落后于计划，并采取相应的措施给予纠正（通常就是加班啦），尽量不使项目的进度受到影响。当然，我们不光要知道任务的进度落后，还需要去了解落后的原因是什么，这样才能根据具体情况采取不同的措施来使得项目恢复到正常轨道上来。
比如，某一个任务的进度落后于计划，发现原来是任务分解的时候漏掉了这个任务或者这个任务没有责任到人，那么在发现了这一情况之后，可以采取的措施有：让开发加班搞定、增加人力投入、延长时间、或者更换效率较高的成员来完成任务。这些都是补救措施，我们再补救完了之后，其实还可以进一步的思考，是不是我们的项目管理流程上面哪里有什么欠缺，是否可以改进工作流程、方法和工具，这样就减少上述情况的发生概率。
2、管人——监控项目的团队成员
大家不要误解为是让产品经理去做间谍之类的角色，混迹于项目组成员中偷取情报什么的。其实，这里所谓的监控项目的团队成员，更多的是去记录下项目组每个成员的表现，对表现突出的给予赞赏和肯定，对表现不好的则应提出相应的批评（当然，很多时候产品经理其实并不是开发部门的领导，措辞什么的还是注意一下为好）。
另外一点，产品经理要去多和项目组的成员进行沟通，这种沟通不仅仅是工作上的沟通，还可以聊聊生活方面的东西，这样不仅可以促进你和项目成员之间的关系，还能及时知晓他们的生活状态，也是有利于项目管理的。
3、管钱——监控项目的开支
一般的软件项目开发并不会涉及到项目开支的问题，因为基本所有的开支都是人力成本。但也有特殊情况，尤其是运营活动相关的项目管理，就经常会涉及到项目开支的问题，这里的监控其实主要是记录下所有的开支流水，看下与项目计划初始阶段的预算相比是否有超出的情况。这个时候可以好好和运营的相关同事进行沟通，找出具体的费用超出项，分析原因找到相应的解决方案。
第二件事情，例行项目会议

管理学大师彼得德鲁克有一句名言，叫做“管理就是沟通，沟通，再沟通”。事实上，我们细想一下，在项目管理的实践过程中，我们是不是经常会碰到下面这些情况：
比如说项目老板隔三差五就跑来询问项目的进展情况，其实是因为没有人给他汇报项目的进展，但老板又比较担心；
再比如说，你把需求的第一部分通过邮件发出去后，没有人回邮件提出自己的意见和疑问，你也以为这个需求会很顺利的走下去，但是那天无意间和团队成员聊起需求，那个成员马上提出来自己的异议，巴拉巴拉说了一通。有的时候你不去问，别人是不会主动来告诉你他的想法的，这个时候可能自己才意识到，其实是需要给团队一个沟通的机会来聊这些东西；
还有，在项目实践中，问题早就已经出现了，但是过了一段时间才通知项目团队的所有成员，这样就导致了大家对于项目进展的信息不对称，很容易导致工期滞后的情况发生；
所以，在项目管理的过程中，沟通是不能忽视的一个重要环节。再说的直白一点，项目负责人最重要的工作之一就是沟通，所要花费的时间可能要占到工作的75%～90%。因为只有良好的沟通，才能获取足够多的信息，才能发现潜在的问题，这样才能更好的控制项目的各个方面。
前面我们提到了项目有相关干系成员，但由于每个成员的岗位和职责不同，所以每个人关注的项目信息不一样，他们关注信息的频率其实也不一样，有的比较频繁，有的则可能整个项目过程就问那么两三次。由于每个人的习惯不同，所以他们获取信息的手段也不太一样，有些人喜欢微信、QQ，有些人喜欢邮件，还有些人喜欢以会议的形式获取信息。
这样的话，就很有必要建立起一套属于本项目的一个沟通机制，统一一下沟通的方法和渠道，比如说最紧急的事情可以通过电话沟通，比较紧紧的事情则通过微信或者QQ沟通，而不是那么重要的事情，则放在每日站会或者是项目周会的会议上进行解决。同时，还应该在团队里提倡主动沟通的精神，这样不仅能建立团队之间的亲密关系，更能表明成员参与者对项目的一个重视程度。
第三件事情，阶段性交付物的审核

在项目进展的过程中，会产生不少的交付产物，产品经理在管理项目的过程中，可以对以下几项阶段性的交付物进行审核，以确保整体项目的计划和执行不会出现大的偏差：
1、需求清单
产品需求清单是一个排序的功能需求列表，是一个持续完善的清单，包含所有产品需要的东西，也是产品需求变动的唯一来源。产品需求清单包含所有的模块、功能、特性、需求描述、商业价值、优先级描述等。
需求清单的内容、可用性、优先级等仅由产品经理负责管理。
2、任务清单
任务清单是一份足够具体的计划，包含对需求清单的任务分解。开发团队在整个迭代过程中都会修改这份清单，比如开发团队对需求有了更多的了解，需要增加一些新的开发任务到清单中去。
任务清单的修改只能由项目经理（产品经理）负责，该列表是用来明确项目团队成员的任务的。
3、项目周报
项目周报是对项目组本周工作内容的总结、以及下周的工作计划安排的汇报，同时项目周报需要及时反馈本周工作中存在的问题以及需要领导协调的资源。
项目周报中切忌报喜不报忧，要反映项目的真实情况。
第四件事情，里程碑报告
当项目进展到一个关键节点，这个时候出现了一个里程碑式的事件，里程碑代表项目生命周期中的重大事件，是衡量项目总体进展的一种高层次的方法，能用于向项目利害关系者和项目组报告高层次的进展情况。
另一个方面来说，在项目进展过程中，通过让项目组成员了解他们为实现里程碑付出的努力，而里程碑的实现对鼓团队成员也是非常有用的。
比如说，在每个迭代结束后，项目组成员聚在一起召开总结会议，回顾一下在本次迭代过程中，哪些是做的好的，哪些是做的不好的，找出潜在的可以改进的事项，作为将来的改进计划。迭代总结会议记录就是这样一份将会议过程记录下来的清单已经后续跟进的依据。
通常的里程碑事件有这么一些：需求分析、详细设计、系统开发、系统测试、正式发布等，产品经理在管理自己的项目时，可以根据自身项目的一些关键节点来做一下里程碑式的总结，达到项目汇报的目的。