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

本篇文章4660字，读完约12分钟

作者:刘飞，哈默科技公司前产品经理。

产品经理在处理来自不同地方的需求时有不同的工作方式和方法:分类管理、定期维护等。那么，我们应该为需求的整个生命周期做些什么呢？

以下是我的经历。

1.在获取阶段有许多需求来源。业务越复杂，需求越复杂。一个淘宝，产品需求可以分为分类、检索、排序、产品展示、营销活动、支付、分销、售后等。

你的级别越高，你周围的人就越有可能提出要求。对银行不熟悉的产品专家或助理主要完成指定的任务；初级产品经理，需求的主要来源是用户和上级；产品和需求来源的负责人应增加老板和其他相关部门；作为老板，任何人都可以向他询问产品要求。

因此，在获得需求的时刻，必须做出判断并记录下来。如果你不做出判断并把它们堆在那里，当你做出判断时，你将无法理清线索，而且你可能大部分时间都在与需求清单做斗争。当然，记录是为了回溯的方便。写下你得到的最小需求。不要指望你记住你每天听到的每一个要求。

判断的内容是什么？

判断需求本身的重要性

在页面上写一个单词也是一个错误。写“登陆”为“登陆”，写“奖励15元”为“奖励50元”。重要性不言而喻。粗略估计一下。

考虑需求的来源

需求的来源会显示一些东西，所以仔细想想。例如，老板提到的事情目前你可能还不明白，但他认为它特别重要，所以他认为暂时它特别重要。这是一项政治任务。另一个例子是用户提到的，但是如果你仔细想想，他不是目标用户，所以你不必太关注他的需求。

简要了解需求背景

我自己的工作中有三种需求，我永远不会记得:

如果你说不清楚原因，就不要记住它(你犯了个xx，别担心)；

如果你没有讲清楚逻辑，就不要记住它(啊，我在这里不明白，你应该先看一下)；

实际上没有遇到，不记得了(嘿，我想有人可能会这样使用它)。

需求背景不清楚是浪费时间。记录一个句子是浪费时间，更不用说背景了。当我记起的时候，我会确保格式是问题+解决方案，“当使用我们的xx功能时，xxx感觉xxx，所以我们可以尝试像xxX这样的解决方案。”

最后，根据这三个因素，大致判断它属于哪一类。一般需求管理分为p0-p3或p1-p4。简而言之，先做一个标签。这里的技巧是试着把它标记为比估计值更重要的需求，也就是说，如果你觉得它是p2，暂时把它标记为p1。为了防止错误和遗漏，低优先级标记为高并不重要，但是如果高优先级标记为低，就会造成麻烦。此时的估计往往不准确，但没关系，等第二步以后再说。

像这样:

2.在讨论/设计阶段，我们将召开一个需求讨论会议来整理需求库，即记录所有已经获得需求的表单。

我们将详细讨论每个要求，并确认几个项目:

1)需求的优先级

先前的判断是粗略的估计，这里的判断将是好的。很难量化一般需求的重要性，尤其是当来源复杂时。市场部很希望我们在活动中合作，如果我们不合作，我们会赚很多钱。业务部非常希望我们合作开发一款自动结账工具，这样可以节省很多成本...有时候选择是非常痛苦的。

在这里，我们仍然使用最常用的判断方法，紧急重要四象限规则(请你自己百度一下四象限规则)。重要性大致如下:

不这样做将导致严重的问题和不利影响

这样做将会产生巨大的利益和优秀的结果

与重要合作伙伴或投资者相关

关系到核心用户的利益

关系到大多数用户的权益

关于效率或成本的

与用户体验相关

紧急程度按以下顺序排列:

不犯错误将继续发生，造成严重影响

它可以控制一段时间，但从长远来看，它会有不好的影响

这样做可以解决许多问题，并立即产生积极影响

一段时间后，它会有好的结果

每个人都认为所有的因素都可以考虑，并将p1-p4标为优先。

2)计划的方向

对于需求有不同的解决方案，所以我们将讨论使用哪一个。例如，如果我们发现有刷机现象，我们可以提前提醒用户，告知用户当前的地理位置或订单信息可疑；你可以限制事情，你必须到达指定的地方，拍当地的照片，等等。限制用户；您可以事后进行处罚，并向客户服务或业务部门提供可疑账单、罚款或头衔的清单和证据。这些项目中我应该做什么？还是做哪一个？优点和缺点是什么？这需要讨论。

有时候会有一个大概的方向，然后去相关部门和有相关需求的同事那里确认。这超出了本文的范围，所以我们不要提及它。

3)指定负责人

我以前经历过两种需求分配系统。一是每个人负责的需求范围有一个明确的边界，所以需求对应的模块可以直接分配；另一种是团队斗争，在这种斗争中，任何人都可以在每次任命或提出要求时接管任何要求。

前者的优点是模块清晰，负责人可以熟悉他所负责的部分，但缺点是工作量可能不平衡，有些同事一直很忙，而另一些同事可能闲着，因为需求不是按照模块均匀分布的。

当我们分配需求时，我们仍然按照模块进行分配，但是当工作负载不平衡时，我们会进行适当的调整，让工作量较少的同事进行合作。

无论如何，必须指定负责人。他需要对需求负责，他也将对产品上线后的任何问题负责。确保运行良好的工作责任制。

4)描绘时间节点

许多产品经理会错过这一点，只是认为他们应该尽快完成，但他们永远也完成不了。

至少时间节点还应该包括计划完成的时间。正是这种需求才能在良好的条件下提交开发。如果没有这样的时间，管理需求是没有意义的。

此外，如果需要与相关部门再次确认，或与用户一起调查，或在做出判断前统计各种数据，则调查/讨论需要时间才能完成。

这个时间节点的划分主要是基于方案的复杂程度，并根据经验做出简单的判断。最长时间不应超过一周，以确保需求推广的进度，因为很难有复杂程度超过一周的产品需求。对于严格的在线时间要求(如苛刻的老板要求、投资者要求、政府要求等)。)，有必要推出最合理和最有回旋余地的时间节点。

在讨论了一批刚刚进入资源库的需求之后，我们将整理并讨论其他州的需求(包括解决方案或研究结论)。这样，当会议结束时，每个需求都将被更新。

此时，我们通常要求负责产品的经理及时更新需求源的需求状态。当然，在95%的情况下，源方对进度不满意是正常的，但是我们不会轻易调整优先级和时间节点，除非源方有充分的理由。

3.当发展阶段有了明确的计划后，我们会尽快与R&D的同事进行可行性研究。这一步是必不可少的。我觉得这个题目中的“不能落地”和“经常变化”的问题应该在这一步解决。

在可行性审查中，完成了对需求的总体评估，有几件事要做:

1)方案本身的可行性

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

2)有更好的计划吗？

务必向技术部门灌输明确的需求背景，以便他们也能想出一些可行的解决方案。该计划可能不完整和准确，但他们提供的想法通常是可行的。

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

这需要相关同事仔细讨论。特别是，许多公司有大量的产品线，这可能导致整个机构。如果相关的产品同事和技术同事不知道，他们将不可避免地拖延、扯皮、制造麻烦并做出各种改变。即使是最小的产品也应该分为正面和背面，以便技术同事能够判断谁需要知道并参与评估。

4)该计划的成本是多少？

这取决于完成项目需要多少人、资源和时间，还取决于项目在技术层面上不太明显的成本，如服务器成本、带宽成本和对用户造成的流量成本。

有了这样的讨论，会议的输出是一个更严格的可执行程序(或草稿)。

如果在会议中遇到各种问题，应该确定解决问题的时间节点。

4.开发阶段中开发需求的顺序不是基于需求池中需求的优先级。如前所述，在可行性评估会议上，我们将计算需求的大致成本，然后将该成本与需求的优先级相结合，以获得需求的性价比。

作为初创企业的产品经理，我该做什么？已经提到了具体的方法，因此这里不再重复。可能是这样的:

提交开发后，相当于关闭需求。原则上，在这个迭代中不会添加新的需求。

当然，如果原则上一切都一样...不会有这么多争吵。

在开发过程中，有三种争论问题:需求太多，不能按时完成；需求的变化导致了额外的工作量和对发展的不满；有新的紧急要求，这导致了释放的延迟。

这三种问题，再次抽象出来，导致许多原因，大概有几种类型，即:

1)不完整的产品计划

不完整的程序通常不被全面考虑。这与需求管理本身无关，也就是说，在退出计划的路上，看你是否能把事情想清楚。

我们以前经常出现，当我们这样做的时候，这项技术发现在睡眠槽中有一个我们无法理解的逻辑。然后，当我们召集产品一起讨论时，我们发现我们需要添加一些功能来完善逻辑。最终的结果是周六加班，每个人都很不开心。

这种事情不容易怪。毕竟，参与者很多，这个过程需要很长时间。坚持认为负责需求的产品经理有问题是可以的，但是这总是片面的:他不一定知道技术开发发现的逻辑。

后来，我们认为应该在每个过程中进行一些调整，以确保最终产品计划的完整性:

分析需求时，首先要理清逻辑，然后拿出一个计划。能画流程图，画逻辑图，画脑图，并穷尽整个逻辑。

讨论计划时，所有产品经理都要参加小组讨论，一起提出疑问和发现问题。

在可行性审查期间，该技术从逻辑角度提出问题并发现问题。

如果再次出现问题，原因将被追溯。如果是前两个环节的问题，是产品经理的责任；如果产品经理不了解逻辑，则可行性审查中的技术同事有责任。

2)需求方的主观变化

这种情况基本上是需求方或产品经理的问题:他们在提交计划之前没有想清楚。

有时他们开始发展，来自业务部门的人说，嘿，我们发现这个问题似乎不存在，所以不要这样做。他们认为没关系，但也减轻了发展负担。但对我在技术部门的同事来说，这就像在说，“你被耍了，哈哈哈”。影响是不好的。

产品经理在匹配他们的需求时应该做出判断，他们是否已经完全考虑过了，这是灵机一动还是一个必须解决的问题。

此外，还有另一种情况，当需求方与产品经理沟通时会出现问题。这种说法是不正确的，他们也没有清楚地核对计划。结果，产品功能上线，却发现问题没有解决。

我们的实践刚才提到了一些事情:当任何需求属性(内容、时间点)发生变化时，我们应该跟上需求方的步伐。让他们知道我们的情况，并得到他们的意见和建议。

例如，这是我们的需求同步流程:

3)不可预测的客观原因

这是唯一可以接受的理由，没有人需要承担责任。

例如，如果我们应该做一个功能来攻击我们的竞争对手，但结果是成功了一半，而我们的竞争对手破产了，那么这个功能将毫无意义，应该被废除。

商业中也有一些不可预知的原因，导致了这样一个事实，即存在的问题并不存在，也没有错。

在这种情况下，产品经理最重要的事情是安抚技术同事，特别是向他们解释背景和详细的原因，不要让他们把他们误认为是刚才提到的前两个原因。

5.在完成生命周期后，将会有一个非常重要的再销售阶段，尤其是在需求管理出现故障和问题的时候。

一个稍微可靠的团队会有一个卷土重来的机制，主要是为了防止问题再次发生。解决问题很简单，但下次如何避免问题就复杂了。

粗略地说，有必要先了解问题的所有逻辑和过程，然后看看可以做些什么来防止问题再次发生。这篇文章有很多要说的，如果你要写一篇文章，你就没什么可说的了。

以上是我的经验，仅供参考。没有完善的过程和机制，关键在于如何解决自己的问题。如果什么想法给了你灵感，那就足够了。

[作者简介]都都美甲前联合创始人、汉默科技产品经理刘飞，不仅是雷锋的专栏作家。搜索“雷锋”。com "公共号码)，但也是产品经理。干货容器里的每个人都是产品经理的专栏作家，也是豆瓣的最佳时代:也许是真诚的企业家日记的作者。文可以通过写作来表达自己的感受，而则通过剪画来进行互动。微信公众号:刘(身份证:刘斐诺)