打算帮助公司另一个项目组解决技术问题

今天和明天都跟着客户放圣诞假，但我需要去公司帮我团队中的一员拿本本，他本本前不久坏了，需要换个新的。为啥我这个PM去拿？谁让俺离公司太近呢。（客户那边-离公司需要2小时路程，去那边上班苦呀）

在公司里碰到老同事，说他们一个项目本身打算只上一个数据集市做BI（目前只针对报表），但客户说大亚太地区都需要上，需要良好的扩展性，那就必须要上DW了，-于是他们在设计数据仓库，以及数据集市。于是问题上来了，时间不够是个问题，需求不明确，离岸工作无法进入数据库察看详细数据判断字段意思，也没明确数据字典，-客户反应也很慢，这问题估计Kimball也不能马上搞定，只能一点一点自己研究并和客户交流，谁让系统在泰国呢。

然而建设数据仓库后要上6个数据集市，而且业务重点不同，又要求灵活性，工作量很大。于是建议他们在数据仓库到集市间采用中间层并使用总线架构思想，如果时间有-限，可以考虑局部使用。同时由于时间紧，现在才开始研究数据仓库各字段意义（面向数据的模型），对于面向业务的模型研究毕竟有限，而且好的架构能节约开发，提高-效率和准确性。不过没关系，我有成熟的架构和行业模型设计，拿出公共的思想出来和项目应正，就能节约大量设计时间，同时也不算滥用原公司的东西。同时优秀的测试-流程能帮助项目组完成整个项目上线进展，因为客户可是很仔细的主。同事笑称都没听说过这种设计，不过听起来很好，但现在时间太紧了，怕来不及了。我说这个项目毕-竟不是很大的项目，要求也不是十分严格，小场面啦，只是把以前项目的几分之一的东西拿出来就可以了。所以我建议他们先把最难的数据问题解决，剩下的我可以帮他们-提高很多效率，同时保证一定的灵活扩展性。

当然我只能兼职做，毕竟要把自己项目做好，同时我看明天有时间去会下该项目组老大，不然就乱插手人家项目了，赫赫。不过部门老大说，项目组之间互相帮忙值得提倡-，公司利益第一，有这个文化就好，传说日本的企业文化可不允许不同职责的人互相帮忙的哦。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友