如今的大部分互联网公司，是不怎么区分产品经理和项目管理经理了。也难怪，它们的工作职责中是有很多重合的部分，因此，往往产品经理也会担着项目管理的活儿。今儿，咱们就聊一聊项目管理的那些事儿。

你是产品经理

也负责项目管理

天天各种问题都要经历

前脚方案被毙

接着开发就延期

新版上线实属不易

即使这样

踉踉跄跄

产品经理依然不一样

我希望你

斗志昂扬

仔细阅读这篇文章

相信项目管理不会再成为你的弱项

运营mm：“老王，你看这个需求这一期能不能给俺加上啊，你要这期给俺做的话，我就答应跟你去看电影。”

我：“嗯，别慌，容我考虑一下！”

 

运营gg：“小王啊，这期这个需求一定要给我加上啊，这都拖了快半年了，啥时候是个头啊？”

我：“急啥，下期一定给你加，这期的话，是不行了。”

当然，作为一个铁面无私的产品经理，一定是本着对需求负责的态度，那么，对于这些来源于不同部门，像是一团散沙的需求，如何去整理归类呢。

需求池的建立

需求这东西，就好比是一条条小鱼，平时你不管它的时候，它活蹦乱跳，真正想去找它的时候，却发现它消失的无影无踪。既然这样，我干脆就把它们圈养起来。什么时候想吃烤鱼了，捞出一条就直接烤了吃，方便快捷。

说起需求池，就不得不说一下需求的来源。一般分为3类：

运营需求

运营部门是衔接产品和用户的桥梁，有时候再细一点会分为用户运营和产品运营。运营在和用户沟通的过程中，会直接的成为用户的吐槽目标。用户说：“你们这个功能怎么用啊？”运营mm：“你好，这个功能balabalabala”，在这个过程中，运营mm知道了用户觉得这个功能不好用。但往往产品经理却很难有精力注意到类似的对话。很多这样的功能改进意见，第一发现者是运营。那么运营便会将该需求提给产品，由产品对该需求进行管理、评定、实现等工作。

战略需求

战略需求，说白了就是BOSS提出的战略层面的需求。这部分需求，作为产品经理，当然可以质疑其合理性，但往往需要坚定不移的去执行。也许，从产品层面上思考，这并不是一个合理需求。但老大思考问题的高度，可能会从各方面去权衡。“小孩才分对错，大人只看利弊”。就像最近很火的人工智能音箱，各大厂商，都开始着手布置自家的人工智能产品，与其说是新需求，不如说是战略性的防御。你不做，别人便会做，到时候侵占的是本属于你的市场份额。大到产品，小到功能。往往BOSS提出的要求，都需要产品经理站在更高的角度去俯视这样一个需求。

迭代需求

回归自我，作为一名产品经理，应有着自己的迭代节奏，在 什么阶段，出什么需求，做什么功能。每次迭代更新的目标究竟是什么，都应有着清晰的规划。比如前期，产品不完善，体验不佳，应本着“小步快跑”的节奏，迭代频繁一些，让整个产品在每一次的更新中，都有着最直观的改进。而到了有一定用户量，活跃度的情况。就应该想着如何去维持现有的活跃，是否要搭建用户激励体系，去提高当前用户的活跃度。是否要构建内容型社区，来充实整个产品的UGC氛围。这些都是在产品不同阶段需要去规划的需求方向。

这么多需求，如果来一条，想一条，一会就都乱掉了。最好的办法是把他们归纳在一起。根据版本迭代的节奏，去决定哪些需求，在什么时候去实现。用一个简单的Excel表格，将每一项都填写完整，区分该需求属于优化部分还是新功能部分，然后通过颜色去区分当前的进度。绿色代表已实现，灰色代表被搁置，蓝色代表正在开发。简洁易懂，清晰明了。每次新版本规划时即可从这个需求池里提取需求。

项目进度的把控

还记得校招时，群面环节有一个角色叫做Timer，负责计时间，把控进度的。当时并不理解这个角色的意义所在。但在实际工作中，才发现能让一切进度按规划顺利进行很不简单。

由于一个项目往往牵扯到多个部门的协作，因此整个项目进行下来，极其依赖于各个部门之间的配合。就拿现在大部分互联网公司的项目流程来说吧。一个需求或项目从立项到完成，往往需要产品、设计、开发（前、后端）、测试配合。

可以看出，在项目的不同阶段，产品经理都有着不同的工作目标。而每个阶段的时间节点，也是由产品经理去把控。这就要求了产品经理对时间管理有着极其严格的要求，否则很容易出现项目delay的情况。

（1）第一次评审

每一次项目立项，产品经理在准备充足的前提下，需要主动召集相关人员去针对此项目进行讨论。基于产品经理已出方案的情况下，每个部门都应有种参与感，对其方案进行评定，站在技术角度上，站在视觉角度上，站在运营角度上，这样子产品经理才可以综合各方面去评定该方案的合理性。这便是第一次需求评审的目标。

（2）调整期

最终结果应是产品经理去做调整，而设计应根据已有结果的原型图，去重新设计最终的效果图，值得注意的是，在这个过程中，产品经理应减少对视觉效果的干预，并不是说不注重细节，而是应将精力重点放在功能层面，各司其职。与此同时，开发也有着手准备开发方案，以此来确认开发排期。

（3）第二次评审

应不再对功能层面上进行讨论与修改。基于最终的效果图，针对各种细节进行讨论与确认，避免需求不明确的坑。开发也需要确认实现方式及技术方案，并给出产品经理开发周期。这样最终在需求层面上，产品经理和各个部门达成一致，并对整个项目开发时间和测试时间掌握详细的排期情况。正式进入开发阶段。

（4）开发阶段

最容易出现问题的就是开发阶段，错误评估开发难度、开发结果与实际出入很大。这些问题均会产生一系列连锁反应，可能导致测试阶段无法正常进行，或导致项目Delay。但这并不是说一定都是开发的责任，产品经理也要承担一定责任。可能由于产品的需求不明确，或漏掉了效果图上的交互细节。

因此，基于以上的问题所在，产品经理需要定期去了解项目开发进度，把控开发时间。

比如说，开发说可能要延期，那产品经理需要知道延期的原因。到底是开发评估时间过少还是中间有新的需求插入。如评估时间过少，要了解是什么原因导致的，是开发前期疏忽漏掉了一些功能的工作量还是其他什么原因。如是新需求插入，则需由产品评估需求的优先级。在此过程中，要有合理的掌握度，既不能对项目进度完全不知，又不能频繁的去问开发，以免因打断开发思考而被打。最好是在项目开发中间阶段，抽时间和开发开个项目进度会，了解一下当前进度，并对开发阶段遇到的问题进行引导、解决。

（5）测试阶段

请一定在提测前，先自测一遍，这应是产品经理的基本素养。如果连最基本的功能都没有完成，那其实根本没有达到提测的要求，因此，在测试进行全面测试前，先将本次的需求点自测一遍，这样可以最大限度的将测试时间花在更多的细节上。在测试阶段时，产品经理应抽出一定精力去着手下一个版本的需求整理了，因为如果遵循“小步快跑”的节奏的话，基本测试结束，也就意味着下一版本的开发正式开始了。

整个项目流程中，每个参与人员，都没有完全的空闲时间。而产品经理，是将他们穿织成一条线，又绕成一个循环圆的角色。

写到这里，基本也就是我在项目管理中遇到问题的总结，不同公司、不同项目的流程可能会存在一些差异，但产品经理要有一套自己的流程标准。这样才能更有序的去管理项目。

#专栏作家#

王伟华，微信公众号：夜漫产品（learnerwwh），一只略带文艺情怀的产品汪，擅长社交，资讯领域产品，心理学爱好者，目前正处于知识体系搭建阶段。

本文原创发布于人人都是产品经理，未经许可，不得转载。