记得以前听某人说过，最坏的方法是武断，最好的方法是倾听。

XX是加入公司以来接触的第一个项目，这个项目大体上是实现数据从源A，B，C（可能还有D,E,F）发布到B，B是DATA-CENTER，从而帮助客户搭建具有统一、高质量、全面的数据平台。

该项目就围绕数据中心设计、数据转换及应用调度等相关项目建设。

说实话，以前我没有过ETL项目的经验，但单从技术层次来说， 这样的项目从表面看起来似乎并没有多大的难度。建立转换字典，使用ETL工具，开发业务workflow，应用程序调用API，定时跑起来，监控一下问题数据，做一下异常处理报告，然后泡杯咖啡数着客户付的钱....岂不美哉。

大概是因为我刚进公司的缘故，对公司的技术实力、管理水平、人力资源都不太了解，所以碰到了很多看似算不上问题的问题。没有相关的项目实施文档，缺少相关的技术share，还有过度的依赖application。我想起在之前公司做的一个广告operation系统，（我对前台开发不甚了解，但对后台数据库开发有一点自己的见解）。这套系统也是要从多套系统后台（广告后台、游戏后台、支付网关）采集相关的数据，项目决策者对这样的系统有点束手无策（原谅我这么说），因为要采集很多系统的数据，决策者不想开发数量众多的API，并且公司大多数人不懂数据库，项目从原先定位的DW降到ODS，使用MYSQL+LINUX平台，采用FTP定时接收的平面文件导入临时数据库进行处理，最后发布到产品库，应用系统由一个小女生开发，从头到尾不用关心数据库，连数据的展现都由SP来完成，应用程序只要调用SP分页，把数据展现在页面上。最后这套系统看似成功的实施上线了，而且给市场部带来不小的视觉冲击，可以说是一种梦幻般的客户体验（数据计算都是由SP来实现了呀，不用再去手工统计啦....）。然而在我看来，这套系统非常的失败，彻头彻尾的失败，因为系统太过于“依赖”数据库，根本不用关心数据的流向，所有的工作都通过调用所谓的API(store procedure)。而且B/S构架采用sp会给服务器带来不小的压力，扩展性也很差。

于是乎我看到现在的项目“过度”的依赖应用程序就产生了种不详的预感。 但我不是那种能被依赖和掌握该技能的专家。

顺便给“专家”一点建议，如果你觉得自己能够搞定（当然自信是件好事），但是没有在项目中真正的应用实施成功过，那么请认真的倾听。

大家都在相互磨合，在实施大中型项目中不断摸索成功的经验。