/ Team

走捷径的系统思考

这里的走捷径指的是在软件开发过程中,团队为了应对超出他们实际能力的工作量时会采取的方式。往往公司由于业务压力,要求团队做更多的时候,团队的能力所能交付的工作与实际的工作量产生了落差,团队为了能按时交付,只好使用一些秘密武器(比如,复制粘贴,在一个方法里堆代码等等),这样就降低了他们的实际工作量。

用系统思考里的因果环路图来表示,就是下图中红色区域的环路
shortcut-CLD
这是一个平衡回路。因为走捷径确实解决了当下团队工作过载的问题。但是,它还隐藏着另一个增强回路, 如下图
vicious-circle-cld
走捷径带来了代码可维护性降低,使得将来的工作量增加了,这就形成了恶性循环,团队将持续通过走捷径来应付工作量的持续增加。这是一个常见的基模:饮鸩止渴。

这个简单的道理其实大家都明白,为什么很多团队还是这样呢?我分析有几个原因:首先这个反馈是延迟的,成本增加不会立刻看到;其次是侥幸心理,比如,觉得将来不会再改这个代码了;第三,团队能力有限,确实不知道有别的选择。

但是不同人或者团队对在同样情况下,处理的方式也会不同,比如走捷径的程度或次数。其实是每个人心里有不一样的底线,有的人写代码的底线低,写代码很随意,能工作就行;有的人写代码的底线较高,走捷径也有限度。

Scrum应对这个问题方式是通过完成的定义(Definition Of Done)来限制大家走捷径。说白了,就是给团队设了一个共同的底线,再怎么走捷径也不能跨过这个底线。从而减少了这个增强回路的发生次数。

CI里使用可视化代码质量数据的方式来减少反馈的延迟性,让大家更容易看到走捷径的后果,也是减少这个增强回路的发生次数。

其实还可以通过培训来提升团队或个人的交付能力和工作效率,比如团队协作,澄清需求,单元测试,Clean Code, 识别Code Smell等。这样工作量的落差减小了,这就形成了一个平衡回路:
training-cld
但是,这里还存在着另一个增强回路:“既然走捷径可以应付,干嘛要去费劲去培训,而且还不知道什么时候有效果”
shift-burden-cld
这里走捷径和培训两个平衡回路,一个是短期,一个是长期。走捷径会使人缺少培训的动力,两个平衡回路间形成了一个增强回路。这就形成了另一个基模:负担转移。

在我看来,这是许多公司常见的问题。究其根源,这些公司里都缺少人关注在团队或个人的能力成长上,所有人都关注在更具眼前利益的“事”上,没人关注在“人”上。很多公司都有Line Manager,比如开发经理,测试经理之类的,但这些经理工作起来更像是项目经理,产品经理。

我觉得解决这个问题的方式,需要像Scrum里有Scrum Master一样,需要有人关注团队能力的成长,加强培训的平衡回路,可以是Manager,Coach等。对于团队或更大的组织,需要把学习作为重要战略,制定长期的策略关注在团队能力的成长。

最后,我还是希望读者朋友能看到这张图没有画出来的部分,可以从不同的视角来解决这个问题。欢迎提供你的想法。

Jackson Zhang

Jackson Zhang

Odd-e敏捷教练,主要涉及组织,团队,产品,技术,工程实践等,曾为多家知名企业提供教练与培训服务。译有《用户故事与敏捷方法》,《.NET单元测试的艺术》和《实例化需求说明》。擅长工程实践(如测试驱动开发,单元测试,重构,持续集成等),产品探索(Impact Mapping,Pretotyping,Lean Startup等)与团队协作。zbcjackson AT gmail.com

Read More