一个idea引发的血案

这是一个关于process复杂度的讨论。来源于同死党pyro和pm done在备份影碟过程中发生重复刻录后的故事。

pm done发布新近刻录的碟片:

• 通天塔   Babel.2006 Xvid 2CD ac3 1.4 424
• 撞车  Crash.2005 Xvid 2CD ac3 1.4 425
• 猜火车  Trainspotting.1996 Xvid 2CD ac3 1.4

lemoon回复：“Faint… 通天塔, 撞车 以前都是刻过的！品质一样！！”

pm done回复：“昏倒。撞车我知道你刻过，这次刻是为了放手边检索方便。可是真没注意通天塔也刻过。”

pyro奸笑道：“嘿嘿，我说过刻碟要申请的嘛…”

lemoon这天心情不错，事情不多，于是有了下面大段回复：“呵呵，现在发生的问题，其实是一个很有趣也很普遍的管理问题：我们是要更多的process成熟度来保证质量 还是少些process，更多依靠个人的成熟度来保证质量？我认为，在团队成员缺乏经验的情况下，应该采用较heavy的process来prevent或discover成员的defect，尽管这常常引起成员的不满，但是当他们看到质量由此而提高时，多半还是可以接受的。在团队成员经验丰富的情况下，heavy的process更容易造成effort的浪费并引起成员的强烈不满，他们会认为这些process是对他们的不信任。这时需要充分利用成员的knowledge并合理的裁减process以减小overhead。裁减的度是最难的，需要在探索中确定。原则是CBA(Cost-to-Benefit)，即采用process带来的cost比发生defect产生的cost要小（越小越好），我们才有必要采用process作为action，而且尽量减小其cost。现在来分析一下这个case中的CBA。defect就是‘重复刻碟’；defect带来的cost就是刻碟时间的浪费（5 minutes?）和碟片材质的浪费(3元一张？)，以及list中碟片的不唯一性（影响可以用mark pink这个action消除，mark pink的cost大概是1-2minutes）。再来看看preventive action，就是增加process-‘刻碟要申请’，它带来的cost包括：1，确定专人检查list并approve/reject申请（需要讨论，effort unknown）2，申请人刻碟前提出申请，并阐述理由，象撞车这种为了放手边检索方便而重复刻是需要特别声明的，否则会被reject(email request effort, various) 3，专人检查list有无重复并回复（2 minute）4，申请人获得approval后才能刻碟(waiting time, 至少超过1天，可能更长，如果有人忽略email的话，当然也可以电话，cost变为电话费）基于这样的分析，我们再来讨论是否需要这个process。小问题，也许这些分析只在头脑中一闪而过就有了结果。实际项目中很多时候需要这样详细的分析工程。CMMI中有个PA叫DAR(Decision Analysis and Resolution)就是专门讲分析与选择决策；在Risk Management这个PA中也有对Action Plan的CBA分析方法。引入工具（比如excel中自动检查并告警重复碟片）可以减小checking的effort，但是，这也是defect发生之后的discover, 而非事前的prevention，除非，在使用nero之前先添加list，这也是个process的变化，effort小很多，主要是习惯问题。其实，刻碟前先搜搜有无重复，也是个习惯问题。习惯好了，就可以简化process了。”

然后pm done：“疯了……就是刻之前search一下子就好啦。很简单的问题，不需要官僚化的。就算search失败，或者蓄意多刻一份，也就是1块钱的事情罢了。虽说email作为沟通不要钱，维持一个制度需要的精力可是比较宝贵的。”

然后pyro也：“刚才晕过去了…看得出有人蹲点时的阅读/思考效率很高…要不找个更复杂点的例子来practice?刻碟子相对太简单了…”

lemoon伤心地说：“不要又昏又疯的，才被manager教育说，细节决定成败；看问题一定不要只看当前，要能抽象出来，看到root cause和本质。看出来了，我们大多数人不是manager的料，，，呜呜。。。”

最后pyro说：“一个idea引发的血案…声讨LM，悼念PM…”