如果你是刚入行1~3年的产品新人，丽莎阿姨掐指一算，你的日常工作里应该至少有70%的时间是在负责产品的版本规划与正常迭代，是不是呢？

温馨提示：此文2900字，阅读完大概需要20分钟

其实做产品规划的门槛很低，低到无论你怎么安排都不会错，因为从来都不会有一个标准的尺子来衡量你的规划正确与否。例如程序员，会有万行代码出错率等指标来代表这位程序员小哥的厉害程度，但很可惜产品经理们并没有Roadmap优美度等过程指标来衡量产品经理的厉害程度。

这是一件快乐又可悲的事情：快乐的地方在于摸鱼无人管一朝成功很意外；可悲的事情在于摸鱼一时救火一世啊朋友们。

看看以下的例子你是不是并不陌生：

1、团队一致认为这个版本是具有划时代意义的，功能非常多，所以需要至少X个月的时间才能开发上线，可是版本上线后，用户已经偷偷焗了油

2、中途突然接到了用户反馈的非常紧急的需求，赶紧插入到当前的版本中进行开发，技术小哥异常生气，挥刀砍你，从此给你贴上了“需求变更魔王”的标签，互相之间信任已不存在

3、团队的整体开发效率非常低，明明一个很简单的需求都至少要开发X个月以上，最后发现耗时最大的居然是团队内的沟通

4、整个团队的开发节奏要么时紧时慢，要么天天救火，要么放羊长草，工作中体会不到迭代的优雅韵律，就像下一口不知道是粑粑还是巧克力。

如果这个时候，你的小脑袋在控制不住地点头，那么请把你的小手手交给丽莎阿姨，让阿姨带你进入优雅版本迭代之门。

依照往常惯例，入门之前，让阿姨来摸摸你的骨相如何。

看看以下哪个观点更像你？

A.我是一个完美主义者，做事情一定要求做到最好

B.我是一个现实主义者，我会在当前可选项里找一个相对较好的解决方案

如果你的选择是A，那么...

请记得从此以后无论什么时候都要选B好吗？

请用小本本抄下来这段话

软件产品的设计出发点都是帮助他人，所以这也意味着永远不可能存在理想情况，产品科学是一门工程科学而非纯理论研究，落地实施才是第一要务

接下来丽莎阿姨将会从以下几个部分来带你入门：

用正确的姿势聊需求

用正确的姿势管理需求的优先级

优雅的安排版本的迭代节奏

第一步：用正确的姿势聊需求

当我们在聊需求的时候到底在聊什么？还原到团队各角色的视角：

产品经理视角：用户的痛点就是需求

设计师视角：需求就是确定的交互细节与界面UI

程序员视角：需求就是我要实现的功能清单

其实这一点也不奇怪，因为团队的分工不同所以理解自然就不同啦。如果非要给需求下一个定义，我想这句话是比较标准的：

特定的人，特定的情况下，可以被解决的问题就叫需求

那如何能大家统一对需求的理解从而正确的传递需求呢？丽莎阿姨缓缓打开机器猫的小口袋，哒！哒！哒！！（自行脑补BGM）这个法宝就是：

PRD（Product Requirement Document）

鲁迅说：做好一个PRD可以提高整个团队90%以上的工作效率。

PRD的生产过程最最最好分三个阶段：

第一阶段：先与你的老板、产品团队内部沟通你的意图；至少要包含需求背景来源、大致框架结构与解决方案草图，这一步非常重要越早沟通越不会跑偏（如果只是是很小的功能迭代可以省略）

第二阶段：在产品团队内部、设计师与开发leader一起沟通这个版本要做的具体内容，至少要包含版本目的与关键指标，细化的产品原型图等

第三阶段：与开发团队一起沟通版本的详细需求，落地版本开发策略与排期，这个阶段才需要输出详细的产品交互逻辑与细化功能说明。

拿图保命：

所以你看，一份PRD的生产过程就是一个把抽象的需求落地到具体的开发细节的过程。这就是产品工程的美妙之处呀~~

如果以前的你有如下情况：

1、一个需求冥思苦想找不到解决方案，抬头一看离deadline越来越近了

2、花了很多时间做的PRD，自认为无懈可击，却在评审例会上被老板一巴掌拍死...

那恭喜你，今后这两种情况应该都不会发生啦~

小本本：我们在做PRD的时候思考是渐进的，沟通也是渐进的

千万不要以为自己独自刻苦冥思苦想最后拿一个漂亮的PRD甩到老板面前让他惊艳~~相信阿姨，老板这个时候只想掐死你，他不拍死你拍死谁？

所以请从今天、此刻、开始答应阿姨我们一起做需求渐进式沟通的好宝宝，好吗？不要一开始就沉迷在交互细节与逻辑中无法自拔，好吗？

第二步：用正确的姿势做好需求的优先级管理

1、管理需求

需求的来源五花八门，但无非以下两种：主动式需求与被动式需求。

产品的业务目标拆解、用户调研、数据分析、竞品分析、性能相关、UI相关、技术迭代等均属于主动式需求；而业务部门（市场、运营、销售、管理层）需求、用户反馈、遗留bug等需求都属于被动式需求。

一个可以随时同步的Excel表格就可以管理起来了

举个例子：

要注意，这个需求管理的表格必须要动态更新与定期评审，尤其要记录需求来源，评审时候经常会发生需要溯源的情况。

2、安排需求的优先级

很多宝宝喜欢用重要+紧急四象限来做需求的优先级排序，但事实的真相往往是：几乎所有的需求都在重要紧急那个象限里

所以请赶紧把这个1902年的方法扔掉，跟着阿姨一起来用2020年的解决方案：满意度模型

简单来说，就是把你的需求按照“可实现”与“能带来价值”两个维度来分为四个象限，重新整理你的需求属性。

那么你的需求优先级就变成了：

• 最先处理能带来价值但是实现复杂度高的需求，因为往往这些需求都需要拆解到2~4个版本来解决，所以越早开始规划，你的团队就越有预见性，节奏就越优雅

  
  

• 次要处理那些能带来价值而且实现复杂度不高的需求，但其实这种需求并不多

  
  

• 第三步就是安排那些带来价值一般、实现难度不高的需求了；这部分需求往往就是按照例行的版本迭代节奏来进行就OK啦

  
  

• 最后要记住，如果你的开发小哥们是那种特别有技术情节的，他们一定会经常跟你提那些异常复杂解决难度很高的问题，此时的你一定要理性判断这部分需求能带来的价值，能按住就按住好吗？

<》》不要问我为什么突然变色，我怕你们看累了>

毕竟对于开发小哥来说能解决复杂的问题才能体现自己的价值，这往往与产品的价值背道而驰。

下图保平安：

第三步：优雅的安排版本的迭代节奏

这个是丽莎阿姨总结的产品开发流程，在我们团队已经跑了5年有余，非常顺畅，相信业界绝大多数团队也是适用的。

我将产品的开发步骤分为以下四个流程：

1. 概念阶段：顾名思义，就是确定需求的阶段，此时需求是OPEN的，会发生任何可能性，需要在这个阶段完成PRD评审、交互视觉评审、以及确定开发方式与开发节奏安排。
   
   
2. 开发阶段：就是需求实现的阶段，这个阶段需求是严格冻结的，也就是说不允许再插入任何需求进来（无能的产品经理才乱插入需求），在这个阶段完成技术评审、埋点评审与测试用例评审
   
   
3. 验收测试阶段：这个阶段需求是允许微调的，毕竟在验收的时候会发生边界条件考虑不周，文案不当等情况，这个时候的微调可不算需求变更哦（拉钩钩）。丽莎阿姨建议每周要有固定的时间来验收（这样的节奏谁不爱呢）。
   
   
4. 发布阶段：千万要记住发布之前还是要做一个发布策略评审哦，尤其要安排好灰发策略，否则一下放开全量用户，BUG扑你脸上，连回滚的时间都木有呀。

下图保平安：

一个版本这样迭代完，第二个版本的流程最好在第一个版本的开发阶段结束开始，因为这个时候开发小哥刚好结束开发的紧张工作，有闲情逸致与你一起来讨论新版本的需求~~~

最后：相关功能的最好隔开一个版本，例如A功能与A功能的优化，安排在第1与第3版本；B功能与B功能的优化，安排在第2与第4版本，这样你留给了自己长达一个版本的调整时间，节奏是不是优美，步伐是不是优雅，安？！

文中的保命图我都打上了二维码，我就不信你还不加我微信要原图。

可能是东半球最棒的教育产品经理团队，一直在招人，撩我。