本节书摘来自华章计算机《需求设计：构建用户想要和需要的产品》一书中的第3章，第3.2节,作者： [英] 克里斯·布里顿（Chris Britton） 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.2 逆向设计
总的来说，笔者不太喜欢敏捷方法，但是这种方法也是有好处的。在个别情况下，这种方法可以奏效。
例如，笔者有一次需要编写一款做业务评审的应用程序，该程序对报表提出了要求，其中某些报表很容易就能从用户需求之中确定出来，但还有一些报表则无法这样确定。特别是该应用程序需要对业务方面遇到的限制进行记录，也就是把阻碍员工达成其目标的那些外部因素记录下来。项目的主要利益相关者要求这款应用程序能够提供某种分析功能，以便从描述这些限制的全部文字之中，找到一些共同的主题，他对我说，他知道一位朋友的朋友是人工智能（AI）专家，很擅长用人工智能来实现这种功能。尽管我内心不赞成把大量资金投入到尚未定型的研究项目中，但我并不反对AI，我只是想在使用AI之前，先试着做一些简单的分析，例如，把常见的单词和常见的词语组合列出来看看。于是，我就按这个思路写了一些代码，然后对需要调整的地方进行了完善。我把它拿给利益相关者去看，接下来又继续做了一些调整。尽管这款应用程序当时没有投入使用，但以后如果需要使用，那我们只需把它拿给用户去用就好了，在使用的时候，自然可以判断出它能否满足用户的需求。假如无法满足，那么可以再改用更为贴近AI的做法来实现。
笔者将这种设计称为逆向设计（upside-down design），因为它的顺序是反的。一般的设计都是从需求到编程，而这种设计则是从编程到需求。从我的个人经历来看，笔者至少可以说：有一些场合是可以采用逆向设计来应对的，尤其是那些需求比较模糊，而且还有着相关研究项目的场合。就我所知，还有一种适用场合也比较常见，那就是终端用户要求应用程序能够向其展示一些信息，可是他们并不清楚这些信息应该以什么样的方式来呈现，只有看到了应用程序的实际样子，他们才能确定这种展示方式是不是他们想要的。在规模较大的项目中，也会出现某种程度的逆向设计，但是其绝大部分设计依然是正向的，即便真的要做逆向设计，这种设计也必须有极其严格的限制，也就是说，它的边界必须非常清晰。我们必须保证这一部分逆向设计不会侵扰其余部分的代码，换句话说，不应该允许程序员按照自己的喜好去随意修改其余部分的代码。
对于逆向设计的编程，笔者给出下列建议：
- 先做简单的部分。如果先做好简单的部分，那我们通常就会发现，复杂的部分其实没有必要再做了。这对于利益相关者也能起到鼓励作用，因为他们可以看到项目正在往前推进。
- 要做好丢弃代码的准备。要经常重构，有的时候还需要重新进行设计。在刚才那个报表应用程序的例子中，有一个大问题，就是怎样对报表参数的设定画面进行设计。这个问题听上去很简单，但实际上却需要反复尝试，它的本质是说，其中有多少内容应该预先设定好，又有多少内容应该通过日期范围等字段来加以设定。
- 要经常对应用程序做评审（例如，可以每两周评审一次），而不能单单指定一个人，叫他一门心思地写几个月代码，最后制作出一个没有人愿意用的东西。
- 试着把某些可选的设计方案拿给利益相关者去看。
其中，最后一条建议是为了解决逆向设计之中的一个问题，也就是程序员可能会自作主张地修改设计，而不倾听利益相关者的意见。
说了这么多道理，有人可能会问，真的有逆向开发吗？我们再来看一遍刚才那个例子。实际上，我们依然需要把报表的内容以及它的输出形式确定下来，而且，我们在编写代码前，也必须设计用户界面，并进行数据库设计与技术设计。换句话说，我们还是按照通常的方式来进行设计的，只不过这次我们在开始设计之前就已经料到，利益相关者很有可能不喜欢这套设计成果。换句话说，这并不是完全的逆向设计，只是一种很有可能需要返工的设计而已，这对于应用程序中的任何一个方面来说，都有可能成立。
在刚开始做设计的时候，我们经常会发现，设计之中有一些部分是可以确定的，我们能够保证自己所做的这部分设计，肯定可以符合利益相关者的需要，而另外一部分则无法确定，因为我们觉得，对于那一部分内容来说，利益相关者并不清楚他们想要的是什么。针对这些内容，我们有可能需要重新审视整个设计，也就是沿着情境设计—用户界面设计—实现这条路再走一遍。或者说，我们应该给情境设计与用户界面设计之中的每一部分内容，都设定一个“不确定性的得分”（uncertainty score），这项得分用来衡量需要重新进行设计的概率。如果两个元素都得到了很高的分数，但是一个位于情境设计之中，另一个位于用户界面设计之中，那么前者更应该得到重视。例如，我们把满分定为10分，以本节开头的那个应用程序为例，“用户需要一份能够对文本做出分析的报表”，这项内容的不确定性得分是0，而笔者当初所做的那套设计方案，其不确定性得分则可以设为7，这表示用户看到了效果之后，有70%的概率会让我们对应用程序做出修改。这项得分至少可以使我们明白自己所在的位置。
这种不确定性，有的时候并不是说利益相关者不知道自己想要什么，而是说用户界面的设计缺乏足够的细节。笔者曾经多次提到刚才那个应用程序的用户界面设计，但却始终没有说它输出的报表是图表形式还是地图形式。在这些情况下，我们需要绘制一些示意图或者采用其他一些并行的手段，来对用户界面的设计做出补充，而且有可能需要做几轮迭代，才能把这些内容确定下来，但即便是这样，也依然应该先试着把整个问题理解清楚，知道自己当前要做的究竟是什么。如果我们能够明白某些奇妙的特性为何如此重要，那么就可以更好地把解决方案引往正确的方向。
要想知道这个不确定性的得分，我们可以直接去问利益相关者，这样他们就会更加深入地思考相关的需求，于是，我们就有可能得到一个较低的不确定性得分。有的时候，我们可以按照用户所说的话去实现某些特性，同时添加一些监测代码，来记录用户对这些特性的实际使用情况。一般来说，我觉得如果应用程序能够给自己添加一些分析能力，那么可以表现得更好。应用程序可以记录下用户正在使用和没有使用的特性，并给用户提供一些反馈机制，例如，可以请用户针对应用程序里的每一个画面来提出意见。
还有一种消除不确定性的办法，那就是把各种备选的设计方案拿给利益相关者看。这样会引发一些讨论，帮助我们消除误会，并且可以使每个人都能够更加深入地理解这个应用程序。
对于不确定性得分比较高的内容来说，我们可以采用多种措施加以应对。我们可以把这个特性放到稍后的版本之中去做，使得其他一些重要的特性不会因此而延误。我们还可以先实现这个特性，等到完工之前，把它拿给利益相关者去看，并问问他们：“我们的方向对不对？”
总之，在有些情况下，不确定性是无法避免的，然而情境设计与细节设计，可以帮助我们对此进行管理。
