2.4　技术可行性分析

在逻辑架构的设计阶段，我们对即将设计的软件系统进行需求分析。这是一个分析设计的过程，而不是简单记录用户需求。因此，这个阶段的输入是用户需求，但输出的是软件最终要为用户提供哪些功能。在这个过程中，需要我们将用户最初的需求进行落实与细化。

然而，在以往的许多项目中，这个过程没有架构师参与，而是直接由需求分析人员完成的。需求分析人员去做需求分析，理解用户需求，然后提交开发团队开始设计开发。这个过程看似流畅、各司其职，但潜藏着巨大的风险，也就是业务需求的技术不可行。

首先我们来看看用户是怎样提业务需求的。用户在提需求的时候，非常清楚他们的业务以及痛点。然而，用户对于软件研发是非专业的，他们只知道业务问题，但不知道软件如何解决这些业务问题，怎样解决会更优。因此，他们提出的业务需求，是用他们对软件知识有限的理解，想象软件如何解决他们的问题，而这样的需求必然是不专业的，它不能最优地解决问题，甚至很多时候是天马行空，技术上难以实现。因此，如果不能在逻辑架构设计这个阶段将这些不靠谱的需求识别出来，那么花费巨大的精力与成本所得到的结果并不会令用户满意。

因此，我们需要在逻辑架构设计阶段将那些不靠谱的需求及时识别出来，有效地去解决。那么，需求分析人员能够识别一个需求技术可不可行吗？不能，因为很多需求分析人员长期远离技术。需求可不可行的识别工作，是需要交给架构师去完成的。架构师都有很好的技术功底，又能够深刻地理解业务，所以能够很好地识别哪些需求技术可行，哪些不可行。但是，如果架构师在对需求确认的过程中发现某些需求不可行，他能拒绝用户的需求吗？不能，他没有拒绝的权力。这时，架构师应该怎么办呢？

笔者根据多年的经验，总结出来了以下三个解决这类问题的步骤。

（1）跳出需求去分析需求相关的业务

用户需求只是整个业务流程中很小的一部分，而且是并不连续的一部分。如果把注意力仅仅停留在用户需求上，就不能把用户的各个业务流程打通，就不能深刻地真正理解业务，对用户需求的理解就会浮于表面。最后落实到软件设计上，就会做出不专业的软件，不能很好地满足用户的需求。因此，有经验的架构师在与用户探讨需求时，起初先闭口不谈当前的需求，而是与用户探讨相关的业务，包括业务流程、业务规则、业务痛点，等等。把这些理解清楚了后再回到业务需求，我们对业务需求的理解就完全不同了，就能够深刻理解用户为什么提这样的需求。

（2）分析需求背后的动机

对业务有了一定的深刻理解以后，就重新回到当前的需求，这时就开始去尝试理解每个需求背后的动机。用户在提需求的时候，每个需求都有它背后的动机，就是解决某个业务问题、业务痛点。用户提需求的根本目的是要解决业务问题，然而他不是软件专业的，提不出更加专业的解决方案。因此，对于我们，抓住了这个业务问题，就抓住了问题的关键。

（3）基于需求动机去制订可行的方案

抓住了需求的动机，即用户要解决的业务问题，就抓住了问题的关键。这时我们就围绕这个业务问题，运用我们的专业知识，制订出新的解决方案。这个解决方案既可以有效地解决用户的业务问题，又在技术上是可行的。然后，我们拿着这个方案再去与用户沟通和探讨。当我们提出问题的时候，适时地抛出解决方案，用户能够接受吗？用户不仅可以接受这个方案，而且还会觉得你非常专业，能懂他。这个方案既解决了他的问题，还能达到他意料之外的、意想不到的效果。这样，你逐渐就能在用户心目中树立威信，让用户觉得你很专业，特别靠谱。这种威信对于架构师来说是非常重要的。

在一个团队中，用户特别喜欢与架构师聊天，因为用户提出问题后，架构师不仅能告诉他这个问题能解决，而且会告诉他我们是怎么解决这个问题的，使用户感觉特别踏实。如果架构师能够在用户心目中树立威信，就能够在整个项目进展过程中去引导用户，告诉用户怎样做能够规避风险，就能保障项目顺利进行。如果架构师具有了这样的能力，就能在项目中起到非常关键的作用，体现出自己的价值，从而成长为一个顶级架构师。