最近碰到一个和技术分析相关的问题。客户在提交订单后，无法立即查看最新的订单信息，团队需要针对该问题进行技术分析，以找到解决方案。但团队在进行分析后只给了干系人一个结论，就是这个问题解决不了，要不就让客户等一下再查看订单吧。我的直觉告诉我这里有问题。
从团队的角度看，这是一个很正常的答案，确实没有可行的方案。但从干系人的角度看，可能会有很多的疑问，为什么解决不了？是不是负责分析的人能力不行？是不是真的考虑过所有可能的方案了？我能相信他们的结论么？我该怎么向产品团队解释？由此可见团队和干系人之间出现了严重的信息断层，干系人只能被迫接受这个结论或者找其他人重新做一次技术分析，这次的技术分析显然是不合格的。
那么，如何才能做出合格的技术分析呢？我们首先需要知道什么时候需要做技术分析，然后在做技术分析的过程中保证能够达到最低标准，最后以ADR和RFC的形式输出技术分析的结果。
什么时候需要做技术分析？
技术分析是用来解决繁杂或复杂问题的，并不是所有问题都需要进行分析。我们可以从重要-紧急和知道-理解两个层面对问题进行分类，不同种类的问题需要不同的处理方法。
重要-不紧急
从时效性看，紧急的问题通常不会给我们时间做详细的分析，我们需要根据直觉和经验立即采取行动，但行动的主要目的不应该是解决问题，而应该是降低问题的紧急程度，以降低决策错误的风险。对于不重要但紧急的问题，我们应该进行充分授权，把它变成对我们不重要且不紧急的问题。对于重要且紧急的问题，我们应该立即采取我们能想到的各种行动，来争取更多的时间对问题进行分析，因为我们很难保证在应激状态下所做出的决定是正确的。
对于不重要且不紧急的问题，我们需要问自己一个问题，我为什么要解决这个问题？这个问题可能是在浪费我们的时间，应该尽量避免。
重要但不紧急的问题应该是我们要关注的重点，下面让我们从知道-理解层面对其进行进一步的划分。
知道-不理解
从理解程度看，对于我们已经理解或解决过的问题，我们通常会有一套最佳实践来解决它们，这时我们并不需要对其进行分析和讨论，例如Java语法，变量命名，敏捷实践等。但如果我们没有在团队或个人层面对解决过的问题进行知识管理，例如总结、复盘、分享等，那么就会出现同样的问题反复发生的情况，也就是经常出现一些我们事前不知道但其实已经解决过的问题，造成不必要的错误或损失。
对于不理解的问题，如果我们知道团队或者业界有人理解，那么我们就需要对问题进行分析，以给出不同的解决方案，来支持团队对其进行讨论决策。
如果某些问题只有在发生了之后我们才知道它的存在，并且我们无法理解它，那么我们也需要做分析。不过这里分析的目的并不是为了解决问题，而是为了降低未知问题所造成的损失，从而让我们有机会从错误中学习和定义这些未知问题。
如何做出合格的技术分析？
最低标准
至少有3个方案
通常情况下，一个需要分析的问题至少可以有两个解决方案
- 什么都不做：什么都不做是指虽然我们已经知道这个问题的存在，但考虑到成本，损失，政策等因素后，我们决定什么都不做。这种方案常常被人所忽略，但有的时候却是最好的选择，而且它可以提醒我们当前的问题也许不是一个在正确时间对正确的人提出的正确的问题。例如，当团队手动测试效率低时，我们提出持续发布，自动化测试等解决方案，但团队在多次讨论后还是决定什么都不做，因为当前的组织架构不支持这些方案，这个问题不是当前能够解决的，也不是单个团队能够解决的。
- 不考虑任何限制：不考虑任何限制是指我们可以做任何我们认为可以解决问题的事情而且一定能够成功。例如，我们可以要求团队有无限的资金，无限的时间和无限的人力供应来解决问题。这种方案往往不会被采用，但可以为我们解决问题提供足够的想象空间，为更好的方案指引方向。
以上两种方案可以被认为是我们解决问题的下限和上限，现在我们需要做的是在下限和上限之间再找出至少一种方案。
至少有4个评价维度
从项目管理的角度看，我们至少可以用时间，成本和范围三个维度对每个方案进行评价，因为每个干系人都会关心方案什么时候能够完成，需要投入多少人力和资源，以及包含哪些修改内容。
但对于技术分析来说，我们可以将这些维度进一步细化以得到更多的维度。
- 时间：我们可以从短期，长期，某个重要时间节点前后等方面对方案进行评价。例如，如果我们采用单体架构，从短期看可以满足快速交付的需求，但从长期看其维护成本会急剧增加。
- 成本：我们可以从代码实现的难易程度，当前团队的人才梯队，外部或基础设施的依赖程度等方面对方案进行评价。例如，如果我们采用单体架构，代码实现简单，不需要扩充当前团队，不需要额外增加AWS服务。
- 范围：我们可以从业务需求，跨功能需求等方面对方案进行评价。例如，如果我们采用异步处理方案，用户下单后需要等待5分钟才能看到订单详情，无法满足立即查看订单的需求，但在后台出现错误时，系统能够自动恢复，稳定性更高。
在确定好评价维度后，我们需要将其应用到所有方案上，这样我们才能够对所有方案有统一的认知，从而便于团队进行讨论决策。
从哪里找方案？
我们不理解的问题通常不会有唯一的解决方案，我们需要做的就是利用自己能找到的一切知识来分析这个问题。在这期间，我们有三个知识来源
- 独立的其他人。其他人就是除自己以外的人，他既可以是团队的其他成员，也可以是第三方的资深人士，例如，领域专家，咨询师等。这里唯一的要求就是他们必须独立的给出意见，这样我们才能尽量避免偏差和噪声。例如，如果团队中有人拥有绝对的权威，那么我们很难在他给出一个方案后收集到不同的方案。
- 不同场景下的自己。想象自己在不同的场景下会如何解决该问题，从不同的角度看问题往往会有新的发现。例如，想象一下，如果未来问题解决失败了，可能是哪些原因导致的？这种方法也叫事前尸检。
- 不同时间的自己。如果实在想不出方案，那就睡一觉或锻炼一下吧，第二天再重新思考这个问题，很多创新的方案都是灵光乍现时产生的。
我们要把能够找到的所有方案都记录下来，包括那些我们认为绝对不可能的方案。如果我们没有记录某些方案，它们就会变成我们掌握的独有信息，这不利于最后的决策，因为这些信息可能会给其他人以重要的启发。
要输出什么？
ADR 是团队用来记录架构决策的文档，它会包含团队在解决某个问题时的背景，上下文，可选方案，决策结果，参与决策人等信息。它虽然是一份文档，但撰写该文档的过程就是技术分析的过程。如果把寻求他人意见的过程和决策过程也包含进来的话，整个过程就是RFC，它也可以被记录，例如, ADR的修改记录，意见记录，决策会议记录等。 ADR和RFC不仅可以用来解决架构问题，也可以用来解决工作中其他我们不理解的问题。它们是一个完整的问题解决框架，也是我们需要输出的内容。
这里需要强调的是，ADR中还记录了决策的效果，这些效果可能是正面的也可能是负面的。这一部分很重要，它可以让我们学到只有在问题发生后才知道的知识，是安全试错和知识管理的重要组成部分。
总结
做出合格的技术分析只是起点，高质量的技术分析是我们成为团队关键角色的重要指标，也是提升我们思维能力的重要方法。当我们能够用另外一种方案来解决问题，能够从另外一个角度来看待问题的时候，我们的能力就提升了。
如果要再引申一下的话，我想引用《高效能人士的第八个习惯》中的三句话
在刺激和回应之间有一段空间。
在这段空间里我们有自由和能力去选择自己的回应。
我们的成长和幸福取决于我们的回应。
知道-不理解这个象限就是刺激和回应之间的空间，如果我们能够把自己要解决的问题集中在这个象限并进行高质量的分析，那么我们将获得自由，我们的能力和幸福感也会不断的提升。