很多团队在习惯性的说出“历史原因”的时候，更多的是一种为了掩盖团队当前对这样的做的原因一无所知的说辞。因为项目运行过久，团队成员的更迭，很多项目上存在的问题或者说现状，对于现在的团队成员而言，俨然成了一个黑盒子。
当你听到团队聊当前现状的原因里包括诸如“因为过去”，“以前就是这样”之类的字眼的时候，就要开始警惕了。
一个团队常常会过度依赖项目开始的时候制定下来的规矩，认为遵守了这些就代表着项目可以风雨无阻的运作的下去，而忽略了真正重要的东西。
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公司所有，如需转载请在后台留言联系。
