<引用> & Z1 t6 M, G/ t大约两个礼拜以前,一个机会来了,一个竞争团队的一个成员在经历了两次延期以后,终于交付了自己的产品,于是QA团队来测试。测试发现,到处都是问题,于是这件事就被一些人蓄意给闹大了,捅到了比较高的层次,以至于那个团队自己是撑不住了。客户决定,这件事邀请我们介入,于是作为技术负责人的我就责无旁贷地参与了进去。经过阅读和测试对方的代码,我写出了一份长达三十几页的报告,按照这份文件,这个产品从高端设计,到模块划分,到数据库,到具体代码实现,再到单元测试,可以说无一是处,于是最后的结论是,redo。这份报告一出来,立刻两边就吵起来了,客户表现得很中立,安排了一场辩论,一个题目一个题目地来,于是双方的重量级恐龙们先后登场,这时候霸王龙的作用就体现出来了,尽管表现得很礼貌。结果是对方惨败,这个产品交给我们重做,对方那个惹祸的家伙被开除,立即生效。' m9 Y. O q) w" f- T
</引用> - Q( M( g: q3 \2 o( n- D ! v: B$ B& K' W看到这段挺意外的。干软件这些年参与的技术决策辩论不少,但如果双方都有正常以上水准的技术实力,那甚少有能清楚分出胜败的,企业应用开发就更是如此。原因是更多事情不好量化,能掰扯的地方太多。拿来两个设计方案,哪个方案“面对需求变化时更有弹性”?“可扩展性更好”?“维护起来更容易”?很难确定性地证明。大多数情况下,我旁观或者参与的这类辩论最终实际上变成了办公室政治角力,拚的是哪边后台硬关系铁。除非有一方实在技术实力薄弱,被人揪出弱智错误,又或者这公司繁文缛节 style guide 一堆,一方仗着熟悉规则用条款拿人,否则这技术辩论能分出胜负的真是少之又少。! J# ?! C g' i, y) T
看您的帖子,现在已经有规模效应了。应该不算是散兵游勇了,这样的就可以吃掉或者兼并其他不太大的小龙了。 h% y, y6 k, B" _% j
2 I. k: H- V; s3 h& F, p# h. o
不过正如所有外包公司,技术或者说技术带来的效率 还是非常重要滴 h M% k" D) E. K& q& G, i( d9 A) s1 H! z
我的粗浅的看法是:您的优势是比甲方只招散兵游勇的contract有集中优势,一下子就可以拉上10-20个contractor,省掉他们管理成本。 * ]* U+ D) p o/ c8 I& M# ]7 b( T9 a# N0 M3 c
不知道是不是正确。 5 s' ^6 I, x0 [& h