项目实施篇之需求分析
在今天数字化转型的大浪潮中，每年各大企业都会在信息化软件上有较大份额的投入。前两天在CSDN上看到一组数据— “37%的IT项目在计划时间内完成，42%的在预算内完成“。这还不包括IT项目完成后的使用情况了。如果把使用情况算在内来计算IT项目的实施成功率的话，可能就更低了。这也就难怪有了“不做数字化转型是等死，做了数字化转型是找死的说法”。
笔者平时和实施人员聊天，常常会问他们项目delay的原因都有哪些，得到的答案几乎都是因为需求变更。我想这一点，估计每一个IT从业人员都有切身体会。笔者作为一个从业多年的程序员、产品经理，想从产品设计的角度来分享一些自己的经验，看看能否为实施兄弟们提供一些帮助。
我们在实施之前，基本上都会到客户现场，和客户一起做需求分析。然后撰写蓝图。那我们就先从需求分析开始说起，看看在需求分析中，我们都可以做些什么，来提高项目实施的成功率。
1、我们当前需求分析的误区
我记得我刚毕业那会，我们软件工程里面讲需求分析，是将功能一条一条列清楚将明白。包括这个功能的业务逻辑、要调什么接口啊等等。他是一个技术视角看到的需求。
蓝图的阅读对象除了相关的IT从业人员，还有软件的使用者，而他们大多都不是计算机专业人员。很明显，作为一个技术视角撰写的“蓝图”在这里对软件使用者并不友好。这也是当需求者第一次看到工程师写的软件后，产生诸多不满意，要求变更需求的重要原因。
那么对于客户友好的需求分析应该是什么样的呢？他是站在用户的视角，按照业务驱动的思想，将用户平时遇到的“业务问题”收集整理、分类、抽象后，再转换成以页面原型为主要表达形式，以功能、数据、业务流程为辅助表达的方式最终呈现。
最终用户虽然看不懂抽象的功能描述，但却可以通过软件页面，对应他们的业务问题，来判断蓝图是否满足他们的需求。以防止软件开发完成进入系统测试阶段后，再发现功能不满足自己需求的问题。
所以，我们必须始终以业务视角去看待需求，并且用业务语言去描述需求。
2、需求描述的关键
首先，有一个很基础的问题：是否所有人都具有说清需求的技能？
举个例子吧，如果大家有装修房子的经验，可以回想一下，当时和装修公司的拉扯经过程。装修的大结构好说，你要中式还是欧式，要不要干湿分离等等。但一到具体细节时，如进门处我们是否要有椅子、是否要有镜子，是否要有一个收纳盒子，是否需要门灯等等。我们知道房子是每天要住的，住的舒不舒服，主要是在早期设计的时候，有没有尽可能的考虑到细节问题。
要让所有客户都具有清楚表达需求的能力，无疑是天方夜谭。那么有什么思考工具，不仅可以帮助我们构建全局，还可以辅助我们不遗漏细节呢？
故事清单
在敏捷开发中常常会使用“用户故事”来描述需求。他一共有5个要素：角色、时间、地方、目的、任务。其中时间+地点=场景。我们在构建一个B端产品的时候，往往都不止一个角色，也不会只有一个用户场景。如果把每一个角色的不同场景的所有故事放在一起，就会得到一个表格，我把他称之为“故事清单”。
对于客户来讲，看到这个表格，就可以迅速了解系统的全貌。因为他是现实问题的描述，更加容易理解。
对于需求分析师，可以通过这个顺序将每一个角色在一个场景下里要做的所有事情逐个记录。一般需求分析师在做完需求调研后，往往是零散的。他是整理需求非常好的结构化工具。
3、如何高效进行需求分析
当我们将故事清单整理完成以后，需要对已经整理的需求进行分析。分析的主要目标是找到核心需求并对需求进行分层分级。以方便在开发中，去规划需求的优先级。在这里，我主要想说下我平时用的比较多kano模型分析；
Kano模型
Kano模型原本是关于质量管理的模型，在互联网产品圈也经常有人把他用来做需求分析用。
Kano模型，把需求分为基本需求、期望需求、兴奋需求、无差别需求、反向需求五个级别。
基本需求：满足任何产品最基本的需求。如同手机的基本需求是打电话，发短信；微信的基本需求是聊天一样。
期望需求：在满足基本需求的基础上，如果还能兼容好的用户体验和一些附加功能就比较好了。这个对不同的用户会有所不同。比如当时我对功能手机的一大诉求就是可以听音乐。
兴奋需求：兴奋需求往往是用户自我无感知，无预期。但是看见了，又突然惊叹：“太好了”。这类似于当你需要一匹最快的马车时，给你一辆汽车；当你想要诺基亚旗舰手机的时候给你一台Iphone一样。
无差别需求：则代表这个需求，你满足和不满足对用户来讲是无感的。无差别需求也是根据产品和用户不同而不同。比如我从来不玩游戏，那微信无论是如何增加游戏功能，对于我来讲都是无关紧要的。这不会让我玩上游戏，也不会让我不用微信。
反向需求：即没有这个功能还好，有了反倒令人讨厌。这依然是见仁见智的事。比如说，现在的电视机都是网络电视，都有一个看网络电视的IPTV。而家里的机顶盒也有，如果家里还有一个小米盒子的话那就显得非常鸡肋。家里电视的那个IPTV对我来讲就是反向需求。但作为电视厂家，这是他们的一个盈利模式，他们必须要内嵌此功能，以实现营收。很多法向需求和商业目的是相关联的。并不是不存在。
我们使用kano模型一般是对不同的需求进行分级、分层。清晰的知道什么时候需要做哪些功能。在前面我提到的主线功能一般就属于基础功能。他必须要有，否则此软件对于用户就没有任何价值。当我们实现或者设计了主线功能的基础上，我们再去实现期望需求和兴奋需求以提高用户体验，增加系统的丰富性。而要谨慎审视无差别需求和反向需求，因为这两类需求在每个人的认知里不一样，需要多方求证再做取舍。
4、需求抽象
“故事清单”只是一个二维的表格。将所有的用户故事根据角色和场景进行罗列。而软件则是对现实问题高度抽象以后的系统级解决方案。在这个环节，我们需要根据不同的维度，寻找用户故事的关联性。合并同类项以后，再去抽象其共性，把一个二维的“故事清单”抽象成一个结构化的系统。
我在做需求抽象时，需要将各个需求串联起来。而这种串联工具就是我们常说的业务流程。如下是我一般最常用的流程图：
主线流程图：整个系统层面的主要流程图。此主流程根据系统的大小不同，数量会有所不同。比如说WMS，他的主流程是入库 - 库存管理- 出库等。那SRM呢，他就可以有供应商管理– 签订合同– 供应商协同 – 结算。我们可以发现，主流程图的每一个主要节点都是一个模块。那么我们就可以使用泳道图画出每一个角色使用某一个模块的流程了。
角色功能图：通过泳道图的方式可以表达。上层为角色名称，泳道内为模块名或者“模块-功能名”，将整个系统通过角色串联起来。
模块功能图：通过泳道图的方式可以表达。上层为模块名称，泳道内根据某一个模块内的功能，将整个业务流程串联起来。
模块内流程：可以通过流程图将业务流程清晰表达出来。一般会在业务逻辑比较复杂的情况体现出来。
通过业务流程图把各个需求串联起来以后，我们就可以得出很多的业务块。这这种业务块按照各种维度归类后，就可以得出一种业务结构图，我们一般会用脑图来表达。这是纯粹的业务领域相关的结构图。对任何一个熟知业务的人员均可以做出业务结构图。
以上就是整个需求分析的过程了。那么从需求分析过后，我们产出了两个成果，一个叫做“故事清单”，他是需求的罗列，是一个非计算机专业人员也能看懂的需求清单。另外一个是故事清单抽象后的业务结构图。这是我们在做解决方案设计时的基础。
