简介
关于ACT的战术导入实践系列，这是第三个版本，我对自己的要求是，不再单纯的展示经验的累积（例如自己是怎么做，有什么心得）
我希望在基于v1.1版本的结构性之上，尝试编写和可视化笔记，让新接触敏捷导入的教练可以更轻松的上手，但同时保持开放的可能性
本文会涉及
- ACT战术手册的保姆式教学应用
- 正模式和反模式的一些总结
- 大量实战应用及图文解答
你将收获一次对ACT战术手册的可视化解读，在一些实践要点上既保留原文，同时备注一些常见踩坑点和策略交流
这个导入实践的系列每经历一个项目都会写一遍，希望对你有帮助
该敏捷实战导入框架基于ACT 敏捷工具箱V1.1版本
F1 痛点目标共识
F1.1 目的：
1. 使得实施过程师出有名
2. 避免形式敏捷（守住部分不适用的敏捷实践无法做出适配）和获得感缺失（没共识的计划也难以认同）
※ 为什么重要：
1. 实施敏捷方法转变客观上存在外部阻力（规则）和内在阻力（意愿）。
2. 师出有名将一定程度上减少外部阻力（即组织授权我做了），通常外部授权和内在意愿是割裂的。
3. 识别团队与组织的进化阶段★对症下药（L1止血、L2凝血、L3造血）
3.1 例如回顾改进和文化塑造就属于更复杂的手段，团队不可能在疼痛剧烈的时候去文化改革。
3.2 编者会尝试先进入“系统”跟着感受一下系统的疼痛感，优先解决有直接痛觉的地方。
3.3 这种处理方式，可以类似于“编者只有在自己难受自己吃药都忍不了的时候才去医院的感受类似，在去医院前更相信这没什么，会强化这只是小事的心理暗示。”
3.4 某些情况下，教练可能不具备太多的时间能持续跟团队共处而获得更稳定的同盟关系，尝试在更早的时候，与核心干系人共识，或准备多套常见分治手段。【如：局部的价值流的改善、会议效率改善..强调对痛点的识别过程】
F1.2 前置检查项：
1. 从整个系统角度识别和确认痛点，目标。【组织工程状态评估问卷 | 组织敏捷状态评估问卷】
2. 明确排序原则，保持痛点、目标有序性。【建立组织级的改进Backup排序原则】
排序陷阱：
1. 排出优先顺序对L1阶段的团队是极其难以接受的，他们无法容忍自己的想法被拆分到第二优先级，或“之后”
2. 同时这将塑造出对内“无法形成排序原则”，对外“无法做标准服务接口”的双重隐患。
3. 理解上下游环节目标、期待、约束和协作方式。【上下游环节访谈】【期待风暴】【约束点】【协作定性】
F1.3 检查项
1. 就关注的痛点、目标的认识与所有人员达成一致。【卡片风暴】
2. 对痛点和目标进行结构化处理，形成唯一、动态、有序的清单。【充分透明的排序】
3. 与高级管理者、业务负责人、团队负责人一起，明确要改进的痛点和要达成的目标的最终内容。【定义验收】
F1.4 后置检查项
1. 结构化的痛点和目标得到了确认。【统一签署】【录像记录】
2. 可视化所有假设、分歧和试验。【If..than.. | But..Problem | And..Sprike】
※ 可选的技法：
1. 名词标签弱化：对于L1成熟度的团队，不建议使用敏捷关键词，可换成团队熟悉的语言模式，先身体践行，再理解，用结果带动意愿。
2. 作战充分可视化：若场地充分，可顺序建立愿景期待列表、组织改进排序列表、协作规则列表、验收条件列表、签署列表、假设分歧实验表等...若场地不足以充分可视，则可选择作战室，或部分关键信息可视，其余信息电子工具化。
3. 关键概念定义：协作中有一些必要的名词澄清（多数时候我们的协作回路遵循了Question->直达Solution的路径）
3.1 Question：疑问（通常由服务使用方提出，考虑多数情况下的协作并未被专业校准，务必进行澄清提炼工作）
3.2 Problem：问题（通常在产品角度指的是更接近于事实本质的问题，一种需要刻意训练，并反复找多逻辑视角切入的产品技巧）
3.3 Fact：事实（一种需要刻意训练，并且在被发现时容易因其易造成虚拟人格毁灭的特质，而易被回避的词语）
3.4 Choice：选择（与被要求、被迫相对，是另一种需要刻意练习的临在状态，同样因其伴随的责任感，而极易被回避）
3.5 Solution：解决方案（因其简单易懂的被教育视作主观能动性的一种技巧"要给方案不要提问题"，被广泛使用，过早使用有害）
※ 编者实践：
1. 编者刚开始接触敏捷实战应用时，最不想关注的就是F1的目标对齐部分，因为去说服管理者和同事，是一件让我感到畏惧和不适的过程，仿佛大家对简单明确的道理置之不理般不可理喻。通过一段时间的实践，回过头来看，其实F1的对齐才是重中之中，不管你要做什么，你都需要稳固的同盟关系。而共识和可视就是最有效的提升关系的手段。
2. 关系∞，是做事中的【原子性手段】
3. 通过共识目标，让编者与团队管理和核心成员在较早时就达成较好的信任基础。
F2 思路方案共识（How）
F2.1 目的：
1. 实施思路和方案获得高级管理者和团队的理解和认可
2. 建立不同级别的定期沟通和校准机制
※ 为什么重要：
1. 痛点Problem可能被共识后，但行动Action不一定也会共识。
2. 大家都怕上班迟到，有的为了避免堵车使用地铁，有的为了避免换乘步行路段而选择开车。
3. 这就深刻反应了即使目标一致，做法可能天差地别，此时依旧不能简单的认为自己的方法就是最好的。
4. 通常共识痛点手持“尚方宝剑”后，容易进入我的方案就是最好的方案陷阱中。
F2.2 前置检查项：
1. 访谈高级管理者及其助理、秘书等角色，获得多种角度的信息和观点。【组织敏捷状态评估问卷】
2. 访谈团队负责人、业务负责人，了解项目/产品背景、组织架构、管理方式等信息。【组织架构图、影响力图】
3. 访谈团队核心成员，从整体的视角了解团队的状态信息。【心智、方法、结构、文化】
4. 与高级管理和、团队负责人、业务负责人、团队核心成员等提前沟通和确认实施思路。【实施思路】
F2.3 检查项
1. 沟通并校准高级管理者启动转型的目的和期望。【目标期望校准】
2. 确认（痛点）改进和（目标）提升的范围和影响【预测性】
3. 结合多种视角制定整体实施方案【分角色痛点方案设计】
- 大Leader关心的：
- 技术Leader关心的：原有的模式改变、怎么证明迭代的节奏
- 产品Leader关心的：需求是否能够排入
- 过程改进Leader关心的：
- 研发关心的：不要又搞一些没用的方法论
4. 确定实施（试点）团队【★关键战略点】
4.1 明确预期效果，制定时间表和度量策略【时间计划表、度量指标定义与使用】
附时间计划表
4.2 明确需要高级管理者支持的内容【启动背书、周期参会、定向鼓励、资源支撑】
5. 制定敏捷教练中、短期目标
6. 制定与高级管理者、业务负责人、团队负责人、团队定期沟通的校准机制【沟通频次】
F2.4 后置检查项
1. 即时通讯工具互加好友【微信，从同事到朋友】
2. 可视化高级管理者、业务负责人、团队负责人、团队成员沟通渠道和校准机制。【仪表盘、看板、月报】
3. 可视化实施思路和方案【里程碑、路径图、宣贯海报】
※ 编者实践：
1. 编者做的时候F1、F2，是最抗拒的时刻。因为对我来说最不受控，要去说服别人。要去想办法和别人共识。而更舒适的方式当然是希望自己说了就算，说了就能做。事实就是会迟到，但不会缺席。这种强推方法的理解，在中后期就会收到反噬，造成中气不足，后继乏力。
2. 因为缺乏早期设计的中长期目标，一旦短期目标达成，团队也将陷入没有锚定的状态，此时航行中已经很难掉头，也将缺乏大规模讨论计划的心境。
3. 锚定 ∞ ，是做事中的【原子性手段】
3. 解决WHY，确认HOW，关注HOW是达成信任的必要内容。
F3 形成领导力小组（Member）
F3.1 目的：
1. 树立推进实施的中坚力量，促进团队提升自改进能力【同盟关系】
2. 对齐实施思路，促进实施方案中关键行动的有效执行【行动支持】
※ 为什么重要：
1. 战术同盟关系是启动阶段最为重要的关系，你需要得到核心团队的坚实支持来扩大影响面。
2. 话从教练口中说出来和从同盟行动中透露出来所带来的影响和感受都是巨大差异的。
3. 尤其在草根教练的积累阶段，并不具备很强的领域背书能力来提升基础信任，更要加强同盟关系。
4. 领导力小组犹如组织的第二增长曲线，可经历初始化、酝酿、外包、验证、新团队..等步骤，逐步淘汰老人（不适应的），聚合新人。
F3.2 前置检查项
1. 团队负责人配合制定领导力小组初步名单【候选人名单List】
2. 访谈领导力小组成员，沟通实施思路并确认参与意愿【澄清以明确意愿】
3. 完成领导力小组培训【敏捷导入 | 领导力相关培训】
4. 确定培训时间、场地、发出培训邀约【工作坊设计 | 可视化 | 下午茶 | 目的共识】
F3.3 检查项
1. 确定领导力小组人员组成、运作模式和规则
2. 实施领导力小组培训，包括但不限于以下关键点
2.1 敏捷思维（PART1）
2.2 工作项准备状态（沙子、板砖、钻石）【沙盘工作坊 | 深刻理解就绪交接概念】
2.3 领导力小组职责
2.3.1 团队工作流程和标准
2.3.2 改进与优化
2.3.3 人员动态调整
2.3.4 领导力小组运作机制
3. 召开启动会议，正式介绍领导力小组，全员宣讲实施思路和方案
F3.4 后置检查项
1. 所有团队成员理解领导力小组的愿景、目的、职责
2. 可视化领导力小组的初步行动项
3. 可视化领导力小组定期学习与调整的机制
4. 可视化达成共识的团队规则 【通过适当的可视化引导来帮助团队进入状态】
※ 可选的技法：
1. 团队级开脑工具包：拼图寻宝（视角）、硬币游戏（流动）、看板沙盘（全局流动视角）
※ 编者实践：
1. 领导力小组通常需要包含各类核心角色，一些情境下，高层管理可能回想塞入更多的人，这里需要充分的做访谈后由教练来进行判定。另一些情境下，可能核心班子可能凑不出完整的价值流角色，则需要在缺失视角上有更多的辅导。
2. 领导力小组是团队自组织的催化剂，促进团队自组织模式的形成，也是教练退场的有效保障。教练需要通过退场来验证模式运行的有效性。
3. 培训 ∞ ，是专业做事中的【原子性手段】
共创
1. 通过学习和行动来试下一个又一个目标是重要的【结构化可视化目标也很重要】
2. 共创是通过实现目标来促进团队进化的循环，由无数调整与反馈闭环组成【飞轮效应、评价体系转变】
过去，我们只有非常粗颗粒度的成功或完成定义，例如完成交付、客户表彰、经济认可，这些环路受制于客观条件，会一直让团队悬于半空，让我们很难有机会落地感受，我们需要更多重新开始的机会。
例如：分开交付多个迭代、庆祝失败仪式、回顾会议、POY卡牌
庆祝仪式设计
1. 要求有30s
2. 每个人都需要参与
3. 有声音、有动作
3. 从组织止血角度，只能被强化不能被省略【回顾的第一原则就是尽可能的少改，只改最痛的】
4. 逐渐使团队形成节奏，加速成长，而不是简单粗暴执行条目，是敏捷教练需要持续修炼的内容。
F4 工作项校准（未来）
F4.1 目的：
1. 团队就各个方面的反馈进行沟通并对积压工作项进行校准【Backlog】
2. 团队就下一个迭代的工作项的理解达成一致【Sprint Backlog】
※ 为什么重要：
1. Backlog的概念需要在培训阶段完成，并需要至少完成对工作流的基本认知培训。
2. 没有积压工作项、工作项的状态、工作流，就无法拓展所有职能接口对完工的定义。
3. 这套基本认知将在某些场景下完全颠覆团队对研发流程的认知，所以请谨慎缓慢的铺垫。
3.1 局部最优VS全局最优问题 【计划不变更VS快速消除不确定性】
3.2 职能接口VS价值加工过程 【职能筒仓VS价值流团队】
F4.2 前置检查项：
1. 完成工作项准备状态的定义【DoD】
2. 在下个迭代开始之前完成【滚动发布周期的衔接】
3. 每个迭代可以进行多次，但至少发生一次【Grooming梳理会 | Refine故事会 | 看板沙盘】
F4.3 检查项：
1. 团队关键各方对工作项的准备状态达成一致【需求状态板拖动】
2. 工作项是渐进明晰的，需要关注：
2.1 每个迭代至少能完成1个工作项【可工作可交付】
2.2 识别并记录外部的依赖与相关假设【依赖线标识】
2.3 工作项需要有目的和验收标准【PO定性目标、定量目标、定义验收完成】
3. 工作项准备状态发生变化时，需要关注：
3.1 需要满足团队级工作项准备状态的定义
3.2 进入板砖状态，需要使用数字1、2、3、5、8进行估算【斐波那契数列】
3.3 进入板砖状态，需要经过排序【排序】
3.4 进入钻石状态，团队对工作项的理解需要达成一致【定性，由开发拉动】
4. 对于可能排入下一迭代但未达到钻石状态的工作项，需要明确跟进措施和责任人【风险跟进】
F4.4 后置检查项：
1. 所有工作项已经具备了不同的工作项准备状态【状态标记】
2. 有足够多可供排期的钻石状态工作项【梳理节奏】
※ 编者实践：
1. 业务人员关注目标和效果，而不是实现手段，实践会因为视角诅咒问题，陷入对手段的解释，需要时刻明确目标和结果，并清晰的展示这种手段的影响。
2. 校准什么？业务方和实现方的理解校准、脑中理解与文档的记录校准、未来以迭代为单位的风险校准。
从页面实现向意图实现进化、从头脑记录到文字表达进化、从浑浑噩噩到时间盒管理进化
3. 工作项的风险，估算为8的工作项【过大未澄清】，未描述假设的工作项【把假设当事实风险】
3.接口定义 ∞ ，是专业做事中的【原子性手段】
F5 工作项校准（现在 | 当下）
F5.1 目的：
1. 透明化团队的协作方式，状态机风险【看板-状态板 | 演化板 | 精益板】
2. 促进团队进入协调统一的工作状态【仪式 | 空间 | 停止】
F5.2 前置检查项：
1. 待决策事项已经决策完成
2. 待讨论问题已经讨论完毕
多数时候，惯性还是会把人带到会议上才开始讨论
F5.3 检查项
1. 可视化协作平台（看板，白板）
1.1 所有工作项及其状态都是透明可见的【用户故事 | 临时变更】
1.2 所有团队成员及其状态都是透明可见的【公仔吸铁石】
1.3 所有协作流程及其状态都是透明可见的【流程专项识别工作坊】
1.4 所有瓶颈及其状态都是透明可见【卡片积压 | WIP】
1.5 工作项应时刻保持在最新状态【每日站会 | 实时更新规则】
1.6 协作流程应时刻保持在优化状态【持续演进需要 | 反馈栏】
※Tips：多数时候，会出现以下情况【反模式笔记说】
1. 大家只是站着，沉默不语，通过肢体和沉默的行为来表达态度（看着远方或打哈欠）
2. 大家会提出问题，但并不没有意愿提出解决方案，这某种意义上也是在审视等待教练引导
3. 只有听到铃声时，大家才换缓慢踱步至看板前，并且在没有铃声时默认不开站会
4. 团队成员并不愿意在大庭广众至下，用彼此能听见的声音讲解自己的进展，且面向白板或教练
5. 团队成员撕卡片的手段停留在业余水平，且无视每一次的撕卡片讲解
6. 因为没有呈现其工作流价值，因此尽力选定时间来规避聚集
2. 立会
2.1 工作日商务的固定时间开始，单次立会在15min以内结束【时间盒】
2.2 固定地点，所有成员站立在可视化协作平台前，形成单层半圆【图示图解】
2.3 每个人阐述，昨天和今天已经或将要完成的工作项、对迭代目标的正向作用及遇到的阻碍和风险【进度】
2.4 任何人都可以对任何沟通不及时、信息不一致、理解有偏差的地方进行提醒【安全授权】
2.5 团队在晨会结束前进行简要总结，对当前的协作状态再次确认【话题关闭的过渡用法】
3. 团队日常协作
3.1 可视化协作平台应为团队日常沟通协作的渠道和基础
3.2 所有需要沟通和协调的事项都需要在日常协作中完成
F5.4 后置检查项
1. 风险的跟进措施及责任人等最新状态信息已更新到可视化协作平台
2. 团队状态日报已发出
★ 站会实践：
1. 任何的决定都应该在立会之前做出，立会需要周知决定、同步风险。【沟通前置】
2. 立会可以分为团队级和子团队级，具体视团队规模和组织形式而定
3. 可视化 ∞ ，是专业做事中的【原子性手段】
引发探索的强化手段
1. 鼓励行为而非鼓励结果：团队主动支持、结对编程、主动找出教练埋坑点、可视化对教练身份的一些以为
F6 成果校准（过去）
F6.1 目的：
1. 持续快速地获得各方的反馈，有效管理交付风险
2. 促进团队形成稳定、可靠的交付节奏
F6.2 前置检查项：
1. 已收集以下数据
1.1 所有的工作项及其状态都是透明可见的
开始：工作项提出的时间点
结束：工作项交付的时间点
1.2 本迭代工作项总规模（根据工作项估算统计）
1.3 待讨论问题已经讨论完毕（根据工作项估算统计）
1.4 生产问题的平均修复时间（Mean Time To Repair,MTTR）
2. 本次迭代成果已展示
3. 各方的反馈信息及新识别的风险
F6.3 检查项：
1. 随时可以使用验收标准对工作项的成果进行校准
2. 以工作项的完成为依据，透过可视化协作平台向各方展示产品/项目的进展
3. 新识别的风险需要明确跟进措施及责任人
4. 收集到的反馈信息需要及时更新相关工作项
5. 检验迭代成果对阶段性目标（实施方案或产品/项目的阶段性目标）的正向作用
6. 根据迭代成果与高级管理者校准实施思路和方案
F6.4 后置检查项：
1. 迭代成果的交付准备工作已完成
2. 根据反馈信息调整实施方案
F6.5 教练提示：
1. 团队要证明每一次迭代都向着期望的目标迈进
2. 用成果来对实施思路和方案进行反馈是非常重要的
F7 成果校准（惯性）
F7.1 目的：
1. 用行动和实践来强化团队持续改进的基因
2. 加速团队自身成长和进化的速度
F7.2 前置检查项：
1. 使用验收标准检核上一次学习与调整的成果（行动类工作项）
2. 更新行动类工作项及其状态
3. 所有团队成员使用回顾调查表进行反馈
4. 用卡片记录本次回顾调查表收集的信息
F7.3 检查项
1.宣读敏捷回顾会议最高指导原则：
2. 新建或更新行动类工作项，并根据工作项准备状态纳入可视化协作平台中
3. 对于新建的行动类工作项，需要明确责任人
F7.2 教练提示
1. 让团队感受到成长与改进的空间
当敏捷教练离开的时候，团队故态复萌。这不是我们期望看到的现象。
我们更加期望看到的是团队能够持续践行调整与反馈的循环，持续改进，这是团队可持续性的体现。
这种可持续性依赖团队的内部传承和安全的外部环境。
如何建立和保持可持续性，是每一个敏捷教练的核心关注点，这是在进入团队并试图形成信任关系的瞬间就要思考的问题。
F8 外部的共鸣
F8.1 目的:
1. 从外部获得认可并注入新的能量，使实施的成果可持续
2. 将成功的经验和模式向外扩展到更多的团队和组织
※ 为什么重要：
1. 一旦获得了团队的L2级别（凝血）的状态，会有一个容易被拉回原有模式的周期。
2. 通过向企业内团队外部，潜在或直接的上下游拉通协作，使得实施效果有更上一层的愿景体现
3. 在刻意练习的过程中，需要避免因新鲜感而维持的假象。
F8.2 前置检查项：
1. 在每一次与高级管理者定期校准时向其展示实施成果【成果数字可视化-定量、定性】
★ 度量实践：
1. 通常在开始迭代（Sprint-1 ~ 2）时，团队会因为从价值流设计、需求移交、质量保证、持续构建等多维度的能力缺失，而呈现无法完成迭代目标的状态，这非常的常见，罗马不是一天建成的，我们需要可视，然后选择最关注的要点去专项改进。
【无意识无能力阶段->有意识无能力】
2. 通常在若干迭代（Sprint-4 ~ 6）时，团队会对看板价值流、站会、需求完成定义、质量移交定义、持续交付的概念得到一定程度上的行为实践，这时候由于大量知识和信息的涌入，会有很大的不确定感。但团队受到明确的目标影响下会开始想方设法完成交付。可以从缓速下降、进度静止、断崖式工作、延期关闭多种情况并行中达成目标。此阶段重点是把抽象概念通过实操落地并给予抓手。
【有意识无能力->有意识有能力】
3. 通常在进行一个季度左右（Sprint-7~8）的刻意迭代练习后，团队的承诺预期交付将与实际交付无限拟合，并细微浮动，这是明显的信号表明团队处于有节奏的交付状态中了，我们的发布承诺可信度也得到了提高。这个阶段我们认为【L1止血的阶段性任务】基本达成，可以认为具备了专业研发交付基础素质。但此时，多数情况下，只是受制于纪律和关注，团队采用了这一类工具方法，并不代表【内心认可】或能【坚守纪律】，此时需要进入专注强化反思的阶段，来消除反弹的力（当改变开始时，人和集体倾向无意识被过去牵扯，通过寻找各种证伪当前状况的证据来找回倒退的舒适感）
实例：
1. 为什么每天要花时间站会，我们自己聊不好嘛？我们的声音吵到别人好尴尬！
2. 为什么研发计划不能一次性的就计划完，非要边做边澄清！
3. 为什么一定要搞这些花里胡哨的规矩，感觉好社死，好尴尬！
4. 为什么迭代开始后就不允许变更了，这些都是同等重要的东西，这轮必须上！
5. 测试难道不该自己找BUG么，延期又不是我们的问题，我们的已经开发完了！
2. 汇总下列信息并形成汇报和宣讲资料【PPT精炼】
2.1 主客观度量数据、成功经验、团队心得等内容
2.2 实施目标、思路、方案和成果的归纳和总结
2.3 实施过程中抽象出的实践和方法【全局方法概念】
F8.3 检查项
3.1 向高级管理者和团队汇报实施成果并获得认可【激励、反馈、减少阻力】
3.2 争取对可持续发展有益的所有支持【站台、招聘资源、协作资源...】
3.3 与组织内外部团队交流经验、实践和方法【外部交流来增强影响力】
★ 业务敏捷 - 看板实践：
1. 业务部门通常也是一部分IT服务的使用者，通常一线对接客户，此时一线客户投诉通过业务部门记录转达，最终反馈至IT部门环路过长未有明确的可视化度量，同时缺乏自身业务过程的改进具体方法。
2. 我们通过将研发领域的方法进行大量的简化，从过程改进的角度辅助业务部门进行流程梳理规划，识别瓶颈点，通过持续看见问题，有意识的改进业务过程，来支持业务部门提升效能。最终一个月后，客户投诉率因得到及时的响应，而有巨幅的下降。
3. 通过和非IT类部门建立链接，建立基于产品的价值流服务体系上的关系基础。有助于从全局上改善价值流动、客户满意度和协作关系。
F8.4 后置检查项
1. 形成可分享的经验总结
F8.5 教练提示
1. 积极鼓励领导力小组进行汇报和分享
2. 争取高级管理者对扩大实施范围的支持和授权
3. 获得外部共鸣的方式包括但不限于：
高级管理者汇报
线上或线下分享
内部团队交流
内部宣传资料
人员培养模式整合
社区或活动等外部分享
F9 内部的传承
F9.1 目的
1. 外部教练离场或弱化存在感
2. 团队自我驱动，实现实施成果的传承和持续发展
F9.2 前置检查项
1. 收集、整理、归纳和提炼实施经验、实践和方法，形成团队规则和模式
2. 确定团队自我驱动方式，包括但不限于
- 团队成员自发驱动
- 领导力小组驱动
3. 确定外部教练支持方式
F9.3 检查项
1. 团队在自我驱动模式下有效地运行
F9.4 后置检查项
1. 高级管理者和团队所有成员通过教练反馈表进行反馈
通过周期性的客观反馈来收获更客观的视角，以帮助教练本身逐步破除知识诅咒带来的视角缺失问题
2. 确定外部教练定期沟通时间表
F9.5 教练提示
1. 通过信任、祝福和期待持续发挥影响力
教练离场不代表支持的结束，一方面需要评估团队是否有独立生长的能力，一方面需要考验传承的力量
在团队中播下一颗种子，然后在未来，他们也将带着这些觉知融入新的生态当中
企业转型，就如同用一各三根手指撑开的橡皮筋。在这个橡皮筋构成的三角形中：上面是领导力，下面是员工，中间是企业的流程。中间的流程即使变化了，但整个企业的惯性还是会把企业拉扯到原来的三角形之中。
★关键战略点：取得战略的目标达成将极大程度上获得正向的反馈。
