真实案例故事:研发/IT部门如何推动业务方敏捷

2021-06-24 09:00:00
敏捷助理
原创
173

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

前奏

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


一个试点团队的Scrum master,很朴实的河南男孩,脸圆圆红扑扑的,带着些许河南口音,诚恳地问我:“王老师,敏捷能不能让兄弟们的日子好过一点?”我顿时心里一酸,至今还记得,他看着我,眼睛里亮出的那一丝希望。

当天回家的路上,我决定,我要为这些兄弟们做些根本性的事情。尽管这个事情在任何一家企业都是难啃的骨头。

酝酿

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

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

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

上船

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

从兄弟们的眼睛里,看到了一丝紧张。Demo后,研发部门高管问业务方领导和同事们的感受。

业务方领导说:“感觉很好,近距离,更清楚看到了进展。”

高管说:"希望你们能够对我们做的变革给予支持。"

业务方领导问:“你们还要我们给什么支持?我们提的需求你们能按时做完就不错了,还需要我们做什么?"

高管还没来得及讲话。项目群经理坐不住了:“你们定的发布目标确实不现实呀,我们完不成,你看,我们这几个迭代就这么少。”

业务方同事们也坐不住了,撕逼开始:“你们搞个敏捷,为什么产出这么慢?”

项目群经理说:“我们不慢,是你们定的发布目标压根就不合理!”

业务方同事们:”还不慢?你们为什么总是延误?!我们都已经延期新设了发布点,还是一再延误!你们说说,什么时候你们准时过?!”

项目群经理:“新设的发布点也都是你们逼的!”

。。。。。。

大家有站起来打的架势了,我站起身:"请大家都坐下,看一组数据再继续讨论。”

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


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

变革负责人打开了加班数据:“我们从前和现在,加班小时数没有减少。而且,有一个根本性的变化,现在大家是自愿加班的,从前是被要求加班。”

业务方同事们吃惊:“自愿?为什么?”



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

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

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

我跟变革负责人相视,他起身:“刚才你们问需要各位业务方同事们提供什么支持,如果你们认可这样的方式,希望以后的敏捷活动你们参与进来,这样大家一起把产品交付得靠谱些。"

业务方领导说:“没问题,但是需要我们参加哪些活动? 千万不要太多,没有时间。”

于是,变革负责人把我们准备好的流程框架讲解了一下,简而言之:PI计划,PI Demo和PII&A(Inspect&Adapt)。

业务方领导说:“可以,我尽量亲自参加。如果我参加不了,这些同事会代表我参加。”


启航

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

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

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

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

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

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

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

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

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

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

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

墓志铭:反向推动业务方变革的步骤

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

跟把大象放进冰箱里一样,研发部门推动业务方(产品需求提出方)变革,只需要四步:

第一:让自己的交付靠谱。自己的交付不靠谱,就没有资格改变别人。

第二:用数据说话,从对立走向信任。

第三:触发价值选择的谈判。

第四:修炼内功,提升自身的效能,加速价值交付。

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

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

不论你在哪里,也许你感觉一直在黑暗中潜行,日复一日,年复一年,不见天日,兄弟,记住汽车人擎天柱的一句话:

“总有一天,会有一个人从我们的队伍中成长起来,启动领导模块的力量,照亮我们最黑暗的时刻,总有一天,万众一心。”



兄弟,那个人也许就是你。

声明:本文源自六年前某世界500强客户的真实案例,向故事原型的兄弟们致以崇高的敬意!
联系我们
联系人: 柴老师
电话: +86 185 1045 6582
Email: clientservice@hardenx.cn
地址: 北京市海淀区善缘街1号立方庭1-105