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

【需求@B端产品，如何分类进行需求分析？】
第二种人属于帮助你改善产品中不合理的地方，面对这类人，要仔细和他沟通细节，让他说明那些地方用起来不顺手，然后询问他有什么好的建议和想法吗，记下但不要照做，回去后好好梳理现有流程和他提出的建议，如果觉得确实有改的必要，务必想好所有关联性流程后进行修改。
例如我在给采购部门做线上询价时，一个业务员对我说，每次我做询价的时候需要在采购单页面确认好我要询价的物料，然后再去询价页面增加一个询价函，这样操作太繁琐了，能不能直接在采购单页面直接询价呢。他这个想法不错，但是采购单页面的单据是主从表的关系，不能在这个页面加询价功能，这就是苏杰老师提起的，认真听但不要照着做。最后我用一种方式完美解决了这个问题。
另外这类使用者还会提出一些系统上没有涉及到的业务，这类业务可能是他们公司特有的业务，再权衡利弊后可视情况选择做与不做。大致可以从资金、开发难度以及业务占比等方面进行考虑。
例如我在做某个公司的检化验系统，一个化验员对我说，对于新物料的检验不应该由我们部门发起，因为我们不知道什么时候来新物料，供应商把物料送到公司时，会第一时间到库房去提交到货单，所以应该由库房接收到货单的同时发起对物料的化验请求。
以上我列举了操作类需求和业务类需求如何去分析，接下来介绍管理类需求如何去做，因为分析类需求不属于我的专业，所以我不能给你们提供更好的建议。
以上我们说到了管理人员一般会根据他所管理的职能去提一些管理类的需求，这类需求是很有意思的，管理类需求做的好，可以把你的产品提升一个很高的等级，使你的产品在同类产品中脱颖而出。
管理类需求思考的出发点和操作类、业务类是不同的，需要你站在管理者的角度去考虑问题，但有一点是不变的，就是目的。管理者提这个需求一定是想达到某个管理的目的，记住在管理者眼中，系统就是个管理工具，他希望系统能帮助他去约束员工，为他提供管理数据，所以管理者提出的需求一般围绕这两点展开。
还是以上述采购部门的例子举例，他们的采购部长找我说，希望我能做一个采购计划的限制，每个月只能申报两次采购计划，分别在月初和月末，我说为什么啊，这个直接让你手下就能办到啊，告诉你的小弟让他们限制申报部门不就完事了。他说他的小弟由于各种原因会不好意思拒绝申报部门的计划，这样我就很烦恼，我希望通过系统去做这件事。然后我就答应他了，但是我给他留了个最高权限，因为真的有申报部门有极特殊情况下，不能不给人家报不是，但是这次你面对的是采购部长，如果没有正当理由，那你就想想怎么混过去吧，这样就形成了一个闭环管理。
当然管理者的需求也不是不可以拒绝的，这个采购经理跟我提另一个需求的时候我就给拒绝了，他说采购员经常把计划处理了，但是他并不在系统上做完成标记，希望我能做一个弹窗提醒，每隔一段时间就去提醒他一次，我告诉他在其他公司不是没有这么做过，但是没有效果，业采购员会直接关闭这个窗口。建议你把这个计划处理效率放到采购员的KPI中，对他有了直接利益加持就有了动力。然后没过多久他又找我做了一个采购员KPI的模块，因为这招太好用了。
三、总结
我们在做需求分析时，首先要给需求归类，然后再想想自己面对的是什么样的人，他基于什么目的提出的需求，然后根据这个目的对症下药才能达到需求人想要的目的。
以上的分类是我自己用着最熟练的分类，但不一定适合你们，我在这里讲的是方法，不是让你们照着做，你要根据我的想法找到适合你自己的分析方法才是最重要的。