进入队伍，如何让队伍敏捷地变革？ 有时候，可能需要放手，也可能需要“挖洞”。 怎么“挖洞”，这是很讲究的活计。
在无数电话面试的时候，面试官问：“如果你做我们的敏捷教练，在没有敏捷基础的队伍中，该如何进行敏捷变革？ ”我问。
我说：“我可能什么也不做。 如果必须做点什么，就被动起来，利用球队的失误，做正确的事。 ”
一、融入：别做团队的麻烦制造者
“我最近加入了队伍，发现了很多问题。 怎么让他们听我说？ ”“我觉得学习Scrum很有用，但是团队不太感兴趣。 我该怎么办？ ”
这是我最近参加敏捷分享会后，被几个学生提问的事。
团队变革存在于各行各业，近年来，互联网行业为了适应市场快速变化的环境，敏捷变革成为了热门词汇。 那么，像学生提问的那样，要进入需要变革的旧队伍，必须做什么呢？
与从零开始组队不同，作为打破队伍习惯的csddy——进入队伍时，既是csddy，同时也是新人。
每个人性格不同，产生的气质和团队形成的氛围也不同，之后适当的转型之路也不同。 有千万条路。 绝对不要走故障制造商这条路。
什么是麻烦制造者？
寻找问题，寻找差异是人类的本能。 无论在什么样的岗位上，为了尽快展现个人的价值，都想用各种各样的方法寻找团队内的问题并逐条列出，根据自己所学到的知识在团队内进行大胆的改革，这就是常见的故障制造商。所谓的麻烦制造者，往往是为了找问题而提出问题，而不说目的是否纯正。 就改革而言，遇到问题而来的项目经理、敏捷教练在实践过程中必然会有无形的阻力。 这场抵抗正好来自需要他的对手——队。
为什么？
请考虑一下。 如果说在原本正常运作的团队中，你通过出现发现了很多问题，那么对于团队来说，这些问题的唯一来源显然来自于你。 当球队认为你是问题的源头时，结果只有“对抗”或“隐瞒”两种。
“对抗”可能比较容易解决，但即使是请客吃饭的“资本腐蚀”，也有很多解决对抗问题的方法。
而且，“隐藏”是很可怕的，“隐藏”是隐藏的问题。 这表明表面上认同你，但内心并不认同或抗拒你。 不理解新方法的同时不表明态度，不想告诉别人真实的想法最终很平静，好像没有任何问题。
但是，看不见，问题不存在吗？
所以，敏捷改革变革中最害怕的不是有各种问题的队伍，而是看起来完好无损、没有任何问题的队伍，这往往是敏捷教练和领队最需要担心的。
正面保护
二、形成：战斗前先统一战线
队伍，建立信任是变革的根本，也是敏捷教练的原则之一。
如何避免在融入团队的初期“对抗”或“隐藏”？
在队伍a的转型过程中，第一个月我只做了两件事，观察和帮助：
观察团队中存在的问题，知道会让成员感到痛苦的成员抱怨时，会出现在身边听他们的抱怨并理解，适当提供帮助。 7月中旬，笔者所属的研发团队经历了需求响应迟缓、产品质量问题频发等事件，受到业务方面的压力。 此时作为敏捷教练和领导者，不能直接参与实际的研发。 能做的就是保护队伍。
怎么保护球队？
保护团队有很多方法，比如为团队屏蔽外部压力，消化业务端、上下级之间沟通上的负面情绪，为团队解决支持等。
总之，保护团队让团队有足够的安全感是建立信任关系的第一步。 信任关系也不需要太多华丽的技巧。 只要你用心认真守护球队，努力，球队就会感受到你的诚实，真正建立信任，战斗也就开始了。
三、改革：挖坑是一门艺术
问题不会因为你最初的“不作为”而消失，也不会因为发生了“事件”而有问题。 的暴露正好证明它一直存在，只是碰巧暴露在事件中。在进入小组a的第一周，我参加了包括部门负责人(市场方面)、产品和研发小组在内的月度计划会议。
会议上，产品根据市场提出的需求，洋洋洒洒几十瓶，然后逐一说明需求，希望有上线的时间。 小组成员根据要求的时间，逐一约定。
最终会议结束后，一个月必须完成近两个月的开发量，总任务数的二分之一被视为最高优先顺序，预定月末上线的任务也被视为最高优先顺序。
产品、运营和市场信心满满，开发团队感到困惑。
在整个会议过程中，即使我察觉到了这次会议之后存在的风险、什么样的问题、团队会经历什么样的痛苦，也没有做任何发言。
一些“漏洞”必须跳下队伍本身。
善于撒娇的百褶裙第一定律说：“所有物体都不受力的期间，运动状态不会改变。”
这个定律也适用于人和团队，所有变化的背后都需要绝对的动能。
团队自己犯错，自己经历错误，自己思考问题的几个过程，也是认识问题——良好动能的必要过程。 这个过程我称之为“挖洞”。 (当然，我们知道所谓的“洞”是可以控制的，在队伍能够承受的范围内，队伍在制造炸弹，
还在旁边抽烟围观是不可取的）。延期是意料之内的事
经过一个月痛苦的研发过程，“坑”如期而至，月末统计：
计划偏差：30%需求完成率：60%更新缺陷率：20% (注：每次更新出现BUG的概率)到底是哪里出了问题，是什么导致了理想和现实的差距？每个人都陷入了反思：“是计划管理出现偏差？”“是研发效能偏差？”……
这里我们再回顾一下月初的计划会大家做了哪些事情：
计划太过理想，月初就定好了整月、甚至下月的需求；研发团队估时不准确；优先级概念不清，一半的需求放到最高优先级。四、转变：如何把“瓜”给扭“甜”了
人性的特点：在相同条件下，对一个事物的绝对值估算的误差，远大于具有参照物的相对估算。
在问题出现后，应团队主动的要求，我和团队来了一场全新的计划会。
1. 计划太理想
月初要做接下来一个整个月的规划，在面对时刻变化的市场需求下显然是不科学的，毕竟这不是盖房子。
那么我们就不做一个月的计划。开始建立需求池，市场提出的需求都收集下来，但我们只承诺第一周要做的任务。在开始第二周的工作前，需求池可由产品自由变动（熟悉敏捷的同学可以看出，潜移默化中团队开始Scrum的迭代冲刺的模式）。
2. 无法准确评估期限
原本团队评估模式是：事先安排好所有任务的负责人，再由负责人根据经验预估任务的工作量做出期限承诺。
“太美的承诺因为太年轻”。
日常工作过程中，各种会议、BUG、活动、甚至一次下午茶的打断，都会影响到任务的完成时间，而任何一个不能完成的任务估时，其实都是一种不负责的表现。
敏捷中关于任务评估有两种方式，通过团队商议，这里我们用到了其中一种“故事点”以及“宽带德尔菲”技术：每个故事由产品讲解，所有开发人员各自进行估算后同时展示，差异部分进行讨论，最终得出所有人一致认可的估值。
同时，我们将需求由组长分配，改为成员认领，谁完成了自己的任务，可以立即领取新的任务，这样可以有效消除任务等待的时间。
3. 优先级概念不清
现实环境中所有需求，在产品、市场单独来看，它都是重要的。其实在产品开发过程中一直存在80/20法则（俗称二八定律），80%用户、价值存在于那20%的功能。
如何厘清全部优先级的时效性？可视化、透明化的工作看板是一个选择。
团队A原本使用的是在线敏捷管理工具Teambition，在线工具有它一定的先进性，例如信息、数据的保存，以及异地办公的支持。但实际上仅有项管、研发团队内部使用，这其实是不足的。
正如我们执行的“早会三件事”，信息的可视化、透明化是为了团队能够更好理解共同的进度、确保大家努力的方向是一致的。所以如果学习工具成本过高，那么我们就化繁为简，用最原始的方法——纸和笔。
就这样，我们开始使用了Srcum看板，把所有的任务按照：“需求明确度*市场价值/故事点=优先级”的方式进行排序。最高优先级的任务一定是：独立、可估量、有价值、短小、可测试的（敏捷中的用户故事属性理论)。
将研发过程、进度、目标贴在最显眼公开的地方，新增需求、BUG再用不同的便签区分。无论是集团总裁还是保洁阿姨都能看懂这个团队现在的工作情况——这便是“信息发射源”的最初用法。
五、体系：成功的标志是建立体系
一个好的方法，没有得到有效的执行，它就只是纸上的文字。方法在执行中走了样、贯彻不到位等都是团队转型过程中会遇到的常见问题。
如何有效执行？授人以鱼不如授人以渔。
通过“挖坑”的事件，方法是团队主动和我共同约定而成的，所以在执行过程中，我唯一要做的就是监督提醒与引导。或许初期会去帮忙团队做一些工作，但一定是在一个限度以内。以至于我经常和团队说一句话“哪天我一忙，这些事就要你们自己做了”。
会议一定要领导者开吗？决策一定要领导者做吗？问题一定要领导者发现吗？
其实有时候团队自己做的比你更好。
团队自我思考的养成，是csddy的终极目标，没有任何一个方法、模式是最好的，好的改进需要团队自我持续思考，这也是一个体系建立成功的标志之一，故“以退为进”是在转型中可以适度使用的方式。
改变是一个长远而持续的过程，敏捷开发管理是一个不断迭代、优化产品来应对市场而提升最大价值的开发模式。而我们在帮助团队做转型时同样也是一个不断迭代、优化的过程。
不同的团队有着不同的特点、习惯、问题甚至于价值观，所以在做转型过程中需要注意以下几点：
1）要根据团队实际遇到的问题和选择合适的方法。现如今常用的工具和方法如下：
管理方法：PMP（瀑布式开发）、CMMI、Scrum、XP等；工具方面：Teambition、Jira、TAPD、钉钉等；技术方面：特征驱动开发、测试驱动开发等。在项目管理、团队管理中有着很多成熟的模型、工具，但切记没有任何一件东西是完美万能的，在团队转型过程中需要“逢山开路、遇水架桥”，裁剪和改进（如看板工作流）已经成熟的理论、工具、方法，这是一件很正常的事，正如我常说的：适合的才是最好的。
2）保持倾听，最好最合适的方式往往来自于团队自我的思考与方式，很多时候大力的铅笔要做的只是点题，剩下的团队自己会告诉你。
3）理论知识不在于记、而在于用。如前面说到的用户故事、看板工作流、敏捷迭代，都是在执行过程中实践反向印证了理论的合理性。
4）问题总是一点一点、一次一次浮现，团队无法一次进行全方位的改变，也无法一瞬间就把问题彻底改好。所以需要保持一些耐心，给团队适应的过程，只要持续进步，相信“all is well”（一切终会变好）。
写下这篇的初衷是为了记录，最终受到了“开源精神”所影响，后续将陆续写关于”产品与团队管理方面”的实战经验。
在实践过程中你和团队或许都会遇到无法解决的问题，勿慌：“破万卷书，心中自有青竹”，路行千万里，共进之。
本文由 @西特张 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议