白纸黑字书写BI项目文档的四个方法

　　一、事无大小，项目文档都需要一一记录

　　不少用户在书写项目文档时，就捡重要的内容来写。一些细枝末节的内容就忽略不计了。笔者认为，这种做法是不合适的。因为从整个BI项目来看，事无小事。有时候一个小的细节如果没有做好的话，就会给BI项目带来致命的影响。举一个简单的例子。如新建一个报表，其中可能含有比较敏感的信息。企业一般对此都有比较严格的权限限制。如果在BI中实现这个报表时，只考虑到了报表本身的内容，而没有考虑其数据的访问权限，那么就可能会给企业带来比较大的损失。

　　为此笔者认认为，对于BI项目来说，事无大小，都必须在项目文档中进行记录。如对于基础数据整理格式的要求、每个字段的最大长度限制等等，都必须有明确的说明。以后如果关键用户离职，那么新接手的用户仍然可以凭借这个项目文档来顺利的接替其工作。那么用户也需要文，项目文档到底该详细到什么样的程度呢？笔者认为，一个简单的判断标准就是，在项目文档中应该包含用户对于BI系统的所有操作说明包括相关的注意事项。这个项目文档在后续的工作中，就可以作为一份教科书来供用户使用。

　　二、失败是成功之母，要重视失败经验的分析与总结

　　笔者在实际工作中还发现，不少用户在做项目文档时，喜欢将一些顺利实施的内容记录在内。而将一些失败的内容不反映在项目文档中。笔者认为这种做法也是不合适的。如现在某个用户在实施BI项目时犯了一个错误，已经交了一次学费。可是项目管理员并不能够保证，以后用户（如有新员工接替原用户的工作）并不会犯类似的或者相同的错误。如果在项目文档中不将以前犯的错误记录下来，那么企业就有可能多次在同一个地方摔倒，多次为同一个问题教学费。显然这是很多企业都无法忍受的。总之，项目文档要能够起到一个警示的作用。具体的来说，需要注意以下内容。

　　1、需要注意，项目组成员在解决某个需求时，可能有多种解决方案。最终用户根据自己企业的实际情况，选择了一种合适的方案。在项目文档书写时，不应该只反映最后选择的实施方案。笔者认为应该将以前考虑到的多种解决方案都一一的列出来。然后再在后面说明为什么选用了某种解决方案、不选择其他解决发方案。因为BI项目是一个持续改进的过程。随着工作的深入，或者员工的调动，用户可能会对原有的解决方案产生疑问。此时查看这个项目文档，估计可以打消他们的顾虑。或者说，为用户后续作业的优化，节省时间。

　　2、对于无法实现的需求，也要一一反映在项目文档中。在需求调研中，项目团队会收集到很多需求。但是在实际工作中，BI系统并不是能够百分之百的解决所有的问题。其实在实际工作中，大家都有这样的感受。有个问题提出来之后，如果第一次没有解决，那么用户在后续的时间内仍然会不断的提出，直到他们找更好的替代方案。

　　如果没有相关的书面记录，那么每当用户提出一次需求，项目管理员员就需要从头开始对这个需求进行调研分析。最终仍然得出否定的答案。显然这会浪费大家的时间与精力。另外一种情况是，随着系统像深入化推进，原先无法实现的需求可能会在后续可以实现。针对这种情况也需要有相关的说明记录。因为在后续考虑这个需求时，前期的需求调研、需求分析等相关的数据能够为后续的工作所用。

　　三、利用图形来说话

　　在文字记录中，配一些插图有时候更加能够说明问题。不过可惜的是，很多项目管理员并没有养成这个好习惯。他们在描述问题时，更加喜欢使用文字，而不是图形。可是现在遇到的问题是，某个需求或者流程，如果利用文字的话，即使使用一千个字，可能也无法将问题描述清楚。但是如果使用图形的话，那么这个问题就会变得简单。有时候一幅图话可能比千言万语还有用。

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!