数据仓库外包项目讨论

作者: innovate511 20071104

很久没来ttnn了, 最近又开始涉及数据仓库外包项目. 不过项目开始接手不久, 就发现其中有的问题值得改善, 而随着数据仓库项目国际外包的越来越多, 也值得大家注意下, 毕竟这也将是软件行业重要的一部分, 也包括DW/BI这个方向.

作者: goldenfish3 20071105

一些客户还无法接受外包的方式，一方面是与传统的现场实施模式不同，客户的思路需要转变；另一方面，外包方式被一些厂商滥用，号称在后台有强大的开发团队，实际可能并没有，导致客户的质疑，使得外包不被认可。

概念可能有一些混淆。外包相对的是靠自己的力量实施，例如很多大型企业拥有技术开发中心，自行进行数据仓库项目的实施。外包会有on-shore、off-shore或相结合的外包方式，离岸外包是外包里比较时髦的方式，前面说的是离岸外包不被客户认可。

作者: Qing 20071105

稀客啊稀客，听说innovate是去西方极乐世界拜佛求经去了，回来了？有啥收获跟俺们说说没。
数据仓库外包。似乎HP这么干，不知道有没有HP的兄弟介绍一下子噻。要说国内的，数据仓库外包不是少数，ibm、ncr的项目，好多不都是找一些本地公司来实施吗，基本都是在现场工作，便宜。那些本地公司，有个长处，就是能够在很短时间里面找到一帮子人，不管是干没干过数据仓库。

外包团队在现场实施，风险似乎要小点。但似乎也是没有办法的办法，因为数据仓库架构现在没有分的那么细，将一些可以将一些固定模式的部分外包出去。呆在现场，我让你干什么你就干什么。看上去风险小，其实未必。因为根本问题没有搞定，整一堆人就有用了吗？也许离岸外包因为客观条件的原因，反而能够逼得项目组在架构上将模块、职责分清楚，我想这回事未来外包的趋势。

当然，goldenfish说目前客户还没有认可离岸外包的形式，我不是非常清楚这点，猜想也许是因为数据仓库项目大多做的都莫名其妙，没法子，整多些人在现场大家心里觉得塌实些吧。

作者: innovate511 20071105

呵呵，那边确实是极乐世界，狗在商店门口睡觉，和人相安无事，牛在垃圾箱找东西吃.......话归正题。我总结下目前DW/BI项目外包有这么几种情况，可能其他软件项目也有类似的，只是DW/BI有其特殊性，导致了困难会更多，而且有的困难不好预期。

1.Onsite外包。比如我们公司有个项目是受一家大型咨询公司的外包，同时和咨询公司和最终客户一起协调工作。这种外包工作容易控制点，因为除了大方向由咨询公司定外，其他细节，如DW设计开发和测试，BI前端设计开发和测试全部自己来。

2.Offshore外包比较负责，由可分为两大类和两种不同的环境。两种不同的环境分别是
（1）远程登陆客户环境，但在自己办公室工作。
（2）自己公司搭建开发环境，然后提交到onsite那边。第一种受网络环境影响，如果顺畅，会没有大问题。第二种有很多制约，首先考虑你能否从客户那里得到测试数据，如果没有拿到测试数据，如何开发、测试？于是这对开发的经验非常重要，否则会做很多无用功，而你不能按时完工的话，又不能怪客户没给你数据。

两大类情况，分别是onsite设计好后你按要求开发。这种情况一般onsite实力非常强大，而且精通客户需求和技术，你只能按照他们的要求去做，自作聪明的话会打乱全局，即便有看法也只能发表意见。还有种情况是onsite实力有限，offshore团队需要参加全部或者部分设计工作，onsite的任务主要是交流、现场维护和个别新需求开发。但如果offshore团队只参加部分设计的话，需要在原来设计基础之上做到最好，而不是推倒原来的东西重来，即使他们的设计有问题，这就需要一点技巧了。

以上是我所遇到过的外包情况。其中offshore开发的沟通技巧很重要，你需要说服onsite的PM和他周围的技术人员，因为他可能连技术都不太懂。而一步一步的开发管理也重要，需要通过经验预测一些意外，同时制定解决方案。

外包是个趋势，商业项目，不是你有实力就能做的，毕竟利益是第一位的。目前国内项目的外包形式多以onsite 外包为主，而国外已经普及offshore外包了。

其实外包做好了，不但和技术有关，更和商业利益有关，无论你打工还是创业，都有机会分享外包的一杯羹。

Qing说到的外包，我03年看见移动经分一期工程就这样做了，这种做法其实很单纯的，只是分包厂商必须有ETL开发技术和管理，并且对业务和数据集市有深入探究，当然第一次做，问题多多，不知道现在如何。这种外包对于管理方面比较简单，出了问题都是本身技术或者业务实力不够，这里就不多说了。

我觉得目前最重要的是如何做好复杂的外包项目。我们可以设想下，5年后中国、印度经济上升，人力成本过高，最基本的开发会不会放到越南？不说远了，就说现在，我们可以从外包职位中发现很多DW/BI的职位。

无论哪种外包，最重要的是看懂已有的文档，并提出问题，把信息不同步的问题解决掉。从看文档的角度看，首先要看架构，然后看项目范围和基本业务知识（如果该客户的业务不太熟的话）。其次就是看说明文档和职责分工。写文档也重要，因为外包的重点就是”文档驱动”，有了文档，才能避免不必要的多方纠纷。

然后是项目管理。这里由于外包承接商可能连客户交流都少（如果offshore的话），那么主要的就是和onsite交流，同时需要提醒onsite和客户交流的问题，并给出一些设计方面的建议（如果有必要的话），只有大家达成共识，才能前进。由于项目进度依赖其他因素的程度高，因为你可能不能和客户经常直接交流，于是需要每周、每天详细安排各个成员的工作和评估，并对进度依赖性有分析，提交给onsite，达成信息一致。

从技术经验来说，如果offshore参与设计，其实对offshore经验要求挺高的，试想在一个没有数据的环境，全靠文档搭建环境去开发测试，需要什么样的经验程度。
这点说起来容易，做起来难，因为感觉我们和印度相比，独战能力很强，但多方协作不一定比他们厉害。不知道各位有何感想？

作者:Hawking, Bin 20071105

“外包”的问题我一直在想。但我想的角度与各位不同。

1、外包的地区概念更广，可以是国之间，城市之间，以及同市不同地段。可以把远处的人拉过来，还可把眼前的人投到别的地区（比如从广州闹市扔到张家界去闭关开发半年）。因此这里说的”外包”的本质多方分布式设计：开发者就象一个EJB；一堆开发者通过网络，由中介进行协调。目的是充分利用资源（环境和人才等）的长处，避于短处。在信息时代随着客户需求、产品功能和产品结构越加复杂，独立设计的效率和效果都成问题，多方设计的需求会越来越多。WEB2.0网站可算是多方分布式内容设计的一个简单尝试。

2、对于传统制造业，多OEM分布式制造也已经有成熟的方法和系统去支撑了。而设计工作的协作就复杂得多了，外包难以控制，搞不好成本反而更高。对这些问题，在技术层面，需要用”BI”方法（泛指一切有用的分析计算技术，除了mining还有OR和各种经济学模型等等）去支持外包。（这是我选择”BI”为现阶段的主业的动机之一。）这不光是考虑BI项目的外包问题。BI项目有自身独有的特点，但也要使用其它类型的技术。

目前我的设想所基于的是软件开发的项目，因为我熟这块。也有应用到其它行业的设计工作的机会，但那就是更遥远的事了。

作者: Steven 20071105

好久不见啊，innovate511

怎么那么巧，我也正做一个外包项目，银行业的，颇多担心，毕竟没做过如此类事情，有时间多交流交流，可能我做的外包和你的外包形式和内容有所不同，我们有外包项目，也有外包人，但经常混淆，北京像软通动力，博彦，做外包做的多了。

关于外包，其实我内心里一直是很抵触的，感觉是那么一帮人用本土廉价劳动力干应该高报酬的活，这样更拉低国内劳动力价格，可以形容为资本主义的帮凶

作者: innovate51120071105

总的说来, 外包就是为了节约成本, 不过你刚才提到的外包公司还做人力外包, 这点才是很多人不认同的地方. 而项目外包, 现在已经很容易接受了, 相当于不同的公司或者部门合作一个项目(有的公司是不同地区的分公司内部外包).

作者: wang yiyun 20071106

现在HP就是在DW/BI这块做啊, 还有Satyam ,这是我所知道的,泛泛的东西,大家已经谈的很多,是否可以根据具体情况,深入谈谈有谁在这两家公司相关的项目中有经验可以说说

作者: innovate511 20071106

深入的东西？首先我知道你去承接人家的项目（哪怕是一个公司的），得要有耐心，即便人家问些初级问题，你也得忍，耐心解答，不然你说的方案和建议再高明也不会有人接受，最后的苦果你得接着，因为最好重复开发还得你自己去做。很多情况下，现场的人不一定非常懂DWBI，但人家最了解客户，而离岸的人最大的缺点就是离客户太远，所以得忍，得多交流。然后由于有的情况，现场的兄弟们很难即使给你数据，于是很多设计需要经验去想象。比如一个大型Cube就不能任由现场的哥们由几个事实表和10来个维表想直接做成，而且事实表之间的粒度还不同，由于有退化维要计算，CUBE直接抽取出来的话肯定是错的，于是我把这个整合的步骤称为从DW抽取数据到数据集市，于是人家就容易理解了。再说一个例子，现场的哥们为了尽快赶出报表，让你直接用存储过程完成报表的逻辑。这个时候你应该考虑客户的需求扩展性，还是得老老实实使用BI工具的建模开发报表。这些扩展性和基本的思路，是不需要数据就可以判断出来的，那么你要等有数据来才做，可能会非常失败。

也就是说，我们需要做的是，在客观条件限制下，能做到自己能做的最好就行了。

作者: innovate511 20071116

做这种项目还有个挑战，就是架构是别人设计好的，哪怕再烂的设计，都需要在此基础上继续去做。

今天和这边的印度人谈起DW的事实表主键，他居然说以前设计是按照表序列号为主键，允许有重复记录进来，只不过原有的有效标志该为无效，而新记录的有效标志为有效。真不知道发达国家的这个知名公司咋请个外行来整哦，还运行了1年多，出现N多问题，大家都靠额外工作去修修补补，汗。真想见识下1年多前的那个”高人”。

作者: 3stone2004 20071119

相当同意以上观点,我在的公司就是离案外包.现在花了很多时间在统计,研究员工的工作评估上并定期报给客户, 以此达到交流目的.还有最头痛的就是数据环境的搭建问题. “试想在一个没有数据的环境，全靠文档搭建环境去开发测试，需要什么样的经验程度” 这点完全就是我们公司的现状.开发,测试人员成天苦于数据没法与客户数据同步.打个比方说就是”又要马儿跑,又要马儿不吃草”. 简直可以列为外包的十大弊端之首了, 呵呵……

作者: innovate511 20071119

所以项目需要不断和现场的人员交流，保持信息一致。不过在某种情况下，我也没辙了，那就是公司要保证现场人员的权威性，但他们可以经常改你的设计，让你重复劳动。这都不说 了，关键是设计让你感觉很……

就像我提到的，对于数据区间范围参数表的设计（如20

我想只有两个方案了，要么公司请一群新手，只会coding的人做项目，这样绝对能保证现场人员的权威性。要么现场的人是行业内高手，做出来的东西至少没有明显漏洞，基本都合理，这样也没话可说……呵呵。

作者: Steven 20071120

第一种方案不可行，新手累死，现场人员还抱怨死，现场人员本身就不是很理解项目的技术，思路，方法，还要他跟一群新手交流，不知道会怎么样的一塌糊涂，一个项目没有几个明白人是很难搞的。

作者: 3stone2004 20071120

“只会coding的人做项目”-这显然也是行不通的, 像电信,银行这些业务逻辑巨复杂的行业,coding跟本是一个最简单的工具,新手恐怕是要现场人员手把手的教了.正如steven所说,现场人员,developer全都抱怨声一片, 效率奇低。

作者: innovate511 20071121

我这里简单介绍下国际IT服务巨头们的ETL/Reporting开发的外包。大家就知道低层开发人员是否需要了解复杂的业务了。

1. onsite方先做基本的系统/模型和ETL架构培训，有了这些基本认识才能开始干活。

2. onsite会开始安排ETL任务，开发人员和测试人员都需要学习并深刻了解任务，并由TeamLead对开发和文档Review，如果有任何疑问需要即使开会交流。

3. 测试人员会根据对任务的理解进行详细测试，并提交测试结果和文档。

4. onsite方会自己测试一遍，再放到生产系统运行。
至于这个任务，必须是很详细的内容，细致到对哪个库哪个表哪个字段的处理，输入输出明确。
所以很多发达国家的ETL/Reporting开发工程师对业务只有表皮了解，但精于那套开发机制。

作者: Steven 20071121

我很怀疑这个任务能详细到什么程度，以及所做的培训能达到什么效果，当然如果说这底层开发人员只是说他在这个流程中处于最低端，分工而已，而不是说他这个人在开发思想，技术能力上处于比较初级的话，我觉得还是没有问题，否则执行起来也比较困难。

作者: innovate511 20071121

这种外包开发技术含量可高可低，取决于外包策略。但如果批量进行开发的话（上百人的团队开发不同的项目），确实可以节约成本，特别是节约发达国家的开发成本。

至于细到什么程度，你看过他们的系列文档就知道了，非常地细致，搞这些项目，肯定会很多人骂死这个文档体制，而且会厌烦无休止地电话会议了。

作者: Qing 20071121

说到这个，我到想起以前遇到的一个情况。

以前我们采用集中式开发的方式，在公司设计etl，然后现场部署。然而，etl这种东西，离开了实际环境，处理大数据和处理小数据遇到的问题根本就不一样。因此，到了现场，往往，这些etl会被做很大的修改。所以，即便家里的人测试通过，也还是不行啊。这有什么办法解决呢？

作者: Steven 20071121

处理大数据和处理小数据有不同的方法，但这不是关键，关键在于是否对每个问题都进行了最优化处理，这要求设计人员在设计的时候要充分考虑到每个解决问题的方法里面所涉及到的技术有那些，择其优而用之，但这样的要求对于设计人员来说是否要求过高了，所以我怀疑innovate511提到的任务细化程度，可能对任务描述的很明确，数据流向也很明确，但最关心的如何做，以及在不同环境下又应如何做，这些可能不会描述的清楚，我现在想要求系统架构师、设计师尽量地在做设计时候考虑到每个技术的实现细节，尽量通过多比量，找出最好的方法，在写技术方案的时候写的明确，这样coding的时候也比较明确，不会让coding的人找不着北，要完成这样的要求，我想让架构师尽可能地设想条件，设想实现的技术可能性，然后给他配合几个coding人员，帮助他去验证他的想法，以此在做分析的时候把详细设计设计好了，不知道这样的工作量在前期会有多大，对于一个bi项目来说，这部分工作占整个项目的百分之多少？

作者: 3stone2004 20071121

这个观点我不是很赞同, 就算架构师的设计做到再完美, 在真正实施的时候,还是会出现偏差,一个方案, 不经过真正的或模拟的实施, 不可能不出错.我认为比较好的办法是必须有一套与现场环境相同的测试系统,相当于是现场环境的copy, 数据可以不是实时的,但要安排好更新周期.这样效率将会大大简化.不过缺陷就是对这个虚拟的环境的建设和维护也需要投入相当的人力和物力, 但从长远来讲,绝对时利大于弊。

作者: Qing 20071121

就像是演习和真正战场的样子？

昨天在出租车电视上看到广州水警演习，几十艘快艇，三架直升飞机追捕胁持人质的逃犯，他们在珠江上玩的挺快活。还搞出很多花样出来，比如将人质推倒水里，考验水警的水中救人技术。还有将脏物丢到水里，考验人家的潜水技术。最后还来一出狗急跳墙，让水警演练水中搏斗。当然，最后自然是水警大获全胜，未损一兵一卒。可是真实的警匪对决恐怕是非常残酷 的。

当时我就想，这个匪徒真够傻的，要逃也不能走水路啊，珠江那条小河，直不笼统，太容易被截住。汽车，也不够好，容易堵车。最好是搞辆直升机。要是那样的话，水警该怎么办？只好望机兴叹了。

我觉得在我们一般的项目环境里面，不光是外包，还是那种集中式开发的模式，有些困难：

1、搭建”演习”环境成本较高，一般集成商受不了。长远看来？恐怕未到长远的时候，集成商已经歇了。

2、缺少经验丰富的架构师。对于真正环境中会突发什么可能的问题，经验也许是更好的解决对策。但我们缺少这样的人。从成熟的服务商那里借鉴架构技术和经验，应该是一条路。

作者: innovate511 20071122

有两种情况，一是对大数据项目，测试环境模拟部分真实环境，也就是加入压力测试环节。如果你公司设计的ETL连压力测试都不到位，当然会造成很大的麻烦。还有部分中型项目，数据量一般，如果有条件的话全部模拟。

如果项目周期非常紧凑，那就根本不能用onsite+offshore的方式了，因为没时间offshore->onsite->客户/第三方这种多层交流关系。

既然是多层合作关系，那么他们的关键环节就是解决信息一致性的问题，但offshore的人再怎么着也无法像onsite的那样了解客户了解需求，于是文档细致化以及QA机制非常重要，如果offshore不了解ETL的是实质内容，onsite不了解offshore开发的细节，那将是可怕的。可以这样说，一般这种项目要保证质量，写文档/交流/确认的时间会超过实际开发和测试的时间。

所以我不建议没有成本原因而使用offshore的方式开发，比如做国内项目，就算都在现场开发，成本也不会提高太多（国际知名厂商除外），而国外为了节约成本，那就另当别论了。不过设计、编写某些很具体的代码（onsite没足够人力编写一些文档齐全的代码的话），可以在公司做这些事情，帮助onsite的人做得更好。