僵尸大会 ---敏捷学堂 开会法 （二）
每日例会变僵尸大会了
需要改变事项
去掉例会两个字 ，让员工引起重视
将会议室的名字改成例如：“战场” “集中营” “根据地” “梁山” “阳台” “茶馆” ………………
每日例会时间不要选择 早晨，需要改变开会时间
利用白板，让员工注意白板
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:哈喽，同学！我叫藤原良木，你叫什么名字……
相关文章
