痛点与目标的共识

大家好，欢迎光临思维发条。我是马菲菲。

我是悟空。

我是王宇。

好久没见。

然后其实最近的话我有收到很多我们act的朋友给我们的一些反馈，说我们手册原来都是每年上课都能拿到一本，然后他们去看里面这样一些内容，然后会反馈这个里面的内容，有一些过于的干了，什么干就是我们干货太多了，导致在嚼的时候有点难以下饭。

意思就是用的过程中可能还需要一些具体的案例，或者说是我们去延展一下这上面的一些说法，我觉得我对这种反馈还是挺共鸣的，因为我自己本身也是手册的一个使用者，那么可能在一些大的共识，然后这样的一些共创和共赢的这样一些过程里面，对于一些具体的实施就总觉得自己想的对不对？

然后有没有其他的同学有其他的理解，然后可以能够进行一些交流，我在想我们是不是可以提供一些对于这个过程中的一个交流，让这个事情显得更加的立体。

大伙怎么觉得。

就是说给大家一些背景，就是说 act手册的诞生之初是什么意思？他为什么会诞生这个东西？是因为之前想有很多的思路方法框架的话，它都是一些原则性的，或者是一些比实践就是更微观层面更高的一个层面的东西。

他有可能从逻辑层面的话讲的比较漂亮，比较美丽，但是的话真正落地的时候的话，一方面它是缺乏这种指导性，我到底怎么做，这是第一点。

第二点的话是什么？当一旦有这种非常具体的指导的话，我们就会发现它其实适用性就不高了，它有可能的话它只能在团队的时候点时间点用 Act的手册的话，就是尝试着去平衡这两个东西，去第一去写就是回到最具体的一些东西，就告诉你就这么做，对吧？

而且要求的话是很明确的。

第二点的话就是说他并不太追求所谓原则上的或者理论上的美丽，因为的话这些东西在我们做这些事的时候的话，有可能的话就会被推翻，很多东西被推翻，也就是我们很高兴的看到 act的手册的话，不停的被自己推翻，这样的话也是我们做这个东西的一个出发点，就是一方面的话回到真正能做的事儿，另外的话能够去能不停的否定自己，能够让大家去做事，但这是背景。

但是真正做出来之后发现有有意思的现象是什么？大家的话确实是这个东西能往前做两步或者是做一步，但人的话需要更明确的更多的知识，他才有理由往前做的更多，你知道吗？这也就是说这也就是为什么刚才的悟空说的，很多人反馈这个手册太干了的原因。

对，因为他们缺乏很多的知识，他只是告手册任务告诉你这么弄，你也不知道为什么这么弄对吧？

然后这种信息也少，所以的话我们其实是可以聊聊这个话题。

我们也知道这个手册是分结构的，我们今天打算重点先聊是哪一块结构。

因为整个的手册分成比如价值观原则，关键的知识点，然后的话是共识，共创共赢，也就是关系让团队进化，然后持续改进几个部分，因为它这样的话分成了几个？

F那就是f1到f9，f是什么？ F的话就是我们的战术关注点，也就是说你作为敏捷教练的话，需要关注到在这些关注点，你可以理解就是我们作为一个顾问或者是一个教练，你的一个关注点应该在什么地方去让这样的一个敏捷在团队中发生？

我们今天的话其实是可以关注到这个共识，也就是关系这部分的预的一个小的一个f叫做f一，叫痛点和目标共识，因为这个东西的话也是很关键的，非常关键的。对，我觉得也很有意思的话，就是说我想快速的介绍一下 f几个f的怎么的一个结构，每一个战术关注点的话，它都有它的目的。前置检查项、检查项、后置检查项和教练提示这几个部分。

对于f一的话的目标的话，就是使实施的过程出师有名，明确目标和目的和目标，避免为了敏捷而实施敏捷。从组织团队的痛点出发，让每个参与人都有获得感，这个东西是我们f一痛点和目标共识的目的。我也很好奇对于你们俩的话，你们俩怎么理解这个f的这个目的，或者你们俩怎么理解这个目标和痛点共识？

好，要我先来讲讲我对这个东西的理解，因为我对这个挺痛的，我在使用这个册子的时候，经常会感觉团队必须得有痛点，原来的话我会觉得我可以按照团这个手册这样的一个框架去在团队里面应用一个我认为比较好的一种敏捷实施的一个逻辑，后来发现很多的实践不一定适合这样的一个团队。

再后来一段时间反思，我感觉是因为我早期没有跟团队达成这种痛点目标的共识。举个例子，例如说我们想要去做这种主干发布，但你会发现其实程序员并不希望持续的每一天在主干上去做这样的提交，因为他们觉得这样很痛苦，自己的到自己的代码会的这种错误会暴露在大家的这种视野里面。对他可能最后有质量，但他并不认为质量是自己的一个痛点，对吧？

然后又或者说我们去做每天的一些展会，但实际上他会觉得太多的开会或者是太多的写日报周报的形式才是他们的这种痛点，所以经常是去自己定义了和假设了一些痛点，然后引领着团队去做这样的一些事情，那么经过这样的一些反思之后就会去做一些调整，但是调整完之后又会有新的含糊，大家好像觉得节奏改进了，然后有一些什么需求沟通关系也变得融洽了。

但是对于这个组织来讲的话，就是做了这个事情好像它背后的收益是什么，然后讲不太清楚，当你讲不太清楚这个问题的时候，做这个事情的长期动力就有一点缺乏，所以我会觉得痛点目标的共识是一个我也特别想在今天去讨论的一个话题。

对的，也想听听菲菲是怎么去理解这个痛点共识的。

首先我看到这一块包括整个结构的话，我最大的感受还是敏捷教练本身，很显然不是仅仅是安装scrum的才就是敏捷教练，对，这首先我觉得这个背景我们要我们要先确定。对于我来讲，我认为敏捷教练你不是到团队去安装scrum的，所以你的目的并不是为了发现大家的早上不开会，看板没人画，不移动就是问题。

所以回到我们整个教练手册里面的最关键的部分就是确定目标是什么这件事儿，我觉得它本身是非常有价值的。

但是事实上在我们遇到的一些比较大型组织的问题的话，就像刚才其实悟空也讲到了，有时候痛点它可能是自下而上的，但是这个目标是自上而下的，所以它之间会有一些不一定能够匹配到的情况，包括作为敏捷教练来讲，我们应该如何引导团队的关键人去理解到底什么是他们想要做的事情，这个本身其实是比较需要一定的技术含量的。

当然作为一本手册来讲，它不可能把解决复杂问题的所有的手段都列在里面，所以我认为我们在这个手册中我们能看到的是最重要的是找到痛点和目标，后面的话你的所有的行动项你都是围绕你的痛点和目标去开展的，我觉得这件事情的价值是非常大的。

在我最近这几两年的工作中，我在一个比大的组织里面，他要去做数字化转型，我们在痛点目标这个部分的分析分解，甚至会长达好几个月就去做这件事情，在可能我整个建设周期才不过3个月4个月，但是我前面论证分析我也三四个月，我就在组织里的做事的方法或者是思路，让我充分的意识到这世界上总有一些团队，他们是很认真的去考虑痛点和目标的，而不是快速的就进入到行动过程中。

就是因为听到菲菲这么去讲的话，我就在想，因为有之前也有机会能看王宇他去做一些实施，他在做有一些实施的过程中，就发现我们其实能够在客户现场的时间会非常的短，这个时候自下而上有一些实践，他需要非常快的去达成一些共识，然后就去做这样的一些行动。

那么有的时候会觉得会议上大家生共识感觉挺嗨的，但是落成了这样的一些目标，好像就有点缺少像菲菲你说的这样子的一种方式，就是花非常多的时间去对齐这个目标，去做这样的一些计划，然后进而去落地。

但因为不同的企业它的这样的一个运行规则和方法是不同的，所以我也很含糊，就是对于我们使用这本手册的同学来讲的话，他怎么样能找到一个锚点，或者说他怎么来去运用这样的一个手册去让他的目标和他的痛点能有所结合。

我多我突然想说几个东西，第一个东西是什么？你看从手册的组织来讲的话，你先得需要痛点目标的共识对吧？然后往下走，123456789，其实不是这样的，也就是说它并不是一个完完全全的瞬时间的，是一个持续的东西，但是我们写东西必须得写成这样的持续的过程。

就像痛点目标的共识，其实它是可能在你做服务的时候持续在校准的，但是他可能在一开始的话会花的时间比较长一点，我是说的这是第一个点。

第二个点我想说的是什么？痛点和目标的话，我们其实都在讨论转型的一个话题，转型转的话，其实跟转型的话，我们有的时候理解一个概念的时候，其实我们就要去从另外一个反向的概念去理解这个概念。

好，我问大家，你们觉得转型的反义词是什么？僵化吗？

固化？很好？

沿用。

也你看你会发现的话，我们从来都没有思考过这个问题，其实的话转型的反面就是说我们并不是说ok转型的效果的反面是什么，而是说转型的这个东西的反面，这是转型是一种手段，另外一种手段是什么？其实就是一次性把这个活干好了，一次性把这个活干好了，是另外一个新团队干的好，他就不需要转型，你知道吗？你就外包，你知道外包其实是转型的另外一个反义词，你知道。所以这样的话我们就要想痛点和目标共识，都是希望这个团队也就是组织内部能够去做一些事情的方式。

这个里边的话就是说有两种力量去推动这个事情，要么就是说ok这个事儿的话已经很着急了，我们很疼痛了，对吧？我们能推动一些事情，另外的一个思路的话是什么呢？就是说愿望。

我特别的想在这地方插句话，我觉得余翔提到了一点就是转型的一个反面是吧？其实刚才于桑讲的时候，我脑子里有一个画面就是大船在一个宽阔的河道上想要掉头，他肯定是逐步挑头过来对吧？它可能是一个过程，我感觉我们其实我们所经历的很多企业在转型，它不是一天两天的事情，它可能是一年两年的事情，对吧？

很多企业做定转型的战略，它可能是个三年战略，那么在这个阶段里面，或者说我们认为如果企业可能它未来的命运或者组织未来的命运，就是持续的去改变他自己要有退化的能力，进步的能力。

那么在这个过程中，对于组织中的个体，包括说任何人员，你以教练的方式或者身份或者心态去工作的时候，永远要首先要觉察到我当前的工作，我的目标，我的痛点到底是什么，我觉得如果我们从这个角度来理解的话，那么教练就不仅仅是到组织里面去搞两个星期，帮你把scrum安装好了，然后就走了。

您安装scrum如果是两周的话，你可能定义痛点和目标可能也只有三天的时间，对吧？所以那可能是个反模式，那么在我脑中，我觉得它可能是一个作为教练来讲，可能是你始终要觉察到我们去有意识的去确定目标，然后去识别准确的识别痛点到底是什么，而且这个东西我认为它是需要内化在组织中的个人的。

你现在我自己的切身感受就是我在企业里的转型的团队里面去工作，我们转型团队里面的不管你是架构师，你是程序员，还是你是一个产品经理，都要求大家有定义目标和痛点的识别痛点定义目标的能力，对吧？比如说你做一个系统架构图，这个系统架构是有变化的，你为什么要变？你肯定是来自于有一个问题要解决，这个问题一定要来自于业务价值对吗？

所以基本上我们现在在讨论的教练手册里面的敏捷教练手册里面的痛点目标共识，它会是一个常态的工作模式。

对的，也就是这种常态模式的话，关键点的话就是在于敏捷教练到底是一个什么专家。我认为的话敏捷教练的话是一个协作的转型，专家这种协作的转型，专家的话就得需要有持续让大家的话改变的这种能力改变的能力源自哪儿？就源自于痛点和目标的这种共识，这个东西就很重要。

因为如果但是另外的与这个东西相对应的话，是很多人就希望知道这个事到底怎么干就对了，怎么干对了，对吧？比如我们讲chrome讲看板，其实很多时候都是告诉大家这个事就这么做，对的，对吧？但是你要知道转型的话，不光可能是要知道怎么做所谓的正确，但另外的话你得走到每一个个体组织单位的这样的里边去催化他们的变化，这个地方的话，所以痛点和共识就是重要了。

你看讲了半天的话，为啥重要？

我也想补充一下，听听完菲菲还有王雨桑说，我和一些用过这个手册的朋友去交流，我就发现大家有的时候会去问，会去问 Why的问题，就是怎么样是为什么要去做这样的一个事情，但是发现可能在组织里面的能量，它的能量层级，在那个位置，当他问完很多个y之后，就发现其实大家找不到这样的一个y我不知道大家是怎么来理解，对于新手的一些敏捷教练或者是刚上手，然后学习用这个框架的同学的话，他如果感受到了这一种gap或者这种无力感，他问下去他发现这个组织好像是没有一个很明确的目标的时候，他们可以去做一些什么，因为这个感觉是有一点抓不住的东西抓得住的，虽然既然他没有什么样的一些目标，我就可以去做一些事情，对吧？

我做了一些回顾，做了一些看板，我就做了一些站会，然后好像显得我做了一些事情，你们会怎么去处理中间的这样一种状态？

我想跟你互动一下，悟空你在讲why的时候，你是说团队或者说客户你遇到的客户他关注 why是吗？转型的why是这个意思吗？

就是使用我们这个手册的这一些敏捷教练，我的刚刚入门去学习他的这样的一些同学，然后客户的话，我们已经也会去有关注到 why的这样一些问题，但是他们可能也并不能很明确的回答出来这个why会有一个组织上安安给他的一个目标。

我们其实在手册中是并没有讲说转型要去做原因识别的对吧？

我们现在讲的是痛点和目标识别，我非常喜欢这个结构，我不太喜欢原因的，通过一个为什么去找问题，因为是这样子，在我的理解中，我觉得不建议大家找找原因，原因和结果之间的关系，臆想出来的，就是你以为你做了什么事情，你会得到什么结果，然后 why就出来了，这个其实是个臆想。

但是我觉得no why或者是去想思考为什么是有价值的，所以在我们的手册中，我们强调是痛点和目标，痛是fact是对吧？痛是客观的，然后目标是由人给定的，是聚焦的，对吧？痛是散的是具体的，这里面我是觉得我们需要回避，不要刻意的去找，为什么？

因为我觉得为什么不一就是在不在这个游戏不在 game里面，或者说为什么不是特别有价值。

就是说它并没有限制你去问为什么，但是这个东西是不是一个真正好的关注点，这个东西我们是可以考虑的，对吧？

对于我再多说一点，就是说还是说为什么这个东西很重要，也就是说敏捷的话的一个很关键的东西的话是什么？也就是我们很多讲很多东西都回到敏捷是什么的一个话题，也就是说敏捷的话，其实你更更积极主动对吧？从外面来看是更积极主动的去做事，行动更频密对吧？思考更多，对吧？做出更多的决策，它的背后的话是你更积极的主动的去承担责任，去这种责任感，这种意愿，这种就是说你会看到的更多，对吧？而且你也愿意看到的更多。

这种状态的话其实是一种敏捷状态，敏捷是并不是说ok做事做得更快对吧？而是这种我们回到这样的一个手册上，痛点为什么重要？是因为你是不是愿意看到更多，你是不是对一个团队，你就是要把这个事做对了，我就做什么展会什么计划会对吧？那些会，还是说你愿意去看到自己的痛点，愿意去不停的改进优化，真正的敏捷的话，并不是说你用了所谓的这些框架了，或者是你用了这套系统了，你用了某些工具了你就敏捷了，不是这样，而且恰恰是你用了这些东西，反而使你更不不敏捷。

所以说为什么我非常坚持的在这种目标和痛点共识很重要的是因为如果客户当然了像马菲菲的说的例子来讲的话，他们花了很长时间去讨论目标和痛点，这很好，但有些公司的话它没有这么多时间，咱们就很快的去讨论一下，对吧？很快的讨论完了之后，咱们往前走一步，如果大家感觉不太对的话，或者是有些调整的话，我们再同步一下。

有的时候的话我们是从高层往下的一个对齐痛点，有的时候我们从底层往上对齐痛点的，这都ok。

但不管怎么说，这种对痛点的或者是对自己想要什么的一种思考，它是应该传递开的，逐渐扩散开的，这也就是说敏捷教练要做啥，我的一些坚持或者是我的一些理解。

我们在前两天还才刚做了一个小的内部的分享，然后我们有一些同学志愿者的一些同学，他们就会问我们做的是回顾，他就问是不是用了这些工具，我们的回顾就可以不尴尬了，或者说是不是把哪些东西做了，我们就可以怎么样子了，感觉就是这样子的一个句式。

就call back一下王宇他刚才说的那个问题，是不是用了这些工具就对了，做正确这个事儿。我在想怎么给大家一些更加能够有抓手有力量的一些建议，就是说大家在学习并且去实践的这样的一个过程之中，他怎么样找到这一种内在敏捷的一种积极主动的状态。

我突然想到了就是说意识的起源就是有本书的话叫做4个分叉，4个分叉的话去讲的是1个什么？其中有1个概念是什么？就是说我们的意识，就像刚才的话，我在call by我刚才说的东西，就是敏捷是更积极主动的去思考，这个东西其实就是意识对吧？意识意愿这种东西我们就回到这种起源，意识的话是在什么地方起源的？就是说第一个细胞第一个猴子，对吧？他怎么开始有想法的，你知道吗？这是多有意思的一些事情。

他的1个观点是4个分叉的，其中有1个观点是当第一个猴子开始有说不的这种想法的时候，意识开始起源。也就是说所有的其实你就像猫的话，你给猫一个地儿对吧？它就很就在这，你如果把这玩具拿走了，他就没有这个玩具了，对吧？但如果说这个意识的话，开始想不我不高兴，不喜欢不快乐不爽，当一旦开始这样的话，你会发现就是说复杂度就开始提高了。

对于团队来讲的话，或者是个人来讲的话，当你去感受这种痛点的时候就是说为什么按摩为什么要做瑜伽？是因为你必须得感受这种痛，知道吗？因为你一旦感受这种痛的话，其实你的意识就开始就像一个几何的分型就开始变得更复杂，更多就开始结晶化，对于团队来讲的话也是一样的，我们去不停的强调你的目标，你的痛点你的改进是什么，他们也会强化团队的意识，但是有些团队的话就是说最后做着敏捷，只有领导思考这个问题了，底下这帮人的话不思考这个问题了，这个是什么？

你说这个组织就不敏捷吗？也不一定，但是我觉得是很悲哀的一种现象，怎么样？

刚才讲了跑题跑了一下。

所以经常大家去安装也好，我就去使用去体体验早期疼痛的过程，就会有一些共有的现象，例如说这样会感觉就是leader一个人在去引导或者去讲一些东西，对吧？

然后回顾上面好像也只有自己在去想一些事情，然后让大家去提出一些具体的问题，大家也不想提，然后看到一些具体的问题，又会觉得就是说现在特别忙，工期特别紧，现在说高需求多，还是不想改的这样一种状态。

我来抢个麦，就是在刚才咱们这一段探讨中，我也在发散，我就在想那么组织需要敏捷教练做什么？比如说我们觉得目标痛点，这个东西它其实是跟这个团队或者是客户自身的一些工作意识和工作的一个内容有关，敏捷教练又在做什么？

当然也可能是有点跑题，我基本上在想的是说我自己现在在组织中就会遇到一些困难，比如说我可能会已经了解敏捷很多年了，然后我就会在组织里面去刻意的去要求大家不断的去思考我们到底是为什么要这样做，我们的目标，我们的痛点是什么？不光是我们在组织运作上的，是我们在制作我们制作我们自己的产品的时候，我们也在不停的去想这个事情，所以我可以认为说由于我们用了敏捷的手段在组织里实施，让我们组织中的每一个交付件，每一个结果，它都是带有目标痛目标和痛点的基因在里面的，而不是无意识的在组织里面去制造一个软件产品出来。

我讲的是什么事情就是说我们可能会看到一些团队，他们也定义目标和痛点去改进，也搞看板也作战会对吧？但是它制造的产品跟他的组织的形式是两件事儿。

所以我觉得有的时候我们要考虑的是作为敏捷教练来来看，你把这个关对于共识中的这个f一点的痛点目标共识这个点做到位，那么整个组织会呈现出一种对于目标和痛点的关注，导致他的所有的结果，如果它是个软件团队，或者它是一个产品团队，它的结果应该也是带有基因的，所以这个东西我觉得回来再看雨伞前面问的转型是什么？

转型可能就是一段病毒是吧？这个病毒是个敏捷病毒，它把大家全部都感染了，我们后面我们的所有的行为，我们做的所有的结果它都是带有敏捷的里面的基因在里面的。

我在想我说那么反过来讲，敏捷教练作为一个组织中的特殊角色，他在做什么？我觉得他做的就是他要提示组织，你们始终要在这个共识阶段你们要关注哪些事情，他要观察这个组织有没有在关注这件事情，我觉得这个是非常有价值的。

为什么我有这个感受？是因为我自己现在我做产品经理的话，我如果关注产品本身，我就不可能再有带宽去关注我们是不是在一个敏捷模式下工作，我们是不是带有这个基因去工作，这件事它是会打架的，所以我非常需要组织中至少还有一个人，他有这个sense，我们就可以打个配合，我关注事的时候他来关注一下我们做事的手段，或者是他关注事的时候，我来关注手段，有一个互相互相配合的这么一个状态，我就会觉得特别的舒适，所以我感觉组织是非常需要敏捷教练，我自己虽然也做敏捷教练，但是我自己做产品经理我就做不了敏捷教练，自己也打架。

敏捷教练还是在起码act的定义的话，它是一个兼职的岗位，它并不是一个你得有这种状态，你能够让这种思考这种敏捷性去能够在公司生根发芽，就像马菲菲说的这种传递开，这个是很重要的。

而且我们认为的话就是敏捷教练的话，每一个未来的管理者的话，都应该有敏捷教练的这样的一个思想，或者是一些基本的这些能力，所以是这样的。

另外的话回到马菲菲刚才说的关注事儿，还是关注这些影响，有可能是因为一些优先级太高了，或者是压力比较大的原因的话，使得就是说因为有些习惯的话，你就没让你变成一种习惯，这种变成了一种肌肉反应，对吧？拿起杠铃的话就举对吧？

所以的话就是很多东西压力一来的话，很多东西有些变形，这个是理解的，但是你只要保证你时时刻刻坐在最高优先级的事情上，团队组织哪个优先级的是最高优先级的对吧？并且积极主动的去做这件事儿。

比如我举个例子的话是什么？积极主动做的话，它的反义词的话其实就是受害者心态，当组织中任何的一个角色都有这种受害者心态的时候，我觉得这个是我们需要避免的。

对最终的话敏捷的话的极致的状态是所有的组织的个体都没有一种受害者的状态。那是什么？整个组织的话不就是一个志愿者，所有的人都是志愿者，所有的人的话都是自己想干这个事儿，没有被流程或者要求干的这些事儿，这个这是终极目标。

我在听大家聊的过程中突然有一个画面感，我们厨余的运行的组织好像雨桑之前也举过这个例子，但是高速公路上面跑轮子，大家可能伸手都很难，在这种艰难的情况下就是流血或者需要非常疼痛的这种时候，我们都是在这个时候去做事情的。

积极主动的一些心态的这种个体，他需要把这种心态播种，然后让在团队里面去生根发芽，进而去影响更多的人。

然后就像菲菲所说的像结对的一些情况之下，我感觉它是为了去提高整个团队的一个意识的一个贷款，它不是提高个人的一个贷款，可能提高你个人的话，你自己去锻炼敏捷教练的这样一系列的能力或者思维方式，它是需要提高集体的这样的一个思维的一个带宽，然后让在不同的场景里面大家都能够调动起来去做这样一些思考的一个状态等整个团体。

他的目标更加去朝向于未来的大的一些目标痛点上面的一些解决。那么这种导向的趋势也就慢慢的就会把大家彼此受害，就是说有问题就把问题给抛出来，等着别人去解决，或者说有问题为什么好像讨论过了，大家也没有人去动，然后这个事情就不了了之，这样的话就会营造出完全不一样的感觉。

我还是举一个例子，昨天跟一个开发的同学去聊天，以前一起去探讨一些事情的时候，他们可能也就是等着别人去push他们做这样的一些事情。然后在等待的时间会觉得你有没有跟我去说接下来要去怎么做，昨天他特别的神奇，他自己在他就会去说那个事情上次去讲的这个事情你做的怎么样子了？我在想以前在一个企业里面，它可能有项目经理或者是教练这种保姆式的去推动这样的一些问题。

同样的在一些外部的这种公益的社区里面也遇到了这样的一些事情，就是当有一个专职的人在那个地方的时候，大家会依赖于这个人去跟催要，或者说是好像做转型还是什么敏捷就是他一个人的事情。

而当这个人他假如不在不存在了，这个组织还能不能运行下去，然后这是一个有趣的实验，但是观察了几天发现其实就算跟催要的人不在了，那但凡里面还有一些人是愿意去承担更多的组织，还是能够运行下去的。

所以我在想怎么去把这样的一个意识往前走的东西给它更深的一个深化下来。

这个就是为什么他这个角色叫做敏捷教练叫教练的一个重要的原因。我觉得是这样的，所以就闭环了是吧？

其实我现接下来的话还想去跟大家去聊一聊，就是我们在这个手册里面其实还有一些检查项，那么去假设我们大家都今天达成了一个小的共识，就是重点目标这样的共识，他到底是在做什么一些东西，那么具体回到一些操作上面，大家前面会需要去检查什么东西呢？

后面怎么知道我们做到这样的一些东西。

我挨个的念一遍，如果有问题的话，你们得提一下哪个东西你希望我多讲一点。

第一个有一些前置检查项，也就是说你在做这个东西之前的话，你就需要第一从整体的角度识别确认痛点和目标。也就是说这个地方的话，我要强调是整体的这个字，也就是说你必须得思考到底从整体当然了你考虑的范围可能不一定是宇宙级的对吧？你能考虑的话，你就尽考虑的更整体一些的角度的痛点和目标是什么？因为你会发现的话，如果我们关注到底层的话，它有可能会被上层的这些痛点和目标所什么覆盖，对吧？这是第一点。

第二点的话就是说明确排序的原则，保持痛点目标的有序性，就到底这些东西到底哪些是优先级高，哪些是优先级低的。

第三是理解上下游环节的目标期待约束和协作方式。也就是说对于我们这样的痛点的话，系统这些支持的一些部件上下游的话，它到底是一个什么样的方式？有可能话会给我们更多的信息。对，这是前置检查项。对于前置检查项你们有什么问题？

像前置检查就是我们进入团队，或者说因为前面提到两个性质，一个是有时间线的，一个是日常可能持续去做的。我可不可以理解为大家可能以回顾为载体，或者平时的这种部门的这样的一些例会为载体，大家可以去拿一些卡片去做一下这种痛点的这样一些排序。

如果没有在外部支持的一个情况下，就自己可能去头脑风暴去思考一些点，可能有外部支持的一个情况下，可能去通过一些引导的方式，让痛点更明确，或者说是给予一些资源上面的一些支持，我可以这么去理解吗？

你可以这么理解，但另外一点的话，如果不一定从回顾会上弄的话，领导的话，团队的leader必须得知道自己的目标和改进方向。

还有一点，刚才我觉得悟空讲的是一个小团队的模式，就是这个团队你天天可以和他们在一起，三什么5个人15个人20个人这样子。

还有一些场景，就是说还有一些场景是说我们组织是很大的，而且这个组织它可能是不是一个具体的 Hr结构上的组织，它可能是一个一一个形式，这个形式它是一个矩阵式的，说难听点叫矩阵式，它在它是渗透在一个活动中的，有不同岗位的人组成的组织，在这种情况下我们要去做帮团队去做改进的时候，你是很难找到一个物理上的空间，大家都在那里，你可以跟他们一起开会，你可以帮他们去改进，有的时候他是会遇到困难的。

所以我反过来看，我觉得前置检查项的本质的目标或者前置检查项这一段提示，我们作为教练来讲，作为教练的心态来工作的时候，我们始终对于一个是系统对吧？你第一段是第一句话是关于系统级的去理解，第二句话是关于排序，第三个是我们就check整体结构上，它是不是维各个维度上，比如目标期待约束，协作方式维度上是否都有具体的就覆盖到。

所以我觉得这个东西你很难讲，它是一个前置检查项，是一个哪一个具体的活动就能解决问题的，你只能从结果上去看一下前置检查项的活动是否完备，我觉得这会是一个比较好的方法。对的。

这也就是说很多东西的话，在act里的这些fact，这些关注点的话，其实都很强调前置检查项，你提前把这个事关注做到位了，其实你不需要在这个过程中花什么精力，比如检查项的话，这里的内容与相关的人员达成一致，对吧？

把痛点目标共识与相关人员达成一致，对痛点的和目标进行结构化管理，形成一个动态有序的清单。

对于高级管理者业务人员团队在一起明确要改进的痛点要达成的目标的最终内容，这就是再次的确认，你可以理解检查项的话，更像是一个确认的过程。前置检查项目就是把这些确认的内容都提前都准备好，你别好开个会或者是所谓的开一个会，然后你再花时间的话去把这些去在让大家再产生内容，这就不好了。

后置检查项的话就是说我们去可视化把这个东西假设分级和实验的内容，结构化痛点目标得到确认，就等于是再给大家发一下确认。对，大概就是这些内容，对于这俩检查项和后置检查项你们俩有问题吗？

我可不可以这么来理解，简单来说前置检查项是做会前的准备的，你准备的越到位，中间的曲折就越少，而检查项就是你这个会议输出的一个checklist，你做到没有，然后输出这个有没有？最后后自己还想可能就是你做完这件事情，一周来看，两周来看，这个事情是不是如你的假设一样。

对吧？

大概这三步其实我感觉像一个开会的一步骤。

你可以就这么用。

对。不止开会会只是一种手段，有些事情很复杂，不是一个会两个会能解决得了的情况下，它依然是这个结构，他依然是这个结构。

所以我很想我稍微再问一个问题，例如说像你们这种矩阵式的团队，或者是多地远程的这样一种团队，他就不在一个物理空间，而且你可能在能力上面职能上面也不一定直接的能够去联系到大家有没有什么好的一些思路能够提供给我们手册的一些阅读者。

都不是说开不开会的问题，是我为什么做三四个月去做前面的痛点目标识别，因为在痛点目标识别中，你要有相关的主题，把相关的人聚拢到一起去，还要再去层层的去堆叠，最后形成共识和目标。

他不有些东西是没办法开会，因为这些人不相关，你不能把他们拉到一起开会。你看我从系统的角度看做一件事儿，如果是流程类的事情，那是流程相关的角色要去参与的。如果是实施上的工具角度的，我是工具角度的人去参与的，所以它不是一个会，它是一个它一个阶段我认为是个阶段，这个阶段中它需要三个，你就需要前置后置，还有中间的里面的东西是吧？

比如说我作为教练来讲，我进团队了，我所在的组织几千个人，你能很快的找到人开会，就把痛点和目标说清楚吗？

应该。

都不行的，他们都要分头做很多提前的调研调查，我们再多次的去迭代，有点像什么，我这两天在看 Chat，GPT它的他怎么去做语言分析对吧？他语言分析它是逐段的去回溯，到底我这一段要干什么，再去跟全文不断堆叠上来的回溯的意义在进行，它是一个比较的过程，最终得到痛点和目标。

但是当然我作为教练来讲，我要始终去关注痛点和目标到底有没有在系统化的角度里面去被识别出来。

这也就是说你可以理解的话，就是说我们这些f1到f9的话，其实是一个量子的堆叠的就是同时在考虑的东西，也就是说就像你去吃你想吃汉堡还是在吃牛排，你并不是说ok有一个if else的那种方式考虑，你是同时在考虑我是要吃牛排还是要吃汉堡，这就是我们的脑子的行进的这种方式。

F1到f9的这个f的话，痛点的目标也是让你时时刻刻需要思考的东西。对，你如果有这样的一个过程去把它的话，根据检查项的话达成这样的一个列表是ok的，但是你要知道它随时可能要调整是的。

它不是一个流程，它是一个状态指导，它不是一个流程，对的。

对，所以其实我觉得这一块的话，我们还是有一直在反复强调，对于很多要关注的一些点，它是一个阶段或者是一个状态，这个状态里面可能分成了一些步骤，你可以装会议，你可以装访谈对吧？

你可以去沟通，你可以用问卷，你可以有非常多的这样的一些形式，但是你要确保这些原则能够覆盖的掉，因为我们手册它会有一些非常具体的用户，那么这些刚入门的一些用户的话，他可能他的组织对他也没有这种完整的约束或者一些方法上的指导，例如说我会做多少个月的这一种排期，我想知道我们这种小白的用户，他的这种上下文也特别不一致的一个情况之下，他们去用这个手册的时候，他怎么知道我也这个问题也不能是他怎么知道他用对了，他怎么去用，他用不错。

你就开个会，简单来说你就开个会，比如说我们需要明确一下我们的痛点和目标，然后把相关的人拉一下，你如果能一下子通过一个会字实现这个目标就可以。

如果大家达成了一些目标痛点的一个东西，你再发给大家，你就说这是我们达成共识的痛点，大家确认一下，因为这些痛点所以我们要做这些事儿就完了。

Ok我再多说一点，多说一个教练提示，是因为我们的节目时间也差不多了，也就是说在进化的阶段的不同的话痛点也不同，有些组织的进化的阶段，它他会看到不同的痛点，需要识别团队所出的当前的阶段的一个状态，比如他当前的话止血对吧？还是是在流血还是在什么状态，对吧？还是他们自己可以已经有了一些东西。

第二个的话就是求同存异，让所有的内容可视化是重中之重，也就是说我们因为一旦可视化了，你会发现你的视角看这个问题的视角就会上升一个维度，这种维度的话可能是抽象的维度，这个东西也是很重要的，基本上这是两点教练的提示。 Ok对于这些你们还有什么想聊的？

可视化，我特别的欣赏可视化的手段，当然话也说回来了，可视化我觉得是挺不好做的。

在实践中有很多痛苦，如果我们将来有机会，我也是倾向于我们是不是可以把单把可视化拿出来讲一讲。

我也挺喜欢可视化的，但可视化的话从以前的经历里面看来的话，它有非常多的场景，有的公司它不允许你在自己的开放空间里面去做一些张张贴贴的一些可视化的工作，有的公司又会在这个工具的可视化上面又会变成一个组织需要去统一共识的一个玩意儿。

然后更多的可视化似乎更普遍的就是落在在开会的时候，大家的白板上面可能有机会能够去做一些透明可视的工作。大家如果在这个方面还有一些其他的思路吗？比如说受限的情况下，更开放的情况下可以去玩一些什么样的东西。

我觉得给大家卖个关子，咱们下次再聊。

对。

节目时间也差不多了，总结送礼物我们的节目习惯。

我先来，我觉得在今天的我们这些探讨中，我们有再去强调说以一种敏捷的模式去做事情，我觉得整体上在我看来是价值我是比较在意的，组织里面敏捷教练的存在的主要的目的应该是在组织里留下这些基因，让组织中的每一个人在他的工作活动和它的结果产出中去强调，有一定的敏捷的基因在，特别是我们在强调的是确定目标的重要性，所以这一块的话我觉得还有很多需要去深入思考的，而不仅仅是在组织里面去开这样会，去贴甬道图，我觉得完全是more than这些东西的，这个是我今天比较想送的礼物，我觉得这个礼物是一个持续的去体会，去思考去实践的过程。

我就送到先说到这。

我的礼物的话就是说还是要回到这种到底什么是敏捷，什么是敏捷教练的目标，这样的话思考的话，其实痛点和目标的话，尤其是痛点和共识就是非常重要，所以再次强调就这些。

我要今天送的礼物的话，也是来源于很多朋友跟我的一些反馈，经常会说做完了这些之后，似乎就没有什么东西可以改了，也像我们今天所聊的，你必须得更自己能够积极主动的思考，然后很多事情能够往前多走个半步一步的，当你能够意识到这个背后是更多的一些调整，你有更多的一些可能性，那么这种改进其实是不会停止这样的一些脚步的。

我觉得就是这个目标和痛点它是一个持续的跟着你的个人的成长，以及你组织的一个发展，都是时时刻刻在更新的一个，所以也是今天想要去分享给大家去关注的一个东西。

今天就到这里，咱们下期节目再见。好，拜拜。

下次再见，拜拜，