痛点与目标的共识

痛其实是主动的第一步

集锦

• 它并不是一个完完全全的顺时间的，是一个时序的东西，但是我们写东西必须得写成这样的一个时序的，我们觉得转型的反义词是什么？
• 首先要觉察到我当前的工作，我的目标，我的痛点到底是什么。
• 我认为的话敏捷教练的话是一个协作的转型专家，就是我们讲scrum讲看板，其实很多时候都是是告诉大家这个事儿就这么做。
• 你以为你做了什么事情你会得到什么结果，然后这个why就出来了，其实是个臆想。
• 我感觉他是为了去提高整个团队的一个意识的带宽。

摘要

1. 手册的诞生
2. 手册的基本结构
3. 痛点与目标的重要性
4. 转型的反义词
5. 能正确的做敏捷吗？还是敏捷做不错？
6. 意识的起源
7. 敏捷教练的目标
8. 为什么会强调前置检查项

内容

马菲菲 00:36

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

悟空 00:41

我是悟空。

王宇 00:42

我是王宇。

马菲菲 00:48

好久没见。

悟空 00:50

然后其实最近的话我有收到很多我们act的朋友给我们的一些反馈，说我们手册原来都是每年上课都能拿到一本，然后他们去看里面这样一些内容，然后会反馈这个里面的内容，有一些过于的干了，什么干就是我们干货太多了，导致在嚼的时候有点难以下饭。意思就是用的过程中可能还需要一些具体的案例，或者说是我们去延展一下这上面的一些说法，我觉得我对这种反馈还是挺共鸣的，因为我自己本身也是手册的一个使用者，那么可能在一些大的共识，然后这样的一些共创和共赢的这样一些过程里面，对于一些具体的实施就总觉得自己想的对不对？然后有没有其他的同学有其他的理解，然后可以能够进行一些交流，我在想我们是不是可以提供一些对于这个过程中的一个交流，让这个事情显得更加的立体。大伙怎么觉得。

王宇 02:01

就是说给大家一些背景，就是说 act手册的诞生之初是什么意思？他为什么会诞生这个东西？是因为之前想有很多的思路方法框架的话，它都是一些原则性的，或者是一些比实践就是更微观层面更高的一个层面的东西。他有可能从逻辑层面的话讲的比较漂亮，比较美丽，但是的话真正落地的时候的话，一方面它是缺乏这种指导性，我到底怎么做，这是第一点。第二点的话是什么？当一旦有这种非常具体的指导的话，我们就会发现它其实适用性就不高了，它有可能的话它只能在团队的时候点时间点用 Act的手册的话，就是尝试着去平衡这两个东西，去第一去写就是回到最具体的一些东西，就告诉你就这么做，对吧？而且要求的话是很明确的。第二点的话就是说他并不太追求所谓原则上的或者理论上的美丽，因为的话这些东西在我们做这些事的时候的话，有可能的话就会被推翻，很多东西被推翻，也就是我们很高兴的看到 act的手册的话，不停的被自己推翻，这样的话也是我们做这个东西的一个出发点，就是一方面的话回到真正能做的事儿，另外的话能够去能不停的否定自己，能够让大家去做事，但这是背景。但是真正做出来之后发现有有意思的现象是什么？大家的话确实是这个东西能往前做两步或者是做一步，但人的话需要更明确的更多的知识，他才有理由往前做的更多，你知道吗？这也就是说这也就是为什么刚才的悟空说的，很多人反馈这个手册太干了的原因。对，因为他们缺乏很多的知识，他只是告手册任务告诉你这么弄，你也不知道为什么这么弄对吧？然后这种信息也少，所以的话我们其实是可以聊聊这个话题。

马菲菲 04:35

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

王宇 04:44

因为整个的手册分成比如价值观原则，关键的知识点，然后的话是共识，共创共赢，也就是关系让团队进化，然后持续改进几个部分，因为它这样的话分成了几个？F那就是f1到f9，f是什么？ F的话就是我们的战术关注点，也就是说你作为敏捷教练的话，需要关注到在这些关注点，你可以理解就是我们作为一个顾问或者是一个教练，你的一个关注点应该在什么地方去让这样的一个敏捷在团队中发生？我们今天的话其实是可以关注到这个共识，也就是关系这部分的预的一个小的一个f叫做f一，叫痛点和目标共识，因为这个东西的话也是很关键的，非常关键的。对，我觉得也很有意思的话，就是说我想快速的介绍一下 f几个f的怎么的一个结构，每一个战术关注点的话，它都有它的目的。前置检查项、检查项、后置检查项和教练提示这几个部分。对于f一的话的目标的话，就是使实施的过程出师有名，明确目标和目的和目标，避免为了敏捷而实施敏捷。从组织团队的痛点出发，让每个参与人都有获得感，这个东西是我们f一痛点和目标共识的目的。我也很好奇对于你们俩的话，你们俩怎么理解这个f的这个目的，或者你们俩怎么理解这个目标和痛点共识？

悟空 06:40

好，要我先来讲讲我对这个东西的理解，因为我对这个挺痛的，我在使用这个册子的时候，经常会感觉团队必须得有痛点，原来的话我会觉得我可以按照团这个手册这样的一个框架去在团队里面应用一个我认为比较好的一种敏捷实施的一个逻辑，后来发现很多的实践不一定适合这样的一个团队。再后来一段时间反思，我感觉是因为我早期没有跟团队达成这种痛点目标的共识。举个例子，例如说我们想要去做这种主干发布，但你会发现其实程序员并不希望持续的每一天在主干上去做这样的提交，因为他们觉得这样很痛苦，自己的到自己的代码会的这种错误会暴露在大家的这种视野里面。对他可能最后有质量，但他并不认为质量是自己的一个痛点，对吧？然后又或者说我们去做每天的一些展会，但实际上他会觉得太多的开会或者是太多的写日报周报的形式才是他们的这种痛点，所以经常是去自己定义了和假设了一些痛点，然后引领着团队去做这样的一些事情，那么经过这样的一些反思之后就会去做一些调整，但是调整完之后又会有新的含糊，大家好像觉得节奏改进了，然后有一些什么需求沟通关系也变得融洽了。但是对于这个组织来讲的话，就是做了这个事情好像它背后的收益是什么，然后讲不太清楚，当你讲不太清楚这个问题的时候，做这个事情的长期动力就有一点缺乏，所以我会觉得痛点目标的共识是一个我也特别想在今天去讨论的一个话题。对的，也想听听菲菲是怎么去理解这个痛点共识的。

马菲菲 08:31

首先我看到这一块包括整个结构的话，我最大的感受还是敏捷教练本身，很显然不是仅仅是安装scrum的才就是敏捷教练，对，这首先我觉得这个背景我们要我们要先确定。对于我来讲，我认为敏捷教练你不是到团队去安装scrum的，所以你的目的并不是为了发现大家的早上不开会，看板没人画，不移动就是问题。所以回到我们整个教练手册里面的最关键的部分就是确定目标是什么这件事儿，我觉得它本身是非常有价值的。但是事实上在我们遇到的一些比较大型组织的问题的话，就像刚才其实悟空也讲到了，有时候痛点它可能是自下而上的，但是这个目标是自上而下的，所以它之间会有一些不一定能够匹配到的情况，包括作为敏捷教练来讲，我们应该如何引导团队的关键人去理解到底什么是他们想要做的事情，这个本身其实是比较需要一定的技术含量的。当然作为一本手册来讲，它不可能把解决复杂问题的所有的手段都列在里面，所以我认为我们在这个手册中我们能看到的是最重要的是找到痛点和目标，后面的话你的所有的行动项你都是围绕你的痛点和目标去开展的，我觉得这件事情的价值是非常大的。在我最近这几两年的工作中，我在一个比大的组织里面，他要去做数字化转型，我们在痛点目标这个部分的分析分解，甚至会长达好几个月就去做这件事情，在可能我整个建设周期才不过3个月4个月，但是我前面论证分析我也三四个月，我就在组织里的做事的方法或者是思路，让我充分的意识到这世界上总有一些团队，他们是很认真的去考虑痛点和目标的，而不是快速的就进入到行动过程中。

悟空 10:51

就是因为听到菲菲这么去讲的话，我就在想，因为有之前也有机会能看王宇他去做一些实施，他在做有一些实施的过程中，就发现我们其实能够在客户现场的时间会非常的短，这个时候自下而上有一些实践，他需要非常快的去达成一些共识，然后就去做这样的一些行动。那么有的时候会觉得会议上大家生共识感觉挺嗨的，但是落成了这样的一些目标，好像就有点缺少像菲菲你说的这样子的一种方式，就是花非常多的时间去对齐这个目标，去做这样的一些计划，然后进而去落地。但因为不同的企业它的这样的一个运行规则和方法是不同的，所以我也很含糊，就是对于我们使用这本手册的同学来讲的话，他怎么样能找到一个锚点，或者说他怎么来去运用这样的一个手册去让他的目标和他的痛点能有所结合。

王宇 11:52

我多我突然想说几个东西，第一个东西是什么？你看从手册的组织来讲的话，你先得需要痛点目标的共识对吧？然后往下走，123456789，其实不是这样的，也就是说它并不是一个完完全全的瞬时间的，是一个持续的东西，但是我们写东西必须得写成这样的持续的过程。就像痛点目标的共识，其实它是可能在你做服务的时候持续在校准的，但是他可能在一开始的话会花的时间比较长一点，我是说的这是第一个点。第二个点我想说的是什么？痛点和目标的话，我们其实都在讨论转型的一个话题，转型转的话，其实跟转型的话，我们有的时候理解一个概念的时候，其实我们就要去从另外一个反向的概念去理解这个概念。好，我问大家，你们觉得转型的反义词是什么？

访问《痛点与目标的共识》-- 思维发条（siweifatiao.com）获取完整文字版内容