需求跟进中的3大步骤

一个产品经理可以随时随地的知晓自己需求的进度，并且能够及时检验，是对产品负责的一个态度。

　　产品经理中打酱油的节点

　　最近负责的产品模块进入开发周期，需求评审、产品设计过一段落，是时候歇一口气的周期。往往很多产品经理在这个时候，最常用的是要么在有任务或需求指标下，不快不慢地进入下一个需求；要么是在下一个版本时间、或需求没明确的时候，没有事情的等待产品上线；不得不说这个周期，我认为是评判一个产品经理是否负责的PM。

　　． 有没有跟进时间计划

　　． 有没有跟进产品节点

　　． 有没有全局考虑全在这里体现

　　01 时间计划

　　我在工作中，会用甘特图或PROJECT去把控产品的开发负责人、开发周期、工作描述，其中如果遇到大版本迭代，参与人数或变动比较频繁的话，我会多采用PROJECT去管理项目的情况。

【PROJECT管理工具】

　　由上图，我们可以清清楚楚的看到每一个阶段会有哪些任务，每个任务会消耗的时间或精力。

　　这个就是时间计划，当然根据你公司的分工情况；有时候项目经理会进行把控时间节点，并没有一个产品经理的时间点的意识。

　　但作为一个产品经理，随时随地的知晓自己需求的进度，并且能够及时检验，是对产品负责的一个态度；并且在需求评审落地过程中，如果是大的需求，可能会遗忘一些产品逻辑或细节字段。

　　这个是我会出现的一个情况，但我不知道正在阅读的你是否会出现以上情况，来一个投票看看大家的情况吧！

　　在这里注意的是，在使用PROJECT工具中，需要注意各个项目任务的前后流程、人员关系，清楚知道时间节点或有评估时间节点。

　　不然，你随便做一个时间节点，可能开发的周期更长，那么这个项目周期的管理能够实际运用的意义就没有了。

　　02 跟进需求

　　刚刚前面说过，有的团队可能会是以项目经理或者BOSS直接去跟进需求进度，时刻CEHCK当时的产品是否符合预期或满足其需求。

　　这里我们抛开上面的情况不说，PM跟进需求通过以上的节点去了解现在的进度。比如一个APP中的某个功能，到了周五交货时间（开发说给你测试包），那么产品就可以去验收，看看现在是否满足其需求。

　　这个过程是频繁、交际较多的，以下就是常见的开发分工情况

　　那么，一个完整的产品需求完成是离不开以上几个工作职责的开发人员，不然你只可能去看看UI，没有数据的产品；要么就是有数据，但是不能按照需求中的算法或规则去显示。

　　比如FEED流的重力算法，是否可用按照需求中的算法，这个需要PM人员进行相关测试，但是如果服务端没有做处理；那么可能数据就是按开发人默认的顺序去执行。

【移动端算法异常的情况】

　　因此，产品经理跟进中，跟进第一部分说的时间节点；去跟进当前的开发需求完成情况，当然根据我的经验中，很多过程会出现以下情况

【根据中的问题处理】

　　在我工作的团队中，经常会出现或数据端跟不上前端的速度，前端需要苦逼的等着接口的到来，这其实无疑是木桶效应。我认为团队中，应该尽可能的去避免这种情况的出现。

　　木桶效应的原理是：影响装水的量最终是木桶中最短的那个木板。

　　这里我们把装水的量比作是开发的进度，因此开发人员中如果有一个部门或某个职责的工作影响了进度，就会导致整个模块的开发推迟。这也是为什么一个好的项目经理或好的产品经理能够迅速去把控相应的问题，争取将团队的木桶效应最小化，开发资源利用最大化。

　　因为每个团队的项目管理、团队大小不同，其每个团队反馈问题或同步问题的方式或流程也不同。

　　在创业公司，或许开发就坐PM旁边，任何问题或情况都能马上知晓。但在一定规模的团队或企业中，往往开发人员对一些需求出现了问题，没有进行处理或未完成，PM根据时间节点才能进行追踪到相应环节出现问题的人或部门。

　　这也是我目前跟进中最频繁的工作，移动端出现的问题是因为服务端，那么就去跟进服务端；服务端做了，但移动端却没有显示，那么就去跟进移动端。

　　保证需求能够顺利的发包，最终按时上线。

　　03 要学会舍弃

　　最终这一部分，说一说最近工作中最常出现的情况，也有可能是在阅读的你工作中出现比较多的情况。

　　需求开发过程中，往往会出现一些需求评审没有出现的问题或技术没办法估计的问题。

　　好的情况是，这个需求经过评审得到开发人员的认可，可以去做，但是需要推迟；坏的情况是，开发人员根本不认可，不做！

　　当然，PM总会说：

　　“砍我可以，别砍需求啊！这个需求评审的时候你不说，现在这个节骨眼给我说。”

　　但是，这个的的确确是执行与会议的区别，每个产品经理都心知肚明。好的产品经理能够在评审中找到关键的难点进行详细评审，新人产品往往就会一篇盖全，不知道最大的坑确实在开发过程中。

　　首先，在工作中产品经理是对产品负责的第一责任人，如果你都不对你的产品负责，不想办法去把产品往好的做；而是以完成任务的心态，上一个需求能上多少就上多少，那这个产品最终能为你带来多少的价值，我们可想而知。

　　在遇到上面的情况，我们首先需要可以从下面几部分去分析或争辩：

　　从以上4个部分来争取需求的开发资源，比如一个用户量只有几十万的用户产品；每天产生的用户UGC就十多条，那么是否有必要增加举报功能？

　　虽然说举报功能对于产品尤其是UGC是很好的一个过滤机制，是能够增加产品的丰富。

　　但每天就10多条，现在的产品重点应该是引导用户去产生UGC，十多条的量人工在后台可以进行删除监控就足够，是不是在当前的用户基数或产品量情况下，可以不用去考虑过滤情况？

【UGC中常用的举报或屏蔽功能模块】

　　总结

　　因此，产品经理需要学会舍弃，用需求池之前有说过垂直社交与需求文档思考的相关管理办法。

　　我看到很多产品经理为了说服开发去做自己的需求，有时候是为了不让自己打脸。毕竟就算一个很小的需求，产品人员也是经过调研或者思考，作为产品设计中，每个人都希望自己的需求能够尽可能的完整。

来源：人人都是产品经理