|
|
<引用>9 X$ G' E" J3 A0 `' `+ H
大约两个礼拜以前,一个机会来了,一个竞争团队的一个成员在经历了两次延期以后,终于交付了自己的产品,于是QA团队来测试。测试发现,到处都是问题,于是这件事就被一些人蓄意给闹大了,捅到了比较高的层次,以至于那个团队自己是撑不住了。客户决定,这件事邀请我们介入,于是作为技术负责人的我就责无旁贷地参与了进去。经过阅读和测试对方的代码,我写出了一份长达三十几页的报告,按照这份文件,这个产品从高端设计,到模块划分,到数据库,到具体代码实现,再到单元测试,可以说无一是处,于是最后的结论是,redo。这份报告一出来,立刻两边就吵起来了,客户表现得很中立,安排了一场辩论,一个题目一个题目地来,于是双方的重量级恐龙们先后登场,这时候霸王龙的作用就体现出来了,尽管表现得很礼貌。结果是对方惨败,这个产品交给我们重做,对方那个惹祸的家伙被开除,立即生效。
; D5 i: M, n9 p, A7 \: ^9 M</引用>
# Y' P% R5 I0 ~6 v# L' ~6 |7 V% R( s, d; i9 F; f0 g0 A9 \
看到这段挺意外的。干软件这些年参与的技术决策辩论不少,但如果双方都有正常以上水准的技术实力,那甚少有能清楚分出胜败的,企业应用开发就更是如此。原因是更多事情不好量化,能掰扯的地方太多。拿来两个设计方案,哪个方案“面对需求变化时更有弹性”?“可扩展性更好”?“维护起来更容易”?很难确定性地证明。大多数情况下,我旁观或者参与的这类辩论最终实际上变成了办公室政治角力,拚的是哪边后台硬关系铁。除非有一方实在技术实力薄弱,被人揪出弱智错误,又或者这公司繁文缛节 style guide 一堆,一方仗着熟悉规则用条款拿人,否则这技术辩论能分出胜负的真是少之又少。
& J' d* y' f: `
, _# W# N9 F% x0 z/ Z R9 o老兵同学,能否稍微讲讲你是怎么干净利落地驳倒对方方案的?很有兴趣啊! |
|