端产品如何分类进行需求分析

　　作者从实际工作经验出发，结合具体案例。分享了对B端定制化产品的需求进进行分析归纳的方法，供大家一起参考和学习。
　　写本篇文章的目的：第一个目的是作者即将步入第一个三年，对以往的工作进行总结，准备进阶突破；第二个目的就是与大家分享与讨论。
　　我目前的工作有些像外包产品经理，给公司做一些定制化的B端产品。下面针对B端定制化产品的需求进行分析和归纳。
　　一、定制化B端产品的需求分类
　　首先我们先了解一下什么人会对产品提出需求：
　　第一种是直接负责这个项目的甲方负责人，他们一般会对产品整体有个需求概况，他们虽然是负责人，但并不一定有多了解具体业务；
　　第二种是管理人员，他们是直接对业务负责的管理人员，这类人员一般会提出一些偏管理的需求，他们更加注重如何通过一个工具系统性的去管理好这个团队；
　　第三种属于公司中高层，他们关心的是宏观的数据希望能够从大量数据中看到公司未来的走向，所以这类人更加会提出一些数据分析的需求，如驾驶舱；
　　最后一种是产品的直接使用者，或者说是使用频次最高的人员，这类人员是业务的主要执行者，他们更关心其业务是否全面覆盖，操作是否简单等需求。
　　所以我总结B端定制化产品的需求一般分为四类：分析类需求、管理类需求、业务类需求、操作类需求。我们将需求分类之后，就能对症下药，找到需求的根本面目。
　　二、如何分析需求？
　　B端产品体术需求最频繁的一类人群就是使用频率最高的，涉及模块最广的业务人员，此类人员需要在系统中完成日常的工作，稍微遇到一些不好用或者操作操作繁琐的功能，都会让他们感到烦躁。他们一般会这样提需求：我要在XX页面增加一个XX功能这个页面太不好用了，XX功能用起来太麻烦了，能不能简化一下。
　　第一种需求属于自认为我很了解这个系统了，我可以直接为产品设计需求，你只要照做就行了；但我要告诉你的是，如果你照做了，那么这个需求90会进行变更，因为他根本不知道他要的是个什么样的需求，这样做出来之后他才意识到自己要的根本不是这样的功能。面对这类人，我一般会问这几个问题：这个需求能帮你解决什么问题？为什么会有这个想法？换一种形式可不可以？
　　举个例子：在给某个公司的采购部门做系统的时候，他们有一个独立的统计室来统计应付账款，有个统计员和我说，我要把入账列表改成默认展示当天入账日期的入账单；很显然这个需求不是很合理，我问他我说为什么要这么做，他说你就改就行了，现在这样很不方便。那我和他说，你问问其他同事愿意这么改吗，如果你们都有这个需求那我可以考虑，然而最终结果是很大一部分不能接受这么改，我又问他我说你为什么要这么改，他和我说了，他想看今天入账的供应商和总额，其他统计员也有相应的需求。
　　原来想看今日入账的供应商和金额才是他最终的目的。需求明确之后我们完全可以有N个方式去满足他，但绝对不是用他的这种形式，最后我们都很愉快的解决了这个问题。
　　第二种则属于目的性强的选手，他不管你怎么去简化这个流程，只是觉得这个流程太复杂，操作起来一点都不方便，最好有一个按钮，一点这个按钮系统就能把他所有的事情都做完才好。这类需求处理不好，他会一直吐槽你的产品不好用，严重的会对产品造成很不利的影响。
　　提出这类需求的人有两种：第一种是对之前的操作流程固化了，不想去花时间学习新的流程（尽管你的流程很标准）。面对这类人，我建议直接告诉他设计如此，如果需要修改流程，可以找项目负责人或者你的领导，同意后可以修改。不要试图和他解释什么，要和他的领导去解释这个流程有多标准。
　　第二种人属于帮助你改善产品中不合理的地方，面对这类人，要仔细和他沟通细节，让他说明那些地方用起来不顺手，然后询问他有什么好的建议和想法吗，记下但不要照做，回去后好好梳理现有流程和他提出的建议，如果觉得确实有改的必要，务必想好所有关联性流程后进行修改。
　　例如我在给采购部门做线上询价时，一个业务员对我说，每次我做询价的时候需要在采购单页面确认好我要询价的物料，然后再去询价页面增加一个询价函，这样操作太繁琐了，能不能直接在采购单页面直接询价呢。他这个想法不错，但是采购单页面的单据是主从表的关系，不能在这个页面加询价功能，这就是苏杰老师提起的，认真听但不要照着做。最后我用一种方式完美解决了这个问题。
　　另外这类使用者还会提出一些系统上没有涉及到的业务，这类业务可能是他们公司特有的业务，再权衡利弊后可视情况选择做与不做。大致可以从资金、开发难度以及业务占比等方面进行考虑。
　　例如我在做某个公司的检化验系统，一个化验员对我说，对于新物料的检验不应该由我们部门发起，因为我们不知道什么时候来新物料，供应商把物料送到公司时，会第一时间到库房去提交到货单，所以应该由库房接收到货单的同时发起对物料的化验请求。
　　以上我列举了操作类需求和业务类需求如何去分析，接下来介绍管理类需求如何去做，因为分析类需求不属于我的专业，所以我不能给你们提供更好的建议。
　　以上我们说到了管理人员一般会根据他所管理的职能去提一些管理类的需求，这类需求是很有意思的，管理类需求做的好，可以把你的产品提升一个很高的等级，使你的产品在同类产品中脱颖而出。
　　管理类需求思考的出发点和操作类、业务类是不同的，需要你站在管理者的角度去考虑问题，但有一点是不变的，就是目的。管理者提这个需求一定是想达到某个管理的目的，记住在管理者眼中，系统就是个管理工具，他希望系统能帮助他去约束员工，为他提供管理数据，所以管理者提出的需求一般围绕这两点展开。
　　还是以上述采购部门的例子举例，他们的采购部长找我说，希望我能做一个采购计划的限制，每个月只能申报两次采购计划，分别在月初和月末，我说为什么啊，这个直接让你手下就能办到啊，告诉你的小弟让他们限制申报部门不就完事了。他说他的小弟由于各种原因会不好意思拒绝申报部门的计划，这样我就很烦恼，我希望通过系统去做这件事。然后我就答应他了，但是我给他留了个最高权限，因为真的有申报部门有极特殊情况下，不能不给人家报不是，但是这次你面对的是采购部长，如果没有正当理由，那你就想想怎么混过去吧，这样就形成了一个闭环管理。
　　当然管理者的需求也不是不可以拒绝的，这个采购经理跟我提另一个需求的时候我就给拒绝了，他说采购员经常把计划处理了，但是他并不在系统上做完成标记，希望我能做一个弹窗提醒，每隔一段时间就去提醒他一次，我告诉他在其他公司不是没有这么做过，但是没有效果，业采购员会直接关闭这个窗口。建议你把这个计划处理效率放到采购员的KPI中，对他有了直接利益加持就有了动力。然后没过多久他又找我做了一个采购员KPI的模块，因为这招太好用了。
　　三、总结
　　我们在做需求分析时，首先要给需求归类，然后再想想自己面对的是什么样的人，他基于什么目的提出的需求，然后根据这个目的对症下药才能达到需求人想要的目的。
　　以上的分类是我自己用着最熟练的分类，但不一定适合你们，我在这里讲的是方法，不是让你们照着做，你要根据我的想法找到适合你自己的分析方法才是最重要的。