我现在该怎么办？为设计变更做规划

我经常需要与人们讨论他们的系统设计、规划和架构。而很多时候，这样的讨论发生得太晚，设计要么已经实施，要么已部分实施。如果正在推进的设计被认定为并不适合当前情况，这会让人非常沮丧。

我理解在这种情况下会产生的沮丧情绪，但这正是我们 IT 从业者必须经常面对的事情，而以建设性的方式管理这种反应是一项关键的 IT 技能。我们必须在技术层面和情绪层面都成为应对这种局面的大师。我们不应被它击垮，这是每一位 IT 专业人士都会定期遇到的自然状况。它不应令人气馁或束手无策，但它给人以这种感觉也是完全可以理解的。

我们之所以如此频繁地遇到这种情况，一个关键原因在于 IT 是一个庞大的领域，在每一种情况下都有大量的变量需要考量。它也是一个高度创造性的领域，对于任何给定的问题都可能存在众多可行的方法。是否真的存在唯一的“最佳”方案，这种情况很少成立。通常会有许多相互竞争的选项。有时这些选项彼此非常接近，有时这些选项又截然不同，使得它们很难进行有意义的比较。

另一个关键原因是各种因素会发生变化。这可能是因为出现了新的技术或信息，发布了新产品，产品进行了更新，价格发生了变动，或者业务需求在决策与设计过程临近时甚至在过程之中发生了变化。作为 IT 专业人士，这种变化的速度并不是我们能够指望去控制的。这是我们必须接受并尽力应对的事情。

我还经常看到被忽视的一点是：一个在做出决定时堪称理想的方案，如果换作今天来做同样的决定，可能就不再理想了。这丝毫不构成原始设计的缺陷，然而我见过许多人在面对这一点时，仿佛它就是缺陷一样作出反应。我遇到的人们表现出这种行为最常见的情形，是对在现代存储设计中使用 RAID 5 的抵触，而 RAID 6 和 RAID 10 出于充分的理由成为受欢迎的替代方案。但这种对 RAID 5 的抵触自大约 2009 年以来才变得普遍，它并非一直存在；从 1990 年代中期直到 2000 年代末，RAID 5 不仅可行，而且常常正是满足既定业务和技术需求的最佳方案（对它抵触情绪的增长大多是渐进的，而非突然的）。然而许多人认为 RAID 5 作为当今的一个选项理所当然地糟糕，却把这种新生的抵触套用到很久以前——有时是接近二十年前——设计和实施的系统上。这毫无道理，纯粹是一种情绪化的反应。RAID 5 在 2002 年的某个场景中是最佳选择，这丝毫不意味着它在 2015 年仍将是最佳选择。但同样地，RAID 5 在 2015 年对于某个场景是糟糕的选择，也丝毫不会贬低或否定它在数年前往往是绝佳选择这一事实。

我曾多次被问到，在做出了不太理想的设计决策之后该怎么办。“我现在该怎么办？”

学会在完美不再是一个选项时该怎么做（仿佛它曾经真的是一个选项一样，所有 IT 都关乎妥协），是一项非常重要的技能。我们首先必须处理的是情绪问题，因为这些问题会破坏其他一切。我们必须尽力退一步，接受现状并理性行事。我们最不想做的就是把一个不理想的局面，通过试图反向为糟糕的决定辩护或惊慌失措，弄得更糟。

接受没有任何设计是完美的，接受没有办法总是把事情做得完全正确，以及接受应对这种状况只是从事 IT 工作的一部分——这是第一步。退一步，深呼吸。情况并没有那么糟。这并不是一个独特的处境。每一位做设计的 IT 专业人士都会一直经历这种事。你应当尽力做出尽可能好的决策，但你也必须接受这很少能够做到——没有人能获得足够的资源来真正做到这一点。我们用手头拥有的资源工作。所以我们就处在这里。接下来呢？

接下来是评估现状。我们现在处于什么位置？在许多情况下，实施已经完成，已经没有什么可做的了。这种局面并不理想，但它糟糕吗？我经常看到的、人们在面对一个已经实施的设计时所犯的最大错误是：它成本太高——通常“更好”的方案之所以更好，并不是因为它们更快或更可靠，而是因为它们更便宜、更简单或实施起来更快。那是个不幸的状况，但谈不上是致命的。无论花费了多少时间或金钱，在当时一定是一个可以接受的数额，并且一定是经过批准的。我们当下所能做的最好的事情，就是从决策过程中吸取教训，并设法在未来避免超支。这并不意味着现有方案不会奏效，甚至不意味着它不会运行得极为出色。只是就所涉及的业务需求（主要是财务方面）而言，它也许并不是一个完美的选择。

有些情况下，一个已经实施的设计无法充分满足既定的业务需求。值得庆幸的是，根据我的经验，这种情况较为少见，因为它是一个困难得多的处境。在这种情况下，我们需要做一些修改才能满足我们的业务需求。这可能代价高昂或复杂。但事情也许并不像看上去那么糟。对此的反应往往具有误导性，而局面常常是可以挽回的。

一旦我们处于这样一种境地——已经实施的方案未能满足业务需求——第一步就是重新评估业务需求。这并不是说我们应当篡改需求，把它们粉饰成我们的系统恰好能够满足的样子，绝非如此。但这是一个很好的时机去回过头看看，原本陈述的需求是否真正有效，或者它们只是没有被充分论证；或者更有可能的是，去看看在实施期间业务需求是否已经发生了变化。也许实施出来的方案实际上确实满足了真实的业务需求，即便这些需求最初被错误地陈述，或者因为需求随时间发生了变化。又或者，业务需求的变化如此剧烈，以至于即便最初做了完美的规划也会满足不了现有的需求，而实施出来的方案未能如预期那样运行这一事实则无关紧要。我曾非常惊讶地发现，对业务需求的这种核实竟如此频繁地把一个被认为不足的方案，变成了一个实际上花费超出必要的“过度配置”方案，仅仅因为没有人对夸大的业务需求提出异议，也没有人质疑某些技术投资的财务价值。

第二步是建立一个新的技术基线。这是非常重要的一步，有助于防止 IT 落入沉没成本谬误的陷阱。任何人都极其常见地——这绝非 IT 所独有——看着一个项目上已花费的时间和金钱，便假定继续沿着最初的路线走下去就是正确的做法，无论这条路有多么愚蠢，仅仅因为在这条路上已经投入了如此多的资源。但这当然毫无道理，你如何到达当前状态是无关紧要的。真正相关的是评估部门和公司当前的需求，并盘点当前可用的方案、技术和资源。鉴于当前状态，便可以确定最佳的前进路线。任何对为到达当前状态所付出努力的考量都只会带来误导。

沉没成本谬误的一个很好的例子是国际象棋。每走一步，重新评估所有可用的着法、风险和策略都很重要，因为为到达当前状态所走过的着法对于今后哪些着法合理并无影响。如果在棋局中途把世界上最伟大的棋手或一套出色的计算机象棋算法请进来，他们并不需要任何关于当前局面是如何形成的知识——他们只会评估当前局面，并据此制定策略。

这与我们在 IT 中应有的行为方式是一样的。我们的当前状态就是我们的当前状态。对于战略规划而言，导致我们陷入该状态的过程是什么并不重要。我们只在进行事后复盘时才关心那些决策和成本，目的是确定决策在哪里可能出了问题，从而从中吸取教训。了解我们自己以及我们的流程非常重要。但这是一项与为当前举措做战略规划截然不同的任务。

这里令人遗憾的是，我们必须重新开始规划流程，但这一次，我们假定，手头有了更多可以利用的东西。然而这无法避免。在最糟糕的情况下，预算已不再可用，没有资源去修复有缺陷的设计并实现必要的业务目标。有时妥协是必要的。用我们拥有的东西凑合，有时就是我们所能做到的最好结果。但是，在绝大多数情况下看来，追加预算与对现有产品进行创造性再利用的某种组合，足以补救这一局面。

一旦我们达到了一种已经解决了不足之处的状态——无论只是通过接受我们超支了、交付不足了，还是已经做出调整以满足需求——我们就有机会回过头去审视我们的决策流程。正是通过这样做，我们才有望作为个人成长，并且如果可能的话，在组织层面从我们的错误中学习，或者判定是否确实存在错误。每一家公司、每一个人都会犯错。把我们区分开来的，是从错误中学习并在未来避免那些同样错误的能力。成长主要来自以这种方式经历痛苦，尽管面对它常常令人不快，但正是在这里，我们拥有创造真实、持久价值的最佳机会。不要推迟或跳过这次复盘的机会，无论它是你亲自进行的严苛的个人复盘，还是由受过相关训练的人主持的正式的组织级复盘，抑或介于两者之间的某种形式。决策流程越早得到评估，记忆就越新鲜，纠偏也就能越早生效。

我们可以做的最后一步，是在对决策流程的复盘完成之后，尽快开始为当前实施设计一个替代方案的决策过程。这并不一定意味着我们应当打算在近期内花钱或更改我们的设计。绝非如此。但通过在决策制定上极其主动，我们可以设法避免过去的问题：给自己更多的规划时间、更多的需求收集和文档编写时间，通过定期重新审视需求以查看它们是保持稳定还是正在变化，从而对需求随时间的变化获得更好的洞察；获得更多取得管理层和同行认同并促使他们对该决策投入的机会；以及对问题域有更好的理解，从而使我们更有能力在下一次实施之前调整既定设计，或者知道何时该将其作废并重新开始。它还有可能给我们更好的机会去把组织知识编纂成文，以便在下一个周期到来时，如果你自己已不在决策或实施的岗位上，这些知识能够传递给继任者。

凭借良好、理性的流程，以及对在系统设计或实施不甚理想的情况下需要采取的步骤的充分理解，我们能够从失误中恢复过来，而且在大多数情况下不仅能在短期内从中恢复，还能使组织在未来免受同样错误的影响。