求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
敏捷实践:比每日会议更疯狂的半日会议!
 

发布于2013-8-8

 

由“每周例会”说起

每天项目例会的话,频率太高了,可能会浪费时间,如果每月一次,似乎时间太长了,于是我们往往会“每周例会”。

有一次我参加了某项目的每周例会,开会的时间是周五,会上其中一位项目成员反应了一个问题。

我问:该问题什么时候发现的。

答曰:周一。

我问:周一为什么不说这个问题?

……

这是真实个案,有问题为什么不立刻反馈,要等到例会才说?担心例会上没有东西可以说吗?

如果你们公司实施年度绩效考核,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了,看看你带领的团队成员是不是都是人格高尚的了。

 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证
 
分享到
 
 

相关文章
由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   

相关培训课程
统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行

成功案例
某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...