Image

管理目标,而非指标

Avatar
陈 加兴
2020.01.03

X-Developer告诉你应该做得更好,如何做得更好,而不是要你来把X-Developer“用好”。这其中,最核心的就是提升您的团队观察、跟随和适应变化的能力。

客户故事

一位X-Developer用户问,最近我们业务和研发都有大量调整,导致团队成员对业务不熟,现在启动和完成指标的对比很难看,怎么办?

我就问:你期望的目标是什么?

用户:当然是真正地完成迭代的任务呀,不要表面的“更新成完成状态”,而是没有剩余工作量。

我接着问:那么,怎么才能“真正的完成”呢?

用户:就是看X-Developer团队报告“产出能力”这个图表上的完成数量呀,我从这上面就可以得到真正的完成的情况了。

我说不对,我们讨论的是“怎么做”才能做到真正地完成迭代任务,而不是“怎么度量”出真正完成的任务数量。

用户:这就是困惑我的地方了,怎么做才能提升完成数量呢?

我说,其实你知道如何提升,但是你的思路被指标困惑住了

用户:这个怎么讲?

我说,因为你的问题已经包含了原因——团队成员对业务不熟,因为指标的缘故,你没有进一步分析原因寻找解决方案,而是焦虑如何让指标看起来更好一点,所以,反倒得不到想要的结果了。如果先从这个原因着手,在迭代中安排一些业务学习任务,持续地观察启动、完成的情况,就可以验证“业务不熟”是否真正影响团队产出能力的因素,并持续地提升。

用户听了,觉得很有道理,但是依然没有缓解指标带来的焦虑:业务也不是一天两天可以掌握的,还有没有什么短期快速提升的方法?

我说,当然有了,比如现在这个浪费的天数,消除一半,就可以缩短交付周期时间,提升迭代的产出了。

用户说,这我也注意到了,目前我们从故事卡的任务切分,没有对准故事卡的持续交付,而是根据开发人员工作量去分配,没想到一度量,估算3天的故事卡,实际上跨了8天才转测,中间不但测试空了2天等开发,最后测试时发现的一个业务逻辑在设计是忽略了,导致这个故事卡不得不放在下一迭代交付。其实功能挺简单的,如果迭代前期,精力更集中一点,就不会出现这种情况了。看来我们还是先聚焦任务拆分的优化,持续关注改进效果,争取把产出能力提升上来。

这个真实的故事想必也是大多数企业管理者的经历。X-Developer早期试用者也问过类似的问题:你们这个产品是不是要团队有很强的执行力才能用好?我的回答是,X-Developer不是让你来“用好”,而是始终如一地告诉你你的现状是什么,和预期有多少差距。

X-Developer告诉你应该做得更好,如何做得更好,而不是要你来把X-Developer“用好”。这其中,最核心的就是提升您的团队观察、跟随和适应变化的能力。比如上面的案例,最核心的就是业务的改变,新知识的涌进,导致产出数量的回落,团队需要时间来学习、提升,才能“达成目标”。

你度量什么,你就“得到”什么

许多大组织花费一两年的时间从版本交付到迭代交付,然而迭代之后,发现不但效率没有提升,质量还下降了!最难堪的还是业务部门的反馈:

迭代,不就是把以前一个大需求,写成很多个小需求嘛,这怎么提升了产出?不是忽悠我们嘛。关键是因为需求变小变多了,我们要不停地提、不停地跟踪、不停地验收,研发可能效率是提升了,但我们业务的效率下降了,我们的感觉很不好。

究其根本原因,就是因为组织追求片面的指标:迭代交付周期。以下就是2016年我在一个不堪近一年来敏捷迭代交付“重负”的200人团队中的原因分析和改进建议:

这些原因是如何发现的呢?因为好的顾问,总是在现场,去发现第一手、最真实的数据,而不是根据听来的某个说法作判断。在这个团队的第一周,通过每天检查代码仓库的变动情况,发现从早上八点起,直到凌晨四点,都持续地有代码被提交上来!开始时,以为是需求量过大,或团队能力不足,再展开调查,才发现这个团队真实的工作状态是:白天做本个迭代的需求,晚上改上个迭代的线上缺陷。

现在已经9012年了,这仍然是许多软件团队的现状——而且是许多实施了“敏捷”的软件团队的现状——既无产出的提升,也无速度上的根本变化。这种“敏捷”没有改变什么,因为它没有从实际上为团队赋能——既没有给团队机会去洞察用户与需求,也没有真正教给开发人员高效管理任务的方法,这是作为一线管理者的无能。

为指标而指标的指标,往往是这一期达成的指标,然后埋下了更多的地雷。高绩效的团队是打造出来的,敏捷是一个动态适应变化的过程。提出有挑战性的目标,然后找到目标的障碍、浪费,尽可能地消除,并积累团队的知识,才能真正地在这个变化的时代构建起持续的竞争力。

开始赋能你的团队

X-Developer作为一款研发效能管理与提升的平台,沉淀了我们多年来帮助企业有效提升研发效能的观察方法与关注点,我们已经推出免费的社区版,从以下几个方面帮助研发团队走向有效管理:

  • 易于实施的代码提交规范:使得团队可以快速从代码中回溯需求与缺陷,加快定位代码和解决缺陷的时间

  • 关注需求价值的实际交付周期:落实到具体的提交与协同成员,帮助团队聚焦对需求的理解,减少过程中的等待与返工,使业务、研发、测试更快地协同

X-Developer的实施过程,正是促使您的软件工程实践不断走向标准化、自动化,达到持续交付的过程,也是促使您的需求管理不断走向价值交付的过程。作为追求卓越的领导者与管理者,为团队赋能,带领团队去达成挑战的目标,正是真正走向卓越的第一步。

Icon For Arrow-up