黑盒项目之历史原因

摘要:

很多团队在习惯性的说出“历史原因”的时候,更多的是一种为了掩盖团队当前对这样的做的原因一无所知的说辞。因为项目运行过久,团队成员的更迭,很多项目上存在的问题或者说现状,对于现在的团队成员而言,俨然成了一个黑盒子。

当你听到团队聊当前现状的原因里包括诸如“因为过去”,“以前就是这样”之类的字眼的时候,就要开始警惕了。

一个团队常常会过度依赖项目开始的时候制定下来的规矩,认为遵守了这些就代表着项目可以风雨无阻的运作的下去,而忽略了真正重要的东西。

01. 误区

我最近在一个敏捷转型项目上,从对团队进行敏捷成熟度评估的时候开始,就不断的听到大家给我的回答包含着上面提到的词,可是当我问道:“所以大家保持这样的状态能够有效的帮我们解决问题吗?能够有效的对客户提出的需求和变更作出响应吗?”的时候,大家却哑口无言。

事实上,这样的事情并不只是出现在这一个团队中,我经历的很多团队也有类似的问题。

直到这个时候,我才意识到,很多团队在习惯性的说出“历史原因”的时候,更多的是一种为了掩盖团队当前对这样的做的原因一无所知的说辞。因为项目运行过久,团队成员的更迭,很多项目上存在的问题或者说现状,对于现在的团队成员而言,俨然成了一个黑盒子。而这造成的一个后果就是 — 难以掌控的“遗留系统”的产生。

其实原因也很好理解,毕竟一个团队的现状和知识对团队自己而言都是黑盒子的时候,外界又有谁能保证对这个团队知之甚多呢?

细心的读者看到这里也许注意到我上面提到了一句话“一个团队的现状和知识”。是的,很多团队在工作的时候会陷入到一个误区中,即只要沿着前人的路走,就一定是正确的。一个很有名的例子就是“萧规曹随”。可是这对于大家来说只是个表象而已,当我们真正思考这个问题的时候,我们应该知道,一个团队最重要的东西,应该是它的核心价值而不是日常的工作或者是代码的实现。

在项目里,我常常会和客户说“我们的最终目标是把价值传递给我们的客户”。在精益里有一句话叫做“Stop starting,start finishing”。程序员往往深陷于编码的快乐而忘了是谁提供给他们买面包的钱。这虽然是一句玩笑话,但道理确实是在的,如果没有客户,或者说,如果没有需求,那么我们编写代码又有什么价值呢?也就是说,编码也好,团队的运行模式也好,对于一个产品需求来说,不过是解决方案罢了。

而我们往往流于表面。

02. 领域问题是策略,解决方案是细节

很多人可能很不理解,“我们明明有代码,在遇到问题的时候可以通过 Impact Analysis 知道问题的原因和故障的逻辑,怎么能叫做‘黑盒子’呢?”。

不可否认的一点在于,代码是系统运行的根本,所以只要想,那么我们永远都能从代码里找到答案,可是,当面对问题时,我们能够多么迅速与准确的给出答案,才是真正意义上的保留了领域知识。在产品开发的过程中,重要的不只是过去的逻辑,还有一个需求产生的当时的原因与意义,以及这个需求接下来的传递。所以我们提倡 Kanban,Scrum,提倡用 Story Wall 来记录我们的 User Story;提倡 Automation test as documentation。

《架构整洁之道》里提到了“策略”和“细节”的概念,其认为“策略”是体现了软件中所有的业务规则和操作过程;而“细节”则是指让用户与策略进行交互,但是不会影响到策略本身的行为。个人认为在这里也同样适用。一个团队的组成也不失为一个由人组成的架构。

重复一下上面提到的观点“Domain knowledge over Coding solution”。过去,我们常常认为 IT 不过是业务的一个解决方案罢了,但是随着时间的推移,业务逐渐的转向数字化之后,我们并很难再坚持认为现在的 IT 只是业务的一个解决方案而已,因为此时,它已经变成了业务本身。而存在与产品中的领域知识便成为了业务。而我们现在所提到所有的内容,都是在当今业务数字化后,我们对于 IT 的认知也应当发生变革。

那么到了这里,真正的“历史”应该保留哪些呢?我的答案是一个项目的策略,也就是是什么形成了这个项目,也就是我们说的领域知识。它的重要在于,这是一个项目的根本原动力,没有它就不会有这个项目。

03. 如何保留系统的领域知识

在解决问题的时候,我们常常给出多种不同纬度的解决方案用以尽量确保“万无一失”。

比如“测试金字塔”从多个不同的纬度来保证系统的代码质量。比如“敏捷转型”从管理到技术帮助一个团队进行深入的改变。比如“敏捷成熟度评估”从“组织结构”,“需求管理”,“沟通协作”,“构建管理”,“简单设计”等多个维度评估一个团队的敏捷情况。

那么如何保留我们上面提到的最该保留的“历史” — 系统的领域知识呢?

以下也同样给出一个从不同角度出发的解决方案集合。

通过以上四个方面从不同角度保留一个团队的“历史”信息:

  1. Value & Management Practice:

    通过保留大到 User Journey,小到 User Story,记录用户的需求从无到有,从有到完成的整个生命周期。

  2. Value & Technical Practice:

  • 使用诸如“Gauge”,“Concordion”等工具使“测试即文档”的思想发挥到极致,每一个用户可以看到的 User Case 都是一个可以运行得出结果的 Test Case。

  • 持有“代码即文档”的思想编写可读性高的代码。

  • 持有“代码集体所有制”,团队中每个成员都为所有的代码负责。

  1. Collaboration & Management Practice:
  • 带有 “One Team” 的概念,团队承担职责,团队接收任务。
    团队共享知识,构建起自主学习自组织的团队文化,消除单点依赖、知识壁垒等问题。
  • 团队成员了解团队的现状与历史状态。
    1. Collaboration & Technical Practice:
  • 团队分享知识,定期的 Code Review,定期的 Dev Huddle 能够有效的保留代码的历史知识,与更新新的解决办法。

04. 后记

事实上,在思考“历史原因”带给团队的影响时,也想到作为咨询师加入到团队时,同样会为团队带来上述影响,如何确保咨询的过程与结果不会成为团队未来又一个新的“历史原因”也同样应该是一个 Coach 或者咨询师应该意识到的问题之一。

而我的做法就是,驱动团队自己产出答案、保持会议的高效进行、作为观察者与提出建议者、激发团队讨论等常用的手段。

而在这里提出这件事,也是为了给作为 Coach 与咨询师来到一个团队的朋友提一个醒,你同样也会为你的团队带来潜在的“历史原因”。

切记,如果一年之后你回访客户团队,询问新人你当初提供的解决方案时,对方的回答是“不知道啊,一年前有个咨询师提出了这样的方案。”这个时候你该警惕了。


更多精彩洞见,请关注微信公众号:ThoughtWorks洞见

Share

发表评论

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

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据