本文共 1714 字，大约阅读时间需要 5 分钟。
在需求设计中，笔者提倡一种称为“逆向设计”的方法。这种方法与传统的正向设计相反，主要是从编程到需求验证的过程，而非从需求到实现方案的过程。尽管敏捷开发方法在某些情况下可能有效，但笔者更倾向于强调传统的需求分析方法。以下是一个实际案例的分享，供参考。
有一次，我需要开发一款用于业务评审的应用程序，该程序能够根据用户需求生成报表。其中一些报表较为简单，直接从用户需求中可以确定其具体内容。但对于一些复杂的报表，尤其是涉及业务限制的部分，情况就有所不同。项目利益相关者要求这款应用程序能够分析描述这些限制的文字，找出其中的共同主题。考虑到这一需求，我联想到一位擅长人工智能的朋友，打算利用AI技术来实现。尽管对AI项目的风险有些担忧，但也不排斥其应用。于是，我决定先尝试一些简单的分析方法，比如列出常见词语组合，编写了一些代码并进行了调整。
将代码提交给利益相关者后，我继续进行了优化。尽管最终这款应用并未投入实际使用，但我认为这是一个可行的方案。如果以后有需要，完全可以将其交付给用户测试，若不符合需求再进行更贴近AI的实现。
这种设计方式得名“逆向设计”，因为它的流程顺序与传统设计颠倒了。从个人实践来看，逆向设计在以下场景下表现较好：当需求不够清晰、或者有相关研究项目的支持时。另一个常见场景是，当终端用户希望展示某些信息，但对信息呈现方式不确定的情况下。然而，在大型项目中，逆向设计通常仅占一小部分，绝大部分仍然是正向设计。即便是逆向设计，也必须有严格的边界，确保不会干扰其他代码部分。
对于逆向设计的实现，笔者提出以下几点建议：
上述建议的最后一条，主要是针对逆向设计中可能出现的问题——程序员可能忽视利益相关者的意见而自行修改设计。通过定期展示设计方案，可以避免这一问题的发生。
有人可能会问，是否真的有逆向开发的必要？让我们再仔细分析一下刚才的案例。实际上，我们仍然需要明确报表的内容和输出形式，在编写代码前也必须完成用户界面和数据库设计。换句话说，这并不是完全的逆向设计，而是一种可能需要返工的设计方法。这在任何项目的各个模块中都可能出现。因此，在设计初期，我们往往会发现某些内容是可以确定的，而另一些内容则存在不确定性。针对后者，我们可能需要重新审视整个设计，或者为每个设计部分赋予“不确定性得分”（uncertainty score）。这种得分衡量的是需要重新设计的概率。例如，在上述报表应用中，“用户需要一份能够对文本做出分析的报表”得分为0，而笔者设计的报表输出形式得分为7，意味着有70%的概率会需要进一步修改。
这种不确定性得分的方法，不是说利益相关者完全不知道自己想要什么，而是指设计细节不够完善。在这种情况下，我们需要通过示意图或其他方式补充设计内容，并可能进行几轮迭代才能最终确定用户界面设计。然而，在此过程中，理解问题的本质至关重要，这样才能引导解决方案朝着正确的方向发展。
要降低不确定性得分，可以通过直接向利益相关者询问，促使他们深入思考需求。同时，开发过程中可以记录用户对各项特性的实际使用情况，并提供反馈机制。例如，可以请用户对应用程序中的每个界面提出意见。这样不仅能够消除误会，还能帮助我们更好地理解用户需求。
对于不确定性得分较高的内容，可以采取以下措施：将其放到后续版本中开发，避免影响其他重要功能；或者在开发完成前，将其交付给利益相关者测试，并询问他们对设计方向的看法。
总之，在需求设计过程中，不确定性是难以完全避免的，但通过情境设计和细节设计，我们可以更好地管理这一问题。
转载地址：http://giemz.baihongyu.com/