项目管理沙龙第二次聚会纪要

项目管理沙龙第二次聚会纪要

本次话题依然集中在敏捷方法和传统项目管理的问题上，在两次聚会之后，一些概念正在渐渐地清晰。

有人提出，如果传统项目管理方法将敏捷的一些做法接受过来，是不是也会变得敏捷起来呢？在讨论中大家发现敏捷的一些做法原本就是早已存在的一些通用的做法，例如头脑风暴、集体评估story的点数、定期的回顾总结、团队工作等，这些做法传统项目管理方法也在做，但是为什么效果不如敏捷呢？关键还是在于敏捷和传统方法的本质区别：后者认为人是需要监管的，需要一个项目经理去监督他们，不让他们偷懒，并需要别人指导项目组成员如何去工作；敏捷的理念正好相反，它认为人是可以激励的，项目组成员天然就有一种保质保量完成任务的愿望，管理者只需要引导他们。从实践来看，用传统方法管理项目，始终无法做好项目规模的评估和进度预测，但是在使用敏捷方法的两个迭代内就可以轻松得到，这个也是我们敏捷实践中得到的最让人惊讶的成果。

传统的项目经理需要很高的能力，他们首先需要能够准确评估每个任务的规模，其次需要及时跟踪项目的进度，还需要收集项目过程中的数据，以便进行评估和预测。另外，他还需要和客户沟通，确保需求的稳定或及时提出需求变更请求，然后定期填写一大堆的报告和表格，向不同的人报告 ... 。有人认为敏捷方法对项目经理的需求比传统的方法还要高，而且这么“高”的项目经理几乎是不存在的。可是只要去回顾实际的敏捷实践过程之后，我们就会发现情况恰恰相反，敏捷方法对项目经理的要求是降低了。实践中我们一个之前没有项目管理经验的人，在敏捷团队的项目经理位置上做得很好。如果我们深入地思考敏捷管理方法，就会发现敏捷团队的管理任务其实是分散到了每一个成员的身上，敏捷和传统管理方法相比，就像是拿“分布式计算”和传统的“单机运算”相比，结果也当然是一样了。敏捷的项目管理力度其实比传统的指令式项目管理方法要高，但是平均到每个人身上的管理任务却比传统的项目经理一个人要低很多。这不正是我们经常谈论的“负载均衡”吗？

与会的嘉宾们一致同意敏捷的一个缺点，就是容易“只见树木不见森林”，认为敏捷团队中依然需要有设计师这样的角色去关注整体架构的实现和演进。

在谈到人员能力问题的时候，我们提到了“检查表”。大部分人都没有关注检查表这个东西，而事实上，检查表是一个公司管理能力的直接体现。一个管理稳定的公司，必定有很多“检查表”在支撑整个公司的运作。简单地通过“检查表”的形成过程，我们就可以了解到这个“检查表”的价值所在。首先公司在实践中得到的经验，会以检查表的形式沉淀下来，并且在实际使用过程中，会逐渐地改进，所以一个公司的检查表肯定是最贴合这个公司实际运作的（因此检查表拿到其他公司去也用处不大，这个也是检查表不为人所知的原因之一了），随后，检查表的使用者只需要直接对照表格内容进行实施和检查，最终就可以把事情做完，或者得到一个评估结果。而且，我们可以看到，检查表的使用者其实并不需要是专家，只要不是文盲就可以了。专家在设计完检查表之后，可以去做别的事情。

最后，我来谈一点沙龙本身的问题。

本次沙龙的缺席率比较高，没有通知就缺席的人数有两位，也许是国庆长假即将到来的缘故吧。但是还是引出两个问题，一个是共同话题如何提炼，第二个是如何让这个聚会对大家产生实际的作用。但是归根到底有一个问题需要首先解决，那就是需要激情和耐心。沙龙不会承诺给大家什么东西，“师傅领进门”，“修行”都要靠“自身”，何况一个小小的沙龙呢，它只是一个交流场所而已。

对于共同话题的提炼问题，我认为还是需要沙龙参与者之间的频繁交流，要么是BBS，要么是即时通讯会议，或者干脆碰头几分钟也可以，实践中使用邮件讨论的方式证明效率太差，达不到双向沟通的效果。其次对于沙龙产生实际作用的问题，目前来看有如下几种：集体阅读，实际案例分析，提问。目前候选的图书有《项目百态：深入理解软件项目行为模式》，如果可以找到电子版，我们可以从中选择几个典型案例来讨论一下实际的应对方式。