用“账本”来记录技术债务

Dec. 15, 2017, 11:03 p.m.

一年多前,团队规模起来了以后,有一个现象越来越明显,常常为了赶工期,然后不断地进行打折,比如说:

  • 前端的数据校验先不做
  • 这儿的 JS 提示也可以先不做
  • 这是和用户体验相关的,先不做,先保证基础功能可用
  • 这儿的数据查询的代码有点性能问题,先不优化,以后有问题再说
  • 自测了就直接提测吧,这次先不 code review 了

要说原因,可能有很多:

  • 产品那边变来变去,事先没说清楚,相当于变更
  • 原来的代码有坑,对这个版本的功能有影响,需要先修复
  • 有同事离职了,人事部门不给力,人手没及时补上

而且交付了以后,大家都认为这是完成任务了,就开始下一个任务了,然后就是这样一个循环:

  • 任务总是很难按预期的工期和质量完成
  • 要修复的 Bug (以及需要优化的小细节)越来越多

这些都是欠下的技术债务,这里我主要分享一下,交付之后的问题,当时我认真地分析了下:

  • Bug 的出现是无规律的,虽然 Bug 始终存在,需要条件触发,这和项目的运行有关,使用的人多了,增加了 Bug 出现的机会,也就是说修 Bug 的任务是一项无规律的事情,虽然 Bug 也有优先级之分,但是积累得多了,紧急和中等的数量也不能忽视,这里的关键点是,要让这类任务变得尽可能的可控
  • === 当时我主要采取了以下几点办法 ===
  • 首先,和小伙伴们明确,这一版本的任务并没有最终完成,是预交付,不是最终交付
  • 预交付结束后,为了避免被别人追债,就需要主动地开始还债
  • 记录下那些未完成的需求
    • 分解到每个还债人
    • 落实到具体的还债日期
    • 我们称为《 XX 版本账本》
  • 适当地加班
  • 在 Teambition 中使用独立项目来进行任务管理,并非在原来的迭代中划分子任务,这么做有2个原因
    • 一个是重视还债这个行为,作为独立的事情
    • 另一个是在视觉和心理上做减法,避免呈现过多的任务项,导致小伙伴们心理压力过大

总结

技术上的问题,最终还是由技术来解决,主动地去做是大于被动地去做的

当 Bug 被动地发生时,很多隐形成本已经出现了

返回首页