业务敏捷这事儿，大家怎么看，有啥想法和困惑一起聊聊吧

这事儿我琢磨好久了，感觉“业务敏捷”现在真是个特别热的词儿，但好像每个人心里的理解都不太一样，我先说说我看到的和想到的,抛砖引玉吧。

感觉人人都说好，但到底啥是“业务敏捷”？

我记得最早好像是（ThoughtWorks的顾问们）他们提得比较多，后来不知道怎么的，就变成了一种“政治正确”，老板开会说要敏捷，业务部门也说要不我们敏捷一点？但仔细一问,发现大家想的根本不是一回事。

有的人觉得，业务敏捷就是开发跑得快，以前一个月上线一个功能，现在一周就能上线，这就是敏捷了，这听起来更像（技术团队的“小敏捷”）,就是开发那边自己玩的一套流程。

但按我理解，真正的业务敏捷，重点应该在“业务”这两个字上，它不是说技术团队加班加点赶工，而是整个公司，从市场、销售、产品到技术，能不能像一个整体一样，对市场变化做出快速反应。（《敏捷宣言》里其实更强调人和协作）但到了业务层面，我觉得就是：我们能不能用最小的成本、最快的速度，去试一个想法靠不靠谱？如果不行，赶紧换方向；如果行，就快速放大，核心是减少浪费，别吭哧吭哧干半年,最后发现做出来的东西市场根本不买账。

理想很丰满，但现实里的困惑可真不少

说起来容易做起来难，我观察和经历中,有这么几个特别现实的坎儿：

1. 计划还做不做了？ 这是最直接的冲突，以前公司靠的是年度规划、季度考核，一切按计划来，稳稳当当，现在说要敏捷，要快速响应变化，那计划是不是就废了？（很多传统行业出身的老板）心里就特别打鼓：没计划，那不成了无头苍蝇？资源怎么分配？KPI怎么定？业绩怎么保证？这就导致很多时候，所谓的敏捷变成了“带着镣铐跳舞”，上面还是要你承诺一个年度目标，下面却要求你随时转向,特别拧巴。

2. 部门墙咋拆？ 业务敏捷绝对不是某个部门的事，它要求所有部门同步，但现实是，市场部有市场部的指标，销售部有销售部的压力，产品和技术又有自己的排期，经常出现这种情况：业务上发现了个新机会，急需一个小功能验证一下，跑到技术那边，人家说“不好意思，这个季度的排期都满了，您得排队”，等排到队，三个月过去了，风口早没了。（这就像一辆车，发动机想加速，但变速箱和轮胎还按自己的节奏来）,根本快不起来。

   

3. 害怕失败的文化怎么破？ 敏捷的本质是“小步快跑，快速试错”，但这个“错”字，在很多公司里是大忌，一次实验失败了，可能就意味着资源浪费，老板会问“谁的责任？”，久而久之，大家宁愿不做不错，也不敢冒险尝试，没有容错空间，大家就会追求那种“看似完美、万无一失”的大方案,而这恰恰是最不敏捷的。

4. 考核指标跟不上。 我们还是习惯用“工时”、“项目完成数”、“代码行数”这类容易量化的指标来考核，但业务敏捷的效果，可能更体现在“避免了多大的损失”、“抓住了多快的机会”这种不太好量化的地方，如果用旧尺子量新事物，那团队肯定还是会奔着容易考核的指标去,敏捷就容易变味。

那我们能咋办呢？有啥可以尝试的思路？

虽然困难多，但我觉得这事儿还是得摸索，聊下来,大家觉得可能这几个方向值得试试：

• 别一上来就全盘颠覆。 可以先从一个小业务单元、一个创新项目开始做试验田，比如成立一个临时的“特战小队”，把业务、设计、开发、测试等必要角色聚在一起，给他们明确的授权和目标，但不对过程做太多干预，让他们用敏捷的方式跑上几个月看看效果，有了成功的样板,再说推广的事。

• 沟通，沟通，还是沟通。 不能各干各的，得建立一些简单的同步机制，比如业务方和技术方每周有个固定的“对齐会”，不聊细节，就同步信息：我们业务侧最近看到了什么新变化？你们技术侧最近在忙什么？有什么可以提前准备的？信息透明了,摩擦才会少。

• 转变对“计划”的看法。 计划不是一次性的，而是一个持续调整的过程，可以把大目标拆成一个个小阶段，每个阶段结束都回顾一下：市场变没变？我们的方向对不对？需不需要调整？这叫（有点像“滚动式规划”）,让计划本身也能敏捷起来。

• 从上到下要真正理解并支持。 这事儿最难，但也最关键，如果高层领导还是只要结果、不看过程，对短暂的失败没有容忍度，那底下的人很难有动力去变革，可能需要找机会让管理层也接受一些相关的培训或案例分享，让他们明白，业务敏捷是一种投资，短期可能有阵痛,但长期看是为了让公司活得更健康。

我觉得业务敏捷不是一颗吃了就立马见效的神药，而是一个需要不断调整和适应的过程，它更像是一种组织能力或者文化，而不是一套死板的流程，咱们也别想着一步到位，能在自己力所能及的范围内，推动一点点改变，让团队的反应能快上那么一点点,可能就是很大的进步了。

大家在实际工作中都遇到了啥具体情况？有没有什么好的经验或者更头疼的问题？一起聊聊呗。