项目管理沙龙第四次聚会纪要模式“快！赶上”和“死鱼”

项目管理沙龙第四次聚会纪要--模式“快！赶上”和“死鱼”

今天聚会讨论了两个模式“快！赶上”和“死鱼”，在 http://book.51cto.com/art/201101/244195.htm 可以看到两个模式的内容。

模式“快！赶上”是一个正模式，也就是好的模式。这个模式里其实讲了两个极端的情况，一种积极前进的“强团队”和一种拖拖拉拉的“弱团队”。与会者对强团队的特点非常有感触，部分参加EAC的与会者认为早期的EAC团队就是一个比较典型的强团队。当时EAC团队在去北京之前，大家都不知道客户的需求是什么，但是到了北京之后封闭开发的那段时间里，形成了一个“客户沟通-分析-实现-客户验证”的一个短促而高效的迭代循环，而团队每一个人都对自己的任务非常明确，弯路很少，即使走了一些弯路，在极短的时间内就可以纠正。EAC的这一段时间，给每一个参加者留下了深刻的印象和回忆。

会中有人问如果谈EAC这段时间的贡献，领导和团队的哪一个贡献较大。有人认为可能会达到1：1的程度，因为别忘记这个是由公司研发的精英组成的团队，而这种水平的团队，即使没有管理，他们也能工作的很好。其他与会者认为组织者会更重要些，作为一个组织的推动者，关键是要先动起来，当整个团队工作形成一种节奏之后，做什么事情都会变得快起来。当“团队的能力”到“领导者的信心”到“客户的满意度”形成一种正反馈循环的时候，团队自然就渐入佳境了。

目标明确是团队能力走强的重要因素（甚至可以是最关键因素），在“明确目标”上，团队领导的重要性毫无疑问是最大的。在如何划定目标范围的问题上，有与会者提出了从微软学习到的方法，就是凡是划定范围，先划定“不做什么”，然后再定“做什么”。在我们前几次的沙龙中经常提到“客户不知道自己要什么，但是很明白自己不要什么”，从这个角度也很容易推断出，先定“不做什么”的合理性。比如我们今天沙龙的目标，首先就是不谈设计，也不谈需求分析。即使不说下去了，大家心里也觉得这个目标比说之前明显要清晰了一些。

这两个模式，都属于团队的极端情况，实践中都很难遇到，大部分团队都是介于两者之间的状态。话题自然就转向了团队管理中如何兼顾和管理那些较弱的成员的问题上。有人回忆了他项目管理生涯早期所遇到的“个性很强”的组员，最终找个机会这个把组员“送”给了其他部门的故事。另外有人也说了一个拙于表达的成员因为不适应敏捷开发的氛围而离职的事情。这时候有人提醒大家，PM在这两种情况下一定要注意沟通，因为无论是哪一种团队成员，他都有自己的诉求和原因，在充分了解对方的诉求和原因之后，才能有针对性地采取措施。不过有人有提醒大家，作为PM，这个时候也受到资源（尤其是时间）的约束，他可能没有时间去慢慢地沟通和帮助后进生提高能力，将这种人请出项目组其实也可能是一种无奈之下的最佳选择。

不过大家一致同意的是，采取敏捷管理方法的团队，无论是团队氛围，还是成员能力培训上，情况都要比传统管理方法的团队要好的多。

模式“死鱼”是一个反模式，讲述了另外一种类似于“死亡行军”的团队形式。和前一个模式相比，他们有一个共同的特点，就是“项目经理”，只要项目经理尽力，“弱团队”和“死鱼团队”都是可以缓解甚至避免的。在如何防止出现死鱼团队的问题上，与会者很快达成了一致，就是“透明度”，无论对于高层的管理者还是客户，保持一定的透明度有利于他们对项目状态的充分了解。当然，如果项目正好用了敏捷管理方法那就更好了，在第一个迭代之后就可以得到工作效率的数据，和工作总量除一下，就得到时间了。只要客户是理智的，看到数据就会说服。接下来无非就是三角关系“功能-质量-时间”中砍掉哪一些的问题了。

但是针对中国特有的“献礼”工程怎么办？这是有人提出的新问题，如果你是修建某个高速铁路的项目经理，客户要求在某个特别的日子就载客运行。你怎么保证不出现事故？讨论的结果是“透明度”原则还是有效的，毕竟每个人都是希望项目往好的方向发展。实在不行，大不了通车之后实现全路闭塞，每次路上只开一辆车。

另外有人举例ZS项目，讲述了客户对项目不管不问的情况。随后总结下来，大家认为这个属于不可抗力。不过我个人觉得这个话题还有继续讨论的空间。

最后总结一下本次沙龙，按照书本的顺序依次讨论所讲的模式效果不好，下一次还是要认真选题才行。