全都重要,但全都没做!【上】

手把手教你解决复杂的团队组织问题,包括单堆等级、团队依赖、建立共识、减少 WIP 工作量、让公司有更好的优先管理方向。

本篇文章分为【上】【中】【下】三篇,欢迎点击下列链接查看全文:

我工作的上一家公司是一个处于发展中期的创业公司,面临很多问题。

这个小公司刚起步时做了很多优秀的软件产品,但现在举步维艰。所有工作都是重要事项,但没有一件能圆满完成,员工士气低落,久而久之很多都选择离职,工程和产品部门的人员流动率居高不下,很多人都觉得离职是必然选择。

意气风发的日子才过去没多久,今夕对比,越发显得当前公司的状态令人沮丧。没人知道公司怎么堕落至此,也没觉得做过什么重大的失误决策。就像俗话说的“温水煮青蛙”,一切都在不知不觉中发生着变化:这里错过一个项目,那里耽搁一个工作,发现了一个新的需求……

这种事情并不罕见,大家可能有过同样的经历。

如果是你,你会怎么办?

目录

发现问题

我在研究“全都重要,但全都没完成”这个问题时,我发现了一个好现象:大家都很沮丧,没人假装一切顺利!

  • 我们在同时间段内安排太多项目了。

  • 没人知道究竟哪个项目更具优先级(因为每个都是优先级)。

  • 没人知道哪些项目是正在进行的,哪些是计划中的,哪些是推迟的。

  • 所以我们决定“优先级”项目时并不了解情况全貌。

  • 这必然导致团队的关注点不停地转移,每周都会出现新的关注点(或遵循“会哭的孩子有饭吃”定律,谁的要求最迫切,就关注谁的问题)。

  • 因为关注度/可观察性不够,所以没人能看到项目中团队和部门之间的依赖,导致出现很多待完成工作(WIP),对项目的能力和技能配置错误。

  • 最终导致效率低下,成果不佳,公司上下士气低落,员工纷纷辞职——这是一个恶性循环。

但是!我们成功改变了这种情况。

我必须得说的是,整个过程长达六个月,需要相当大的投入,而且很艰难,但我们成功地把所有项目都拉回正轨,完成交付,并将离职率降低到接近零(从 50%的高点)。

所以,如果你觉得你也在经历这种苦恼或者你也在想办法解决,请一定要读下去~

解决问题

第 0 步:达成共识:承认存在问题

这一步看似简单其实不容易,我们必须要让所有人统一意见,认识到确实存在问题。

要先让大家认识到这是个问题而且必须解决,再提出解决方案,这样达成共识之后,就只需关注执行解决方案和成本/权衡。所以,我把这一步叫作“必要前提”。团队全员都认为存在问题,知道当前项目都未完成,影响合同和功能的交付,阻碍公司整体发展,会影响所有部门(包括销售、运营、产品和工程部门)。

全员意见如此统一的原因之一是我们已经换了两个产品主管和一个工程主管了。大家的工作体验告诉他们:这里的一切都需要改变。所以,我不需要说服任何人,而且我自告奋勇来承担这份工作,因为没有其他人想接手一个注定会失败的项目。

但这都是我喜欢且一直在寻找的不对称项目。如果能解决不对称项目,就能前进一大步,就算解决不了,也是一次很好的学习机会,没人会因此责怪你。毕竟,他们都在问题还没解决好的时候就辞职了。即使是微小的进步也值得肯定。

我的建议是:如果有机会,要主动参与不对称项目,赌一把。

第 1 步:为所有工作建立一个统一视图

在解决问题之前,要先理解问题的范围。

既然问题的核心是“什么事儿也没做成”,那就得从头开始:我们要做什么?大家的期望是什么?有哪些正在进行的项目?目标清单是什么?

我们的“工作”可能在很多地方隐藏着。我们在多个 Jira 板上记录并跟踪技术工作,也用电子表格记录了一些项目,但还有一些项目是以非正式的形式存在着。例如,有人提出一个侧信道请求,工程师由于抹不开面子,同意偷偷帮忙做,这就是完全由工程师发起的项目(重构、迁移等),公司并不知情。还有一些项目是因为高管有 OKR。另外,每个团队都有书面清单,记录用户请求的功能、bug 修复和主要举措。

我们把这些内容全部整合成一张电子表格,无差别地收集所有信息。统计结果显示,我们这个近 40 人的产品和工程团队竟然有 300 多个项目。经过审查,有些项目是重复的,有些已经没必要再做,有些请求早就关闭了,还有一些项目是大项目的增量部分。

经过几轮筛选,只剩下 140 项独立的任务/项目,并将这些项目最终归类为 20 个主题。

电子表格里还记录了项目请求人(主要利益相关方)、负责人、当前状态、是否可估算、期待完工时间(从业务需求角度考虑)等信息。

例如:

项目名称 利益相关方 紧迫性 密钥所有者 依赖
创建微件 销售、市场 1 月 3 日 400 万美元用户端合同 A 组 需 B 组、C 组协作,且完成微件前的项目。
增加用户可配置性 客户成功 N/A 在更新方面减少对工程部门依赖(每月约 15 个小时,节省 18000 美元) C 组 D 组需解决数据更新
搭建一个外挂(bot)来解决常见的入站问题 运营 尽快(尽管没有明确截止日期) 取消 3 个全职雇员(节省 250,000 美元)。 A 组 需要完成外挂框架,依赖 B 组和 D 组

这样做是为了把所有请求用一个表格清晰明确地展示出来,先不对项目进行评判,找到所有正在进行的、计划做的甚至是想做的工作。我们的原则是:“不在列表上则视为不存在”。尽管这个列表会长的棘手,但我们鼓励所有人把能想到的项目都添加进去,无所谓大小。重要的话说两遍:“不在列表上则视为不存在”。

在此基础上,我们才能实事求是的讨论目前的项目,确定如何处理这些项目。

第 2 步:创建并执行项目的比较标准

我们的另一个问题是:“所有项目都是优先级”。

传统的“优先等级”指的是管理软件生成的“高-中-低”三级,这是统筹工作最不好用的方法。这种方法有三个问题:

  • “高-中-低”不适用项目较多的情况
    如果有 4 个以上的项目,你就不得不给等级加倍,或给优先事项创建子类别。最终,你有一堆“优先事项”,不知道先从哪个着手。

  • “高-中-低”分级缺乏背景信息
    有些事项对有的人是“高”等级,但对其他人是“低”等级。即便是在同一个部门都有可能出现这种情况,何况是一个公司呢。因此,董事和经理们会发现各部门在互相推诿。例如:工程部门会认为重构代码库来提高效率或转换到新的数据库是优先事项,产品部门觉得开发新功能是优先事项,而销售部门认为给新的定制开发合同分配能力才是优先事项。更深层次的问题是:

  • “高-中-低”分级缺乏解决冲突的细节。
    “高”和“低”分别指什么?这种分级没有具体的细节和框架,如果出现冲突,怎么给不同事项定级?大多人说的“高优先级”指的是这个项目有点紧急且影响较大。“紧急”和“影响”这两个词都是可计量的参数,但不正式的传统优先排序反而忽略了它们。

那么,如果我们通过管理目标绕开优先等级呢?

有目标非常好,目标和优先级的关系就好像问题和解决方法的关系。有了目标,也就有了达成目标的方向,设置好自己的优先次序,接下来就只关心目标是否达成。

但目标不是协调层。即使每个人的目标相同,也没有办法确定一个达成目标的具体路线。如果你像我们一样有很多目标,就再次回到了原点:究竟哪个目标更重要?

所以你需要冲突解决机制和精力协调机制,如果两个项目发生冲突,要有一个标准来确定应优先处理哪个项目。

所以我们再回头看上文这句话:“优先其实就是该事项紧急且影响较大”。所以我们可以创建一个量化事项的紧急程度和影响大小的标准:

  • 紧急程度(Urgency) 要根据截止日期和依赖来判断。明天完成?还是两周内完成?项目需要依赖其他方推进吗?
  • 影响(Impact) 指的是该项目的潜在价值和实现该价值的概率。

这些定义适用于各种部门和团队。有了这两个参数,我们就不用再进行抽象的、形式主义的讨论,再没“所有事项都是优先事项”这样的可怕言论,直入主题,讨论项目的相对紧急程度和价值。

当然,除此之外,我们还需要考虑其他因素和参数。例如:战略价值、研发价值、期待用途、该功能是否有合同及销售协议等。但这些都可以归类进紧急程度和影响大小这两个标准。

这两个参数看似简单,实则不然。计算项目影响和概率通常是产品管理部门的主要工作。如果没有一手信息,就非常棘手,但我们没有时间去调查回顾了。领导团队采用了一些背靠背的数学方法来估计商业价值,产品团队可以在后台继续探寻更精确的数字。

如果想直观地看到效果,可以整理成下面这种 2 x 2 的图形:


关注影响大、紧急程度高的项目,避开影响小、紧急程度低的项目。注意标黄的项目:如果某个项目影响很小,你可能混淆了工作和进展的意思;如果某个项目紧迫性低,你可能高估了该项目的价值。

本篇文章分为【上】【中】【下】三篇,欢迎点击下列链接查看全文:

原文作者:Roman Kudryashov
原文链接:When Everything is Important But Nothing is Getting Done

推荐阅读
作者信息
AgoraTechnicalTeam
TA 暂未填写个人简介
文章
210
相关专栏
本专栏仅用于分享音视频相关的技术文章,与其他开发者和 Agora 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。