[Day06] 团队系统设计 - 张力分析

某次参加站立会议,某位 PM 情绪激动的说:「我後天要跟客户回报进度了,但 A 同事这周请假三天,明天才回来,他手上的工作都没有进展,我後天是要开天窗吗?」此时团队的眼神全向我扫来,因为我是 A 同事的直属主管,此时,我空降这个团队刚满三个月。

我之前的文章有提过,空降初期,以观察与欣赏为主;这个事件暗示了「禅机」已到,我嗅到了改革的机会。在这个事件中,PM 身上明显有张力,张力会试图被舒缓,这是一个简单的张力-舒缓系统:
https://ithelp.ithome.com.tw/upload/images/20210921/20129624DnPnc39S6h.png

最直观的解法,就是赶快去问 A 同事,他手上的任务进度,然後告诉 PM 。如果采用这样的解法,PM 接下来就会得到启发,开始频繁的去追 RD 的进度,每天的工作负担变重,形成了新的张力;而舒缓之道就是,降低追进度的频率,过没多久,进度又开始不明,张力-舒缓系统变成了摆荡的系统:

https://ithelp.ithome.com.tw/upload/images/20210921/20129624XC8A4ETCEK.png

从上图来看,两种张力无法同时的舒缓,同时追问进度,又不能问得太频繁。这里衍伸的问题是,当 PM 的张力舒缓了,但 RD 一定会不堪其扰,因为没有 RD 喜欢每天被追着问:你的进度呢?

就这是典型的解决眼前问题,但忽略了「系统性问题」,让张力四处的碰撞。当然你可以说,我们可以在中间抓一个平衡啊,但其实这是一种回避处理复杂情境的推托之词。所以针对这个情境,我们该做的是:

创造具有「透明化」的专案推进状况特性的系统

我在另一个团队中遇到的张力,来自 QA 部门。某次,QA 同事带着烦恼来找我:「 B 同事交给我们验证的程序,时常在简单的正向流程就有 Bug ,导至我们双方必须来来回回好几次,影向产品的交付时间;我们也尝试过在实作前先跟他开会,提供很详细的验证步骤给他,一来我们的工作量变大了,二来他觉得我们在找碴。现在情况虽然有好转,但他产出很蠢的 Bug 机会还是很高。」
此时 QA 的张力舒缓系统如下:

https://ithelp.ithome.com.tw/upload/images/20210921/20129624A8Pd53ymZH.png

如同我上段所说,改善这个状况,紧盯 B 同事的工作绝不是好主意。最好的方法:

创造「降低出错率」的开发系统

每个团队会遇到的状况不一样,所以张力-舒缓系统也不同。在团队中常见的情况是,当系统不健康时,总会有某个成员会以增加工作量的方式,来让系统内的张力得到舒缓。用人的抗压性来解决系统问题,也太不人性。

我们最终想要得到的团队系统,可以这样描述:

一个高效的敏捷 Scrum 团队,具透明化、高品质是这个系统的性质。

如果你要的「禅机」一直不来怎麽办?这表示你的团队系统处在一个稳定态下,系统中的张力是让团队成员舒服的,此时进行系统修改,不仅无效,而且容易引起反弹。团队的最高优先任务,还是在於「产出」。如果产出都正常,成员也满意於现状,不要冒然的进行改革。张力总会累积,就耐心的等待张力需要释放的时刻到来吧!


<<:  day7 来管理 firewall 吧 (雷)没人知道答案的问题

>>:  DAY6 Figma Prototype

Bloom效果,又或是高光效果

文章内使用Unity 2019 LTS 目标 Bloom效果 Bloom 以下这张图片也是一个常见...

Day2 # Hello World

在第一天完成安装後,就可以使用 Go 来写程序啦! 作为一个工程师,一定要来段 Hello Worl...

Day05-入口管制(四)

前言 前面几天谈的都是纯文字的资料验证,像是信箱、电话等等,但很多 API server 除了文字资...

菜鸟日记Day 30-用JSON-Server自建云端资料库

铁人赛终於来到最後一天了! 为响应JavaScript菜鸟研究室的主题,最近一个月我们尝试串接过各种...

[day-11] 一切的基础! Python "运算式与算符"的运用(Part .1)

一、何谓运算式?   所谓的运算式是指『运算资料的式子』,其中代表着运算行为的符号称为 『算符』 ,...