佳通项目总结

佳通项目第一阶段终于告一段落了，这是我的第一个BI项目，感触非常深。其实发觉应该经常每天总结一下，写写日记什么，因为繁忙的工作，烦恼的事情，经常会让人忘记自己每天的路到底是如何走过的。而在许久以后当我们想回忆起往事的时候，却会不时感到一种空虚，工作上是，生活中更是……

虽然现在的状态可以说还算不错，但是我很清楚得记得自己第一天进入佳通大楼的感觉：没有自信，没有技能，没有项目经验，我甚至不知道我将会做什么。不过我依然非常感谢那种无知，因为如果不是那样我无法看到自己的进步，虽然细细算来那种进步远不及我所预想的程度，不过我不得不承认，我的心太急了，我渴望自己能有能力，渴望自己在技术和英语方面都远远超过一般人，渴望自己能有能力带老妈去欧洲旅游，渴望一直找到一种已经失去已久的东西。

项目非常辛苦，非常累，特别是初期，体验了我从未感受过的压力与无助，感受了什么叫做Something is just out of your control，刚开始对于BI项目前端的熟悉与理解都不是现在可以相比的，很多报表的格式，很多可能出现的分析项，很多技术上需要研究的知识点，比如YTD、同比、环比、预聚合等技术点。整个项目在刚开始的时候，由于Oracle和GiTi方面的背景因素，使得需求控制和难度大大增加，至少在我看来是的。刚开始项目的技术上也管理上也是重重的难题，BIEE的Bug导致许多报表无法实现这样灾难性的技术困难点，以及因为时间仓促在BI项目方法论上不走正规道路而去另辟蹊径（比如：ETL竟然要用视图的方法来实现）导致整个项目在节点上难以推进，各种瓶颈频繁发生，最典型的就是报表的速度，当使用视图作为ETL的时候，导致在DM中生成的查询语句的逻辑非常复杂以至于根本无法调优；项目的初期管理比较混乱，因为项目经理竟然要处理一堆的技术取数以致于根本无心顾及管理，即使前几个月忙得人快吐了，依然没有被客户肯定，依然被评判为沟通不够。之后的工作继续着，虽然我慢慢对BIEE有所理解，并且通过沟通解决了许多的Bug，不过项目的范围没有被很好得控制，使得项目上线两次不成功结果导致项目事故。最后项目经理换了，虽然不是技术出身，或者说技术上根本不能深入了解，但是在项目管理上我又有了新的观念，因为这次我看到了一个不懂技术的人如何管理一个技术项目，不停的开会讨论，严格限制项目需求，严格管理客户，更好的交流最后使得项目第一阶段上线基本完成，但最后的BIEE报表优化由于时间关系，只做了一个Page，但是10分钟的报表现在只需要最多45秒左右的时间显示出来，效果应该是非常明显的。很有成就感，也找回了属于自己的价值。

总结项目：

1、  高效的沟通能够带来价值：沟通能够带来价值，在项目实施过程中，客户希望功能越多越好，而实施方则相反，因为客户并不是十分了解项目的事实过程的难点，因此如果通过合理的沟通能够减少对可有可无的功能的开发的话，会节约大量的人天，即创造价值。

2、  要管理客户：项目的两次上线失败的根本原因是放任客户的需求无限制的扩大导致所有的报表根本无法在指定的人天内完成，虽然项目的范围确定了，但是由于没有对客户的需求有着全面透彻的理解导致许多可有可无的需求都被客户视为必须实现的需求，作为项目经理而言，应该要及时沟通。本次项目时间非常紧，非常不合理，因此根据客观条件，过多的需求一定要及时通过沟通的方式来排除在开发内容之外。

3、  要学会出针对自己有利的选择题：做顾问的确和做普通的技术有着不同，之所以许多技术人员都不被重视有一个非常重要的原因就是大家都只是矿工，砌砖工而已，根据上面的架构慢慢把整个项目搭建成架构师所需要的样子。顾问需要做的就是帮助有困难有疑惑的客户解决他们的困惑，给出不同的解决方案并且要深入给出每一个方案的利弊及可行性。也就是说，顾问回答客户的问题和需求一定要十分注意：就像老妈平时教的一样，说话要给自己退路。当即回答“可以”或者是“不可以”都是十分危险的，特别是面对那些非常强势的客户。什么都要做到三思而后言。

4、  忘却“自我”：我相信不止我一个人的毛病，很多人都是我认为、我以为怎么怎么，其实这样的回答方式都是非常差劲的，因为给人的感觉自己并不是站在宏观角度来对待问题，即使是纯从沟通技巧出发点来看，也一定要努力纠正让自己在正式场合发言和与客户正式沟通的时给对方太过主观的感觉，但是说容易做非常难。

5、  界限有时不能太明确：甲方和乙方通常是客户和我们顾问团队的一种让人可以区分的称呼，但也是直接导致了某些客户强势的原因，一个项目的实施必定需要依靠两方面的合作，才能实现双赢的结果，要让客户知道其实项目结果的成功与失败同时关系到双方的利益，其实也就是一条船上的人，要让客户知道，这个是大家的项目，单方面的专业是无法圆满完成项目的。

由于是第一个项目，所以有一段时期我一直很想知道，为什么和有项目经验的人相比，他们能以非常快的速度知道研究一个前台报表工具应该针对哪些点进行切入，但现在我了解了，没有其他原因，只是因为项目经验，下面对前台报表工具的技术研究切入点进行，特别是当刚拿到一个新的前台报表工具的时候。

前台工具技术总结：

1、  逻辑层的映射：我傻傻地因为一个Flag的关系在BIEE中配置了两个Resource，其实只要在映射的字段上用一个CASE WHEN就可以了。

2、  同比、环比：相信每个工具都有相应的功能，特别是销售订单的报表，这样的分析项是非常重要的，一定要很快搞清楚。

3、  累计（YTD/MTD）：同上。

4、  监控每张报表的SQL：前台工具基本上都是内部生成SQL后发到数据库中进行运算，但是当很多问题（比如数据不正确等）的跟踪全部都是需要查看SQL的，使用BIEE的很多情况中就是由于后台没有很仔细得关联好关系导致查询逻辑的不正确以及不正确的表关联，直接导致了数据的不匹配。

5、  报表速度的优化：可能就是所谓的预聚合，数据仓库事实中的两个技术核心问题就是1、报表速度。2、SQL的优化；GiTi项目的报表经过优化后节约的时间成本是非常让我心动的，甚至有些陶醉。

6、  钻取：必定需要的功能，但是功能可能各有不同，比如要实现不同路径的钻取等等这样的功能。