资深产品经理如何做需求管理（二）：需求的生命周期

内容简介：资深产品经理如何做需求管理（二）：需求的生命周期

上一篇和大家分享了我对需求的理解以及如何评估需求的优先级，接下来我们将从生命周期的视角去梳理一遍需求的全流程，方便各位建立整体视角。同时，通过对各个环节的复盘，尤其是平时容易忽略的环节，可以发现影响需求预期效果和工作效率的瓶颈点，更有助于各位PM提高自己的工作效率。

需求全生命周期

通常情况下，一个需求的完整生命周期可以划分为六个部分：

1. 需求搜集及评估阶段： 以最终需求确定为节点，在这个阶段，需要和产品运营及相关业务方确认“这一版要做哪些事”；
2. 需求方案设计阶段： 以需求方案评审为节点，在这个阶段，需要和技术明确上一阶段确认的最终需求要以怎样的技术方案实现，该阶段必须产出PRD 文档;
3. 测试评审及排期确认阶段： 以需求排期确定为节点，在这个阶段，单独将测试用例列出，也是想提醒各位PM们：一定要重视分支逻辑和异常情况。最好自己用脑图将用户可能遇到的情况遍历一下，必须做好托底逻辑，因为BUG是一定会有的，而且会以各种你想不到的方式出现；
4. 需求跟进阶段： 在这个阶段，所有的逻辑和不确定情况必须落实到PRD文档里。很多团队会建立自己的协作平台，方便跟踪不同阶段的文档，如果有协作平台的话，尽量做到及时更新；
5. 需求验收阶段： 在这个阶段，需要产品经理完成产品自查或者是交叉走查，此时暴露出来的问题要快速反馈，看能否灰度期间修复或者热修复，验收的标准以PRD文档为准；
6. 需求review阶段： 需求可以正常按照预期上线并不是需求的终点，产品经理做需求的目的不在于kill一个需求，而在于验证是否满足了用户的demand，在这个阶段，需要产品跟进用户反馈，对线上数据进行对比分析，形成可靠的结论。对于需要后续改进的功能，重新列入需求池，跟进下一版迭代。

需求方案设计中的要点

如果业务或者运营提出的需求过于直白，比如“在哪个位置加个button，实现XX功能”，产品经理一定不要将需求直接“路由”给研发。在工作中我们也会发现，优秀的产品经理在这种情况下总是会不停地询问，“这么做是要实现XX功能，对吧？ ”“实现XX功能的数据预期是多少？”“实现同样的功能，我认为B方案更友好更方便，要不要一起讨论下？”——实现功能的方案绝对不止一种，重要的不是button放在哪里，而是怎么实现这个功能更符合用户的习惯，同时更与产品架构契合。

在需求方案设计阶段：

1. 产品需要将需求“翻译”为技术能读懂的实现方案。 这里的实现方案并不是指要亲自写代码，而是要明确功能设计的流程和分支逻辑：你可以将自己设想为用户，在脑海里走一遍所有的流程，就好比在游戏中一样，如何前进，后退后怎么处理，遇到障碍要如何躲避，等等。
2. 在设计方案时，要考虑产品架构的可扩展性。 这里涉及到一个经典问题“产品经理需要懂技术吗？”答案当然是肯定的呀。产品经理懂技术，不是说要文能写文档，武可写代码，而是说，产品在设计功能时，不能跳脱现有的技术架构和技术瓶颈，而且必须要考虑到后续产品的演进和架构的可扩展性，千万不要为了一个功能做一锤子买卖。

尝试用测试用例遍历

遍历这个说法是我自己的一个小窍门， 当我还是产品小白时，很幸运地遇到一个专业测试，他输出的测试用例不管从架构还是细节都让你服气，包括很多看起来不起眼但是万一遇到你就会懵逼的细节，他都能cover。在最开始的阶段，我发现自己总是在需求跟进阶段不断被询问，某个分支的分支的逻辑是怎样的，然后再临时起意定一个，如果cover的内容少，你还能hold。但是当你切换到multi-tasks模式，就会陷入困境。

解决困境的方法其实很笨，就是遍历。最好用脑图记下作为小白用户走过的所有路径，然后再针对不同的路径设计交互的流程。很多时候产品经理会有一种自我麻醉心理，或者是高估了自己的用户。遍历的时候每走一步，可以停下来想想这一步还可能怎么走，按照自上而下的结构将所有节点走一遍。当你“遍历”完每个功能的时候，你就会发现基本上形成的脑图可以作为测试用例使用了，如果团队配有专业的测试人员，正好可以交叉对比下，可以互为补充。

Kill需求并不是终点

很多产品将自己定义为“需求killer”，杀一个需求就Mark一次，多多益善。对于这种思路，我不是很认同，当然量变是质变的基础，但是如果将完成需求作为需求的终点，而不对需求的完成效果进行评估和review时，成长的密度就会大大降低。

完成需求，只是将需求转化为了已经实现的功能，但是这个需求是不是伪需求？用户会买账吗？这才是产品存活的关键问题。假设你加个一个button，可以让用户实现某种功能。你自认为功能非常酷炫，交互非常友好。但是产品经理的直觉往往是南辕北辙的，如果上线后数据表现很差怎么办？你可以直接砍掉迅速否认，然后下一版重来一遍，但是一个产品的反复对于用户是不小的伤害，而且单就数据表现差这一点，就有很多点可以挖掘。比如，是整个功能本身就不是用户需要的？还是这个入口隐藏太深？或者是交互影响核心操作路径？诸如此类，必须要结合数据和用户反馈对需求进行校验，然后再形成可靠的结论。

以上就是我对需求全流程的梳理，欢迎大家分享自己相关的心得。

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 基于多视图需求树的军民融合信息平台需求分析
• 小程序端接口需求分析
• 报表需求分析(10.5)
• 一个需求的一生
• 需求的收集及分析
• 如何进行测试需求分析

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。