科技猎资深产品经理是如何做需求管理的（一）：需求的优先级判定原则
需求管理是产品经理的基本功。虽然从入行开始，产品经理们就开始接触需求了，大部分的人跟过一遍需求流程都能快速上手。但是基本功也正是考验功力深浅的关键所在。本来希望用一篇文章去讲清楚如何做需求管理，但发现这样会导致文章过长不易读，索性用一个系列来仔细聊聊，到底什么是需求，如何做好需求管理。
这一期主要讲两个基本问题：
- 什么是需求
- 整体思路下的优先级判定原则
以下，Enjoy。
需求是流水线上的零件？
回想刚入行时，我对 需求的理解就好像是从流水线上传过来的一个零件 ，这个需求是上游给的，这个需求是业务给的。即使是mentor说，或者你意识到要评估衡量管理需求，对于一个新手来说，事实上总是缺少对需求的管理的。当然，这是每个产品经理成长必须经过的一个阶段，我以及周围很多同行的经验告诉我，这个阶段是无法jump过去的，在这个阶段中的PM们也不要心急，没有什么秘诀或者捷径可以让你获得老司机的功力，必须有这样的思想准备。
和所有迷茫焦躁的新手PM们一样，我也是跟着一遍一遍走需求的完整流程。最开始在需求的管理和把控上都很被动，因为在业务驱动的公司，业务部门具有天然的话语优势，你会感受到分分钟被GMV碾压——“这个功能非常重要！这一期必须上！”“为什么？”“不上我们会损失XXGMV，会严重影响用户体验”……类似的对话相信很多产品都很熟悉了。 我当时的感受是，每个月总有那么几天是在和业务围绕着成吨的需求进行低效率地撕逼，撕完之后再去反省，就会觉得自己好弱鸡，“如果换成这样的思路，这样的说服方式，效果应该会好一点。” 经历多次撕逼——反省——撕逼的非良性循环后，正好是另一个新的大版本的开始，我下定决心要整体复盘寻找这种循环的七寸。经过一个春节假期对所有旧版本需求的梳理以及分版本的复盘之后，突然感觉打通了经脉，有一种“呵，原来需求要这样管理”的感悟以及“我原来到底是怎么做需求的？！”的诧异。
需求是part of your plan
前面讲到，最开始我认为需求是流水线上的零件。虽然每一期都会对需求进行“ 优先级判定 ”，但是那个阶段做得更多的是把零件放到不同的地方而已。 看起来好像已经排了优先级，但是这种排序的问题在于——缺少连贯性和继承性。这个问题的症结在产品的顶层设计。
当然这个insight来自于我对旧版本的复盘。我惊讶的发现，在一个大版本里面，竟然每个小版本都有交互优化型需求。（我究竟干了些什么样的需求。。）在移动产品中，大部分交互优化型的需求属于紧急（资源集中在前端并且要跟着发版上线，时间上游限制）但不重要的需求。不重要，并不意味着交互优化对用户体验没有作用，而是说，根据这个工作的ROI来看，根本不值得每一版伤筋动骨。
那么，为什么会出现密集的交互性需求呢？只有一个原因，产品经理根本没有想过“产品框架设计”。就好比一个建筑师首先必须明白房子的结构是怎样的，产品经理也是，必须跳出需求本身去思考产品框架怎么设计。也正好比一栋建筑的结构不能随意改动，产品经理在设计产品框架时，也必须用长期的视角去考虑，要搭建什么样的基础框架，更直白点说，一个大版本，基础产品形态是怎样的？整体的思路如何？
经过这样的复盘和思考，我对需求的理解也有所升级：需求应该是part of your plan,是大框架下的小模块甚至小砖头，也就是说，所有的需求都要为Plan这个整体目标服务。
整体思路下的优先级判定原则
当意识到需求要为整体目标服务时，对需求的优先级判定就有了顶层设计思路。
当然，涉及到大版本的整体思路，必须要和相关团队同步脑暴，形成共识。（后续会和大家分享下如何做产品规划）在团队达成共识的基础上，由于大家目标一致，在小版本上的需求管理就会变得容易很多。实战经验表明：如果团队目标一致，主要是业务方和产品有统一的共识，不仅在 需求提报环节 模糊的需求会减少很多，在 需求评估环节 ，双方也更倾向于快速达成一致，低效的撕逼也减少了。
团队没有共识的时候，很容易发散地走向不同的思维路径，这种情况是我做低年级产品时经常遇到的困境，经常是沟通了多次之后发现谁也说服不了谁。在团队思路一致的情况下，这种情况基本上不会出现了，如果意见不合出现分歧， 那就回到争论的原点从整体的思路出发看到底哪种方案更有利于共同目标的实现（优先级判定的终极原则）。
如果你发现你总是陷入低效的沟通或者无结论的争辩，建议lead团队对产品的框架进行脑暴和review，对于后续整个的需求管理，这是最重要的步骤。
本文由 @时雨 原创发布于人人都是产品经理。未经许可，禁止转载。
