背景

互联网公司的产品经理基本上是身兼数职，设计，交互，产品，需求，项目多个端口都需要产品经理一人完成，可能会有大公司或者较好的组织规范流程的公司会把各个角色的分工在项目开始之前就定义的非常清楚，但实际上大多数情况下你我作为数据产品经理更多的都要把除了实际开发任务以外的所有内容全部管了，自己也是从产品经历的视角不断的向外拓展，在主导多个项目在推进，过程当中公司也组织过相关项目管理的培训，自己也阅读过一定的书籍，但实际上书本上的培训能为你在实际的工作做到的支持非常有限，甚至是毫无卵用，还是得靠不断的尝试和碰壁，总结出属于自己的一套实践心得。特此将自己的实践心得沉淀下来，记录成文，如果你是产品经理同时也在身兼项目经理，你不清楚这个对你来说略有生疏岗位应该做好哪些事情，希望本文能给你有点启发。

项目管理能力拆解

以一个从产品经理过度项目管理的角色来看看如何进行项目管理，从产品实现的几个环节节点来看，需求承接设计锁定；需求开发实施交付；用户试用验收上线；就三个大的节点，项目管理能力也是围绕这三个大的节点进行的构建，其中“需求承接设计锁定”要做好“任务控制”，“需求开发实施交付”要求项目经理要做好“任务拆解”，“客户试用验收签字”要做好“任务完成”，做好这三点，不能说你成为一个资深的项目经理，但绝对可以正常推进项目进程。

我们分别来看这三项能力，下面我们通过给自己提问题的方式来检验当前是否已经完成，

一、做好需求控制

1.锁定需求

问题：“什么时候可以锁定需求务实施范围？”

toB 项目，在已经确认可以进行项目进入实施的时候，虽然标书已经确认好了项目范围，但项目经理仍然在 开始实施关注一个点，“什么时候可以锁定需求实施范围？”当然如果项目很大，需求可能是逐步确认的过程，但是一定要有需求确认的这个流程，不管是以项目邮件的形式还是成文签字的形式，具体情况需要和商务，客户进行沟通来协定。

这里会出现项目管理当中的一个重要场景，即“客户预期过高，需求控制不了，出现需求蔓延现象”，其实我个人认为也很好解决，如果已经明确超过了合同范围就提出增加成本的理由，如果没有超过属于“售前商务的坑留给项目填”的情况，则和商务沟通，由商务进行主导进行处理解决

2.验收标准

问题：“如果需求开发完成，接下来怎么做就算是达到了交付的标准”

一般来说，这里可能就是一个流程，搞清楚验证流程的各个节点内容和上下游的依赖条件，一切项目的实施与输出均围绕各个验收节点的要求。一般来说流程上是关键用户确认→关键部门确认→分管领导确认→总领导确认，动作上邮件或文件签字

二、做好任务拆解

问题：“在什么关键时间点，什么关键责任人可以完成什么任务”？

整个项目管理最核心的一部分就是这里，在需求锁定和需求验收都清洗和明朗的情况下，项目管理主要就是定出上述。作为产品经理定研发计划的时候肯定都烂熟于心，但这里身为项目经理，有几个点需要注意：

1.人员匹配

一是什么样的人适合做什么样的事儿？这个本质是对人性的洞察，要明确关键任务和责任人是相互匹配的关系，以防出现为了定计划而乱拍责任人，导致责任含糊不清到了既定节点进行互相推诿的形式；

2.预留缓冲

二是这个事儿的死亡时间（deadline）是什么？计划不能卡着 DDL 进行排，一定要留出缓冲，而且这个缓冲只有你自己知道（别问什么，问就是人性）

并且任务计划表定好以后一定要在组内进行评审，达成共识

三、做好任务完成

问题：“每个人的任务都按时完成了吗？”

上一个任务拆解更多的是考验项目经理的专业能力，而在这一节则需要更多的管理技能了，如何让你的每个人按照要求按时把工作进行完成，这里分为两种情况

1.自发性完成

为什么项目经理或者空降的领导都喜欢用自己人呢？本质上就是为了降低自己的管理成本，因为自己人带来的“安全感”很强，毕竟是自己人，各方面的衔接与配合都较为默契，有一定程度上的合作基础

2.管理性完成

这就是纯粹的通过管理手段进行关键任务按时交付的干预了，不同的公司环境因素、文化氛围、项目目标不同，项目遇到的具体情况也不同。根据不同的项目综合情况，合理的裁剪和选择项目管理办法。也是根据项目的不同阶段和团队成员的接受程度进行处理，我个人的心得有以下几点：

交叉检查机制

对于重要事项的产出来说，可以让产品经理与测试人员进行双重验证、岗位内互相检查，减少出现问题的可能

项目日会

每天早上用 15 分钟时间召开日度站会，明确当天任务，并且邀请甲方客户技术人员与我们项目组一起进行。在会上需要明确是否与当前项目行事历达成一致，对应的任务与需要输出的成果是否如期进行了目标达成

代码审查

对于关键性的交付代码，每个模块至少 1 次让组内成员进行配合检查，具体参与深度由技术负责人来定，反正尽可能保证代码实现逻辑不会出现重大逻辑问题与性能问题

高频问题反讲

对于逻辑比较复杂的功能需求，各个技术实现人员与测试人员需要能对需求的设计背景与思路进行反讲，以教带学，达成共识，经验吸取

风险管理升级

对于出现重大的项目风险所进行的后续改善措施，需要每天进行至少三次跟踪，确保出现风险蔓延

结语

管理就是管人性

正如上面我所提到的，我自身本是互联网出身，对 PMP 接触不多，对所以不会有科班八股文，完全是属于个人经验所得。我对于项目经理这个角色的理解均源于一点，就是“如何把这个项目的活给它干好，干完”，为了这个目标。那可不得先告诉大家目标在哪里（一、做好需求控制），每个人负责什么（二、做好任务拆解），每个人完成的标准是什么（三、做好任务完成），而如何把这个 123 贯彻落实下去，这就是人性的问题了，所谓管理，这就是管人性。

麦格雷戈说，每一个管理决策或每一项管理措施的背后，都必定有某些关于人性本质及人性行为的假设。人性管理是非常复杂的问题，也是不断需要上下而求索的过程，有了基本的人性管理基础，才有所谓的 123，我们对人性把握的力度越大，我们上述的 123 甚至有更多的 456 才能更好的实施。

自己也是在人性管理上栽了更多跟头，但是好在自己作为从基层成长起来的员工，对于“感同身受”这件事还是非常有体会的，对于人与人之间的“共情”有着些许理解。个人的心得就是寻找共赢的机会，与你的客户共赢，与你的组员共赢，为你的组员，你的客户不断的创造价值，在价值共生中促进双方的发展，通过不通的价值实现路径来聚拢整个项目组的目标，最终实现人性管理的基础，有了人性管理的基础的 0→1，才有后面的具体项目管理技能。