由“每周例会”说起

每天项目例会的话，频率太高了，可能会浪费时间，如果每月一次，似乎时间太长了，于是我们往往会“每周例会”。
有一次我参加了某项目的每周例会，开会的时间是周五，会上其中一位项目成员反应了一个问题。
我问：该问题什么时候发现的。
答曰：周一。
我问：周一为什么不说这个问题？
……
这是真实个案，有问题为什么不立刻反馈，要等到例会才说？担心例会上没有东西可以说吗？

如果你们公司实施年度绩效考核，12月你的领导找你谈话，进行绩效考核，你的领导说：小X啊，你1月份做得那个事情不对啊，然后2月份到11月份你每个月都重复犯类似的错误啊！你的领导之前一直没有跟你说过此事，直到绩效考核才跟你说，你会有什么反应？如果因为这样，你的绩效成绩很差，导致你得不到年终奖，你会不会有冲动去掐死你的领导？

绩效考核这个案例是虚构的（尽管是虚构，其实有很多类似的真实个案），但道理和“每周例会”其实差不多，开会到底是为了啥？其实我很反感“例会”的这个“例”字，一旦带上这个字，就很容易认为这是例行要做的事情，这样就很容易导致我们走形式，而忘记了为什么要开会？
不过话说回来，前面提到的“每周例会”个案已经不算很差的了，一些项目的每周例会说的事情是：本周干了啥，下周准备干啥。变成了工作汇报会议！如果遇到这样的会议，我会直接开骂：你这项目经理干什么吃的？大家干了啥你平时不知道吗？下周要干啥，你事先没有规划吗？

为了避免走形式，下面开始我不会用“例会”这个词，为了让你们的会议效率更好，建议不要用“例会”这个词，你甚至可以考虑将会议室改名为“War Room”！每一次会议都是一场战斗，是需要解决问题的！一位同事曾经形容过会议给她的感觉，只有四个字：刀光剑影！会上所有与会者都会投入进来，为了项目的成功各抒己见、据理力争。没错，咱们要的就是这个效果！

每日会议是这样开的吗？

极限编程有每日站立会议，SCRUM有每日晨会，那是不是每天开一次会就是敏捷呢？
有朋友提到他们也实践每日会议，但没啥效果。
我问：你们每天开会是不是说一下最近一天干了啥，接下来了一天打算干啥呢？
答曰：是滴……
那自然没啥效果了，这样就变成工作汇报会了，而且更严重的问题是：敏捷开发是今天计划今天的事情，见一步走一步的吗？
极限编程中的小版本发布，以及SCRUM中的Sprint（冲刺），其实就是一次迭代。在某一次迭代中的工作应该是事先规划好的，绝对不是见一步走一步的。每日会议完全没有必要说那些大家都知道的事情，说废话可不是敏捷的初衷。

每日会议应该怎样开？

每日会议应该重点说以下有价值的内容：
1.有什么问题、困难、风险影响你当前的工作，以致不能按照既定计划进行。
2.有什么问题、困难、风险会影响当前迭代的成功？
3.有什么问题、困难、风险会影响项目的成功？
4.当前计划是不是已经或者可能不合时宜了，需要立刻更新或改进？
5.有什么做法或建议可以让项目更加成功？
简单说，每日会议主要是用来让你提出问题、困难和风险的。

每日会议可以让问题隐藏不会超过24小时，并且可以让你的工作及时获得其他成员的支援！这是“白痴”也懂的道理：问题早一点暴露和解决，将会节省莫大的成本。可惜我们往往是为了节省开会成本，日会变成周会甚至是月会，看上去节省了不少开会时间，但项目的问题就在你的姑息下滋生和蔓延，最后可能会要了项目的命！任何项目都会存在大量的问题，如果说你的项目没有问题，那么你要警惕了，没有问题是最大的问题！不是你的项目真的没有问题，而是你们连发现问题的能力都没有了！质量是需要投资的，每天会议就是一种投资。

敏捷开发绝对不是今天计划明天的工作的，要保证每一次迭代都能成功，那么工作就必须落实到每一天。每日会议是保证计划有力执行的重要手段，将项目的情况每天都可视化地展现在所有项目成员面前，让我们一天一个脚印、踏踏实实地将项目做好。

让项目组全体成员明白为什么要每日会议和如何每日会议，这样每日会议其实很容易做到很有效的。每日会议无论是站着开还是坐着开？是早上开还是下班前开？要用白板还是用投影？等等这些都是形式而已。开门见山，抓住要害，必要时要做书面记录。

每日会议进阶

在我的项目中经常会每日会议，而且更变态时我会每半天会议！
我为什么要这么变态半天开一次会议呢？
1.每日会议虽然可以让问题存在不会超过1天便暴露，但我仍然觉得1天的时间太长了，我受不了，最多半天我就要发现它！
2.中国教育制度出来的技术性人才，大多是闷头苦干型，有问题喜欢自己解决，有想法不主动提出来。中国教育制度我无法改变，但我必须改变团队成员的这种工作习惯，那么半天会议会比每日会议更加有效。
3.项目的工作是争分夺秒的，我的项目中的工作时间是精确到小时甚至是半小时的。问题如果可以存在一天，那么一天中就很可能至少会有2-3小时的工作时间是浪费的，将来要返工的，如果半天例会一次，这种返工的时间就会缩短到1小时内。

我的项目加班的时间一般不多，很大程度是得益于每日会议甚至是半日会议。其实每半天会议不算什么创举了，只要清楚明白你想要达到怎样的效果，你就可以实践出更多的最佳实践！美剧《24小时反恐》，剧中处理某些突发事件时，那个反恐部甚至是每1小时一次会议！

开发人员需要长时间的独立思考，你可能会质疑：半日会议会打断开发人员的思路，反而降低效率？你也可能会质疑：项目的整个过程都需要半天会议或每天会议吗？
这个问题很好！每日会议或者是每半日会议，并不会在我的整个项目周期中出现，我一般在以下情况才实施每日会议甚至是半日会议：
1.项目初期头绪很多、隐藏问题很多的时候。
2.项目组成员提不出问题，无法迅速进入战斗状态的时候。
3.软件发布阶段，不断地发现bug和解决bug的时候。

除了半日会议这个变态做法外，我还有其他“另类”的做法：

1.突然会议
当我意识到有危机或隐患需要立刻处理时，我会立刻召集项目会议。

2.任何人都可以召集会议
任何项目组成员遇到问题需要其他人支援，或者他预感到有隐患或危机时，不需要得到我同意，可立刻召集项目组全体或部分成员召集会议，他成为这次会议的领导！

其实道理很简单，就是：发挥团队的力量，尽早发现和消灭问题！在萌芽状态就消灭它，而不是等待问题发芽并壮大到不可收拾的地步。更加不是做鸵鸟，将头埋在沙里，对问题视而不见！

回到原点——为什么要开会？

有朋友在群中提到，他们项目基本不需要开会，因为平时就把问题给解决了！
我觉得这实在是太牛了！说到底开会只是一种形式，问题是我们开会的目的是什么？如果不用开会能用更简单有效的办法达到开会的目的，那么开会干嘛？回到这个原点，我们自然就会处理很多项目中的问题，让会议更加有效甚至不需要会议！

当然有些沟通是必须通过会议来进行的，目前可能我们暂时没有办法完全不需要会议，那么必要的会议是必须的！译作会议的英文单词有“meeting”和“conference”，你知道这两个英文单词有什么不同意思吗？
meeting：参与人数不多，参与者聚在一起讨论问题，每个人的发言权力是平等的。
conference：参与人数比较多，说话的人占少数，大部分人是听众。例如你参加什么过程改进年会，我在上面演讲，你在下面听，那种就叫conference。

两个词的意义不同主要在于三点：
1.目的不同：meeting寻求各人的意见来达成共识；conference主要是宣讲某些人的观点。
2.参与人数不同：meeting参与人数不多（我建议不要超过7人，5人以内最有效）；conference参与人数可以很多。
3.参与方式不同：meeting人人有均等发言权力；conference中演讲者占主导，其他人是听众。

按照上述的定义，你可以看看你们项目中的会议是meeting还是conference？
如果你要打造自组织的团队，那么就必须赋予小组成员权力，让你的会议是meeting而不是conference！而且在meeting中做到每个人都是主角！

后话：每日会议不会助长懒人歪风？

有朋友提到：他们解决不了的问题都会抛给我，自己也不思考，搞得我频繁救火，感觉很疲惫。
再进一步深挖此问题，发现：这些项目成员是来自不同部门的，项目经理基本上没啥权力了管理他们，不能影响项目组成员的薪金、奖金和职位升降等。
也就是说：这个项目小组全体成员并不在一条船上！项目的成败只与PM有关，与项目组成员基本没有关系，项目组成员当然是能少干就少干，能不干就不干了！

会议中提问题的目的是集合全体智慧来应对这些问题，如果提问题的目的是为了偷懒，那根本就不是这个味了！这个团队建设或者说团队文化就超级有问题，在这样的基础上，其实无法实施任何敏捷实践。曾经在2011广东过程改进年会上，有朋友问到什么东西是最需要首先改进的？我提出的观点是：首先要做好团队建设，否则其他都是虚的；如果团队建设能做好，那么团队就能自觉解决很多问题，也很容易实施各种敏捷实践，甚至打造属于自己自己的最佳实践。

本文关于每日会议及半日会议的实践体会，是基于项目组全体是在一条船上的基础上的。如果目前你的项目组还不能坐在一条船上，那么请参考一下我在CSDN上已经或即将发表的关于团队建设的文章。

但要提到的一点是，项目组必须是相对独立和有一定的权力，项目经理应该有一定的权力。至于SCRUM中提到的ScrumMaster有点项目经理的意思，但他是没有行政权力的，仅是充当教练的角色。问题是：这样的角色在国外可能适用，但在国内如果你没有任何权力，仅靠人格魅力来带动团队，那要看你的RP了，看看你带领的团队成员是不是都是人格高尚的了。

如果你对敏捷感兴趣，欢迎关注我的“敏捷学堂”系列网络直播课程：（免费滴）
http://www.duobei.com/room/2805475316

作者：张传波

创新工场创业课堂讲师

华为某团队高级顾问

《火球——UML大战需求分析》作者

www.umlonline.org 创办人