在需求的生命周期里 产品经理究竟该做什么？

　　按：本文作者刘飞，前锤子科技产品经理。

　　产品经理们在处理来自不同地方的需求时，有着不同的工作方式和方法：分类管理、定期维护等不一而足。那么，对于需求的整个生命周期来说，我们究竟应该怎么做呢？

　　下面是我的经验。

　　1、获取阶段需求的来源有很多。业务越复杂，需求就越杂。一个淘宝，产品需求就可以拆分成分类、检索、排序、商品展示、营销活动、支付、配送、售后等等。

　　你的职级越高，也代表着身边人提需求的可能性越大。初入行的产品专员或助理，主要是得到被安排的任务；初级产品经理，需求来源主要是用户和上级；产品负责人，需求来源就要增加老板和其他相关部门； 而作为老板，谁都可能跟他提产品需求。

　　所以在获取到需求这一时刻，就必须做一个判断，并且记录。如果不做判断堆在那里，等做的时候根本没办法梳理出头绪，可能大部分时间都在疲于折腾需求清单。记录当然是为了方便回溯。获取到的再小的需求也记下来，不要指望你随时能想起来每天听过的每个需求。

　　做判断的内容具体是什么呢？

　　判断需求本身的重要性

　　同样是页面写错了一个字，把「登录」写成「登陆」，和把「奖励 15 元」写成「奖励 50 元」，重要性不言而喻吧。有个大致的预估。

　　考虑需求来源

　　需求来源会表明一些事情，要慎重思考。比如老板提到的，未必是目前你能理解的，但他认为特别重要，就暂且把这个当成特别重要的，这是政治任务。再比如是用户提到的，但细想他并不是目标用户，他的需求就不必太关注。

　　简要得到需求背景

　　我自己工作中有三类需求绝对不记：

　　没说清楚原因的，不记(你做个 xx 出来，别管那么多)；

　　不说清逻辑的，不记(啊，这里我也没搞懂，你先看看)；

　　不是实际遇到的，不记(哎，我觉得可能有人会这样用)。

　　需求背景没搞清楚，完全是浪费时间。有一句话的记录，但不说背景，也是浪费时间。记的时候，我会确保格式是问题 + 方案，「xxx 在用我们的 xx 功能时，感觉 xxx，我们可以尝试 xxx 这样的方案」。

　　最后，依据这三个因素，判断属于大致哪个类别的。一般的需求管理都会分 p0-p3 或者 p1-p4，总之先打个标签。这里的技巧是尽量标记为比估计的更重要一层的需求，就是你感觉是 p2 的，暂且先标为 p1。这样以防错漏，低优先级的标成高的没关系，但高优先级的标低了会出现麻烦。这时候的预估往往不准确，但没关系，等后面第二步再说。

　　比如这样：

　　2、讨论 / 设计阶段隔一段时间，我们会开需求讨论会，整理需求池，也就是记录所有获取到需求的表单。

　　我们会详细讨论每个需求的情况，确认几个事项：

　　1)需求的优先级

　　之前的判断是粗估，这里的判断就要精细了。一般需求的重要程度很难量化，尤其来源复杂的情况下。营销部门着急要我们配合做活动，不做就少赚好多钱，业务部门着急要我们配合做一套自动化结账工具，做了能节受多成本... 有时抉择很痛苦。

　　这里还是用最常用的判断方法，紧急重要四象限法则(请自行百度「四象限法则」)。重要程度大致按这种排序：

　　不做会造成严重的问题和恶劣的影响的

　　做了会产生巨大好处和极佳效果的

　　跟重要合作对象或投资人有关的

　　跟核心用户利益有关的

　　跟大部分用户权益有关的

　　跟效率或成本有关的

　　跟用户体验有关的

　　紧急程度按这个排序：

　　不做错误会持续发生，造成严重影响

　　在一定时间内可控，但长期会有糟糕的影响

　　做了立刻能解决很多问题、产生正面的影响

　　做了在一段时间后可以有良好的效果

　　大家把能考虑到的因素想全，会标上 p1 - p4 的优先级。

　　2)方案的方向

　　需求有不同的解决办法，我们会讨论清楚到底用哪种解决。比如我们发现有刷单现象，可以事前提醒，告知用户目前地理位置或订单信息有嫌疑；可以事中限制，必须到达指定地点、拍摄当地照片等等操作来限制用户；可以事后惩戒，提供给客服或者业务部门疑似刷单的名单和证据，罚款或者封号。这几项到底做哪个？还是做其中哪几个？优劣在哪？需要好好讨论。

　　有时会有大概的方向，再去跟相关部门和需求相关的同事确认。这不在本文讨论范围内，暂且不提。

　　3)指定负责人

　　我之前经历过两种需求分配制度。一种是每个人负责的需求范围有清晰的边界，那需求对应哪个模块，就直接分配即可；另一种是团队作战，每次指定或者认领，谁都有可能接手任意需求。

　　前一种的好处在，模块清晰，负责人可以对自己负责的部分足够熟悉，但缺点是，工作量很可能不平衡，有的同事一直在忙，有的可能就比较闲，因为需求不是平均按模块分布的。

　　在我们需求分配时，大致还是按照模块分配，但在出现工作量不平衡的情况时，会酌情调整一下，让活少的同事予以配合。

　　不管怎么样，一定一定要指定负责人，他需要对需求负责，一直到产品上线后，出了的问题他也要承担责任。要保证运营良好的工作责任制。

　　4)划定时间节点

　　许多产品经理会疏漏这点，只是觉得尽快去做，但总是做不完。

　　时间节点至少也要包括方案完成的时间。就是这个需求，能够完好提交给开发的时间。如果没有这个时间，对需求的管理就没有一点意义了。

　　另外，如果是要跟相关部门再确认、或者要跟用户调研、或者要统计各种数据再作判断的需求，那还要有调研 / 讨论完成的时间。

　　这个时间节点的划定，主要是按照方案的复杂程度，用经验做个简单判断。最长的时间周期也不能超过一周，保证需求的推动进度，因为很难有复杂程度超过一周的产品需求。对于有严格上线时间的需求(经常会出现，比如很苛刻的老板需求、投资人需求、政府需求等)，要倒推出最合理又富有余地的时间节点。

　　讨论完刚刚入池的一批需求，我们会再整理和讨论其它状态(有方案或者调研结论)的需求。这样会议结束，每条需求都会得到更新。

　　我们在这个时刻，一般会让负责的产品经理，及时更新需求状态给需求来源方。当然，来源方 95% 的情况下会对进度不满意，这很正常，但除非来源方有确凿的理由，我们不会轻易调整优先级和时间节点。

　　3、待开发阶段有了确切方案，我们会尽快跟研发的同事做可行性评审。这一步必不可少。我感觉题主出现的「落不了地」和「频繁更改」的问题，要着重在这个步骤里解决。

　　可行性评审上，完成的是对需求的大致评估，要做的有这么几件事：

　　1)方案本身的可行性

　　在技术方案上，是不是能够完成？就是让技术部门评估这个问题。

　　2)有没有更好的方案？

　　一定要跟技术部门灌输清晰的需求背景，让他们也想一些可行的方案。方案未必是完整、准确的，但他们提供的思路，一般是可行性较高的。

　　3)涉及的产品和技术环节有哪些？

　　这个需要相关的同事仔细讨论。尤其是很多公司产品线比较多，有可能存在牵一发动全身的情况，如果相关的产品同事和技术同事不知情，必然会延期，必然会扯皮，必然会造成麻烦，必然会有各种改动。即便是再小的产品，也要分前后端，让技术的同事来判断有哪些人需要知情和参与评估。

　　4)方案的成本如何？

　　看方案需要多少人、多少资源、多少时间来完成，也要看方案在技术层面耗费的不太明显的成本，比如服务器成本、带宽成本，给用户造成的流量成本等。

　　有了这样的讨论，会议输出的，就是比较严谨的可执行方案(或草稿)了。

　　如果会上遇到各种问题，要确认解决问题的时间节点。

　　4、开发阶段开发需求的次序，我们不是完全按照需求池里的需求优先级来的。刚才说到，在可行性评估会上，我们会核算大致的需求成本，那成本结合需求的优先级，就可以得出需求的性价比了。

　　我在创业公司产品经理怎么做？提到过具体的方法，这里不再赘述。大概是用这样的表格：

　　提交开发之后，相当于关闭需求。原则上，本次迭代不再加入新的需求。

　　当然啦，如果什么事情都是原则上那样... 就不会出现这么多扯皮的情况了。

　　在开发中，扯皮的问题归纳起来就是三种：需求太多，没按时做完；需求有改动，导致了额外工作量以及开发的不满；有新的紧急需求，导致发布延期。

　　这三种问题，再抽象一下，导致的原因很多，大概有几类，分别是：

　　1)产品方案不完整

　　方案不完整往往是没有考虑全面。这个跟需求管理本身没关系，就是在出方案的途中，看能不能把事情想全。

　　之前我们经常出现，做的时候技术才发现卧槽这里有个逻辑没想通埃然后喊产品来一起讨论的时候，大家发现需要加一些功能才能完善逻辑。最后结果就是周六加了个班，大家很不开心。

　　这种事情也不好追责，毕竟参与者很多，流程拖得很长。硬要说是负责需求的产品经理有问题倒也可以，但总是片面的：他也不一定知道技术上开发才发现的逻辑。

　　后来我们反思，各个流程中的环节都要做一些调整，才能确保最终产品方案的完整：

　　分析需求时，先梳理逻辑再出方案。能画流程图的画流程图，能画逻辑图的画逻辑图，能画脑图的画脑图，穷举整体的逻辑。

　　讨论方案时，所有产品经理参与小组讨论，一起提出疑惑，发现问题。

　　可行性评审时，技术从逻辑角度提出质疑，发现问题。

　　之后再出问题，会回溯原因。如果是前两个环节出的问题，那就是产品经理的责任；如果是产品经理未知的逻辑，那就是可行性评审中，技术的同事的责任。

　　2)需求方的主观改动

　　这种情况基本都是需求方或者产品经理的问题：他们在提交方案前没有完全想清楚。

　　有时候都开始开发了，业务部门来人说，哎我们发现这个问题好像不存在了，大家不要做了。他们觉得无所谓，还减轻了开发负担。但对技术部门的同事来说，就好像在说「你被耍了，哈哈哈」。造成的影响是恶劣的。

　　产品经理在对接他们的需求时要做判断，他们是不是完全想清楚了，是灵机一动的小点子，还是不得不解决的问题。

　　另外，还有一种情况，是需求方跟产品经理对接时出了问题。表述有误，并且方案没有跟他们核对清楚，结果产品功能上线，才发现并没有解决问题。

　　我们的做法刚才多少提到了一些：要在任何需求的属性(内容、时间点)发生变化时，跟需求方同步。让他们知道我们的情况，也获取他们的意见和建议。

　　比如这是我们的需求同步流程：

　　3)无法预测的客观原因

　　这种是唯一一种能够接受的原因，不需要有谁承担责任。

　　比如，本来要做一个功能狙击对手，结果做了一半，竞争对手倒闭了，那这个功能就没有意义了，确实要废除。

　　还有一些业务上的确无法预测的各种原因，导致原本存在的问题不存在了，也无可厚非。

　　这种情况下，产品经理最重要的是安抚技术的同事，尤其是跟他们解释清楚背景和详细的原因，不要让他们误以为是刚才提到的前两种理由。

　　5 、复盘阶段需求从获取到上线，走完生命周期之后，还要有一个很重要的复盘阶段，尤其是在需求管理出过故障和问题的时候。

　　略靠谱的团队，都会有复盘的机制，主要是防止问题再次发生。解决问题很简单，如何尽量规避下次再出问题很复杂。

　　大致就是，要搞清楚之前出现问题的所有逻辑和流程，再去看在哪些环节可以做点什么，去防止再次出现。这块的内容说得多了又得写一篇文，就不多讲了。

　　以上就是我的经验，仅供参考。没有什么流程和机制是完美的，关键在于怎么去解决自己的问题。如果哪些思路给你了启发，那就够了。

　　【作者介绍】刘飞，原嘟嘟美甲联合创始人，锤子科技产品经理，除了是雷锋网(搜索“雷锋网”公众号关注)的专栏特约作者，也是产品经理干货集装箱的人人都是产品经理的专栏作家，豆瓣《最好的时代：可能是最真诚的创业日记》作者。文能提笔抒骚情，武能切图画交互。微信公号：刘言飞语(id：liufeinotes)