作为产品经理，面对各种需求，我们需要有管理好各项需求，统筹安排的能力。作者总结了在项目过程中需求管理的一些方法，希望对你有所帮助。
今天聊一聊需求管理~
之前有写过一篇文章叫《需求和期望管理——初级项目经理巨坑之范围篇》有聊过怎么管理需求的范围，今天来聊聊整体的需求管理。
在之前的文章里我有过一个简单的定义：万物皆产品，万事皆项目；在日常生活中，我们无论做什么事都会有一个出发点，而这个出发点则是我们做这件事的“需求”；比如我要去喝水，那我的需求是解渴，我要喝奶茶，那我的需求则是解馋。
绝大多数糟糕的项目，究其原因大多数都是因为需求没有管理好，这其中有很多原因，有个人层面的也有企业层面的，但无论何种原因，需求管理一定是项目经理们需要牢牢掌握的一个重拳技能。
那么这次我将从多方面来介绍强仔在项目过程中需求管理的一些方法，抛砖引玉供大家借鉴~
在做某一个项目或者某一款产品时候，很多新手都是拿来领导指令或者合同后不去做需求的基础分析，直接就去对项目干系人做需求调研了，最后调研的结果勉勉强强，运气好会顺利通过，运气不好就被甲方或者领导直接拍回来，然后自己原地懵逼，不知道问题出在哪。
那么什么是需求的基础分析呢？
很简单，就是这个需求——或者说这个项目——是给谁做的，要满足什么目的。
比如，这个需求是领导想做出来给领导自己长长脸，还是客户提出来想满足内部工作效率的，是政府要解决民生需求的还是领导小姨子觉得你们的产品不好看随意给领导吹枕边风的。
那么为什么要做需求的基础分析呢？
是因为我们要明确项目的最终交付方向是否正确！
因为开展工作的环境各不相同，如果单纯是做交付型项目经理，其实比较简单，绝大部分项目都是外部客户的需求，但是对于产研类的项目经理来说，则需要做好区分。
这个区分的点在于需求的交付对象是谁，同样都是收到了领导指派的需求，那么需求的提出者是谁？是终端客户是老板还是产品经理们？他们的目的是什么？是为了产品使用更加舒服？还是要增加盈利？是为了职位升迁？还是补齐曾经的产品缺陷？
不同的诉求，不同的对象，项目管理节奏是不同的，偏重点也不尽相同。
盈利型的项目在质量管理中要尤其偏重，优化产品型的需求则需要在沟通管理中指导产品经理做好需求调研，补齐产品缺陷的项目则需要注重进度。
总之项目类型千千万，着手启动前需要尽可能做好准备，以便达成最终目标。
其实很多新手刚刚项目经理或者产品经理刚刚开展工作的时候，比较缺少一些管理思路，我们需要知道，做一个项目的时候，我们的目标在哪里，最简单的目标可能就是完成项目交付收回尾款，那么，什么才叫做“完成项目交付”呢，很多时候我们明明按照需求清单一五一十按期保质完成了交付物，但是客户就是说不满意，这里的原因就是我们没明白客户的基础需求点是什么，也就是说，我们在需求调研阶段做的不够好
“需求调研”是我们在开展工作中常有的对于客户诉求收集的常用叫法，但其实在多年工作过程中，我发现这个叫法实在是太过于不清晰不严谨，以至于很多产品经理、售前经理、解决方案经理等等需要做需求收集的人拿着纸笔冲到客户现场就直接去问了：您的需求是什么？
我觉得这种做法对于公司对于客户来说都太轻浮，对于“需求调研”的工作也是不负责任。
为什么我会说的这么严重，因为我觉得“需求调研”的工作应该拆分为两个阶段，分别为“需求挖掘”和“需求引导”。
当然，做好这两个阶段的工作的前提是要有“自知之明”，也就是说要对本公司产品能力有着充分的了解，对自己能调动的资源有着清醒的认知，清楚明了的了解你能做出什么样的东西，才能更好的对客户负责。
好，聊聊需求挖掘和需求引导。
为什么我觉得需求挖掘和需求调研不同，而需求调研比较不谨慎呢？是因为需求的调研仅仅是根据一个方向来问，比如你收到的需求是给客户做一盘西红柿炒鸡蛋，单纯的做需求调研，可能出现的情况就是直接问客户：您喜欢甜口的还是咸口的？放不放葱姜蒜香菜？加不加米饭？而做需求挖掘时，说的更多的则是为什么；为什么您想吃西红柿炒鸡蛋了呢，是因为最近馋西红柿了还是只是饿了呢？
客户往往要做一件事时总是要有一个目的的，而客户往往不是一个人，而是一个公司或者一个体系，那么所有的干系人就都会分别的有一个目的，项目成果——即交付的产品——一定是他们的显性需求，这个是众所周知的，哪怕不清晰明了的部分也仅仅是功能点不同或者流程不同而已，影响并不大，就算真的有所疏漏解决起来也方便。
那么所有干系人，他们的隐性需求是什么呢？是因为这只是领导指派的任务？还是他们需要我们的产品来解决一些问题？又或是满足国家政策的需求而相应号召？还是其他的什么呢？这些隐性的需求，或者叫做诉求才是我们需要挖掘出来的内容。
需求引导，这个听起来是销售经理们在做销售工作的时候做的动作，其实并不全面。
我们在做需求挖掘的时候，一定会出现的情况就是客户的需求以我们现有的能力还做不到，这时候就体现出来我们的“自知之明”了，了解了客户的隐性需求之后，这些我们现阶段实现不了的功能我们是否可以用现有功能平替呢？或者说客户需要的功能是否真的是他们所表达的功能呢？这些都是我们需要引导的。
举个例子：之前服务写字楼物业管理公司的时候，接到了客户的一个需求：我要做园区写字楼内部的美团！且不说当时我的公司很小，无法开发功能及其复杂的带有支付、配送等一系列的完整的外卖功能，单单是一个支付功能就已经可以把我们完全打死了。
那么我们是如何解决的呢？特别简单，就只是派工单，将商品平铺陈列，收到用户“下单”就指派给相应的工人，工人现场收钱，并带着两张打印出来的纸质工单，双方签字各留一份，所有流程就完美闭环了。
当然，例子归例子，有很多不完美的地方，但是最终我们的目的还是达到了，解决了客户的诉求，也解决了公司回款的要求。
回顾一下，调研需求的要义就是，有着清晰的“自知之明”，做好“需求挖掘”及“需求引导”工作。
管理需求，市面上已经有很多书籍、文章、资料介绍了，我就按照我个人的逻辑再唠叨一遍吧~
前期即开工前期，比如软件项目的研发开始前。
在开工前期，做好前期调研过来的需求的梳理，根据梳理好的需求编撰项目的解决方案，给客户进行汇报，在双方都确认无误之后要做好解决方案的确认工作。
这里有两个重点：
一是解决方案一定要覆盖好客户的全部需求，哪怕有些需求无法满足，也要在解决方案中说明解决办法，是二期做，还是协商一致取消，还是采用其他方法来满足，如果没有全覆盖，哪怕解决方案做好了确认，项目后期也可能会出现扯皮现象，算是一个风险点吧。
二是做好需求确认，这个确认并不是说开一个汇报会，大家都说好就结束了，是真真实实的要落到“纸面上”的确认，可以是发邮件双方都回复确认，也可以是打印出纸质版方案双方签字确认，最次也得是微信、钉钉等群里的所有人回复OK；确认好需求解决方案再动工，才能保证有的放矢，也能保障自己工作的顺利进行，减小风险。
中期即研发/施工中期。
控制需求范围：项目管理是一个非常严谨的工作，需求范围的控制也是一个非常严谨的工作；当然这并不意味着控制需求范围很难，相反它还非常简单，只需要按照需求解决方案一五一十的做就好了，保证交给客户的产品不要多也不要少即可，多了的话算是对项目镀金，客户不会说什么，但后期问不太好解释，少了的话客户大概率会追究，对后期验收影响很大。
控制进度：这一点与控制范围一样，只需要严格按照前期与客户确认的项目计划实施就行了，需要注意的也是不要提前也不要延后，提前完成的话会让客户有一个我们谎报工时或者需求非常简单的印象，后期可能随意让我们增加功能或任务；延后就更不用说了，项目延期对项目验收是一个相当大的风险点。
说起来很简单，但是控制进度还是相对较难一些的，进度提前了还好说，只需要压着到指定的时间再交付即可，但是绝大部分情况其实是很难按期交付的，那么我们要做的就是两点：
其一是定期、频繁的跟踪完成情况：这点很好理解，定期跟踪完成情况能让我们做到心中有数，这样就算有突发情况或者有延期风险我们也能尽早准备对应的解决方案。
其二是及时、全面的汇报：这一点是非常容易做到，但是非常容易被忽略的一个点；很多新手，甚至是老手都很喜欢埋头苦干，不喜欢汇报，就算是汇报也是报喜不报忧，想着就算出问题了，也先自己解决，对客户进行隐瞒。
其实没必要隐瞒，也不要去隐瞒，项目是给客户做的，不要想着所有事情都自己来做，所有的风险都自己扛，这会带来很多很严重的后果，包括但不限于：给产品或工程留下隐藏的缺陷、严重增加项目工作量、项目范围控制不住等等。
其实不是所有的后果客户都承受不了的，也不是所有的困难都不能让客户参与解决，及时汇报可以让客户也充分了解项目难点在哪、风险点在哪，有一些突发情况出现的时候也可以及时与客户协商，做一下需求的变更或延后。
汇报工作没啥的，很多人不做汇报主要是“怕”，想开点，没啥的~
控制变更：做项目，变更是常有的事，没有变更是及其罕见的，所以做好项目有变更的准备，以及做好变更的控制，是项目管理中很重点的一环。
那么如何控制变更呢，并不复杂，无非就是聊钱和聊时间的问题。
需求变更分为增加和减少两种，其中减少需求非常少见，或者基本见不到，出现了也不用慌张，无非就是菜已经炒完了钱肯定不能退了而已，而且进度也不大可能提前，除非是客户突然对项目进度要求非常紧急，比如省、市领导下个月就要来检查了，必须在本月底之前完成，那么就跟客户商量好，哪些需求或者工程就不做了，先做最重要的部分，达成一致即可。
然后一定做好记录，也就是签订需求变更协议！
绝大多数情况的需求变更都是增加的需求，那么就要与销售做好配合，聊聊钱，聊聊时间，算好工时，增加这个需求后，需要加多少钱，客户是否能接受，项目工期要延后多少，客户是否能接受等等，也是达成一致即可。
然后也一定要做好记录，也就是签订需求变更协议！
项目后期指的是研发/施工完成之后。
管理验收：验收工作是项目经理最体现商业价值的工作，一般做好验收就可以跟客户要钱了，所以网上相应的资料简直是太多了，我这边就不啰嗦了，重点还是要把工作落实到“纸面上”，即要么签字确认，要么邮箱回复确认。
管理记录：其实单把“记录”工作拿出来会显得有些突兀，但是这是我在工作中发现的另一个非常重要的环节，与汇报一样，很多新手以及部分老手，对于项目资料的记录工作非常不上心，认为我做好验收就行了，什么项目资料啥的完全不重要。
其实不然，项目资料非常有价值，说项目资料属于公司资产都不为过，比如项目的需求解决方案，如果适用于其他客户的话，脱敏后直接与其他客户进行讨论会省去很多资源；再比如同一个项目要做二期工程了，那么一期工程里都做了哪些工作，什么东西可以利旧，如果不是同一个项目经理来做或者前一任项目经理离职了，新项目经理对项目完全不了解，那么就会导致客户与我们都两眼一抹黑，还得费时费力重新梳理，何苦呢。
至于怎么去记录项目的资料，就按照标准的项目交付模板，严格记录就好了，必要时打印出来留存，交付模板大点的公司都会有，小公司没有的话网上也一大堆，实在不行淘宝都可以买到，用心做即可~
本文由@李强~ 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。