一个优秀的B端产品，必然契合了客户的场景需求，为客户创造了价值。而想保持产品持续优秀，则必然需要持续不断的有高价值需求输入。所谓“问渠哪得清如许，为有源头活水来”，所谓“Garbage in，Garbage out”。
高价值需求是从需求池中对比筛选出来的，做好需求池则必然需要做好需求收集。所以，有了这个话题，“如何做好B端产品需求收集”。
商业化、自研、纯定制等不同类型B端产品需求收集渠道不太相同，本文主要基于商业化B端产品展开。全文分5大部分：
WHY，为什么要做好需求收集？WHO，应该由谁来收集需求？WHERE，从哪些渠道收集需求？WHAT，需求收集什么信息？HOW，用什么工具收集需求？
首先，需求收集是产品打造的第一步，是产品价值的源头和根基， 想做出对客户有价值、商业上成功的B端产品必须重视。
其次，客户在产品使用过程中，难免会提一些需求。是否有人能及时响应，响应是否够专业，对客户服务感知非常重要，影响到 项目滚动续签 。
再次，一旦研发规模过百，很多公司会投入数百上千万来做研发效能改进。但是，如果我们方向不对，工程效率、协作效率再高， 对客户有什么价值，对市场有什么帮助？想追求研发效能改进的整体ROI，就需要从源头一起抓。
研发效能提升的方法论很多，敏捷、精益、看板、TOC、DevOps、平台工程等，这些方法论确实可以让研发更快的开发、更快的响应、更快的发布。但对于B端产品，如果让客户频繁升级，升级的功能客户无感知或增加了认知复杂度，那可能还不如瀑布慢跑。
百科上对价值的定义是“价值是指客体能够满足主体需要的效益关系，是表示客体的属性和功能与主体需要间的一种效用、效益或效应关系的哲学范畴”。所以，产品价值即客户需要，想增加产品价值就要更好、更多的满足客户需要，满足客户需要就要尽可能多的收集到客户需要。
收集需求要走近客户，要接触大量客户，有大量的时间跟客户在一起，能跟客户建立起一定的信任关系。
可以接触到客户需求的角色有很多，比如销售、售前工程师、解决方案工程师、行业拓展工程师、POC测试工程师、大客户交付经理、项目经理、产品经理、售后客户响应中心、老板等。
承担需求收集角色的人，应该具备 “以客户场景为中心” 的观念，应该 对产品定位、边界、功能很熟悉 ，有基本的产品化思维。
产品经理在技能上最适合做需求收集，但产品经理能接触到的客户数量有限，能用于客户交流的时间精力不足。若让产品经理来承担这个职责，则会限制需求收集到的数量。
售前阶段的项目，解决方案工程师是需求收集相对更合适的角色，他们可以大量接触客户 ，但又不会深度参与项目招投标文件等事务性工作中，跟产品经理沟通机会也多。但很多中小公司职能划分可能不会太细致，由一个能连接客户和产品经理的角色来承担这个职责即可。
售后阶段的项目，项目经理是需求收集相对更合适的角色 ，他们可以将客户、POC测试工程师、交付工程师等角色反馈的需求统一归口收集，反馈给产品经理，帮助产品经理减少多角色对接的时间精力。
但是，解决方案工程师、项目经理有可能缺乏业务背景知识、需求沟通挖掘的经验，所以产品经理需要沉淀出赋能指导的材料。归根到底，其他角色都是帮助产品经理分担压力的， 产品经理自身不可脱离需求收集的职能 。
另外，虽然解决方案工程师、项目经理是相对合适的需求收集角色，但由于需求有多种不同渠道反馈，以及需求收集的重要性， 企业需要建立起全员需求收集的文化氛围 ，把“以客户为中心”的企业文化落到行动上。
B端产品可以通过访谈、观察、问卷、工作坊、竞品分析、招标文件分析、在线系统等多种方式收集需求， 对于商业化B端产品最常用、最有用的是访谈，其次是招标文件分析、工作坊、竞品分析 和在线系统（SaaS比本地部署软件更适用）。
在售前交流时，由于还未和客户建立信任关系，不太容易让客户说出真实需求。这个阶段客户也会接触大量的友商，想法天马行空，又多又杂，很难判断需求的真实性和价值度。所以， 售前项目不太适合收集需求（但适合验证需求规划） ，更适合根据产品能力引导客户期望。但如果已经建立信任关系，客户可以提出业务真实痛点，或基于POC操作演示提出明确期望，就可以作为有效需求收集渠道。
客户的招标文件通常是将多个产品的功能参数拼在一起，其中有客户真实需要的功能，也有友商引导控标的功能。无论从防止被控标还是发掘潜在需求角度，招投标文件都是不错的需求收集渠道。 我们需要建立招标文件集中存储库，作为需求收集的一种渠道。 同时，也可以通过招标文件看到友商产品进化的方向。通常来讲，售前人员是更适合维护招标文件库的角色。
项目交付时，随着不断有新的干系人加入，客户可能会产生一些新的需求。这些需求可能源于真实的使用场景，有业务价值。但考虑到产品需求排期通常不会随项目调整，为避免影响验收时间节点， 交付中项目一般不适合主动向客户收集需求 。
已验收售后项目，客户通常已经在实际业务中使用产品，基于实际使用体验会产生一些需求。这些需求相对来说更真实、价值更高，不会有严苛的交付时间要求。同时，客户也更愿意安排实际使用用户深度参与访谈调研沟通，反馈真实的业务痛点。而且，售后需求收集有助于提高客户满意度，增加项目扩容续签概率，一举多得！售后需求可以由项目经理统一收集反馈给产品经理，产品经理根据实际情况安排线上/线下会议访谈沟通，更全面、深入的了解需求。综上， 售后项目最适合收集需求 。
B端产品竞品分析并不容易做，因为竞品的线上体验环境很难拿到，详细介绍材料也不易获取。若能拿到友商详细材料或线上环境，则可以通过对比分析找出一些值得参考的功能。 竞品已实现的功能，通常意味着客户有真实的需要，是不错的需求收集渠道 。但是，在竞品分析或招标文件分析中拿到的需求，也不要着急纳入开发，最好先跟几个客户沟通验证一下，真正了解功能背后的业务需求后再动手。同时，需要意识到，抄竞品只能避免产品的竞争劣势，无法保证产品可以超越友商赢得客户。 做好B端产品不是跟随友商，而是跟随客户。
工作坊通常是基于特定目的，拉通多种角色通过头脑风暴来寻找需求。这种方式可以获取到解决特定问题的大量需求，有助于问题解决，但获取的需求中也可能存在大量非客户真实存在的需求。
在线系统（如QQ群、微信钉钉群、论坛、在线表单等）更适合SaaS或自研产品；观察法更适合自研或纯定制产品；问卷很难收集到有效需求；开发团队或老板的需求，容易偏离用户实际场景。
若多种渠道收集到相似需求，是不是一种人力资源浪费？我认为不是，恰恰多渠道收到相似需求，更容易证明该需求的通用性和价值，促进产品经理做出正确的决策。
需求收集不是仅仅将客户的原始需求描述传递给开发团队，它需要通过不断的提问全面了解需求背后的业务目的。
在需求收集时，不建议以产品功能为中心，而应以角色使用场景为中心，避免过早陷入技术实现、交互设计细节中。
需求收集的信息越完整，对需求分析的帮助越大。我目前提供给售前、交付等职能的是5W3H结构化需求收集法。它比较适用于客户已有某个明确的“一句话需求”，需要我们详细的了解、评估该需求。若客户尚没有明确需求，则更适宜先做一次全面的业务调研沟通。通过将整个业务划分成若干的环节，每个环节中放一系列问题，来全面了解客户业务中可能存在的问题，然后再用5W3H细化了解特定某个需求。全面业务调研更适合用于项目售前、扩容续签等场景中，而5W3H则更适合于挖掘“一句话需求”，5W3H具体包括：
-
who，谁提的这个需求？最终影响的角色是谁？解决问题的第一步是先明确这个问题涉及哪些人，谁造成的、影响了谁、谁有能力解决、该谁解决、能否让其他角色解决等。
-
why，需求的业务背景是什么？由于什么原因产生了这个需求？了解需求的业务动机有助于判断需求背后的业务价值，找到正确的问题。
-
when，发生了什么事，造成了什么问题，所以有了这个需求？这个需求未实现时，客户是怎么解决这个需求的？过程中有什么痛点（不便的地方）？需求的直接诱因、后果有助于判断需求价值，以及判断需求的个性化程度；客户原有解决方案、方案不足之处，可以为功能设计提供参考。
-
what，原始需求描述是什么？业务过程有哪些主任务、分支任务？业务过程有哪些异常场景？为了避免需求传递过程出现信息偏差，需要记录原始需求。业务过程主任务是将整个业务过程划分成若干个环节，分析每个环节中需要的信息、操作及结果；若涉及多个角色，则还需要从每一个角色的视角去分析他要参与的所有环节及步骤，确保主任务过程顺畅；分支任务是那些本身完成并不会推动业务目的达成，但可辅助主任务更好完成的任务，比如在运维资源纳管这个主任务中，添加一个访问参数模板是一个分支任务；业务过程中的异常场景、规则约束对B端产品很重要，可以让功能设计更完善，更贴合客户需要。
-
where，客户期望这个功能做在哪里？使用频率有多高？客户对功能使用场景、期望模块的描述，有助于确定该功能定位，是否在本产品中做，具体做在哪个页面；使用频率有助于判断需求价值度。
-
how，客户期望功能怎么做？友商功能怎么做的？有些客户喜欢直接给功能方案，此时，我们需要追问为什么想这么做功能，以挖掘客户可能未表达出来的业务目的。客户对功能的期望以及友商的功能设计，可以给后续功能设计提供参考。同时，客户对功能的期望及友商是否实现，也可以辅助判断该需求的个性化程度。
-
how much 1，需求实现后对用户有什么好处？业务价值有多大？需求实现带来的好处是判断需求是否接纳、优先级及排期的关键因素，比如实现后可以每次减少30分钟人工操作，可以缩短业务中断时长等。
-
how much 2，需求是否具备全行业或特定行业通用性？是不是个性化需求？个性化需求不适合在产品中实现，ROI不高，还会增加产品复杂度，通常产品不接纳，交由定制开发来实现。
在需求收集沟通之前，如果已经知道客户大概需求方向（一句话需求），尽量提前对业务背景和问题做准备。根据经验大致推理业务主任务过程、角色主任务过程，提前考虑可能存在的问题。采用业务主任务的模式准备访谈问题清单，可以有效的避免产品功能设计偏离用户实际使用场景。
最后，我想强调的是， 我们做产品，不能基于功能开发角度思考，而应该从用户使用角度考虑。客户要的从来不是功能，而是在特定场景下能解决问题。
国内外有很多需求管理工具，我也曾给多个运营商做过需求管理系统。这些工具通常大而全，可以实现整个研发过程管理，但我用的最顺手的依然还是在线文档和在线表格。
在线文档用于跟用户线上沟通需求 ，在沟通之前我会梳理出业务主任务过程及每个环节中的疑问。在沟通过程中通过在线会议演示文档，让用户能直接看到问题和会议中记录的笔记。同时，文档也会给所有参会人授权，每个人都可以在文档中写下自己对需求的理解。会议结束后，该文档可以直接当作会议纪要，也会作为后续需求分析时的主要信息输入。在线文档的主要缺点是统一存储查看不便、文档缺少结构化属性标识、跟后续需求分析及开发过程脱节等。
在线表格用于原始需求池管理 ，每一个产品单独做一个sheet，主要记录需求描述、反馈人、客户名、提出时间、期望完成时间、优先级、当前状态等信息。在产品规划、需求分析、迭代排期、产品汇报、大客户交流等场景下，这个文档是重要输入。在线表格的主要缺点是无法可视化自动呈现、调整需求排序不便、需求状态维护不便、数据统计不便、跟后续需求分析及开发过程脱节等。
我期待中的需求管理工具，应该 既具备在线表格的基本优点，又能提供产品路线图、用户故事地图看板、迭代排期看板等可视化呈现 。
在线表格的基本优点包括：增删改查的便利性，自动保存的安全感，受限分享的自由度，按需调整模板的灵活性。
产品路线图 是通过时间轴可视化的呈现产品每个大版本中（如季度版本）已完成或规划中的关键特性，它可以 帮助产品经理、高管、售前、开发团队等角色整体、清晰的看到产品规划，统一产品认知 。另外，它还可以在大版本规划(平衡工作量、优先级和规划容量)、向上汇报、产品品牌宣传、版本发布宣传等场景中提供帮助。 
用户故事地图看板 是敏捷方法论中工具，它主要 用于同开发团队沟通需求，帮开发团队建立“以用户为中心”的思维。 在使用时从左至右按用户业务过程、操作步骤的先后顺序组织需求分类框架，然后将需求按用户操作步骤填入每一个列中。同时，也可以根据版本规划创建多个泳道，将需求池中已明确的需求移入版本规划。故事地图跟产品路线图的区别在于，它更关注规划中未完成的需求，更多以用户使用过程为视角组织需求。在使用时，可以采用产品级的视角，也可以基于某个大业务过程特性视角组织需求。 
迭代排期看板主要用于给特定开发团队制定近一两个月明确的开发计划 ，除了明确已经纳入产品规划中的需求，需求池中还会有一些小需求，以及通过多种渠道不断收集到的备选新需求。产品经理需要根据团队容量、需求工作量、需求ROI、迭代目标、项目紧急度等综合评估迭代中具体排入的需求。需求排入后，通过迭代排期看板可以很直观的看到每个迭代中的具体需求、开发状态、计划完成时间、当前完成度度等信息。
