前言
记得还是15年的夏天，那时候王石还没现在热度这么高。彼时他在万科集团内部例会上说到，“你们之间怎么谈我不在乎，请你们不要在我面前说大数据这三个字”。为何，他认为大数据和企业是有关系的，但是作为传统行业，在数据还不全的时候，谈什么大数据呢?
对于此番言论，相信每个人都会有自己的看法。但毫无疑问的是，商业智能在中国发展十余年后，大部分领域及诸多企业中仍有可为。如果将大数据视为数据源的扩充以及新方法与技术的引入，那么大数据的基础上加上商业智能，又何尝不是一番新生呢。
而在与不少朋友的沟通过程中，发现越来越多人不愿谈及自己是从事“商业智能（BI）”的了，何解？因为，BI项目的成功率不高是事实。
那么导致BI项目低成功率的因素是什么呢？据有关统计，约有70%以上的效果不佳的BI项目，其原因多与需求相关。而本文则期望结合自身多年BI建设心得，提炼了需求分析阶段常见的一些黑洞，避免后来人的“跳坑”。
黑洞一，需求分析阶段计划与资源安排不合理
俗语云：“凡事预则立”。由此可见计划的重要性，而BI项目中此方面典型问题常体现在计划与资源不合理两个方面。
由于项目工期等各种原因，项目计划中给需求分析这个阶段分配的时间相当可怜。笔者曾经多次看到有些一定规模的商业智能项目计划里，需求阶段只有寥寥两周时间，这种情况下匆忙忙的进行需求分析的整个过程必将问题频出。此外，有些项目中，需求环节并不安排专门的需求分析师（BA）角色，让本身不具需求分析技能的项目经理或是架构师兼任需求分析师。这些都将给整个需求阶段即项目带来很大的风险。
造成这种情况，多数原因是企业方或是项目实施方未有对需求分析的重要性有足够的认知。尤其亦发生在初次建设商业智能项目，且缺乏专业人士的情形。
解决的方式，一是遵循BI项目的规律，掌握科学的项目实施生命周期的特征及方法论，科学安排计划，同时引入专业的需求分析的知识与技能，培养专门的需求分析人才。
黑洞二，没有抓住关键人物
跟人沟通聊项目适时，通常会听到感叹，项目做得快差不多了，发现业务用户不满意，更悲的是给高层或老板看了不满意。这种情况，很多时候会与初期聊错了人有关。
凡事都要抓重点。什么事情，都讲求找到对的人。BI项目自然也不例外，找到并“搞定”相关人员，甚为重要。如何避免聊错了人呢？可以在需求过程中注意如下。
首先，是关键人物。那些项目负责的高层，或是能够拍板起到决定性因素的人，或是对项目持以积极态度的人，是我们需要仔细识别出来并予以特殊对待的。
其次，关键用户，每个BI项目都有它的定位的，面向哪个群体，哪些角色，解决他们什么问题。那么关键用户，就是未来使用这套解决方、系统或服务的人，所以在需求过程中需要认真考虑他们的输出。
黑洞三，需求发现过程的产出质量欠佳
需求质量不高，这类情况的现象如，采集了过多的用户需求，但却没有挖到客户真正的迫切且重要的需求，或者是所整理的需求通篇都是原有业务报表从Excel版本的搬迁。导致的后果通常是后续的交付过程中花费了大量的力气，却没打到痛点，或是提升寥寥，最终无法得到业务用户的认可和满意度。
需求发现阶段，主要包括需求访谈与需求分析，其是整个需求分析阶段的极为核心几项工作之一。商业智能项目很大一部分的需求都离不开需求访谈这一步骤。
比较理想的情况是，需求发现的过程中，我们应要挖掘到客户工作中的“痛点、刚需、高频”的需求，这就要求我们在需求访谈的环节，切记要从业务用户的视角看问题，此外，还对诸多的软技能，如沟通技巧等方面有相当要求。
提炼出来的需求应用点，相较于原有水平，要结合到项目定位、预算与周期，做适度的提升。适度，也包含了不宜太超前，导致工作量超出预期，或是努力的边际效益会递减的情况。
当然，在BI项目里另外一个较为普遍的情况则是，在此阶段，即有可能需要开始兼顾数据实际情况降低用户与客户不切实际的预期，因此可谓是任重道远。
黑洞四，需求规格说明书如天书
这个“坑”非常好理解，也经常会被项目组员吐槽颇多。
笔者就曾遇到过一份号称是某BI项目的敏捷需求。需求规格说明书里通篇太多的语焉不详，譬如指标定义的细节，又如计算的逻辑，再如应用的场景与可以衍生的操作，极少描述。而在之前BA离职之后，项目组内众多同事们就从此陷入了大坑，后续新入组的成员也全是一抹黑，而这却是发生在一个大型IT公司和大型客户里的真实事件。
我们来看看好的需求规格说明书，需要有哪些要求吧：
需求描述全面，包括面向对象，使用场景，数据源，逻辑规则等等；
需求表达准确、清晰、无二义；
各个细节部分描述足够详细；
鉴于BI需求的复杂性，很多时候可以利用图形化的原型图绘制来提高需求的可理解性。 原型图将报表，分析、仪表盘等应用的交付内容进行绘制，以更好的阐述、沟通与传递需求。阐述内容包括静态展现形式以及部分动态交互。
除此之外，通常一个BI项目内，需求应用点会有很多，他们之间一定是有重要性的差异，有实现成本的差别，而项目整体预算是有限的，因此划分优先级、识别关键需求，对整体项目效果提升以及项目管理很有帮助。
黑洞五，需求未与用户最终正式确认
从字面意思即可理解，这说的需求没有得到正式确认。很多时候，业务用户们对于签字确认这一个动作，总是颇为谨慎且不那么爽快的。而越是这种情况，则越是需要加以重视。因为合约可能潜意识里，他们就是担心的是“签字了就不好再变了”。
下图Boehm's Curve，我们一定不会陌生。越是在项目后期发生的变更，其造成的成本将会是数倍乃至数十倍，足以使得整个项目里各方人员都筋疲力尽。
因此，在与项目利益相关者及用户们沟通完认知不一致的地方，并确认过可实现性，最终达成一致之后，关键一步就是正式对需求进行签收，即是确认这份需求规格说明书反应了他们的需求，在项目的后续进行过程中，就将作为避免变更风险的一个重要保障。
好了，说到这里，有的人会说了，现在不是流行敏捷BI吗，那我要走敏捷路线，别说签个版本出来，我连写都不想写了。
笔者要说的是，敏捷BI并非不好。而只是依个人感受，在甲方乙方这种常规项目里，敏捷的话，是很容易持续到没边的。比较好的方式，是甲方内部自行建设，很多事情都可以商量商量，另外一种就是纯外包，乙方只要出人，其他都可以按甲方的来。而即使是敏捷BI，也建议尽可能的再每个阶段平衡精力，留下原型图及逻辑说明等一些中间产物，而不要挥挥手，一片云彩都不留下。
小结
总之，请君切莫要小看需求分析这个环节，实在是有太多的内容，需要我们清晰的认知它的重要性，科学掌握它的方法论，才能在各个BI项目中披荆斩棘而无往不利。
写到这儿，也还是感觉意犹未尽。关于需求分析这个话题，越是聊、越是写，便越是会发现它的丰富与精彩。足以值得为此开设一门小课程了。是的，我想这极可能变成是一篇引文，后续天善智能会推出的BI项目需求管理课程的一个抛砖之文。届时，也请大家多多关注。
说明
本文作者：天善智能，此文允许转载，转载时需请完整保留以下内容，违者必究。
原文来自天善智能 www.hellobi.com ，原文地址：https://ask.hellobi.com/blog/fashionBI/5584
