初级产品经理必知：做好软件版本规划的三方面
发表时间：2024-07-12 14:02:01
文章来源：炫佑科技
浏览次数：104
菏泽炫佑科技
初级产品经理必知：做好软件版本规划的三方面
如果你是一个入行1~3年的新产品开发者，你应该至少把70%以上的时间花在产品版本规划和正常迭代上，对吗？
其实产品规划的门槛很低，低到无论你怎么排布都不会错，因为永远没有一个标准尺来衡量你的规划到底对不对。比如程序员有每万行代码错误率这样的指标来代表程序员的能力，但遗憾的是产品经理没有优雅度这样的流程指标来衡量其能力。
这是一件既快乐又悲哀的事情：快乐是当你懈怠的时候，没有人会来打扰你，你会出乎意料地成功；悲哀是懈怠只能拯救你一时，而拯救你却要花一生的时间。
看看下面的例子，看看它们是否对你来说很熟悉：
团队一致认为这个版本是划时代的，功能很多，所以至少需要X个月的开发和上线。然而版本上线后，用户已经偷偷改变了主意。在中途，我们突然收到用户一个非常紧急的需求，迅速插入到当前版本进行开发。技术小伙气急败坏，一刀砍了我们。从此，我们被贴上了“需求变更魔”的标签，相互信任不复存在。团队整体开发效率很低，明明一个很简单的需求，至少需要X个月的开发，但*后我们发现，*耗时的地方是团队内部的沟通。整个团队的开发节奏要么紧要么慢，要么每天要么救火要么放羊长草。工作中体会不到迭代的优雅节奏，就像不知道下一口是便便还是巧克力一样。
如果此刻，你的小脑袋正情不自禁地点头，那么请把你的小手交给Lisa阿姨，让她带领你走进优雅版本迭代的大门。
照例，进去之前先让阿姨摸摸你的骨头：
以下哪种观点更符合您的观点？
答：我是一个完美主义者，我总是力求做到*好。
B.我是一个现实主义者，我会在现有的选择中找到一个相对较好的解决方案。
如果你的选择是A，那么……以后请记住不管怎样都要选择B，好吗？
请将这段话抄在你的笔记本里：
软件产品设计的出发点是为了帮助别人，所以这也意味着理想情况永远不会存在。产品科学是一门工程科学而不是纯理论研究，实现才是重中之重。
接下来就让我一步步指导你。
步骤 1：以正确的方式谈论需求
当我们谈论需求时我们在谈论什么？让我们回到每个团队成员的视角：
产品经理视角：用户痛点就是需求设计师视角：需求就是确定的交互细节和界面UI程序员视角：需求就是我想要实现的功能列表
其实这并不奇怪，因为团队里的分工不一样，理解自然也不同。如果非要给需求一个定义的话，我觉得这句话比较标准：
能够为特定的人、在特定的环境下解决的问题称为需求。
那么如何才能统一对需求的认识，并正确传达需求呢？法宝就是：PRD（）
鲁迅说过：一个好的PRD能使整个团队的工作效率提高90%以上。
PRD的生产过程*好分为三个阶段：
PRD 的生产过程就是将抽象需求转化为具体开发细节的过程。这就是产品工程的魅力所在！
如果你之前有以下的情况：
曾经为一个需求绞尽脑汁想解决方案，但抬头一看，却发现离目标越来越近了。我花了很多时间做了一个 PRD，自以为完美无缺，却在例行的 会议上被老板一巴掌打下来了……
那么恭喜你，以后应该不会再出现这两种情况了！
我们做PRD的时候，我们的思考和沟通都是循序渐进的。
千万别以为你一个人努力工作，*后能拿出一份漂亮的 PRD 扔到老板面前，让他刮目相看。相信我，你老板此时只想掐死你。他不杀你还能杀谁？
所以请你从今天起答应阿姨，我们要做循序渐进沟通需求的好宝宝好吗？不要一开始就纠结于互动的细节和逻辑好吗？
第 2 步：用正确的方法管理需求 1. 管理需求
需求的来源多种多样，但可分为主动需求与被动需求两大类。
产品的业务目标分析、用户研究、数据分析、竞品分析、性能相关、UI相关、技术迭代等都属于主动需求；而业务部门（市场、运营、销售、管理）的诉求、用户反馈、遗留bug等都属于被动需求。
管理可随时同步的Excel表格。
例如：
需要注意的是，这个需求管理表一定要动态更新，并定期审核，特别是要记录需求的来源，因为审核的时候往往需要追溯来源。
2. 确定需求的优先级
很多人喜欢用重要+紧急的四个象限来排列自己的需求的优先顺序，但事实往往是几乎所有的需求都在重要+紧急的象限中。
所以请赶紧扔掉这个2019年的方法，跟着我使用2020年的解决方案：满意度模型。
简单来说，就是按照“可实现”和“附加值”两个维度，将你的需求划分成四个象限，并重新梳理你的需求的属性。
那么你的需求优先级就变成：
毕竟对于一个开发者来说，能够解决复杂的问题才是体现其价值的唯一方式，而这往往与产品的价值相悖。
第三步：优雅地安排版本的迭代节奏
这是Lisa阿姨总结的产品开发流程，我们团队已经运行这个流程五年多了，非常流畅，相信对行业内大部分团队都适用。
我将产品开发步骤分为以下四个过程：
概念阶段：顾名思义就是确定需求的阶段，此时需求是OPEN的，任何可能性都有可能发生，这个阶段需要完成PRD评审、交互可视化评审初级产品经理必知：做好软件版本规划的三方面，确定开发方式、开发节奏安排。 开发阶段：是需求实现阶段软件开发，此阶段严格冻结需求，即不允许再插入需求（只有能力不足的产品经理才会乱插入需求），此阶段完成技术评审、点评审、测试用例评审。 验收测试阶段：此阶段允许对需求进行微调，毕竟验收时可能边界条件考虑不周、文案不合适，此时的微调不算是需求变更（拉钩承诺）。Lisa姨建议每周要有固定的时间进行验收（这样的节奏谁不爱呢）。 发布阶段：发布前记得做发布策略评审，特别是要安排好灰度发布策略，否则一次性发布给所有用户，BUG就扑面而来，你甚至来不及回滚。
这样当一个版本迭代完毕之后，第二个版本的流程*好是在**个版本的开发阶段结束时就开始进行，因为这时候开发人员刚刚结束繁忙的开发工作，有闲暇来和你讨论新版本的需求！
*后：*好把相关功能分开一个版本，比如功能A和功能A的优化安排在版本1和3，功能B和功能B的优化安排在版本2和4，这样一整个版本就有足够的时间调整，节奏是否优美，步调是否优雅？
作者：Lisa Deng；公众号：Lisa D的产品笔记
