中兴敏捷转型的2个核心3个阶段和4个故事
2019-12-24
来源：壹佰案例 张莹
清晰化；
实物情节增强了办事成就感；
可视化对周边的影响力辐射；
得领导认可，赢获更多支持；
暴露新问题，引出下步改进。
●回顾会的故事
从纸条变革开始，团队转型第二件最有价值的事是启动并长期坚持召开回顾会议，并最终形成了一周一回顾的持续改进闭环。这是支持团队转型最重要的制度基础，但坚持此会的过程并不容易，它先后经历了多个阶段：
团队领导（研发科长、开发经理）根据需要偶然召开回顾会，队员被动参与。这阶段实际上不能真正及时发现并解决团队问题。
固定节奏的回顾会制度，但话题和改进措施都是团队领导提出，队员被动执行。这阶段很多人觉得开回顾会是在浪费自己时间。
团队领导尝试通过头脑风暴等方式收集队员意见，却发现会议变成吐槽大会，大家提出的都是非常大的全局性问题，而且都认为这是别人的问题，应该反馈给项目，让其他人去改。这时候团队领导也很困惑，回顾会真有价值么？难道让队员主动去考虑团队改进问题，让他们自觉去实践改进真是件不现实的事？
队员开始提出一些自己能够搞定的问题缓解办法，但同时也发现可改进的东西太多，大家根本无力投入实施。团队领导也在思考，队员承诺改进却不去做，难道真是因为大家只习惯于在强制命令，考核督导下做事？
收敛改进项，每次回顾会只选择一个（最多两个）改进。当在改进内容和精力投入间做出调整后，改进之轮终于能比较顺畅的转动。很快我们发现，高频小改进（比如每周半小时会议，设定一个改进项）的效率远远胜过低频大改进（比如三周一个半小时会议，一次设定三个改进项）。
把改进当做两次回顾会间隔之间的小尝试。没有“改进”，只有“尝试”。尝试是中性的，且无关乎好坏，最坏的尝试最多也就是持续满一个回顾周期，而一周一次的高频回顾会议能有效缩短回顾周期，也控制了试错代价。此种信念指导下，大家开始更加放松的投入到各种尝试中。
发现回顾会也是团队协作场域的调节器，不一定每次都需要产生外部尝试动作，因为会议自身就是在不断改善团队的协作。
●防火墙的故事
可视化和回顾会打造了团队持续改进的基础，那进一步，我们该如何去引导团队更好地做事？在很多情况下，当团队领导看到团队层面问题时，会自然而然从问题本身出发，下达命令要求团队执行来解决问题。比如发现团队中存在技术壁垒，特定人只能做特定事，导致团队人力调配受到严重限制时就强制规定队员间结对互备。
但是，这种解决方案实施效果往往并不好，这是因为团队整体利益和个人痛点之间缺少足够联系，队员并不会天然就基于团队利益去做事。在这个问题上，告警团队采用了一种特殊的改进步骤，总结起来就是：
解决集体问题，先跟个人痛点
解决个人痛点，带动行为改变
连续小步改变，导向集体目标
该方法的实际案例，就是团队防火墙的形成过程。当团队发现队员们越来越和特定模块绑定，不管在计划会上估算，还是每日立会讨论问题，每个人都只表现出对“自己模块”事务才关心时，并没有直接下命令去改变这点。而是先访谈队员，了解到他们的共性痛点是对外支持任务多、杂且随时会出现，导致无法专注的编码做需求。
开发经理在回顾会上抛出此问题，引发了队员们强烈共鸣，所有人都觉得应该有所改变。于是全员同意成立防火墙机制，并规定：各开发按月轮流担当对外防火墙，负责全团队对
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
