编辑导语：需求管理是产品经理日常工作之一，我们会发现提需求很容易，但是做一个需求文档却不简单，需求文档需要进行优先级的划分、各相关方的分配等等；本文作者分享了关于产品经理在做需求管理时需要注意什么，我们一起来看一下。

言之有理的需求竟然暗藏巨坑？众望所归的功能为何屡遭波折？需求池频频饱满，是产品的懒惰还是业务的过错？让我们跟随产品经理的视觉，走进需求管理爱恨交织的奇幻世界。

小P曾经作为一个产品实习生，被安排到跟着我一段时间；虽然非产品专业出身且又非211/985，但好在这后生争气，把自己当做产品一样不停迭代，以几何速度在职场中打滚发展，终究练就了一套需求管理的心法；其中离不开被各方需求的鞭笞毒打，以及我的毒舌吐槽。

以下日常对话摘录，可从中窥见其成长的心路历程，与大家分享与共勉。

一、垃圾分类，从需求池做起

小P：“哥，最近的需求多到要爆炸了，周末我还想约女朋友去看电影呢，但一堆需求文档和原形设计没做完，开发测试那边也整天催催催，救我！”

我看着他整理清单上的需求点，一脸嫌弃的说：“你在开垃圾场？什么乱七八糟的东西都当做是需求写进来，又不划分优先级，这样做需求管理，把自己干死都做不完，嫌头发多吗？”

接着我草草几笔，在本子上写了一个需求管理生命周期的流程出来。

我：“你小区有搞垃圾分类么？”

小P：“有，有”

我：“好小子，垃圾分类的口诀记不记得？”

小P：“啥？”

于是我敲了几个字给他：猪能吃的叫湿垃圾；猪不能吃的叫干垃圾；猪吃了会死的叫有害垃圾；可以卖出去换猪的叫可回收垃圾。

小P一脸茫然的问：“这个和需求管理有啥关系啊？”

我：“你每天丢垃圾时，会把钱包钥匙手机一起丢掉吗？不会，为什么，因为你知道那不是垃圾；你在收集需求时，为什么就不识别一下，对方说的话到底是垃圾还是需求呢？就全部一股脑的接了。其次，你丢垃圾的时候会分好类吧，接需求的时候也要分好是业务需求还是技术需求，优化建议还是问题缺陷？以后你接需求前先心理默念几遍上面那句口诀，用来提醒自己要记得分类！分类！分类！”

小P似懂非懂的点了点头：“知道了，我下次捡垃圾，啊不，接需求的时候会注意点”。

二、与人为善，从需求文档做起

小P每天在工位上噼里啪啦的敲着键盘，工位上访客车水马龙， 等到午休时候，我端着茶杯过去看了一下他像弹幕一样飞过的聊天窗口记录，关怀的问：“小P，你在忙什么呀？”

小P不疾不徐地说：“我在和不同的业务和开发聊需求呢。”虽然一边看着我说话，但丝毫不影响他飞快地敲键盘。

我说：“怎么天天都这样聊个不停，需求文档给我看一下”， 但当拿到需求文档后，我不禁陷入深思，这写的什么玩意，只有业务描述、功能框架及简单的原型交互！

我：“好小子，就知道经常和女朋友去看电影，那你知道为什么爆米花电影票房总是比文艺片的票房要高一大截吗？”

小P：“那还用说，爆米花电影受众广，什么群体都合适，看着轻松愉快；而文艺片都是面向小众群体，没多少人看得懂，也没多少人有兴趣看，自然没那么大卖。”

我：“同样的，你需求文档的受众不止是业务方，还有交互/UI/开发/测试/项目经理等人员，甚至是作为产品经理的你自己！你文档里不把各个相关方照顾好，那么就会在相关处理节点和别人一直纠缠；爆米花电影容易大卖也是最容易被狂喷，因为他要兼顾好各人的期望。”随即拿起本子刷刷刷的写了几点关于需求文档的重要性。

小P也和我交了底：“哥，技术方面我很小白，什么数据字典、实体属性那些都不是很懂。”

我：“需求文档并不是意味着要补齐很多技术方案在里面，但这些要素你是要考虑到的：

• 不写背景与目标，以后回溯这个需求时，你还记得当时为什么要做这样的需求吗？
• 不写修订历史，开发测试们怎么知道你每次更新的版本增添改动过什么内容？
• 不写业务流程，在分析业务时怎么明确自己和业务方的理解是一致的？
• 不写交互说明，设计测试们怎么把握功能界面上每个交互的细节以及你所达到的期望效果？
• 不写……（此处省略1000字）。

你的需求文档上啥都不写，那大家肯定都是一直围着你团团转，看似每天都很充实，其实一直在浪费大家的时间。”

小P停下抄笔记的动作，凛然到：“哥，我错了，你给个模板我吧！”

三、顾全大局，从干系人做起

经过一天的埋头苦干，小P向我展示了他的初步成果，“哥，xx部门的人之前提的个需求，看我这方案牛B不。”

我看了一眼需求方案，“好小子，你想笑死我好继承我的蚂蚁花呗吗，被人卖了还帮忙数钱。”

小P似乎有些不满道：“我觉得这解决方案写得很完善，挺切合他们痛点的呀，而且需求提出人也很认可。”

于是乎，我又在本子上草草地写了一下干系人的关系图。

我：“你和女朋友结婚，是不是还得问问丈母娘的意见？是不是还得了解下自己爸妈的意见？评估需求前，先看看这个需求是否合乎规范，就像你和你女朋友是近亲或有不适宜结婚的疾病，那就不能结婚了；例如随便一个人给你提需求要查看全公司人员的工资条，你也接这个需求吗？其次，还要评估该需求是否符合需求提出人领导的管理意愿，假如你越过对方领导给对方做了一些业务功能，虽然提高了业务的工作效率或体验；但削弱了业务领导的管辖权限，架空了对方领导，底层干活的人爽了，领导可就不爽了。”

小P还是想继续挣扎：“可是我的方案给需求方和他的领导都看过，他们都没问题啊。”

我嘴角微微一扬：“你这个方案，需要投入大量的设计开发测试资源，咱部门的资源有多紧缺你知道不？另外这个业务部门和我们之前也没有合作关系，接新业务时应该请示一下自己领导，考虑下是否应该和对方建立合作关系，能否调配资源去支持需求实现，别人说你就做，咱们的开发测试怕是要拿你来祭天。”

我见小P开始有点泄气，安慰道：“其实你的这个方案还是有可取之处，起码这是一个符合业务逻辑和用户使用习惯的合理需求；像在疫情期间你帮行政部门做的采集员工健康情况需求，要求每个员工每天重复填写一大堆同样的信息，但其实大家每天的健康信息几乎没有变化，但却不能自动获取前一天的所填信息；这种方式虽然符合业务方的期望及管理要求，但真实用户的体验就差劲至极，遇到这种情况，也应该在做方案时候识别好其中的风险及问题点，及时和相关业务方交底；以后管需求都记住4个字：顾全大局。”

四、结语

小P只是万千职场产品新人的缩影，曾经是你也曾经是我。

希望大家的职场岁月不只有被吹散了的头发，厚实了的肚腩，还有被产品工作历练加持的职场美德。

本文由 @ kenfai 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议