敏捷转型的坑和敏捷教练的感悟（随笔）

蹚过去和还没蹚过去的坑：

第一坑，没认清常态 - “不配合”才是常态。

第二坑，自己的心态 - 专家的技能&教练心态。

客户需要“治疗”，我是专家，这样的心态基本是不工作的，好用，那是运气好。有时候能爬出来，有时候还爬不出来呢。

第三坑，只顾敏捷导入，忽略了产品经理的诉求，是安全，还是业绩，还是什么？

做了别人的敏捷教练，忘了做自己的敏捷教练。

第四坑，敏捷导入的不够-导入的知识面以及导入的渠道不够宽。（产品经理导入没成体系）

业务方对敏捷误解的坑，敏捷不只是项目流程管理，敏捷可以从处理需求开始的，敏捷也不是业务方频繁更改需求的理由。

个人思考：是否需要帮产品经理在整理一套流程，工具之类的 - 把所有产品经理用的单独抽离出来？也是某日教练圈活动听说产品经理课程这边真的要做的投资分析等各个维度。当然有些东西应该是一个合格的产品经理自备的技能。

第五坑，没有正式介绍敏捷教练的工作方式-后续补上了

讲出去的教练技术，讲出去敏捷教练如何工作 - 很重要！！！

如何驱动团队的最佳状态？......

敏捷转型的背后其实是组织的变革，是组织文化的变革。

第六坑，一入敏捷教练深似海。时间，精力，金钱。

LeSS 3天, A-CSM 2天, CSP-SM 3天, SPC 4天, 埃里克森 I II 模块 8天, ACP 4天, SA 2天, SDP 2天CSPO 2天, 埃里克森卓越团队教练 3天, A-CSPO ,其他读书时间

---

领悟 1：

大道至简

大道至简意味着“少而精”，博大精深意味着“多而广”，大道至简与博大精深是一对矛盾，是一体的两面。大道至简与博大精深是可以转化的，大道至简往往要博采众长，与其他专业融会贯通。仅仅融会贯通又会造成新的“博大精深”。融贯中西、博采众长只是基础，还不是大道至简，大道至简必须再整合创新，跳出原来的框框，去抓取精髓，抓住要害和根本，挥动剃刀，剔除那些无效的、可有可无的、非本质的东西，融合成少而精的东西。所谓“为学日增，为道日减”就是这个道理。

忽然理解了，敏捷教练的推荐书籍里为什么有老子之类的书。

熟练运用底层，然后向“上”探索，才能运用自如，飞花摘叶，信手拈来。

多读多看多听，探索其道，用其道，指引其术，横向扩展，融会贯通。

没有为学日增，就没有为道日减。

教练工具-精通之旅

精益画布 - 九点地图 - 利益相关者

任何一个格子都可以用四个计划性问题去深入探索。

用户故事 - 四个计划性问题 - 人人都是产品经理，都是持续探索用户诉求的过程

教练技术四个计划性问题在用户故事的应用

SAFeDevops雷达 - 平衡轮 - 三阶平衡轮 - GROW模型

六顶思考吗 - 三位置计划法/迪士尼策略 （我们不讨论先有鸡先有蛋的问题）

“六顶思考帽”（Six Thinking Hats）是英国学者爱德华·德·博诺（Edward deBono）博士开发的一种思维训练模式，或者说是一个全面思考问题的模型。六帽法强调“能够成为什么”，而非“本身是什么”，是寻求一条向前发展的路，而不是争论谁对谁错。

学习发展四阶段 - 乔韩窗 - 教练反馈\镜子

修辞学与纵横术

......

领悟 2：

从新学习聆听，会了聴以后开始学说。以为自己会听，会说。然后发现自己，其实不会听，也问不出，问的问题也不是“人话”。

领悟 3:

思维模式的变换，打开另外一条思维模式的链路。思维的逻辑层次，在同一个层面不能解决的问题，试着去从上层去看待问题。可能在不经意间会用到，但是还没有形成回路。

计算机科学中也是如此，业务中也是如此。比如class.object，比如建模类数据项目，下层应用没法达成一致，做上层宽泛标准，向下推进，反向拿数据，提炼最佳实践然后在做下层标准。