真实案例故事：研发部门反向推动业务方变革

摘要：几乎在任何国家，任何企业，任何组织，持续多年，听到研发兄弟们热议的话题：我们自己敏捷了，如何逆向推动业务方变革？实在是难啊。尤其是当你没有权利的向上游变革的时候。

几乎在任何国家，任何企业，任何组织，持续多年，听到研发兄弟们热议的话题：我们自己敏捷了，如何逆向推动业务方变革？实在是难啊。尤其是当你没有权利的向上游变革的时候。

1.前奏

六年前曾经在一家企业做SAFe规模化敏捷大型Program（项目群）级敏捷咨询。刚去的时候，整个研发部门都在抱怨：发布日期是业务方拍死的，范围是业务方定死的，所有的需求都必须交付，明知不可能，也只能朝前冲，延期，加班，延期，加班，延期．．．年复一年，日复一日，通宵达旦。

一个试点团队的Scrum master，很朴实的河南男孩，脸圆圆红扑扑的，带着些许河南口音，诚恳地问我：“王老师，敏捷能不能让兄弟们的日子好过一点？”我顿时心里一酸，至今还记得，他看着我，眼睛里亮出的那一丝希望。
当天回家的路上，我决定，我要为这些兄弟们做些根本性的事情。尽管这个事情在任何一家企业都是难啃的骨头。

2.酝酿

第二天，我跟变革负责人谈了推进业务方变革的话题。他是九型人格里的6号人格，细致，认真，是悲观，担心，怀疑很多。（btw，曹操应该属于六号人格）。他说：“不行吧，怎么可能呢？我们这么多年都是这样的。” 我说：“咱们逐步来。现在团队已经开始从行为上固化了流程，思想上也开始上道，工作士气比从前高很多。我们邀请业务方来参加PI（规模化敏捷框架SAFe术语：Program Increment）的Demo，让他们先感受到这些变化。”

他同意了。我拉他跟整个研发部门的高管谈了这个事情。高管是九型人格里的8号人格，决断，命令，掌控一切。（btw，任正非应该属于8号人格）。虽然他对业务方没有直接管理权，但他同意这个提议。我说："需要您亲自参加这个PI Demo会。" 他大手一挥：“好！我去！”

最高领导对变革亲力亲为，是变革得以成功的首要环节。

3.上船

线下，我跟几个做Demo的兄弟好好准备了一下，也跟变革负责人准备了一些数据，并演练了会上要怎么谈。第一个PI Demo开始了。

从兄弟们的眼睛里，看到了一丝紧张。Demo后，研发部门高管问业务方领导和同事们的感受。
业务方领导说:“感觉很好，近距离，更清楚看到了进展。”
高管说:"希望你们能够对我们做的变革给予支持。"
业务方领导问：“你们还要我们给什么支持？我们提的需求你们能按时做完就不错了，还需要我们做什么？"
高管还没来得及讲话。项目群经理坐不住了：“你们定的发布目标确实不现实呀，我们完不成，你看，我们这几个迭代就这么少。”
业务方同事们也坐不住了，撕逼开始：“你们搞个敏捷，为什么产出这么慢？”
项目群经理说：“我们不慢，是你们定的发布目标压根就不合理！”
业务方同事们：”还不慢？你们为什么总是延误？！我们都已经延期新设了发布点，还是一再延误！你们说说，什么时候你们准时过？!”
项目群经理：“新设的发布点也都是你们逼的！”
。。。。。。
大家有站起来打的架势了，我站起身:"请大家都坐下，看一组数据再继续讨论。”

变革负责人给大家看了敏捷启动前，和敏捷启动后效率数据，说：“看到了吧，我们从前就很慢。敏捷让我们每个迭代都知道自己有多慢，而从前我们过了很久才知道慢。其实我们从前就在带着乌龟壳跑步。”

业务方同事们质疑：“听说，搞了敏捷就不加班了，工程师现在是不是不加班了，所以这个PI你们做得少？”

变革负责人打开了加班数据：“我们从前和现在，加班小时数没有减少。而且，有一个根本性的变化，现在大家是自愿加班的，从前是被要求加班。”
业务方同事们吃惊：“自愿？为什么？”

项目群经理：“从前，我给他们设定交付日期，我要求大家统一加班。现在团队自己做迭代计划，自己承诺，每天进展有落后，他们就主动留下来冲刺。”

业务方同事们一片沉默。1分钟后，业务方领导说：“敏捷这个东西，我们不懂。但是你们现在这样的工作方式，我觉得不错。可是，我们没有办法，市场就是这么残酷。”

会场一片沉默。空气中弥漫着尴尬。兄弟们一脸失望。

我跟变革负责人相视，他起身：“刚才你们问需要各位业务方同事们提供什么支持，如果你们认可这样的方式，希望以后的敏捷活动你们参与进来，这样大家一起把产品交付得靠谱些。"
业务方领导说：“没问题，但是需要我们参加哪些活动? 千万不要太多，没有时间。”

于是，变革负责人把我们准备好的流程框架讲解了一下，简而言之：PI计划，PI Demo和PII&A(Inspect&Adapt)。
业务方领导说：“可以，我尽量亲自参加。如果我参加不了，这些同事会代表我参加。”

4.启航

第二个PI计划开始。几十个兄弟们第一次这么近距离接触业务方同事们。

PI执行期间，我跟变革负责人、每个团队的Scrum master，再次整理数据，整个项目群这几个迭代逐渐交付稳定，而且有了缓慢上升的趋势。我们做了发布预测，预测的发布时间都把兄弟们吓了一身冷汗。按照这个进度，发布遥遥无期。发布时间不变，范围不变，团队效率不会飞，这是个死胡同。

我和变革负责人、项目群经理、高管讨论如何钻出这个死胡同。大家决定，在第二个PI I&A（Inspect and Adpat）会议上动手。我们事先演练了一下怎么触发这个谈判。

I&A会议开始。业务方同事们到齐。我环顾了大家的眼睛。兄弟们仍旧有些神色紧张，业务方同事们很平静。

项目群经理结合每个产品的PI和迭代交付数据，介绍了整个项目群研发效率的稳定和缓慢上升的趋势，业务方同事们纷纷点头赞许。

接下来，他又讲解了每个产品发布预测的时间。业务方同事们大惊失色。纷纷说，“这个时间，杀了我们也无法接受！”

唏嘘了几分钟，空气凝固了。

项目群经理继续：“大家已经看到了，兄弟们已经尽力了，现在虽然有缓慢上升的趋势，但是短时间不可能直冲云霄。如果时间不能延后，大家有什么其他的办法？”他走到story map墙，指着墙上待发布的卡片：“这些需求卡片，我们能不能一张一张看一下，是不是一定都要在这个发布做？”

业务方同事们围过来，一张一张开始看起来。优先级排序就这样自然的开始了，有的卡片往后移动，有的卡片往前移动，有的卡片甚至破天荒移到了垃圾桶。

就这样，多年以来，所谓的所有需求都要做，一个都不能少，终于，有的进了垃圾桶！

对于产品而言，如果一个需求都不能少，那么产品一定是个定位不清的大杂烩。选择不做什么，永远比选择做什么更重要。

5.墓志铭：反向推动业务方变革的步骤

我坐下来，看了看会场那个兄弟，当初他看着我，问，"敏捷能不能让兄弟们的日子过得好一点？"，现在他的眼里明亮无比。我为他的明亮而感动。

跟把大象放进冰箱里一样，研发部门推动业务方（产品需求提出方）变革，只需要四步：
第一：让自己的交付靠谱。自己的交付不靠谱，就没有资格改变别人。
第二：用数据说话，从对立走向信任。
第三：触发价值选择的谈判。
第四：修炼内功，提升自身的效能，加速价值交付。

这个过程中，不是一蹴而就，有的时候，也许你不得不放缓，中庸一些。

中庸是中庸者的通行证，变革是变革者的墓志铭。有时候，暂时和表面的中庸，是为了长远和根本性的变革。

不论你在哪里，也许你感觉一直在黑暗中潜行，日复一日，年复一年，不见天日，兄弟，记住汽车人擎天柱的一句话：
“总有一天，会有一个人从我们的队伍中成长起来，启动领导模块的力量，照亮我们最黑暗的时刻，总有一天，万众一心。”