承认吧,你要的不是敏捷,你要的是加班

发布时间:2020-08-16

见过太多公司,打着“敏捷”的旗号,干着“加班”的事情,你的公司是否也是其中一员?今天就让我们花点时间,来扒掉伪敏捷的皮,也看看为何好好的敏捷,怎么就变成了加班。

1.jpg

敏捷的“快”与领导的“快”

我们在谈到敏捷的时候,一般会谈到“快”。

看到快,很多管理者瞬间高潮了——啊,快啊!我们要的就是快!

但这两种“快”是一个意思么?显然不是啊!

敏捷的快,讲究的是“快速交付真正有价值”的需求,所以这种快是一种相对价值交付层面的快,即原本你需要2个月才能搞懂用户需求,用了敏捷方法后,可以在1个月就开始交付有价值的东西给客户。

而诸位开始高潮的领导们的“快”是——今天下班提需求,明天上班就上线。

于是这两种不同的快,造成了双方(敏捷践行者 && 领导)的认知差距。

PS:从某些层面来说,领导的理解不能说是错的,毕竟“敏捷”也的确是有“身手矫健”的含义。

2.jpg

深入分析为何快不起来

稍稍深入分析一下,老板是真的不知道快速交付对客户有价值的东西么?肯定不是,甚至我认为对于老板而言,这个理念他恐怕是最能认真体会的。

既然如此,为何还有这么大的差异呢?

从过去的工作经验来看,发生这种情况的根本原因还是卡在了对敏捷落地的认知、人员相关能力不足、企业文化上,最终导致在实践的过程中动作变形。

对敏捷落地的认知

有一部分管理者认为,敏捷转型、落地,这本身就是Scrum Master 或者敏捷教练的工作,其他人员(包括但不限于研发、产品、运维、UI/UX等)不需要做任何事情。

这种想法就类似于“文盲换了一副眼镜就能读懂红楼梦”一样的荒谬。

敏捷落地,不仅仅是几个敏捷实践执行起来就行了,而是需要从理念和习惯上让团队接受,并且以此来改变团队的开发习惯,从过去的Big Bang形式的交付,转变成敏捷推崇的增量-迭代的形式交付。这才是敏捷落地的根本。

在这个过程中,我们需要改变团队的想法、做法,而这些都需要团队配合。这个过程本身就需要多角色、多角度配合,单纯SM能做的事情太有限。要知道,SM 能做的仅仅是教导、辅导团队在流程上面进行改进,而敏捷作为一个系统工程,单纯流程改变,是远远不够的。

相关人员能力跟不上

这点可以直接体现在流程的流畅度上。如果真的要说,大概可以从技术能力不足、产品能力以及管理能力不足三个方面。

技术能力不足,就不用说太多了。基本的TDD、CI都做不到的开发团队,你希望他能“快速响应”,基本上就是痴人说梦。在这种情况下,为了做到快速响应,唯一的选择,怕是只有“加班”了(某种意义上,也是快速响应,但这种快速无法长时间持续)。所以从某种意义上来说,研发人员算是受害者,也算是事件的原因,看你从哪个角度观察。

PS:这里有一个很有趣的现象。有时候研发不做工程实践是因为工期太急,没有时间进行工程实践。但是没有工程实践却又会进一步拉长工期。我将这种现象称之为“工程实践与交付悖论”,即想要省时间,结果还是浪费了时间。

而产品能力不足,更可以说是这件事情的核心因素。

国内互联网企业,有一些产品经理被我们戏称为“原型机器”,不是没有道理的。这些所谓的产品经理,每天干的事情就是去画图,从Axure 到墨刀,从Sketch到 Balmasiq,一个个用的那是风生水起,乍一看还真的有“原型在手,天下我有”的感觉。

但是,如果你把这些放一边,让他们去将产品的业务逻辑通过影响力地图进行分析一下的时候,你会发现他们的能力匮乏到让你惊讶,甚至没有办法理解一条完整的价值链。问他们为何如此设计,得到的回答是——业内都这么做,或者说老板想要,或者就是一句“我就是这么设计的”。

这还只是在单个产品经理层面,如果你要把这个级别拉高到产品总监的级别,你会有更让人背后发凉的感觉。

在这种产品水平之下,产品经理是没有能力将业务进行拆分,并确保拆分的部分可以分批次交付,更有甚者对MMF与MVP的功能都不能正确区分。因此,产品设计出来的结果,就必然成了需要大块交付,甚至一次交付的内容涉及到多条价值链。这最终导致了每次产品交付量都会有各种交叉,以至于“不是我们不想分批次交付”,而是“如果分批次交付,产品功能就不全”的情况时有出现。

用一个比喻来说就是,敏捷需要的是步枪,通过单次发射(发布)以及发射后的客户反馈来快速调整方向,最终在多次发射后,最终满足用户真实需求。如果产品业务能力不足,就会导致无法使用步枪(无法单次发布小需求),转而使用霰弹枪(一次性发布若干没有关联的需求),并希望可以在这些需求中蒙中几个客户需求。

至于管理能力不足,本质上并不是敏捷才有的,因为这种管理无能并不会因为不使用敏捷而消失。

这种管理能力不足主要体现在对研发工作的理解。

研发本质是一种创造性工作,而且这种创造性工作一定是非线性工作。即无法通过长时间加班、对员工施加高压就能解决的问题,更不是一个1+1=2的简单计算。除此之外就是所谓的“外行指导内行”,即领导是万能的,什么都需要指点一下。这点在产品研发层面是行不通。研发或者产品被打断后,需要花费更长的时间重新集中精力,这种浪费是很可怕的。当然,比这个更可怕的是,很多管理者不仅觉得这不是问题,反而还会沾沾自喜自己又“帮助了”团队进步。

其他的一些低级管理错误,凡是能打击到团队积极性、认同感的做法,都可以在管理能力不足场景下出现,这里就不再赘述了。

上述三种能力不足,对团队的影响由小到大,解决的难度也是由小到大,请各位自行对照。

企业文化

企业文化比较好理解,用一个极端的简化模型来说就是问责模型。

如果企业文化对“做错事”这种现象的态度是深恶痛绝,那么在这种企业中就会有很多评审步骤。这些企业寄希望于预先的多次评审来减少最终对市场的误判。

这种做法不能说有问题,但是这种做法强依赖于评审者对市场的认知与感觉。也就是这位评审者是“产品是否正确”的保证,而且常规情况下,部门或者小组最大的负责人,一般都会成为这么一个角色,不论他是否真的专业。这点也和前面所说到的“问责文化”是比较贴合的。

先不谈这个产品最终交付是否正确,但是评审者的岗位,就会非常明显的在整体研发流程中增加一道门(Gate),而这道门是不能逾越的,这就很大程度上导致工作的流动(Flow)受到影响,进而影响开发节奏、交付速度;若再加上中途需求的变化、增加一般也不会根据时间盒来进行的话,整个产品、研发、交付流程彻底崩坏,最后不论是回到门径还是瀑布,都会让敏捷落地无法进行。

3.jpg

扒掉伪敏捷的皮

都已经谈到了这里,下面还是让我们来扒掉伪敏捷的皮吧。

我相信大多数使用敏捷的团队、组织的管理者,都是希望敏捷可以为他们带来一些变化,否则他们也不会承担着风险来引入一项新的事物。但是很多情况下,这些引入敏捷的人,由于对敏捷的认知的缺失,单纯认为敏捷就是快,而不是将敏捷视为一个需要全体成员共同努力才能实现的东西。如果这是引入敏捷的第一步,那么敏捷落地,从开始到失败,也就是肉眼可见的了。

从我们上面的分析来看,影响团队、组织进行敏捷落地的三个方面——对敏捷落地的认知不足、人员能力不足、企业文化——但凡出现一种,都会让真正敏捷分崩离析。

对敏捷落地认知不足,你会无法得到支持,甚至这些支持你是永远无法获得的,你直接陷入孤军作战的境地;人员能力不足,导致你短时间内无法让团队产生变化,最终走上被干掉的道路(见这里);企业文化缺陷,敏捷生存的基础土壤不足。

这些都会让你无法做到领导所需要的“快”。然后,请告诉我你能做的事情是什么?亲自写代码?亲自写需求?

其实们还有一些能做的,比如导入Scrum流程,比如导入Kanban,再比如使用一些自动化工具(这里我是真的不愿意将自动化工具说成DevOps 工具,工具和DevOps 中间至少差了10个Scrum)。这些工具和实践都一定程度上让你看起来好像更敏捷一些,但你总觉得哪里不对——每次迭代计划都会变、每次看板都不更新、每次评审都没有人来、每次回顾都成了茶话会。长此以往,你会开始怀疑自己能力,甚至开始怀疑敏捷是否真的有效,再然后就要走向“从入职到开除”的康庄大道。这一点都不意外,毕竟对一个伪敏捷来说,你还要求怎样呢?

所以,你重新想一下,你还能做什么?

别傻了,你能做的,怕是只能压迫研发加班了。通过增加工作时长,来满足领导对于“快”的诉求。有Bug怎么办?不要紧,我们加班修改;客户有要求怎么办?不要紧,我们加班完成;老板又想到一个需求怎么办?没关系,我们996;如果Blablabla?不要紧,我们加班!

你看,没错吧,加班才是伪敏捷的最终归宿。

至于研发累不累,产品爽不爽?管他呢,谁让他不是老板呢。


- ./main end -->

Copyright © 2020 All Rights Reseverd Designed by 5thspace.net      备案号:沪ICP备15017019号-1