[zz]说说"解决问题团队的有效组织"(17章)

转载自：http://shockfly.spaces.live.com/blog/cns!21E9409AD00F24E1!120.entry

还是在EEG的课程中遇到的一点想法, 拿出来跟大家讨论一下.

 

对一个微软的开发人员来说, 在整个项目开发周期中, 也少不了开各种会议. 比如前面提到的代码文档复审会议, 当然还有比如进行任务时间估算的会议、 疑难Bug问题处理的会议、稳定阶段变更管理的会议等等。而每一个会议都要作一个决策出来，至于这个决策如何作出，会议采取什么样的形式，可能每个人都有自己希望的风格，或者也有通吃型，什么风格都无所谓。

 

在进行专家决策的时候，有一种比较知名的方法：叫 Wide-Band Delphi法。培训中也有提到。简洁地说，它有这样一套流程：

 

1.   Select estimation moderator.

2.   Select “expert” estimation group.

3.   Define project scope, proxy, tasks and assumptions.

4.   Hold planning/kickoff meeting

5.   Individual estimators complete initial estimates.

6.   Moderator tabulates.

7.   Report results to estimators.

8.   Discussion.

9.   Repeat from step 5 to narrow to an acceptable range.

10.  Project team review and acceptance.

11.  Re-estimation at checkpoints, as needed.

 

然而就像很多其他的方法一样，这个流程看似清晰，但是真正实际中会用好用差，就有很多“艺术”上的东西。这些“艺术”往往要靠每个人很长时间的个人积累，然而，温伯格在<成为技术领导者>的第17章分享出他的经验，让人豁然开朗。

 

温伯格把会议的组织形式频谱分为4类：

 

1.    独立解决求平均。

2.    投票解决。

3.    强有力的领导者来拍板。

4.    尽可能达成一致意见。

 

温伯格的思想的价值就在于，首先他能像马丁弗洛（重构，企业架构模式等书的作者）一样有一个善于进行分类的大脑，而后他又能针对分出的每一类有足够的经历与经验向你进行分享他的艺术。

 

书中有一个实验，一个小型团队模拟解决一个吉尼斯世界纪录的排名问题。恰巧这个实验，我在上周一个技术培训的间隙，请我得所有学生协助我一起做了一次。分别针对于上面的4种频谱，全部给出结果。最终的结果是投票解决的成绩反而高于后面两种（最后一种应该跟Wide-Band Delphi 很像），也就是说，我们这个临时的团队里，针对于这种问题更适合用投票去进行解决。原因也很容易经过分析并在书中找到，首先我们这个临时的团队，不能一下子识别出谁是见多识广的人，所以强有力的领导者的选择问题上出现问题；其次在尽量达成一致意见的测试时，有太多的折中收回的意见，大家没有能完全靠逻辑和事实来说服其他人，这也犯了温伯格说的大忌。

 

温伯格的东西需要不断思索，不断实践，我会这样一点一滴的继续贴下去，希望我的一点体会对其他人理解温伯格能有一些用途。

 

下面是我们实验时候用的工具,完全模拟温伯格书上的提示: