谈及需求，不论是产品经理还是部门经理，甚至是开发者总之都不会孤单，因为他们的组织工作几乎无时不刻不在与需求关系密切。或者更加狭义的来讨论，需求其实随处不在，能说只要有业务的地方，需求就会存有。

既然他们时时都在同需求关系密切，那么需求又该怎样分析与管理呢？今天Jaunpur的来简单聊聊聊。

- 1 -

需求作者

在展开分析前，首先他们要知道需求来自于哪？可能将他们第三反应需求肯定是作者于客户，这一点不可否认，事实上客户的需求是他们需要管理分析的第三大需求作者。除此以外，一小部分需求还源于于工程项目开发项目组内部，比如产品/部门经理对于产品/系统的分析思索、开发者过程中新发现的问题等。

如果按照客户类型新埃，需求又能分为B端和C端。其中B端需求，像ERP、CRP、PLM等系统是面向全国与企业服务，它的需求可能将更多要结合特殊组织工作情景，会对工作效率有比较高的需求，这时需求分析要相对从群体性起程，理智全面的展开剖析，务求稳定；而C端客户面向全国德国大众，则更多的是贴近生活情景，需要从内在性设计起程，更加天真和严苛的满足用户的需求。

所谓的需求分析，是通过分析用户、研究用户，发现并解决用户问题，实现用户的期许。在把握用户需求时，是要挖掘有价值的需求，将伪需求展开过滤器。

这里提到了伪需求，同样是客户需求，为什么还会存有真假？

举个范例。本栏作为一个河南人，来到南方读书，进入到一家宾馆打算喝汤肚皮，对服务员说：“来三张豆腐”。服务员满脸蒙：“不唉，他们这没有豆腐”。于是只能到第三家店，另一家服务员解释道：“他们这没有豆腐，但是他们能提供湖州咖喱、铁板面~~~。”

（PS：河南人不是都吃豆腐的，为总括生动活泼，特转作呆板第一印象）

在这个范例里，“三张豆腐”是伪需求，而“喝汤肚皮”才是或者说的有价值的用户需求。

在为数众多业务情景的为数众多客户群体中，可能将有的是客户能够辨识自己的或者说需求，可能将有的是客户会借某一解决计划误当做是自己的需求。这主要是因为人们在遇到某一具体问题时，往往会受另一方面经验和掌握的信息限制，从另一方面起程得出需求提议，这种提议可能将会欺骗产品/部门经理偏移了用户真实需求。

所以在需求分析时，产品/部门经理不能被带进到用户计划观念中，不要听用户说“我要XXX功能”，而是要听“我有XXX问题“。从工程项目另一方面起程，多去深入了解用户面临的业务情景问题，这样得出的重大决策提议才是或者说能解决问题的计划。

- 2 -

模型方法

在展开需求分析时，往往会用到一些常见的模型方法，比如头脑风暴、调查问卷、用户访谈、情景观察、数据分析、同理心、倾听用户反馈等等。

在这里，只介绍“头脑风暴”的一些内容，其他见观念导图的图片。

开始前：需要拟定风暴主题；拟定参加人员，最好在15人以内，不仅是产品/部门经理、需求分析师参加，最好也有开发、测试、运维人员参加，同时还要指定记录人员做好记录；将拟定的主题提前一天发给参与人员准备。

头脑风暴：直接法，不指定发言人、发言顺序，任何人有想法直接发言；观念导图：拟定大模板为根节点发散讨论；卡片法：10min思索，以便利贴形式收集，再做归纳整理；

结束后：针对记录逐一质疑并讨论可行性，最后的靠谱点子整理。

这种开放式的讨论需要注意的是：自由讨论，不受限制、不同角度、不同层次、大胆提出想法；禁止批评；禁止当场评价；把握时间与主题，不要偏离；时刻观察项目组成员，确保全员参与。

其他模型方法如下：

- 3 -

非功能性需求

非功能性需求，主要是开篇提到的内部性需求，是从开发运维的技术角度起程，要把握一些需求实现的影响，比如技术架构、后台数据处理方式、数据库设计等内容；程序的易用性、人机交互防呆设计，比如提示、容错等；程序的安全性、保密性；数据的安全、备份；系统的可维护性、可扩展性；系统的性能，容纳用户量、并发访问量、响应时间；服务器容量存储大小、数据量、是否有图片等等。

以上这些技术内容虽然不是需求分析一定要掌握的技能，但是如果在前期就有意识的去思索、布局设计，在后续的开发、运维组织工作中会有很大的助力。同时也一定程度上能让开发者能够更好、更舒服的与PM来对接组织工作开展，促进整体工程项目项目组的合作。

以上是对需求分析的一些简单整理，谢谢观看。