黑盒项目之历史原因

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

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

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

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。
• 持有“代码即文档”的思想编写可读性高的代码。
• 持有“代码集体所有制”，团队中每个成员都为所有的代码负责。

3. Collaboration & Management Practice：

• 带有 “One Team” 的概念，团队承担职责，团队接收任务。 团队共享知识，构建起自主学习自组织的团队文化，消除单点依赖、知识壁垒等问题。
• 团队成员了解团队的现状与历史状态。

4. Collaboration & Technical Practice：

• 团队分享知识，定期的 Code Review，定期的 Dev Huddle 能够有效的保留代码的历史知识，与更新新的解决办法。

04. 后记

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

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

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

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

本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。