需求@B端产品，如何分类进行需求分析？ |产品|需求分析|

作者从实际工作经验出发，结合具体案例。分享了对B端定制化产品的需求进进行分析归纳的方法，供大家一起参考和学习。

本文插图
写本篇文章的目的：第一个目的是作者即将步入第一个三年，对以往的工作进行总结，准备进阶突破；第二个目的就是与大家分享与讨论。
我目前的工作有些像外包产品经理，给公司做一些定制化的B端产品。下面针对B端定制化产品的需求进行分析和归纳。
一、定制化B端产品的需求分类
首先我们先了解一下什么人会对产品提出需求：
第一种是直接负责这个项目的甲方负责人，他们一般会对产品整体有个需求概况，他们虽然是负责人，但并不一定有多了解具体业务；
第二种是管理人员，他们是直接对业务负责的管理人员，这类人员一般会提出一些偏管理的需求，他们更加注重如何通过一个工具系统性的去管理好这个团队；
第三种属于公司中高层，他们关心的是宏观的数据希望能够从大量数据中看到公司未来的走向，所以这类人更加会提出一些数据分析的需求，如驾驶舱；
最后一种是产品的直接使用者，或者说是使用频次最高的人员，这类人员是业务的主要执行者，他们更关心其业务是否全面覆盖，操作是否简单等需求。
所以我总结B端定制化产品的需求一般分为四类：分析类需求、管理类需求、业务类需求、操作类需求。我们将需求分类之后，就能对症下药，找到需求的根本面目。
二、如何分析需求？
B端产品体术需求最频繁的一类人群就是使用频率最高的，涉及模块最广的业务人员，此类人员需要在系统中完成日常的工作，稍微遇到一些不好用或者操作操作繁琐的功能，都会让他们感到烦躁。他们一般会这样提需求：“我要在XX页面增加一个XX功能”“这个页面太不好用了， XX功能用起来太麻烦了，能不能简化一下” 。
第一种需求属于自认为我很了解这个系统了，我可以直接为产品设计需求，你只要照做就行了；但我要告诉你的是，如果你照做了，那么这个需求90%会进行变更，因为他根本不知道他要的是个什么样的需求，这样做出来之后他才意识到自己要的根本不是这样的功能。面对这类人，我一般会问这几个问题：这个需求能帮你解决什么问题？为什么会有这个想法？换一种形式可不可以？
举个例子：在给某个公司的采购部门做系统的时候，他们有一个独立的统计室来统计应付账款，有个统计员和我说，我要把入账列表改成默认展示当天入账日期的入账单；很显然这个需求不是很合理，我问他我说为什么要这么做，他说你就改就行了，现在这样很不方便。那我和他说，你问问其他同事愿意这么改吗，如果你们都有这个需求那我可以考虑，然而最终结果是很大一部分不能接受这么改，我又问他我说你为什么要这么改，他和我说了，他想看今天入账的供应商和总额，其他统计员也有相应的需求。
原来想看今日入账的供应商和金额才是他最终的目的。需求明确之后我们完全可以有N个方式去满足他，但绝对不是用他的这种形式，最后我们都很愉快的解决了这个问题。
第二种则属于目的性强的选手，他不管你怎么去简化这个流程，只是觉得这个流程太复杂，操作起来一点都不方便，最好有一个按钮，一点这个按钮系统就能把他所有的事情都做完才好。这类需求处理不好，他会一直吐槽你的产品不好用，严重的会对产品造成很不利的影响。
提出这类需求的人有两种：第一种是对之前的操作流程固化了，不想去花时间学习新的流程（尽管你的流程很标准）。面对这类人，我建议直接告诉他设计如此，如果需要修改流程，可以找项目负责人或者你的领导，同意后可以修改。不要试图和他解释什么，要和他的领导去解释这个流程有多标准。