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