前一阵子,我们的知识开发(KD)团队在把知识交付给工程师(EG)团队进行决策分析器开发上出了点问题:知识的讨论时间太长,交付过程太慢。这样的后果是,EG团队会经常没有分析器可开发。

导致这个问题的主要原因,我认为主要有以下几点:

  1. 没有根据业务发展需要,制定一个知识的讨论范围。一旦知识点多了,知识团队则更倾向先对简单的知识进行开发,或者更随意地,先对自己熟悉的知识先进行开发。这样显然是不合理的。因为简单和熟悉的知识并不一定是最迫切需要上线的知识。同时,这样也导致越往后,知识越复杂,开发周期越长,交付速度越慢的情况。
  2. 由于没有第一时间找产品拥有者(PO)进行确认,开发出来的知识经常返工重新讨论,浪费了大量的时间。
  3. 产品拥有者职责不明确。尽管PO有权要求对知识进行重新讨论,但他并不对交付延期产生的后果直接负责。很多时候,他提完意见就去忙别的了。修改后进行二次或三次确认往往需要被动的等待,这样拖长了知识交付的时间。同时,由于他对交付延期所导致的后果并没有完整的认知,PO在进行确认时也显得不够重视。
  4. 缺乏交付标准和对讨论时长的约束。在明确提出一个知识需要被开发时,经验尚浅的知识开发者往往无法明确需要花多长时间来梳理和讨论,也无法明确需要什么样的资源来协助开发。由于他们潜意识中害怕由于他们开发的知识不够好导致产品出现问题,影响用户体验,他们往往容易陷入过度思考或过度设计中。

要解决交付慢的问题的核心,我认为如何优化决策流程的过程。而这个优化的目标是:又快又好。

我认同一种观点:公司的决策可以大致分为两种类型:快决策和慢决策。

  • 快决策 – 指的是可以并需要被快速做出的决策。这些决策通常是可逆的。
  • 慢决策 – 指的是需要一定时间研讨,谨慎做出的决策。这些决策通常不可逆,并且如果决策失误,后果相较于快决策更严重些。

对于我们而言,在产品研发过程中,大部分决策应该是快决策,只有极少数情况才需要慢决策。这主要是因为我们采取的是“小步快跑”的迭代方式进行开发。每次迭代结束,我们都有时间去审视当前产品存在的问题,并及时在下一次迭代中进行应对。知识的开发是高度可逆的,因为当我们发现一个分析逻辑是错误的时候,我们可以快速rollback。所以知识开发的决策过程应该是快速的,但问题就在于大部分知识开发的决策成了慢决策:他们耗时长,返工多,交付慢。

为了让知识开发的决策能更匹配产品开发的节奏,我们需要把这些慢决策变成快决策。于是,我重新设计了知识开发的工作流,并为新的工作流设计了一个简单的看板(如下图)。

结合工作流看板,新的知识开发工作流可以被描述成一下几个步骤:

  1. 所有想到的知识点(所有人,包括EG团队,都可以贡献知识点)首先会被贴到1号区域(待讨论区)。我们采用Lean Coffee的方式来投票决定哪些知识点将被率先讨论。这些知识点随即会被转移到2号区域(正在讨论区)。
  2. 知识点在2号区域都不能停留超过2小时。这个设置是基于我们的观察经验:一般而言,一个知识开发都可以在两小时内完成;如果无法在两小时内完成,基本就意味着我们需要额外的资源(如内、外部专家)参与讨论,这也就意味着这个知识有极大的可能会超过半天甚至一天时间完成梳理和讨论。
  3. 任何超过2小时都没有完成讨论的知识,都会从2号区域转移至4号区域(需要支持区)。如果一个知识在4号区域停留超过2天,这有可能意味着我们讨论它的时机还尚不成熟,这时候它会被重新移回1号区域。每天下班前,我和PO都会对待在4号区域的知识进行review, 要么统筹资源尽快安排更多人参与的讨论,或将其移植1号区域。
  4. 在2小时内完成讨论的知识,在通过PO的review后,会被移至3号区域(待开发区)。这些知识也会通过Lean Coffee的方式来决定哪些会被优先(在当前迭代或下一次迭代中)开发。
  5. 正在被(EG团队)开发成决策分析器的知识会被移至5号区域。
  6. 开发完成的知识被归档后,将从看板中移除。

新的工作流看板,能让所有人都能快速了解每一个知识点当前的状态。而我们所要做的就是保证2号区域的知识尽可能得少,并保证3号5号区域的知识充沛。

为了让新的知识开发工作流程更好地被执行,我们设计了一个简单奖惩制度:如果知识在2号区域超时滞留(即:即没有被及时转移至3号4号区域),KD团队将被集体罚1分;当罚分累计到10分时,KD团队需要请所有人吃饭。同时,PO作为reviewer也被划分到KD团队中。如果有因为他review不及时造成了超时滞留的情况,他将承担KD团队请客吃饭的费用。累计到10分后,罚分自动归零重新计分。(由于目前团队规模小,我们采用了更适合团建的惩罚方式;当团队具备一定规模后,罚分会与绩效考核挂勾)。

事实证明,新工作流是有效的。原先一个一般复杂度的知识,一个人需要2天左右才能交付给EG团队。而执行了新工作流后,一个人2天能开发3-4个知识。值得庆幸的是,从KD团队到PO,大家都已经慢慢适应了这样的决策节奏,知识交付的质量并没有受到影响,超时滞留的知识也变得越来越少。

发表评论

电子邮件地址不会被公开。 必填项已用*标注