BIDW项目容易忽略的几个重要细节总结（原创）

innovate511

随着BIDW的发展，越来越多项目在各个行业的龙头企业和单位中展开。不过多数项目都存在着严重的加班和返工现象，透过这个表面，不难发现其中容易忽略的因素。

1. 调研阶段漫无目的。调研阶段主要任务是通过项目范围，进行有效的业务需求调研，确定业务细节规则。特别是多家单位合作做项目，还可能出现互相推委的情况。解决办法就是确定项目范围后，找到对应的业务人员，确定原始需求文档中不确定的业务规则，并和最终用户解释项目范围，不是每个需求都能随时变更。最后是完善调研文档，由项目负责方确认。

2。设计阶段。设计阶段容易忽略项目要求和实际设计技术是否完全吻合。如果这个有所忽略，会造成比较严重的技术性后果。

3。开发阶段，这个阶段容易忽略分工和责任以及版本管理。如果是TL去负责相关文档，那么要使具体开发人员的相关信息和TL一致，开发人员需要参与开发文档的一部分，需求变更时，开发人员必须要得到有效的通知。

4。测试阶段，这个阶段容易忽略测试细节，漏掉测试内容。这个阶段需要业务和相关数据模型熟悉的人参与，并审核测试结果。

5。实施阶段，这个阶段容易忽略实施细节文档，在实施上线的时候，由于是环境的迁移，细节决定一切。同时需要注意客户使用跟踪，因为正式环境也许有测试环境没有的陷阱。

6。维护阶段，这个阶段容易忽略需求变更和增加后必要的测试环节，需要进行一定的回归测试，以确保整体项目质量。

最后是甲方需要审核项目各阶段需要提交的内容，不然在实施阶段补充，已经来不及了。

innovate511

说明一下，DWBI项目的开发，其实也可以看成软件工程的一种，需要有严格的流程和规范，如果资深人士从太高的角度一来就否认细节，而拿出理论来，那就太可笑了。所以细节决定一切，这才是真正做实事的人应该去思考的问题。

作为实施方，无论是甲方还是乙方，首先要理解在调研阶段，你不可能面面俱到，把所有业务需求都把握到位，也不可能满足客户所有业务性、功能性的问题。那么早期确认项目业务目标、功能目标很重要，这样就能避免延期的需求调研和无数次的无用功会议。所以这里也提到了一个技术问题，是否有规划？是否能让客户意识到循序渐进的项目开发，现在能到什么地步，近期、中远期能到什么地步？如果这样的话，后期维护阶段，他们的新需求就能在能接受范围内了，所以和最终用户交流的时候，不能只调研业务，还要指导如何逐步使用BI，而不要指望一步到位使用BI。

innovate511

最终决定项目成败关键的还是业务定义、业务组织是否无限制改变、具体的BI需求范围是否在调研时定义好。

我见过有这样失败的案例，某些业务定义和组织一直没定下来，设计阶段也没有，项目前期耽搁了太多时间，后来根本没时间开发、测试和实施，而在先期早早地就把项目时间表定下来了，导致客户满意度极低。所以项目实施的时间表，必须有必要条件定下来，客户也会没话可说。二则是必须要有合理的理由拒绝无故的大改动。至于小改动，也有技术原因，先进的数据建模技术是不怕改动的，但一般未必有这自信吧。

还有就是需求范围，在项目实施好后，客户可能要求增加新功能而迟迟不结项目，这样公司的成本会增加不少。我的建议是，把握一个度，如果1、2天就能帮忙的紧急新需求（需要客户项目相关的领导一起来控制需求），那就帮个忙，如果影响项目进度，那就委婉拒绝，说下个项目去实现。所以说要和甲方项目人员搞好一定关系也重要，大家一起来为这个项目努力。

innovate511

现在先简单介绍下设计阶段。这个阶段也是我们容易忽略的地方，因为以往项目都是从ODS-DW-DM-CUBE/REPORT，只是根据情况，再在遇到具体困难后，再做些具体的设计调整，有时甚至开发过程中再做些设计调整。

我在另外一个帖子中写到过规划，有人说很理论化，其实不是，理论书上有从这些角度去看数据仓库的么？在设计中，不要说中长期规划的远见，至少得有一个项目范围内的预见吧？所以我一直不鼓励刚毕业的或者经验少的去直接设计商业项目，那样不但设计不出合理的项目，反而让他们的经验引向不合理的方向。

设计方面，前端BI主要看客户的需求，因为客户直接使用前端来实现BI。那么这里主要说数据仓库，没最终用户关心你后台架构怎么设计，只关心你怎么把BI 做得更好用，更可靠。如果说客户更需要你帮他们用BI实现更多价值，那你说的应该是已经有成熟数据仓库架构的成熟项目，不在本主题讨论范围，如果客户连你的BI都不够信任，觉得不好使，后期的BI思想再好，又有什么用呢？

目前多数商业项目是从BI主题（也就是业务主导）引导数据仓库建设，技术主导的项目属于少数。这里以业务主导为例。业务主导的主要特点是需要较快见效，最终用户为主导方向，也是甲方考核方向。所以需要以合理的时间和投入去建设BI以及数据仓库，同时也考虑多个主题的统一性，以及使用效率问题，对于高价值数据，还需要自定义行级别的数据安全管理。当然理性的客户，最终还是会接受，在未来的规划中，范式建模的数据仓库的重要性。但他们的特点是想先产出效果，老板才能拍板再继续不断投资建设，于是你就不能强制推行Inmon先生主导的EDW，否则完成不了项目，自己就兜着吧。

那么这个时候主要几个要点，一是是否有统一维度建模（如果是某部门独立建的集市项目，那就不必了），是否模型中不但支持业务变化，还支持业务组织结构变化（如原来销售区域分3层，现在分4层，有结构交叉了）。在ETL方面是否有合理的增量抽取方案，每个包是否都有统一的检查流程，每个ETL过程是否有数据验证功能。模型设计中，PK，FK是否都设计合理。是否预测到数据量会带来架构瓶颈。而对于客户的合理的需求变更，数据集市是否有足够的变化空间，不要只有聚合汇总数据吧。

经常会碰到的项目开发中修改设计架构，往往就是对困难的估计不足，架构灵活空间太小，所以开头说的，如果设计偏差太大，后果不堪设想，会导致开发改变，重新测试，难免会顾此失彼，而且时间被严重浪费。后台设计空间要足够大，数据集市主要考虑功能，效率不是最大的问题，正常运行好几年的项目，一般数据集市都重组过2、3次了，效率问题每次重组后就不是问题了，如果说是空间换效率，那么数据集市相比数据仓库的数据量，应该不是大的问题。

innovate511

这是本人今年春天在其他论坛的发的原创精华贴，翻出来在此与大家共享。

hero--008

比较深刻的经验总结啊！精华～

其实我觉得前期的需求调研，探查，以及前期的规划还是很重要的！

penknife

路慢慢！
慢慢体会中！

RNW

非常不错。。。