谈到需求，无论是产品经理还是项目经理，甚至是开发人员想必都不会陌生，因为他们的工作几乎无时无刻不在与需求打交道。或者更为广义的来讨论，需求其实无处不在，可以说只要有业务的地方，需求就会存在。
既然我们时时刻刻都在同需求打交道，那么需求又该如何分析与管理呢？今天抛砖引玉的来简单聊一聊。
- 1 -
需求来源
在进行分析前，首先我们要知道需求来自于哪？可能我们第一反应需求肯定是来源于客户，这一点毋庸置疑，事实上客户的需求是我们需要管理分析的第一大需求来源。除此之外，少部分需求还源自于项目开发团队内部，比如产品/项目经理对于产品/系统的分析思考、开发人员过程中新发现的问题等。
如果按照客户类型来分，需求又可以分为B端和C端。其中B端的需求，像ERP、CRP、PLM等系统是面向与企业服务，它的需求可能更多要结合特殊工作场景，会对效率有比较高的需求，这时需求分析要相对从群体性出发，理性全面的进行梳理，力求稳定；而C端客户面向大众，则更多的是生活化场景，需要从个体性设计出发，更为任性和苛刻的满足用户的需求。
所谓的需求分析，就是通过分析用户、研究用户，发现并解决用户问题，实现用户的期望。在把握用户需求时，是要挖掘有价值的需求，将伪需求进行过滤。
这里提到了伪需求，同样是客户需求，为什么还会存在真伪？
举个例子。笔者作为一个山东人，来到南方上学，进入到一家饭店打算填饱肚子，对服务员说：“来两张煎饼”。服务员一脸蒙：“不好意思，我们这没有煎饼”。于是只能到第二家店，这家服务员解释道：“我们这没有煎饼，但是我们可以提供扬州炒饭、锅盖面~~~。”
（PS：山东人不是都吃煎饼的，为举例生动，特借用刻板印象）
在这个例子里，“两张煎饼”就是伪需求，而“填饱肚子”才是真正的有价值的用户需求。
在众多业务场景的众多客户群体中，可能有的客户能够识别自己的真正需求，可能有的客户会借某一解决方案误当作是自己的需求。这主要是因为人们在遇到某一具体问题时，往往会受自身经验和掌握的信息限制，从自身出发给出需求建议，这种建议可能会误导产品/项目经理偏离了用户真实需求。
所以在需求分析时，产品/项目经理不能被带入到用户方案思维中，不要听用户说“我要XXX功能”，而是要听“我有XXX问题“。从项目自身出发，多去深入了解用户面临的业务场景问题，这样给出的决策建议才是真正能解决问题的方案。
- 2 -
模型方法
在进行需求分析时，往往会用到一些常见的模型方法，比如头脑风暴、调查问卷、用户访谈、情景观察、数据分析、同理心、倾听用户反馈等等。
在这里，只介绍“头脑风暴”的一些内容，其他见思维导图的图片。
开始前：需要拟定风暴主题；拟定参加人员，最好在15人以内，不仅是产品/项目经理、需求分析师参加，最好也有开发、测试、运维人员参加，同时还要指定记录人员做好记录；将拟定的主题提前一天发给参与人员准备。
头脑风暴：直接法，不指定发言人、发言顺序，任何人有想法直接发言；思维导图：拟定大模板为根节点发散讨论；卡片法：10min思考，以便利贴形式收集，再做归纳整理；
结束后：针对记录逐一质疑并讨论可行性，最后的靠谱点子整理。
这种开放式的讨论需要注意的是：自由讨论，不受限制、不同角度、不同层次、大胆提出想法；禁止批评；禁止当场评价；把握时间与主题，不要偏离；时刻观察团队成员，确保全员参与。
其他模型方法如下：
- 3 -
非功能性需求
非功能性需求，主要就是开篇提到的内部性需求，是从开发运维的技术角度出发，要把握一些需求实现的影响，比如技术架构、后台数据处理方式、数据库设计等内容；程序的易用性、人机交互防呆设计，比如提示、容错等；程序的安全性、保密性；数据的安全、备份；系统的可维护性、可扩展性；系统的性能，容纳用户量、并发访问量、响应时间；服务器容量存储大小、数据量、是否有图片等等。
以上这些技术内容虽然不是需求分析一定要掌握的技能，但是如果在前期就有意识的去思考、布局设计，在后续的开发、运维工作中会有很大的助力。同时也一定程度上能让开发人员能够更好、更舒服的与PM来对接工作开展，促进整体项目团队的合作。
以上就是对需求分析的一些简单整理，谢谢观看。
希望看完的朋友可以点下【在看】，这对我十分重要，谢谢。
