转型成败的基本法

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

我是悟空。

我是岳庆。

庆庆是我的老朋友，又是我的老朋友，我又有一我怎么又有老朋友来了，就是人脉比较广，庆庆确实我们确实是很有渊源，给大家做一下自我介绍。

大家好，我是岳庆，对我是也是工作了有十几年的一个职场老兵，以前从研发开始做起，中途转做项目管理，目前在一家科技公司主做项目管理以及敏捷转型这块的工作，然后今天也很有幸能够参加到思维发条的活动中来，非常感谢各位，也希望今天能有一个比较愉快的探讨过程。

我们今天庆幸难得来我们看看聊聊点什么，因为转型好像现在各家公司都还蛮热的，像我自己我也是在相当于在服务我们的组织的一些转型，当然是研发团队的转型了，我也比较好奇，庆庆你们的转型现在做成什么规模什么样子，有什么有趣的事情或者有什么困扰，可不可以给我们大家也分享一下？

其实我做的也是研发这一块的，因为以前也是在从传统的项目管理这种方式朝着现在这种敏捷的过程管理的方式在做转型，整个转型过程中也会遇到各种各样的历史的问题，或者还有包括一些文化的问题，真正落地的问题，也有很多有趣的事情，也有很多的困惑，今天主要是想各位探讨一下很多团队很多公司在转型的时候所期望的一个点，那就是大家对于不同公司对于做敏捷转型他有不同的看法，他往往会遇到一个想要了解的问题，我怎么样才能够算是转型成功？

因为按照我们以往的思路来讲，在做一个事情之前，首先去定一个目标，这个目标就是我在做敏捷转型的话，怎么样算是成功，他会把成功作为一个他转型的目标。 这个就是我今天带来的一个困惑的地方，就是我们可以探讨一下在我现在所处的团队里面怎么样的一个结果才算是比较成功的。看这个看一下我们大家不同的角色，不同的不同的所属的公司，以及说要有不同的人的一个看法吧。

对像刚才跃进聊到说转型怎么样算成功，我觉得这是一个也挺多汁的一个话题，成功和做成这件事情，就是在你看来这件事情有没有什么样的一个区别？

就按照以我的理解以往的这种项目目标达成，我们会认为这是这个项目是成功的，如果把敏捷转型这个事情当做一个项目来看的话，应该是既制定一些既定的目标，这样的目标完成之后，我们就认为这是一个成功的项目，在有限的时间，在有限的资源下达成这样的目标，这就算是一个成功的项目。

但一件事情做成和做成功，在敏捷转型这个事情上来看的话，我认为那还是有很本身定义是不一样的，如果说做成了，那就是这个事情做完了，做成了，但是从敏捷转型这个来角度来理解是否成功，我们可能自己的目标实现了，但对这个公司来讲，他的期望是不是被实现了？

他希望如果被实现，他可能认为这是成功的，但他如果说我们的项目目标达成了，但是他的期望没有被实现，它可能就不是一个成功的结果，这是我对做成和做成功的一个看法，可能我们自己认为是成功了，但是对这个公司来讲，我们给他带来的收益或者说能不能把帮他把他的想要的期望给实现，我觉得这个可能在这个公司或者从业务方的理解和我们的理解上都来讲是有一些差距。

这问题一拿出来说，我就立刻想到我我原来在某某银行的研发公司，某金融的研发公司，我们那是可能是12年13年的时候最早接触敏捷，就就不讲过去的事情，主要是一下子就想到当时我那时候还是一个普通的需求管理，需求分析人员，我是觉得敏捷很好玩，所有的模式都不一样了，所以我现在刚才青青讲的时候，我心里在想，敏捷他对于每一个在里面深入其中的每每一个研发团队的成员来看的话，可能还是协作模式上的变化。

那么反过来就说我们现在可能我们需要定义对吗？如果我们要讨论成功的话，那么一个是什么是成功对吧？什么是成功？ 再一个说如果从我们把这个范围确定一下，如果是讨论敏捷带来的整个企业或组织的产品化的成功，和我们讨论说狭义上的我是一个敏捷研发的模式，我的模式研发模式上的成功可能还不一样，对吧？

所以我觉得其实这个问题好像在敏捷圈子里大家也经常讨论，因为团队如果要做敏捷牵头立项的变革，推动的组织负责人一把手，你势必要向完全不了解这个事情，或者对这个事情有很多期望的人去解释，我这么做带来什么价值对吧？

这个是我们要去解释需要论证的，包括有可能我需要一些资源，如果我没有这个蓝图的话，资源也是不太好圈定的，所以还要看这个问题到底是用来证明什么，如果我是向内证明，比如说我自己是一个小的组织的研发leader，我觉得悟空的做有过创业的经验，可以就，如果是做leader你们自己怎么玩，你可能你会有一个论证方式，定义方式怎么叫成功，和以及我在一个庞大的组织里，我要向上一级的管理领导申请资源，我要跟我的同僚们说，这件事的价值可能还也都还是不一样，对吧我？

其实聊这个成功，我觉得真的它是属于规模大，规模小的话，对于这个东西来讲，上下文场景特特别的不同。我记得原来也分享过自己在做一些公司项目的经历，因为规模都比较小，对于我来说的话一开始只要搞定缩短发布周期，然后保证发布的质量的，这个问题就就可以了。当然在这里面做了非常多的一些实践，就会也能做到很短的周期，很有节奏的高质量的去做发布。

但是这一些实践过后，因为我们的周期比较快，因市场也和我们联系的比较紧密，马上就遇到一个新的问题，就算我在保证质量，在保证交付了之后，我们市场打不进来，他没有办法打到客户，可能你对你的商业模式就形成了挑战，你这个事情业务还做不做就形成了一个挑战。

我记得你最早在去学习敏捷实践的时候，教科教科书里面就会去讲你做的这个事情，他更快的给你反馈完了是要什么，是你到底还要不要接着做这个事情，所以我那个时候经常遇到的上面就是实践都做完了，但是这个事情发现其实要么就是想的太简单了，要么就是随后的资源要投入，其实根本没有那么多资源投入，马上就要做一个选择，叫做转向停下还是转向其他的，其他其实是用来辅助我去做决策的。

所以在这种小规模的这样的一个产品项目里面，我认为它敏捷这件事情对他的帮助是带来一些很强的纪律性，并且让软件工程这件事情变得比较的有条理，然后比较可期，而且它确实实实在在能带来这种结果。

但对于所谓的客户成功或者业务成功来讲的话，我觉得他并没有并不是决定性的一个因素，它并不是一个决定性的因素，如果没有前面的那些战略层面的一些思考的话，对的，所以我也非常好奇在庆庆你们的上下文里面的话，周期也比较长，验证也比较长，能遇到这样的一些情况，你会有没有一些什么样的分享或者一些思考？

其实先抛开成功与否的这这个事来讲的话，我也在思考说敏捷到底能给一个团队一个业务带来什么那。 刚才悟空也讲到能够让大家更有纪律性，能够缩短整个的发布周期，我对他的思考是也是类似的，我们在整个缩短迭代能够更快响应市场，能够更快的去向市场交付价值这个层面能够我是认为敏捷能够带来这方面的一些改进的，而且敏捷是比较注重价值的输出和价值反馈的，也就是能够保证我们在遇到包括是遇到一些这种非高价值需求的时候，能够及时发现能去寻找更高价值的需求。

所以在团队里面一个是要有一个比较好的价值的判断和识别，能把高价值需求最高优先级的去做实现。第二个是能够快速的去响应市场和反馈市场，能够去输出价值。一直以来是我觉得应该通过敏捷的这种转型能够带给团队的呃，但这里面有一点，任何一个业务的成功，它其实包含两个方面，叫做一个是最正确的事情，另外一个是正确的做事情。

其实我呃以往是把所有的方法论，包括敏捷转型，这个是放在第二个模块里面的，就是属于正确的做事情，对。 所以往往遇到说在如果说业务方向或者是整整个价值分析不是很准确的时候，往往我们的这种快速迭代能够帮助他去发现你现在这个业务方向是有问题的，就是快速受挫对吧？

敏捷小步快跑快速迭代，其实就是降低一些试错的成本，通过这种方式快速发现价值，快速交付价值，最终目的是提高价值产出。对，这个是我对敏捷能够给团队带来的一些东西的一个理解。

就说到这儿，我就我就给我刚才开了一个框，是我们来把它关一下，我觉得虽然我们刚开始尝试去把这个问题做了一下建建构，但是事实上其实敏捷的很多方法论里面也都会去讲，但其实蜻蜓的分享结合实际，其实总结得很到位了，一部分就是我的研发团队有能力去支撑一个快速验证，对吧？

第二个是说我的产品团队在研发的支持下可以快速的去做反馈，接纳市场的反馈，接纳价值判断的反馈，然后我去调整我的节奏，对吧？其实还有一part，我不知道我们现在庆这个公司应该也涉及由于part我是作为一个可能是集成伙伴，我要跟我的客户一块去合作，敏捷方式有必有利于客客户可以快速拿到响应，这个也是被认为是有利于增强客户合作之间的一个有利的做法，对吧？

我频繁的去响应客户需求，我让客户看到他花的钱不断的有版本出来，客户的变更我也可以配合他，其实我觉得是属于客户合作方面的一个价值。

但是我感觉我们今天本来可能也不是完全探讨这个方向，因为很显然庆庆你在企业里面应该是在做这个变革对吧？算是做变革至少也是变革的最核心的部分了，是不是？这个地方有什么需要去论证的东西，有焦虑或者是因为我们都知道变革势必会触动到一些人，对吧？

你可能是需要他有更多的能力，你需要承担更多的职责，你需要它改变一些工作流程的方法了，它是不舒适的，也可能会有一些角色或者岗位或者部门，它是不是很理解，是不是有这个方面的困扰，我觉得我们也可以稍微再探讨一下。

对也的确是存在的，因为本身一个团队的就是一个组织的变革或者是一个团队的转型，它一定不是一个舒服的过程，因为只有向下的路是一个舒服的快乐的下坡路，对任何一一个团队一个组织想要做得更好，是一定上坡路，对吧？

这一定是会需要你做一些呃额外的付出的。

包括我们在做敏捷化的转型的过程中，其实也遇到了一些各种各样的问题，比如说我们把整个需求拆的更细之后，会发现以前的产品经理，包括说以前的产品需求分析的这些角色，他可能不太具备，能够把整个一个大的特性或者大的功能拆分的更可独立交互的小的这种用户故事这样的这样的能力。

往往时候说我们现在他马上告诉大家说你们按照什么样的方式把它拆分成一个独立的用户故事的时候，产品经理或产品需求师就非常抵触，但是有时候你不得不面对这样的情况，因为他可能以前没这样去做过，你一下要求他这样去做，他其实能力上并不具备，你告诉他，你现在必须按照这种用户故事去给我去做拆分，他的唯一做法可能就是那我就死给你看，这种情况你就不得不考虑说基于现状怎么做更合适。

对往往遇到的是一个对应角色上的能力的提升，他其实米基转型在对大家的能力是有要求的，并不是说米基转型之后你就可以躺平了，对吧？快乐的一定是下坡路。

第二个就是说从业务的角度来讲，因为很多这种咨询顾问，包括说很多咨询行业给企业在讲的很多的培训的时候，包括相关他们会讲说真正的一个转型或者是变革，最终是以业务成功作为目标的，因为这个是企业比较关注的，你你讲这个业务会成功，或者你成功概率会更高，企业就会很动心对吧？

我就很愿意掏这个钱请你去干这个事儿，当然最终成不成功，那是另一说，但是刚开始都是这样去讲的，所以企业本身就有一个期望，说那我通过这样的敏捷转型或者说一些组织变革，到底我的业务是不是能成功，或者说你用什么方式能保证我的成功概率会更高，往往在业务层面上比较难去短期内去呈现，当然我们可以很比如说很多例子说以前某某公司对吧？

以前某某公司他请了专门的公司做变革，他的公司这个老板想的就很清楚，我就是要去做这样的变革，你不要问我为什么你们就先这么做到了，正确的做不到那就是有问题了，先做到然后再说怎么去优化，他会按照这样的步骤去走，他就想得很清楚，但是不是所有的公司都像他这样的公司一样，比如说还有其他的很多公司可能在想着说，我在一切正常的时候，那就是按照以前的模式走是没问题的。

当我遇到问题的时候，我才想到说我怎么样通过一些更好的方式能让我的整个组织更有活力，能让我的整个价值产出更高，对他本身对敏捷转型或者说一些组织变革都就是这样比较比较目的比较强的这样的期望在往往这个时候我们比较难以用一个比较确定的数字啊或者确定的指标来告诉你，你这样做了今年的业务就能多么的好，或者你这样做了，你今年业绩就能达到你期望那样的数字，其实在短期内是很难去给这样的一个承诺的，而且我觉得大部分公司都很难说，你一下子做完这样的组织变革，你这个业务就好，因为本身业务好坏跟你的选择行业，跟你的客户的情况，跟你的公司的整体能力都是相关的，所以在这个方面上，这是第二个遇到的，往往很难去证明或者说服它，这就是我们的敏捷转型所带来的一些价值。

然后第三个在推进敏捷转型或者是组织变革过程中，的确会遇到一些历史问题，对这个历史问题在调整的时候，往往也会触动到一些人的职责或者一些全责的一些问题，往往也会形成一些阻力，可能就具体问题具体去看了。

突然间我在想这个问题是不是换成简单一点的论述是两种情况，一种叫做老板想得很清楚，所以他不需要你们给他想做的这个事情提供论证过程，也就是老板自己为结果买单。

第二种情况是似乎老板并没有特别想清楚这个事情，然后也不一定会为结果买单，所以最后就变成了看谁为结果，买的可能有负责组织变革的部门要去证明自己做这件事情成功的，或者是外部咨询公司要证明做公司掏了这个钱，你们做的事情有价值的，又或者是作为职能部门来讲的话，参与了这一个大的运动或者专项之后，你们做什么成功是有价值的，我感觉好像是这两个维度是。

我觉得这个地方其实讲到了有一个关键点，我们以前讨论敏捷价值论证的时候，往往会觉得说要向老板去证明，或者是说希望老板一大家都说一把手一定要亲力亲为，亲自站在阵线上，这个部分我觉得也确实是没有任何问题。

只是我这两年的是实战经验有那么一点点实战经验和观察，我觉得首先一把手完全不懂的比较少了，它不是说10年前那种情况，一股腥腥风吹过来大家都不知道，一把手不懂的不认为有价值的已经比较少了，甚至很多关键岗位的关键领导，他其实是非常懂的，他知道这个事有必要。

另外一个就是说在他已知这件事有价值的情况下，这些论证往往还是要发生，为什么？因为我不能说我自己做变革，我自己知道就行，我老板知道就行，因为你还是要得到人民群众的支持，对吧？或者换句话说，我比如说现在我们企业里变革变了，有一年一年半了，各种大改，呃到了今年要收尾了，收尾了我们就要去做调研，就是确保工程师对于整个变革的过程是舒适的。

因为不管你怎么变，你工程师提代码写代码加班，你得要考虑到大家不要怨声载到一一直都认为说是跟你的变革有关，所以我们在收尾阶段，我们依然要去收集一线的员工的意见，然后我们再看应该怎么去调整，或者是做一些科普也好，流程调整优化工具的优化可能都要做啊。

所以我觉得论证这个事现在看来我就算不向老板论证，我也要向我的合作伙伴对吧？内部的这些合作伙伴们去论证。其实刚才庆他就讲到了三个点，第一个问题是关于赋能的，就是能大家没有需求拆分的能力。然后第三个问题是讲说我有些历史上有一些坑算是这个东西在变革，它就是正常运作都比较困难，我又现在遇到变革了，难上加难怎么搞？

因为我觉得这两个问题，我们一个打开，我觉得先打开，第二个，因为咱们刚才一直在聊，第二个关于成功定义，我自己其实我最大的对于敏捷的理解还是归根到底它还是一个文化，那么为什么又提敏捷是个文化了，因为前面我们的讲是工具，是流程，是产品成功验证，为什么我又要讲是文化？

其实归根到底还是老生常提，市场到底是不是世界是不是乌卡的，如果你认可，你相信它只会越来越混乱，越来越无序，越来越不像是以前的模式的话，你就要让你的团队具备，它可以小像特种兵一样作战，他能够在他的范围内去响应市场变化，响应客户变化，做出他举像一定程度上你要给他授权，你让他做出局部最优选择，你不要让他回到所有内部的大流程里面去做决策。

因为我们组织越大，是我的产品线越大，我的组织越大，我的企业越大，我的决策流程一定是人员越多越复杂的，无论如何都是这个样子的，最糟糕的是一人投一票对吧？不但结果不可控，还要把所有人卷进来对吧？

所以我觉得有一part是我们做敏捷教练也好，我们做转型也好，我们的信念是市场是有变化的，我们希望团队可以去最快的效率去响应变化，因为你不动就一定是死定了，你动的话你还是有很多可能性是不小心碰对了，哪怕你客户正在生气，你给他有你跟他互动一下，如果给你搞两个需求先弄做上去，你是不是也没有那么生气，如对吧？

所以我认为我们我们这拨人我们肯定是相信这个东西，那么问题来了，你希望你把企业的你不管你是年轻的公司科技公司，还是像我们这种较为传传统的智能制造的去转型，我们都遇到一个问题，就是员工或者是小的组织，它能不能独立决策，你有没有组织的协作的模式支撑它做小范围的决策，你鼓不鼓励大家决策，你容不容忍失败？

如果这些答案是yes的话，好多事情就好办了，对吧？

然后我才会有我为什么我要拆分团队，我要拆分产品线，我要服务微服务，我要团队要经常的去迭代去调整我的需求，这些都是因为我们的信念是这个团队有这个能力去响应变化，避免大事小事都来到公司集体决策，我们并没有说你的企业不要做长期的战略商业，还有产品线的规划要做的，你不做产品线规划，你不做商业决策，你可能未来两一两年就失败了，是来自于你不做决策，但是团队依然还是要在基于大的决策下去建设自己的快速响应的能力。

所以我觉得刚才青青讲的第二点的业务成功，我们现在去做工具对吧？蜻蜓行也讲了，我们刚才是题外话讲的蜻蜓你们也在考虑说用什么样的工具链对吧？帮助大家提升工程能力，包括我们所有作品节都涉及到组织的变革，为什么要组织变革？希望大家能力下沉对吧？然后每个人是不是能力比以前更强，你这样你从而可以去做一个自给自足的运作。

这个它体现在纸面上可能是一起开站会，然后我要有个doubles流水线对吧？我会有这些体现，但是内核我觉得我们就是把原来的集中式决策繁重的决策简化为分布式的每个人都是一个很smart的一个小的团体，小的个体去响应这个变化，对吧？我感觉 Part还是我是很乐于见到转型成功的组织，它进入了一个新的模式下，对吧？它就可以向这个方向去运作，它就不是原来那种都等着别人安排，然后都等着别人说话，你才能干活的那个状态了。

包括我觉得这个地方有一个误解，就是我们认为有的时候我觉得我们敏捷教练有一些也会有误区，认为如果这个人开站会的时候，不自己主动说话，他就不敏捷了。其实不是的，我觉得不是，我们并不是要具体到每一个人要你改变你的性格，你去做超过你能力的事，我们说的是整个组织形态倾向于他能够做出自己的promise，对吧？

然后他还为了自己的promise去承担结果，而且这个组织除了他之外，其他的人不会不愣，他不责怪他去做这件事，我觉得至少我个人认为这就算是敏捷成功的一个特别关键的指标，相当于你给企业带来一个全新的模式。然后这一part我觉得虽然我个人没结婚，但是大家有我们今天又有结婚，家里有两个小孩的亲戚，你说什么时候成功的婚姻吗？那不就不离婚，就是成功的婚姻，所以当你决定要结婚的时候，你说ok我们开始一个新的模式了，我们以前是男男朋友和女朋友，现在开始我们是老公和老婆，有可能这个行，我们可能要更明确的去承担一些家庭的责任，我们可能要把钱放在一起关，我们可能要要生小孩，有要就一起赡养老人。

所以我觉得有的时候说做敏捷，我就会想到就像谈恋爱谈到该结婚一样了，一个新的，你一旦进去了，你只要保证他一直运作就可以，我们就不要走到离婚就可以，这就是成功的敏捷是吧？我先说这么多。看看庆庆对于婚姻的例子有没有共鸣。

对这个就进入了一个新的模式。在这个模式中，只要你一直处在这样的模式中，能够去动态均衡，我觉得这个应该是敏捷模式应该也是能够发挥它对组织的一个作用的。

刚才听听菲菲讲，我是觉得关于证明是不是成功这件事情应该是分成两个趴的，而且我对你说企业的老板，他是否知道这件事情有一个新的感悟是什么？原来我老觉得向别人去证明自己做的事情有价值，这件事情很没有意义知道吧？

因为我觉得这件事情是一个很费劲的事，你得费很大劲去找出一些度量单位，然后让大家去认可你共识，我就觉得这些事情很没劲，然后突然间发现一个视角是什么，你对内去证明的过程是你拉共识的过程，可能人家也不是非得让你去证明，但是你白纸黑字的去写，然后成为一些文档，成为一些流程，或者说是有一些宣贯，拉了一些会这个过程之后，大家慢慢就把共识拉起来了，然后规模大了之后就通过这种影响力更大的方式去去做。

而对内来说的话，我们讲敏杰讲的比较多的时候，其实这种组织层面它比较小比较灵活，我上次跟一个程序员聊做敏捷，你为了什么？他就想看看自己的需求还有没有活着，业务还有没有活着，有没有是有向上趋势的健康的这样一个活着，所以有一个话叫做什么？其实敏捷的实践有没有成功一说有一种说法其实就没有什么所谓的成功，一说这个过程你在调整，你一直在调整，你就有机会让你的业务的更加往上一层或者业务有机会去做存续，哪一天你不做调整了，你也就慢慢的往往往下走了。

所以我感觉是这两个方面的角度。

是我顺着悟空提的这一点，当然我前面就主张说其实老板都懂，不用跟老板论证，但事实上我真正的意思是说，你如果真的要跟老板论证的话，其实这个问题就是个老生常谈的问题。在老板角度看资源线之间对吧？我的几个团队之间他们彼此不沟通，对不对？这是老板每一个老板都头疼的问题，就是筒仓然后做的事情没价值，不知道他们自己在想什么，或者就是大事小事都汇报不到，我这里大家都不动了，都是踢不动，也就是a团队和b团队吵架，因为他本来是合作的，然后他们吵架，你去问我们说稍微高级一点的管理者觉得管理的团队是职能是多样的，啊是或者说这个老板是要涉及到财务就是零售类的，有职责的，一他应该一般来说他都会有这一个方向的困扰，那么我们反过来看说我们做敏捷的话，是不是可以在这个角度我有效果的，我个人会就说我们如果真的非要回答这个问题，我觉得我会倾向于从这个角度，因为我觉得工程建设流水线建设这个不是特别的需要额外证明，或者换句话说它好证明，对吧？

流水线建好了， Lead time更短是吧？然后构建更快制品，很快就管理的有序，对吧？我的代码提交我都很清楚，我觉得这个比较容易证明，如果是业务角度的话，除了产品不太好论证，我也不是什么产品专家，我觉得从组织敏捷的组织管理的角度来看，如果我能向一把手管理者提供的是说解决你的筒仓，让你的决策的过程更快速，或者说我有一些成文的流程，刚才悟空也提到了，说我在团队里搭建一些流程体系，让决策是分布式的，我觉得这些都是一般来说比较不太会被排斥的一个效果，对吧？

因为这是一个通用的管理或者常见的一个管理痛点，就我不知道庆幸你们在实践中变革中有没有这个方面的一些观察或者是经验之谈也可以。

对，现在有一些团队还是在做试点，关于这团队里面有什么样的角色是去做决策，包括说团队之不同团队之间了，怎么样去更好的去沟通和而来最终的一些目标，这些都是在有做一些尝试。

然后在做的过程中也会遇到一些也会遇到一些问题，因为现在有些团队他其实有些敏捷项目团队，它是由各个不同的职能部门组合在一起的，也能看到这样团队其实大家都是参与到其中都是挺积极的，特别是我觉得开发测试的这些角色反而是非常积极去拥护的。

我们现在遇到比较大的这个问题点还是处在需求的阶段，往往有时候变成发现需求是个瓶颈，然后需求是瓶颈之后，你就发现这个想要提高产出，然而就是个瓶颈的时候，这个问题就比较尴尬了，对吧？

你说整个团队能力具备了，但是我整个需求路径还没有打通，我们其实在做敏捷转型或试点过程中，也就会也会引导团队说怎么样跟一些客户直接去就也没有客户进来能跟客户去进行沟通，能够去了解客户的一些需求。

而且我们发现跟客户接受之后往往会遇到以前会通过这种商务的角色和售前角色把需求给传递过来，这传递过来之后，我会发现他和中间很多角色在扮演的是一个需求的搬运工，而不是需求的分析师。

真正的，需求分析师其实往往会根据客户提出来的一些方案性的东西，去反推他的需求痛点到底是什么，然后再结合我们的产品规划，看看我们的产品的方案能不能解决他的痛点，可能往往跟他提了一个痛点，是这个方案是不一样的，非常就需要我们能够真正去了解客户，了解他的业务，然后能够去分析到底是客户，说现在你给我在系统上加一个什么样的功能，他加这个功能加这个按钮，他目的到底是什么？

可能我换一种方式就能够解决，我们以前更多的是能把这需求直接搬运过来，然后让大家去做完之后交给客户，刚开始用的觉得很爽，过一会又觉得这样做不是很好，又换一种方式，对我们往往在这个过程中就耗费了大量的时间，就会让整个需求缓解，变成了一个瓶颈，需求变成瓶颈的时候，我觉得一个团队的入口就价值的入口变成瓶颈了，它很难有一个高的产出。

所以比较关键的两个点，一个是输入，再一个是输出，那么现在收入这块变成了问题了，这个就是非常需要给团队赋能，就跟他说你现在让这个产品经理或者让一些需求分析师一下子做到某一种程度，他可能直接就死给你看了。

所以我认为在敏捷转型过程中往往就是赋能，特别是有些组织它有专门的 pmo的部门，它的定位就是说是一个附农中心，有时候也是因为是卓越中心，它其实就是要不管是自己内部去赋能，还是寻找一些外部的专业的人士给团队去赋能，其实是让团队具备一定的能力，能够和整个的敏捷转型的，包括是敏捷团队能够去达到他那样的标准，才能够让整个团队的产出高一些，或者让他的瓶颈持续突破。

我突然间有一个疑问阻碍就是咱们的产品同学去到现场跟客户待在一起这件事情。当然这可能是个假设这件事情，它最大的就阻碍是什么呢？假设你现在的权限足够的大，然后可以去做成这件事情，它的阻碍是什么？然后假设一个人去办成这件事情，从开始到跟客户聊城把反馈拉回来，大概会需要多久的一个时间？

因为我觉得在多数人就后面，你我需要去给他形成能力上面的一个培养，我可能服务的是规模化，也许有大部分人缺这一部分的经验，但是这条路子现在能不能打得通，阻碍它的点是什么？

根据以往的我收集到一些情况来看，倒不是说有什么这个公司层面的一些阻碍，其实公司非常鼓励大家去跑客户现场的。

那一方面我的理解对于我所了解的情况，我分析一方面是跟努力有关，因为很多这种这种类型的客户，他需要他可能对自己的问题或者自己面临的这种业务不太了解的时候，其实是需要我们一些公司的人员能够站在客户的角度去帮客户梳理好他的业务，分析他的问题在哪里，然后提出一个整体解决方案的，整个整体解决方案可能并不只限于某一个产品，它可能涉及到多个产品，甚至涉及到多个公司，这个层面其实就很难说有我们某一个产品的产品经理去整体去规划了。

对，这往往是需要现场或者是客户那边有一个比较强的整体的解决方案，这样的一个角色能够去知道整个方案是什么样子，解决了客户的什么问题，这个方案在我们的产品中如何去实现，等到这块我觉得是目前我们这个团队面临的一些相对薄弱的一个地方，可能只站在自己产品角度去考虑客户的需求，而不是站在整个客户的痛点，以及说他的整个解决方案层面去考虑他的需求，所以往往抓回来的需求有时候是不是那么的准确，也有时候抓捕的需求可能经过好几次反复的沟通之后才能够比较了解客户真正的痛点是什么，这是一个。

第二个问题，我们现在所处的行业其实跟它不是 c to c的话可能直接接触客户，我们这行业它并不是to c它属于这种to b这一类型的，你有时候跟客户的沟通，其实是要通过一些这种比如说商务的一些角色去带入过去啊，往往是说有时候跟客户之间的这种沟通说是需要有中间的人一起去引荐去带你去见客户。

但问题是客户往往不是第一手的用户，客户可能就是甲方，他比如说to b我某个公司，我采购了你们的把公司的产品或者服务，我有钱，我买了这个服务，但我不是最终用户，对。

所以我们有时候接触到的它不是那种真正使用的产品和服务的用户，往往是客户会告诉我们说我告诉你们有什么问题，这个问题是什么样子，我们在这样的情况下，有时候比较难以去接受到甲方真正的用户，因为有时候他们用户也是存在一些这种比较难处，达到他甲方的一些原因。所以这两点是目前相对来说比较影响我们真正达到需求的一两两个因素。

这个部分其实其实我是我们其实也有这个问题，当然我们这个企业的模式它也并不是一个to b的模式，呃只是说自己我个人的工作，我是在企业内部做敏捷教练，其实我个人是一个to b的模式，所以我感觉这一点确实是非常痛。痛在什么？我们大家都知道，我们如果你做一个组织，你会把你最重要的人员放在哪？悟空你以前做创业创业公司，你们花重金招的架构师，你放在前线还是放在后线？

在办公室肯定。

对吧？

所以你看当我们自己换位思考，我们做老板的时候，我有这个资源，我一定放在我的产品线，为什么我产品线是这一花一分钱可以挣100分钱，如果他成功的话，他肯定是这个模式，所以我一定不会把我的最牛的人最脑子最好用的人，不管是业务分析还是架构设计，我都不会放在一线去，因为我方一线也许这个生意它不一定成对吧？

所以它本身他本身是个悖论，就是在庆庆讲的这个人去不去客户现场是，什么样的人什么样的水平的人去客户现场，它就是个悖论。

所以所有的to，b类的常见的模式就是最最之前你让他去跑客户，然后他天天扎在客户，他堆了很多时间在，但是他带过来的东西效率是非常差的，但是我也要讲说我还说说我们的信念，因为我们既然做你的教练，我们一定是对一个成功时的样子模式，我们是有信念感的，不然我们为什么要就说告诉我们的组织，你们要反过来做或正规去做事情对吧？

那么我们看看我们认为正确的做法是做是什么？是首先比如说庆庆他在一个他们这种是科技公司，你科技公司最大的问题就是我有技术，你有业务对吧？客户你有业务我有技术，他就不知道我的技术怎么用，我就不知道我的技术怎么往他的业务里边堆，所以两边它都是很痛，那么很显然这个理想模式就是大家一定要密切的在一块去协作，而且都要把各自的精兵强将放进来。

所以在这件事情它可能更多的是理想主义的情况下，我们也只能假设说一个合理的模式，是我们的真正在客户角度的解决方案的人员，首先要是行业的专家，应该我们要重点的去培养他，他有一定的行业背景，他又有我的产品知识，然后这个人它的时间利用要比较高，对吧？它有方法论可以几次探访客户就会有比较好的收益，也不是说天天的我像我一个前线的现场，人家天天趴在那，客户现场搜集一些边边角角的优化需求对吧？

我们不要那个模式，我们更多要的有可能要的是一个咨询顾问的模式。

所以在我个人的信念和信仰中，我认为像我们这种科技公司型的，或者是我们做一些这种的咨询顾问类的工作，我们卖的产品本身，他钱他真正的面目应该是我们卖的一个服务才对，只是说这个服务我要帮助你落地，我肯定是用一些我的产品，这有机房有设备对吧？

肯定我要这样去给你落地，但是本身我一定卖的是一个服务，所以我认为我们谁我们科技公司青年科技公司好像听说也找了麦肯锡这样的，好像是吧，我不知道我以前的主和我现在的雇主都在找麦肯锡做咨询顾问，你看麦肯锡在干什么？

派一堆人竟然给我们出一个价值百万的PPT对吧？然后他有一些流水线建设，它有我的集成商，你们业内的这些中中小型的咨询顾问公司过来给他做一些其他的呃落地的服务，然后再把产品卖进来，其实基本上都是这个套路。所以我觉得我觉得这个模式在科技在我们属于it类的，我们已经享受到了。

那么我往传统行业去赋能的时候，我觉得大差不差，将来应该也是这个模式，只是说我们可能需要去等待一个合适的时机，让这一切顺理成章的发生。

包括我觉得我们要保有一定的信念，因为我觉得短期之内很难，你说服一个老板，你要把你的架构师放到客户，天天跟客户在一起，客户都不放他的对吧？田忌赛马客户放一个虾兵蟹将，你这个架构师就废了是吧？所以我觉得我们还是要乐观，这个有点像什么呢？有点像我不知道你们是不是都买接触过保险销售人员，其实你作为一个用客户来讲，你的需求是很复杂的，你看我家庭几口人对吧？

我这个孩子多大了，我的爸爸妈妈是一个什么情况，要不要做一个保险计划，这个是我的整体需求，但是你想想销售人员如果水平很一般的，对你情况不了解的，跟你说不上两句，就给你卖一个保险产品，就是保险产品还很贵，你可能买了过一阵子你醒悟过来，这个东西根本不符合我的需求，所以这种比较复杂的东西，保险行业它也会建议说我以一个什么理财规划师的方式进入到你的比如说岳先生我给你理财规划，把你全家的情况给你盘清楚，我就专门给你长期服务你，你需要什么我就给你配什么东西，该升级了，什么东西该增加了，我给你把金融计划做得很完整，甚至我可以把你的其他的财务的那个场景就给你规划到位，对吧？

我觉得我们好多 To b的业务，我们的甲方他其实也有这个痛，但是他并不知道你过来给我服务的这个人能够提供什么，包括我作为一个产品公司，我也未必愿意这么去做对吧？我不一定能投一个钱能得到多少回报，所以有的时候也不能太着急，我觉得企业也要安下心来稳定的去做业务。

从我个人来讲，其实前面青青也讲到说人员怎么培养，其实我觉得很简单，就是我们的公司内的这些人员，你都要知道你所服务的业务，你对这个业务要非常了解，然后你还同时比如是个产品经理是个研发，是个架构师，是个测试，我觉得要是一个是业务再结合自己的专业技能，包括我是项目管理的话对吧？

我觉得还是要往这个方向去发展。

有了这个东西，其实很多时候你的工作会作为乙方，我提供产品服务，我会更多的享受分享到客户成功的幸福，我觉得对于个人职业目标幸福感的实现也挺有价值的。

刚才咱们也提到说在敏捷转型这样事情中到底会有哪些困惑？其实我们现在点中遇到的有些问题确实是存在一些需求上的瓶颈，那嗯，对因为呃也的确是跟这个行业一个是相关，因为是跟团队的能力也是相关的，所以我确实觉得应该公司内部也应该是有这种赋能的这样的机制在的，而不光是说让大家自己去做一些这样的一些主动的改变，同时这种大家在愿意主动改变的同时，我们应该是要有一些富农的机制或者富农的这样的让事情去让大家去持续提升的。

然后再提到说敏捷转型本身价值上来讲，我不要同意菲菲刚前面说的，我们在这无卡环境下就是要去敬畏市场，要跟着市场去就是紧跟市场去调整自己，这是敏捷背后的一个逻辑，我们要能够跟着市场不断的去变化，去调整自己，让他能够去对这个市场可能做出反应，才能够去抓住市场，才能够在这个变化非常快的市场中就存活下来是吧？

所以长期来看就是说敏捷价值，我觉得就应该能够去拥抱市场，让市场去驱动产品的一个研发的，但是可能很多公司包括是很多团队是比较在短期内比较难以去看出很明显的一个变化。

我所了解很多咨询公司在给任何一个公司做变革或者是做辅导的时候，它都是一个长周期的过程，少的话也都需要两年左右多得花3~5年，对吧？

我们整个科技界有比较著名的，以前 Ibm给咱们某公司做这个变革是很长时间的，所以从我的理想来看，应该说企业需要有一些这样的耐心，能够相信自己选择了一个拥抱市场的一些方法，能够去用整个周期拉长去看，怎么样通过这种方式来引导，或者说是能够帮助对于公司走向业务成功这样的一个目标，而不是短期我觉得可能只有一些指标很难说是能够把这个事做或者去做成功。

非常赞同，我觉得庆庆最后的发言非常有水平，我让我很感慨，我觉得我们现在送礼物环节对吧？我非常感慨是因为我们前面也讲了组织怎么成功，企业怎么成功，我们其实是有些打开探讨的。

我觉得我的最后的收尾环节，我比较想送的礼物是说关于怎么去做职业选择，就是因为我们自己做敏捷教练，我们以其实日常遇到最多的个体上的问，个体人员他的员工他的疑问就是我怎么去做职业成长，我路径是什么？我哪里有我的价值感。我最近也遭遇我身边的关系很密切的小伙伴，他要离职了，寻找自己的梦想，我觉得非常开心。

那么我为什么要讲这一点？我觉得如果有兴趣的话，会是非常欢迎大家在科技公司在这个to b的业务里面去深耕。我觉得大的我们往大了说，国家说你科技赋能百业，你怎么赋能，你不就是to b你不就是科技和业务相结合，所以这条线上其实是有很多的发展机会的，而且它是一个越老越值钱的一个工作模式，对吧？如果你做你已经在软件行业里面，你有35岁、40岁45岁的焦虑，我都觉得往业务里面深耕，包括一个面向to b的，它都是一个比较好的职业选择，我觉得这个是一点。

第二点无论如何这个世界变化走到今天了，你肯定不能做流水线上的螺丝钉。年轻的听众，我们有些年轻听众如果听节目的话，如果你的岗位上你不知道价值是什么，你只能去天天负责拧螺丝的话，这个真的是表情包快逃。说到底就如我们做敏捷教练，我们做转型的人，我们希望团队是一个可以做一些决策的，自给自足的，有一定的承担责任的能力的人。

同样我们也希望说组织里的每一个个体，他本身是有自己的意见，他有自己的经验记忆，他能发表声音的，他能够作为一个大脑去跟其他的伙伴去配合去协作的。

所以我觉得嗯我认为这个时代新的时代是非常需要个性鲜明的，有自己的观点主张做事不遵循旧规律的人，你一看我就不愿意按照流程走，这个流程有问题我要改我要更好，我要更有效率。

我要知道更多，I want to know more，我觉得这种都是非常好的一个呃，未来的组织最需要的就是这一类的人，所以希望我们如果有一些年轻的听众大家有职业困惑的话，一个是你可以联系我们来上我们的节目，我们可以聊一聊，再一个就是希望可以从今天的节目里面就是收到一些信息，有一些有用的信息给到你，最后时间给悟空，你有什么礼物可以送。

ok我也送点礼物。

其实我的礼物也是想围绕的，就是说现在也越来越多的企业它在做敏捷转型，然后它可能有一些传统的一些职能角色，产品经理、项目经理，然后又新的会有什么po Scrum master。等等层出不穷，反正我最近也有同学来问我，就是说想怎么来能做一个敏捷教练，做一个好的scrum master。当然这种问题可能对于做变革组织，它从组织的维度上面来讲，说我要去设置哪些课程给服务到这些，我个人觉得它可以是一个有少部分人去趟出来的一些东西，因为我自己本身走的是这条路，就是企业没有怎么给我赋能，但抱着自己要给自己企业能够找到一些目标的一个情况之下，就是圈哪就去学什么东西，那是一条比较漫长的一个道路，真的是一个漫长的道路，大大大概有非常多年的实践经验需要去做这样的一个累积，然后我认为当自己设定的目标和去做验证的时候，这条道路基本上跑了一个小闭环，也就是说它其实本身没有一条就是说必须得具备这些东西，才能把这件事情做成，反倒是你把这件事情做成了之后，你回来去总结一下有哪些能力可能形成一些方案给到团队去用，更加能够服务于企业自己的这样的一个情况，有的企业它可能解决问题也不需要那么多的额外的支出，所以先花钱还是后花钱的问题。

怎么来说？我认为这些点来说的话，就是说更多在企业里面有意向愿意站出来的人多去释放自己的一些影响力啊。我的某位老师曾经说叫做你在公路上开车的时候，如果你要变道，你要先打转向灯，对吧？大家都不往出来站的时候，你要先往出来站一下，那就多往出来站一站。

对这个企业需要你就多占，然后你需要培训先垫钱就先垫点钱，可能你有一两个人做了这么一件事儿，你就大概有思路了，你还愿意为这个公司奉献一点的话，对吧？咱们的方案就出来了，但实在要是没有的话，业界也有一些思路对吧？

敏捷教练的3个垂直领域，还有4个大象限的一些技能那，课程多的是，但是这个时候就扯不清楚了，所以今天给大家最后一句话的礼物，如果你真的想做的话，实际上你就把它当成一种能力的学习，它并不一定会成为一个专门职业上面的一些主流，但是拥有了这些能力，你在任何的公司和任何的场景里面，你都处理任何一样的事情，你都是不会去做，不会有什么担忧的，今天的礼物就在这里送给大家然后嗯。

好，我们时间也差不多了，时间差不多。

就给大家道别。

欢迎大家对我们这期节目去做转评赞一键三连。好。

欢迎下次收听，下次再见，拜拜。

Bye bye。