僵尸大会 ---敏捷学堂 开会法 (二)
每日例会变僵尸大会了
需要改变事项
去掉例会两个字 ,让员工引起重视
将会议室的名字改成例如:“战场” “集中营” “根据地” “梁山” “阳台” “茶馆” ………………
每日例会时间不要选择 早晨,需要改变开会时间
利用白板,让员工注意白板
a.重复汇报没有解决的问题
b.关注汇报工作问题
轮流主持会议,并做个人会议记录。
根据情况必要做会议记录,汇总个人记录,做有价值记录。
每日会议-初级阶段
a.每天精细计划工作
b.如果实在不能精细化近期1-2周的工作,那么也不必强求,可以每天持续细化
c.每一位都需要精神高度集中,充分发言和仔细聆听
每日会议-高级阶段
a.当前Sprint的计划应该尽量明细,至少要做到近期1-2周的工作时细化的,落实到人头上的,可检查的
b.每日会议讨论重点不是今天干了啥明天打算干啥,而是每一位对照计划和自己实际的完成情况,交流影响当前进度的问题、风险等
c.每一位为其他成员提供解决这些问题或风险的线索,会中不具体讨论解决办法,而是会后相关人员继续沟通
d.提出问题,风险,(多个)解决方案,改善方法
e.有事上奏,无事退朝,无事不说,直接散会
每日会议进阶
在我的项目中经常会每日会议,而且更变态时我会每半天会议!
我为什么要这么变态半天开一次会议呢?
1.每日会议虽然可以让问题存在不会超过1天便暴露,但我仍然觉得1天的时间太长了,我受不了,最多半天我就要发现它!
2.中国教育制度出来的技术性人才,大多是闷头苦干型,有问题喜欢自己解决,有想法不主动提出来。中国教育制度我无法改变,但我必须改变团队成员的这种工作习惯,那么半天会议会比每日会议更加有效。
3.项目的工作是争分夺秒的,我的项目中的工作时间是精确到小时甚至是半小时的。问题如果可以存在一天,那么一天中就很可能至少会有2-3小时的工作时间是浪费的,将来要返工的,如果半天例会一次,这种返工的时间就会缩短到1小时内。
我的项目加班的时间一般不多,很大程度是得益于每日会议甚至是半日会议。其实每半天会议不算什么创举了,只要清楚明白你想要达到怎样的效果,你就可以实践出更多的最佳实践!美剧《24小时反恐》,剧中处理某些突发事件时,那个反恐部甚至是每1小时一次会议!
开发人员需要长时间的独立思考,你可能会质疑:半日会议会打断开发人员的思路,反而降低效率?你也可能会质疑:项目的整个过程都需要半天会议或每天会议吗?
这个问题很好!每日会议或者是每半日会议,并不会在我的整个项目周期中出现,我一般在以下情况才实施每日会议甚至是半日会议:
1.项目初期头绪很多、隐藏问题很多的时候。
2.项目组成员提不出问题,无法迅速进入战斗状态的时候。
3.软件发布阶段,不断地发现bug和解决bug的时候。
一块木头,机械工人,一盘散沙
a.尽早发现问题,减少成本,避免伤经动骨
b.面对面沟通效果更好
c.每天同步一次项目状态
项目失败是有一天一天的问题积累导致的
项目成功是发现问题并合理解决问题的过程,每日修正项目方向
重大问题多修改为突然会议,紧急会议
短时间的半日会议
任何人都可以召集会议,去没有会议角色,在会议上无官职角色,保证人人平等的发言权,忌讳嘲笑等举动。
1.突然会议
当我意识到有危机或隐患需要立刻处理时,我会立刻召集项目会议。
2.任何人都可以召集会议
任何项目组成员遇到问题需要其他人支援,或者他预感到有隐患或危机时,不需要得到我同意,可立刻召集项目组全体或部分成员召集会议,他成为这次会议的领导!
其实道理很简单,就是:发挥团队的力量,尽早发现和消灭问题!在萌芽状态就消灭它,而不是等待问题发芽并壮大到不可收拾的地步。更加不是做鸵鸟,将头埋在沙里,对问题视而不见!
开会的目的是解决问题
Meeting & Conference
Meeting 小会议(规模较小,无角色,有参与感)
Conference 大会议(规模较大,有角色)
meeting:参与人数不多,参与者聚在一起讨论问题,每个人的发言权力是平等的。
conference:参与人数比较多,说话的人占少数,大部分人是听众。例如你参加什么过程改进年会,我在上面演讲,你在下面听,那种就叫conference。
两个词的意义不同主要在于三点:
1.目的不同:meeting寻求各人的意见来达成共识;conference主要是宣讲某些人的观点。
2.参与人数不同:meeting参与人数不多(我建议不要超过7人,5人以内最有效);conference参与人数可以很多。
3.参与方式不同:meeting人人有均等发言权力;conference中演讲者占主导,其他人是听众。
按照上述的定义,你可以看看你们项目中的会议是meeting还是conference?
如果你要打造自组织的团队,那么就必须赋予小组成员权力,让你的会议是meeting而不是conference!而且在meeting中做到每个人都是主角!
避免懒人歪风
他们解决不了的问题都会抛给我,自己也不思考,搞得我频繁救火,感觉很疲惫。-----再进一步深挖此问题
这些项目成员是来自不同部门的,项目经理基本上没啥权力了管理他们,不能影响项目组成员的薪金、奖金和职位升降等。
这个项目小组全体成员并不在一条船上!项目的成败只与PM有关,与项目组成员基本没有关系,项目组成员当然是能少干就少干,能不干就不干了!
敏捷基础,保证我们在一条船上
每日会议的“疑难杂症”
1)项目中是“木头人”太多,除了项目经理,其他人都不说话。
改善建议:让大家轮流做每日会议的主持人。
2)SCRUM
Master不懂具体需求和技术,每天都是他来主持会议。
改善建议:每日会议是“自组织团队”自己开的,SCRUM
Master在一边旁观就可。
3)敏捷教练“书生治国”,只关注理论和敏捷的条条框框,不切合工作实际,每日例会上只顾搞漂亮的燃尽图。
改善建议:项目经理学习相关敏捷知识后兼任敏捷教练,活学活用,不要拘泥于形式。原敏捷教练应该到研发第一线去做具体的研发工作(注意不是敏捷教练的工作哦),获取实践经验。
4)会议中大家只是口头说某某用户故事做完了,但实际完成情况有没有底,事实上程序员的工作质量你懂的……
改善建议:通过测试的用户故事才叫完成了,测试工程师是每日会议的重要角色。
会议中提问题的目的是集合全体智慧来应对这些问题,如果提问题的目的是为了偷懒,那根本就不是这个味了!
这个团队建设或者说团队文化就超级有问题,在这样的基础上,其实无法实施任何敏捷实践。
首先要做好团队建设,否则其他都是虚的;
如果团队建设能做好,那么团队就能自觉解决很多问题,
也很容易实施各种敏捷实践,甚至打造属于自己的最佳实践。
项目组必须是相对独立和有一定的权力,项目经理应该有一定的权力。
至于SCRUM中提到的ScrumMaster有点项目经理的意思,但他是没有行政权力的,仅是充当教练的角色。
问题是:这样的角色在国外可能适用,但在国内如果你没有任何权力,
仅靠人格魅力来带动团队,那要看你的RP了,看看你带领的团队成员是不是都是人格高尚的了。
关于每日会议及半日会议的实践体会,是基于项目组全体是在一条船上的基础上的。
有些事情我们可能是有心无力的,在自己的能力范围内做好事情,真诚地对待每一位小伙伴,做到问心无愧就OK了!
声明:本博客高度重视知识产权保护,发现本博客发布的信息包含有侵犯其著作权的链接内容时,请联系我,我将第一时间做相应处理,联系邮箱ffgign@qq.com。
作者:Mark Fan (小念头) 来源:http://cube.cnblogs.com
说明:未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。如有疑问,可以通过 ffgign@qq.com 联系作者,本文章采用 知识共享署名-非商业性使用-相同方式共享 2.5
中国大陆许可协议进行许可
BTW:哈喽,同学!我叫藤原良木,你叫什么名字……
原文:http://www.cnblogs.com/cube/p/3712991.html