B端产品的客户需求推动落地全流程
负责B端产品，在接到客户所提的需求后，如何处理？有哪些方法、流程可循？
需要说明的一个点是：B端产品的需求，往往直接来源于客户，小部分是自身的产品规划、功能优化，后者已经很明确；另外，本人没有从0到1的产品经历，所以这里主要讨论是产品迭代过程中，如何处理来自客户的需求。
作为产品经理，常说需要有逻辑思维，流程通畅，这不仅是对于功能设计，在日常事务中，都需要先捋清楚其流程，才能输出高质量的产物。
而在处理客户需求时，流程按顺序大致为：初步整理、沟通确认、梳理解决方案、评估做与不做、优先级排序、分解开发任务、推动落地。附上流程图：
image
下面详细说明各流程节点：
1、初步整理，记录完整：
- 来源：来自哪个客户，从什么途径，便于沟通、回溯
- 内容：完整记录客户所提的需求内容，后续可在他处精简、补充
- 定位：该需求涉及到的功能、页面，如果系统有多客户角色，需收集角色
- 背景：在什么场景、条件下提出，或为什么要提出
- 重现操作：根据上述信息，操作几遍看是否存在该问题，排除异常干扰（如网络异常等）
- 普遍性：是否有其它客户提出类似或有关联的需求，是什么
- 真实目的：客户提出的该需求，要达到什么目的
- 紧急程度：客户是否之前提过，是否说明该需求上线时间，如果没有，后续做判断
- 系统关联：该需求与系统中某页面、功能存在的联系，是什么
重现操作这一步很有必要，是一个验证需求真实存在的过程。另外，以上信息非一次性就整理完毕，需要和客户持续的沟通确认。
2、沟通确认，挖掘需求：
- 沟通确认：将整理好的内容与客户进行确认，缺漏的补充完整，以免后续操作做无用功；
- 挖掘需求：客户所提的需求一般是不完整的，或仅是说明这个需求是做成什么样子。经过初步整理后，产品经理有一个基本的判断，在与客户确认的过程中，讨论是否可拓展、缩小、转换、废弃该需求；
注意：非直接与客户对接，而是从销售、客服等部门拿到的二手需求，警惕该需求是否经过加工，需要花时间还原客户本来需求。
3、梳理解决方案：
- 前置条件：产品是一条线，牵一发而动全身，需要将关联的页面、模块、功能、数据储存等流程彻底捋清楚，才能着手思考解决方案，否则会产生一系列的坑。
- 如何梳理：进入->退出，初始状态->非零状态，产生数据->储存->统计->导出，设置->生效->取消，基本上按这几个点去梳理方案即可。
- 解决方案：提出几套方案，与开发、产品等同事沟通，综合考虑开发成本、难度、时间，以及对其他客户的影响程度、是否有感知等方面。
注意：
1.与开发：解决方案是产品综合各方面信息提出的，而非和开发去讨论，开发负责的是如何实现。当然，开发可以从技术角度评估方案的优劣，怎么实现。
2.与客户：客户是不关心背后的技术难题的，不要试图和客户科普。客户永远只关心能不能做，什么时候上线。
4、评估：
问自己几个问题，如果不做：
1.是否会影响到客户基本功能的使用？
2.该客户签约时间是否快到期，实现该需求有助于客户续约？
3.该需求是否合理，超出了系统能力范围？
如果做：
1.最优解是哪个，如何引导客户选择我们的最优解？
基本上客户所提的需求不是太过分，都是要满足的。
5、优先级排序：简单粗暴，别想那么多优先级排序的方法。
- 是否影响客户的基本功能使用？如果是，最高级别，否则往后挪挪。
- 客户要的很急，不能拖？如果是，往前挪挪。
- 已经答应客户上线日期？如果是，在这个日期前实现。
在B端，客户就是上帝，就是财神爷，所有让客户不满意的行为都是不可取的，能这个版本实现就别拖到下个版本。另外，确定需求实现日期后，要向客户反馈。
6、分解开发任务：
- 类别：前端的归前端，后端归后端，这个原理大家是懂得。
- 流程：也可以说按使用顺序来，同一环节的，放一起。
- 重要性：在开发任务繁重情况下，有涉及到，但客户暂时无感知、用不到的功能，可以在挪后实现。
7、推动需求落地：每天去跟开发要进度太折磨人啦……
跟进：
1.抓大放小：小的需求，开发容易理解的，如页面增加某些字段，基本不用怎么跟进。
2.抓先放后：优先级比较高的需求，要跟紧，至于频次方面，根据版本迭代周期而定。
3.进度反馈：除了向开发要进度之外，还要向上级汇报一下各需求的进度，及能否按期完成。
开发遇到问题：
1.整体进度慢：这个问题产生的原因多种多样，治标的方法是先做来自客户的优先级高的需求。
2.难度超出预期：开发过程中，发现该需求实现难度超出预期，先搞清楚是需求的哪部分开发任务，再想办法解决。
3.需求文档描述不清：开发看不懂需求文档就很尴尬了，马上沟通处理后再检讨反省，别推却责任。
4.其它问题：不管是什么问题，客户的紧急需求要优先实现，不紧要的推到下一版本并向客户说明（最好不要推）。
测试验收：
1.功能测试，一般会由测试工程师来负责，但有时候产品也得亲自上手，所以这时候考验开发任务/需求文档（测试用例）是否写得足够清楚，千万不要挖坑。
2.功能验收成果后，又需要将注意力放在未实现的需求上啦。
测试的流程如果产品未曾做过，绝对不要自作主张，要认真请教；另外，不同的公司、产品或许测试流程不一样，也需要向人请教，否则宁愿将该任务布置给测试人员。
上线：
1.上线后，第一时间反馈给客户。
总结：
- 需求做与不做，什么时候做，怎么做，过程中遇到问题如何解决，都很考验产品的能力，大家加油。
