需求的把控就像开车握着方向盘。可能只是偏离一个很小的角度，车行驶的轨迹便完全不同。
重要性
不知为什么，大部分时候我们总是倾向忽略需求管理的重要性因此我会老实地多写一些字来强调这点。
我尽量用轻松的语气聊这个话题，虽然这个话题沉重无比。
需求是产品不断完善与进化的核心抓手。
我们的产品团队，研发团队，测试团队,交付团队，他们一个个都在围绕需求，日以继夜地工作，挥洒汗水，试图把产品变得更完美。
大家如此努力，我们的产品真的有变得越来好了么？
有没有发现产品里充斥一大堆没几个人用的玩具特性？
产品的各种功能仿佛一大坨狗皮膏药层层叠叠地贴在一起，让人望而生畏
。
没有一个人说的清楚产品的完整的权限体系，总有各种漏洞和分支情况。
经常碰到奇怪的小机关在不起眼的角落，过了一段时间没有人知道这上千个开关都是做什么用的。
研发变得越来越慢，技术小哥每做一个新功能都徒劳地想把牵扯到的几十种场景梳理明白。最后决定推翻了重做。大量重构让人身心俱疲。
一个按钮是否显示的判断逻辑写了十几个条件，让人眼花缭乱。即使是一个小修改，由于产品经理一时考虑不全相关联的几十个点，后期总有大量的【设计遗漏】类型的bug提上来。
哦！这简直糟糕透顶！难道不是吗！
我仔细思索了一番，我们时常选择忽视需求管理，可能因为这实在是一件很难的事情。
我们需要有大智慧，大勇气，大决断，来做好需求管理。
需求管理在产品研发流程的最上游，因此每一个错误的决定，都会导致后续巨量，无效的研发成本投入，测试成本投入，修正成本投入，额外运维成本投入。杀伤力堪比原子弹。
很多人都了解【技术债】这个词儿。由于初期用了不恰当的架构，导致后续所有研发都不那么对劲，总是有着不可理喻的限制或者瓶颈。
类似的，如果忽略了需求管理，我们会慢慢背上【设计债】。
这种债更直观，见效更快，效果更明显，影响更广泛。
当我们焦头烂额，步履维艰的时候，看不下去的老板可能终于有一天来问你
小马，我如果给你2000万，让你再拉30个人，花一年时间把产品重做一遍，是不是能解决问题？
如果不清楚症结所在，我相信你答不好老板的这个问题。
你需要的角色
这个部分我们探讨你需要哪些小伙伴来做好需求管理。产品总监
产品总监的作用可能比我们想到的更广泛，更具体，更具影响力。这绝对不是一个虚无缥缈的Title。在产品型公司，产品总监就是公司的灵魂，是产品进化的舵手。除了清晰的思路，他需要像孩子一样疼爱自己的产品，不停地思考如何才能把自己的孩子培养得更优秀。
这个职位的人需要有相当的决策权力，以保证其智慧，决断，领袖气质，能够引领产品向着正确的方向行进。
最优秀的产品总监会争取他所需要的决策权，为了让产品符合自己的设想不择手段。然而这样的人真的可遇不可求。所以不是找到一个能力出众的产品总监就结束了，一般情况下他需要充分的授权。
他的重要性
必不可少他的工作内容
规划产品边界
产品是什么？能做什么？不能做什么？成本是有限的，产品总监通过厘清产品边界，帮助我们阻止成本浪费在无谓的特性上。再强调一遍，这里的成本包括研发成本，测试成本，交付成本，运维成本等一系列巨量的下游成本，所以千万别在产品设计环节省钱！
我讲个故事大家都懂了。
有一个做考勤打卡产品的公司，他们有很多大客户。
有一个客户提出能不能帮忙管一下员工休假。
于是公司花了一个月完成了休假模块，员工可以在产品中提出休假申请，并进行主管审批。
过了一个月客户提出不能做休假申请撤回，有时候员工不能按计划休假，需要有个撤回休假申请按钮。
又过了一个月，客户再次提出员工休假需要有公司级别控制，需要在产品中完成员工休假计算模块，计算员工休假剩余天数。
一切还没结束。
没过几天客户打电话来，员工休假数据没有和薪酬系统打通，休假需要影响薪酬计算。
这个故事我还可以写很长。
但是意思大家明白了吧？
假如我们的产品是一个完美的圆，当客户要求边界外的东西的时候，就相当于在这个圆上凸起一个【包】，我们的产品不圆了！不要存在侥幸心理，后面一系列压力会让我们把这个【包】周围都补全了，变成一个更大的圆。
做这件事情有着我们很难预估的成本。当这个包不是我们产品应覆盖的东西的时候，画这个圆的成本就是不折不扣的浪费！
规划产品进化方向
产品边界并不是一成不变的，产品总监要有高屋建瓴的思路，要有对竞品降维打击的气概和长远规划。没有这个规划，产品的生长就是无序且混乱的，必然导致多走很多弯路。很经典的案例就是美团产品的进化扩张路程。
由最初的团购，到涉足外卖业务，到合并大众点评，到现在的美团打车。
一个产品体系中的产品互为倚重，相互引流。点评搜到饭店可以直接美团打车过去，美团外卖会送打车优惠券。这种产品体系的扩张方式体现了产品总监高超智慧。
参与需求总监评审
需求总监评审是产品总监控制产品发展的重要抓手。总会有纷纷扰扰的需求不停地被提出，做还是不做？自己做还是用外部产品？自己做的话用什么方式做？
产品总监需要清晰的思路和优秀的沟通能力，表述自己的观点，说服需求提出者按照自己的意志来进行。
其他日常事务
包括招募团队成员，协调分工等，在此就不细述了。产品经理
产品经理要做的事情复杂而繁琐。你绝对不想让什么人来兼职这个角色。那未免太不人道了。
我们不妨先来看下产品经理的职责清单。
| 产品经理的职责 | 描述 |
|---|---|
| 竞品调研 | 时刻保持对竞争对手的了解 |
| 客户交流 | 了解用户的感受 |
| 形成初步需求（产品故事） | 梳理产品需要哪些新特性 |
| 与产品总监一起完成总监评审 | 说服产品总监花成本做这件事情是有意义的 |
| 与其他模块产品经理完成需求概要传递，检查模块间影响 | 可能需要其他模块的配合才能做好这件事情 |
| 与技术负责人一起完成技术评审 | 技术负责人会根据技术实现，提出一些自己的实现建议，这些建议十分重要 |
| 形成完整的需求文档 | 根据以上所有输入，完成最终的详细设计 |
| 与UX&UI团队沟通，完成UX&UI设计 | 向UX和UI团队讲解所需实现的需求 |
| UX&UI验收 | 保证UX和UI与自己的需求设计一致（这一点非常重要） |
| 与开发小组，包括测试团队完成需求详细传递 | 根据需求详细设计，UX，UI，与开发团队全员传递所有的需求细节 |
| 开发提测后，完成产品初期验收，防止需求变形 | 为防止开发过程需求变形，产品经理需要在开发提测后，第一时间判断实现是否大体满足要求。不要在上线后采取看开发做的东西是否是自己想要的，那时候一切都来不及了。 |
| 需求上线后完成上线验收 | 上线后检查需求是否完整无误。 |
| 上线后监控需求效果，进行后续调整 | 产品经理需要关心自己花了大量人力物力做出的特性用起来反馈如何 |
这绝对是一个高难度的职位！
鉴于产品经理的工作如此繁杂，有些公司会将这个角色拆分，多到可以拆分成4个：
| 角色 | 分工 |
|---|---|
| 运营经理 | 主要接触终端用户与市场部门 |
| 产品经理 | 主要完成产品故事相关的工作 |
| 需求分析师（BA） | 详细的需求设计与实现方案 |
| 项目经理 | 监督研发上线进度，对需求保质保量按时落地负责 |
优秀的产品经理需要具有以下特质：
| 优秀产品经理的特质 | 描述 |
|---|---|
| 良好的沟通能力 | 他需要和形形色色的人沟通。表述和说服占用了他很多时间。 |
| 良好的团队合作能力 | 他需要和外围团队以及产品团队内部的每个人维持友爱的关系，不然他的工作就会步步维艰，或者漏洞百出 |
| 良好的抽象能力 | 产品不是单纯的特性堆积。每次一个新的需求出现，都是对现有产品体系的挑战。产品经理需要思考为什么产品架构无法轻易地实现这个新出现的需求，形成架构层次的实现方案。否则产品就变成了一堆膏药贴在一起的丑东西。 |
| 高要求 | 对自己要求低的产品经理，对产品的要求也不会高。他的输出的东西也会让人痛苦。不要让这样的人留在产品团队。鉴于产品经理的重要性，他将成为我们的木桶的最短板。 |
| 熟悉产品 | 这是一切的基础，我碰到过经常想不起来产品有什么功能而去问研发和测试的产品经理。那真是一个噩梦。 |
需求生命周期
好吧，我们千辛万苦找到了牛逼的产品总监，凑齐了优秀的产品经理，来了解下需求的生命周期。我们不想漏掉以下任何一个关键步骤，那会让我们产品团队的能力大打折扣。
产品总监评审
前面多次提到这个过程。这个环节保证研发的工作基础是有意义的，是有益于产品的。这个过程的缺失，会导致产品走大量弯路，产品总监的思路和构想将难以落地，其价值也难以体现。
产品经理内部需求概要传递
当产品总监认可一个需求项后，需要在各个模块的产品经理传递需求概要。这个步骤保障需求在落地过程中可以获取到各个模块的支持和帮助。这个过程的缺失将可能引起模块间配合遗漏，导致有缺陷特性产生。
技术经理评审
产品经理与模块技术负责人完成技术经理评审。技术经理从技术架构的角度分析需求，给出实现建议。在这个过程中，产品经理将得到技术负责人的帮助，完善需求的实现方案，并根据技术负责人的成本评估对一些特性做出取舍。否则有些锦上添花的次要特性会占据研发的一半以上时间。
需求文档编写
当接收了产品总监，各个模块的产品经理，以及技术负责人的建议与祝福后，产品经理现在可以综合考虑前面的输入，完成最终的需求设计。这是产品经理的最重要的输出之一，体现了产品经理的综合水准。值得注意的是，需求详细设计并不是只为了指导研发完成需求落地，它还是产品逻辑的文档体现，为后期知识传递以及未来逻辑追查留下的重要文献资料。
UX和UI的评审
产品经理需要验收需求的UX以及UI。很多需求变形都是从这一步骤开始的。UX组对需求的理解不透彻，导致UX图就有问题。UX作为研发团队的重要输入，将为研发团队提供错误的指导。最终做出的特性也会和产品经理的想法大相径庭。需求宣讲
当一切准备就绪，产品经理需要向研发团队（包括测试组）宣讲完整的需求，包括每一个细节。工具就是需求详细设计，UX&UI。技术经理将拆解需求到任务，编制研发计划，准备开展研发工作。
测试组也将根据这次宣讲的内容，以及需求详细设计，完成测试用例的编写。
这一个步骤还是在避免理解差异，导致需求变形。
研发实现
这是个很容易理解的过程，也是个复杂的过程。我需要一个专门的部分来说明这个步骤，这里就不细述了。预验收
当研发提测后，产品经理需要在测试环境再次确认需求是按照设定的方式实现。我们不能等到需求上线后再做这件事情，毕竟那时候一切都晚了。上线后需求的回归评审
需求终于上线了。等等，需求生命周期还有一个步骤。就是这里提到的回归评审。
需求是否达到了我们预期的效果，如果没有达到，我们还需要做哪些调整，我们要接受哪些教训，学到了哪些东西。这些都是需求生命周期中，给我们（产品团队）的最宝贵的财富。
没有反思，就不会进步。这个过程会让产品经理的思路得到升华，也就使得未来产品走的弯路更少。
问题与应对
产品中最重要的部分
产品中最重要的部分，是产品的基础架构。包括登录模块，人员组织结构，权限结构，系统字典，配置模块等等。这些基础的东西不好用，会导致产品的根基不稳，而所有的需求都是在这个根基上生长而出的。
当未来发现这些根基上的裂缝，再想要弥补的时候，仰头一看，我们会发现根基的裂缝已经遍布所有上层架构。弥补的成本可想而知。
我们需要思路最缜密，条理最清晰的产品经理负责产品的基础架构。
这些模块虽然简单并且有例可循，但千万不要轻视。轻视他们就是心存侥幸，就是玩火。
千万。
不要玩火。
这是一个有价值的需求吗？
对于产品而言，什么最重要？这是一个首先要回答的问题。每个产品的答案可能不一样。举个例子。
如果流量对于产品最重要，那么这个待评估的需求可以贡献多少流量，使用人数占基数的百分之多少，或者对留存率提升多少？
这些问题搞清楚了，需求的价值就不难估算了。
价值不高的需求首先尽量不要去做。甄别这些低价值需求是产品总监的分内之事。至于如何将这些来自老板，来自重要客户，来自心爱的产品经理的低价值需求挡掉的技巧，也是产品总监的必修课。
如果各种压力导致我们不得不完成一个没什么人用的特性怎么办呢？
用尽可能少的成本做这件事。不要过度考虑交互！不要过度考虑稳定性！不要过度考虑例外情况！
时刻牢记，这个需求对你的产品不重要。每多一个研发人天的成本都是不值得的！
然后，把这个不得不实现的低价值需求记在一个小本子里，它是产品的瑕疵。未来一旦有机会，就立刻把它拿掉！
是的，只要需求上线后，发现确实没什么用，就把逻辑删掉。
产品要做加法，也要做减法。保证我们的产品时刻保持在健康状态，我们需要修剪一些额外的枝叶，这是我们不能忘记做的事情。
协作的问题
当产品越来越复杂，一个产品经理已经忙不过来的时候，我们开始拆分模块，将不同模块分配给不同的产品经理负责。这么做无可厚非。但是一定要小心初期的混乱。
除非模块可以划分的十分清楚，否则要想好对策，规避模糊地带。
要知道，模糊地带可能会变成没人管的区域。这些无人管理的地带会让研发团队不知所措。会导致大量设计缺陷类的问题出现。
各个模块的产品经理需要互相协作，共同加强模糊地带的管理。
这是一个巨型需求
哇塞，我设计了一个巨型需求，它是如此的壮观，如此的宏大！它是一个史诗级的用户故事！它大到需要所有模块的研发团队整个迭代任何其他的事情都不能做。小心这样的巨型需求。它是不受欢迎的，因为大部分时候，各个团队在迭代中都有些其他必须要做的事情。
结果就是，这个巨型需求无法放进任何一个迭代中。拖了半年之后，你发现系统已经和半年前完全不同，这个巨型需求的详细设计也不再适用。
很可惜，不是么？
正确的做法是，你需要尝试把巨型需求拆分，拆分成一个个可以独立上线的阶段。每个迭代塞进去一点。慢慢编织你的宏伟的史诗故事。
这不是我要的东西
前面需求管理生命周期中，很多过程都是为了避免需求走形而设置的。没有什么比漫长的等待后，发现研发给出的东西面目全非，更让人沮丧的了。在完成需求宣讲后，产品经理需要在各个节点，勤快地跟进研发成果。否则就难免沮丧了。
小结
- 重视需求管理环节，否则后期将产生大量成本浪费
- 找到符合产品的【需求价值衡量标准】。尽量摒弃价值不高的需求。
- 做好产品的边界管理。
- 产品的基础架构一定要做好，这是根基所在。
- 注重各个模块间产品经理的协作。
- 小心巨型需求
- 参与各个环节，防止需求变形
