本节书摘来自华章计算机《需求设计：构建用户想要和需要的产品》一书中的第1章，第1.1节,作者：[英] 克里斯·布里顿（Chris Britton） 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
第1章 情境驱动设计入门
本书讲的是如何设计IT应用程序。笔者写这本书，是想建议大家采用与原来不同的办法去做设计，尤其是想进行下列三项变革：
- 要使人意识到自己并不是在收集IT应用程序的需求，而是在设计它们。对应用程序所做的设计工作，正是建立在这样一种认知之上。
- 要把程序的设计做得像工程学一样，特别是要在实现之前先对设计进行分析，并寻找其中的缺陷。
- 要确保当前所开发的应用程序能够与现有的或同时开发的其他应用程序协同运作，以创建出一套连贯的IT架构。
本书要谈论如何思考应用程序的设计，以及如何对设计进行分析，而不会过多地涉及如何组织开发团队、如何管理团队，以及每隔多久就应该向终端用户展示新版程序等问题。如果你遵循本书的理念，那么自然能够找到很多种规划并管理项目的办法。没有那种能够适用于每个组织和每种项目的万能办法。
笔者首先要在1.1节讲解上述第一项主张，也就是对需求进行设计。1.2节会给出一些准备知识，有了这些知识，我们就可以在1.3节中讲解上述第二项主张。其后，会在1.4节讲解上述第三项主张。
1.1 对需求进行设计
为什么要对需求进行设计？这么做合适吗？就一般意义而言，需求确实用不着设计，但是对IT应用程序来说，这么做却很有必要。原因非常简单：没有谁愿意平白无故地去开发一款商用的IT应用程序，之所以要开发这种程序，是为了给业务提供支持。因此，我们必须注重IT应用程序的设计，令其能够反映出整个业务解决方案的设计情况。这正如盖楼的时候必须把地基设计好，因为它会体现整幢房屋的设计。
本书的很多章节都在鼓励大家改变原来那种为IT应用程序收集需求的消极做法，以一种更为积极的姿态，去对IT应用程序所要支持的业务解决方案进行设计。下面就来解释这种设计工作为什么这么重要。
要对业务做出变革，是有一定困难的。其中某些变革，可以由公司管理层通过调配资金和资源等手段来强行推进，这属于那种实现起来相对简单的情况。此外还有一些变革，推动起来则不太容易，这些变革旨在降低业务运作过程之中的出错概率、减少成本并提升其灵活度，换句话说，就是想使员工改变他们长久以来所习惯的那种工作方式并将他们移出“舒适区”。如果再把IT应用程序也考虑进去，那么这种情况就更为复杂了。IT应用程序如果推出得比较迟，那么会影响新工作方法的推广进度，IT应用程序若是做得不够好、不够可靠或不够高效，则会使员工对整个变革计划产生抗拒情绪。当IT应用程序的功能与使用者的期望不相符时，他们会开始怀疑这个变革计划是否行得通。
引发上述风险的根本原因在于，一旦将IT应用程序考虑进来，就必须把公司打算推进的业务变革精确地转化成具体的要求，使员工依照这些要求来改变自己的工作方式。然而，不同的人即使在面对同一个目标时，也会提出不同的实现方式，每个人都认为自己的方式是最好的。如果再加上各部门之间的争斗、业务环境的变化，以及各个地区在做法和习惯上的差别，那么大家在看法上面的冲突，自然就难以避免了。对于业务变革之中的某些环节（如培训）来说，你可以不处理这些分歧，并把它们通通掩饰起来，可是一旦涉及新的IT应用程序，那你就必须面对这些分歧了，因为IT应用程序中的计算和编程工作，都必须精准地去完成。举个非常简单的例子。大家肯定都见过这样一种网站：它要求你在输入框里填写一些数据，并且会用星号把刚刚输入的字符遮住。为什么会有这样的机制呢？或许是有人觉得这份数据相当重要（而且不太可能会遭到仿冒），因而规定客户必须先把这个字段填好，然后才能继续访问该网站，尽管这么做比较麻烦，但他还是强迫访问者必须输入这份数据。那么，是不是公司里的每一个人都同意这项决定呢？这很难说。IT应用程序中到处都能遇到这种可疑的决策。是否要求访问者填写某个字段，这是个很容易就能修改的决策，然而还有一些决策，会对应用程序或业务的开展方式产生结构性的影响，这些决策修改起来可就不那么容易了。
再来看一个复杂的例子。笔者住在英国，也在那里工作，过去几年，有些银行因为违规销售金融产品而遭到重罚，它们在客户不知情或没有获得足够信息的情况下，就卖出了一些很昂贵或者没有必要购买的支付保护保险（Payment Protection Insurance，PPI），这种保险，本来是针对投保人有可能无法偿还贷款而设立的。现在假设有一家银行，想要设法避免这种违规销售的情况。首先，必须知道问题出在哪里。银行里面并没有人会给员工下命令，让他们去违规销售产品。之所以会出现违规销售，是因为销售人员在销售目标和奖金等指标上面，受到了银行所施加的压力，从而导致自己会疯狂地向客户兜售金融产品。这种压力有可能是直接的，也有可能是间接的。比如，银行可能把某些支行装修得很漂亮，把它们打造成销售金融产品的场所，或者曾经在培训过程中告诉销售人员，说每一笔贷款业务都和PPI有联系。这家银行以后还是会销售金融产品，但是要销售得更加明智。它必须更加理解客户的想法。如果银行只告诉员工“以后要好好做”，那么这些员工的工作方式是不可能有太大改观的。银行固然可以针对某些事项重新进行培训，但员工只要看到下一次的奖金计划，就很可能会把培训时的内容丢在脑后；此外，如果银行开始追求更高的业绩，那么培训时的那些话，也有可能等于白说了。于是问题就来了：银行到底应该怎样使员工领会这个意思呢？银行最终采用的办法是：命令员工在与客户谈话的过程中，向客户提出一些关键问题，并把客户的答复记录下来，以便确认这次销售是否合理。这些问题旨在探查客户是否确实需要某一款金融产品。不久之后有人建议，应该把客户对问题所给出的答复，放在新的数据库里，以后万一出了问题，可以从这个数据库中查出对话的双方以及他们当时所说的内容。又过了一小段时间，银行发现客户对这些问题所做的回答，其实是很有价值的营销信息。紧接着，有人提出（这个人可能是和CEO一起打高尔夫的朋友，他碰巧在一家大型咨询公司上班）：可以编写一个应用程序，把客户对种种问题所给出的回答，全都捕获到数据库之中，这样的应用程序应该很快就能写好，而且几乎不需要额外的开销。这些做法看起来似乎是比较合理的，但只要仔细想想，我们就会发现，其实还有很多事情需要解决，例如：
- 这套办法针对的是哪些金融产品？所有的金融产品都要按照这套办法来销售吗？
- 如果销售人员是第二次向某位客户推销，那么他是不是还要把上次推销时问过的那些问题再问一遍？这么做可能会使客户感到厌烦。
- 除了销售金融产品本身所需的时间，问这些问题要花费多长时间？银行为此需要付出哪些成本？
- 应用程序需要把银行现有的数据用作自己的输入数据吗？如果需要，那么具体需要哪些数据？所需的数据存放在什么地方？
- 如何对这些问题做出修改？谁有权修改它们？
- 如果有人修改了问题，那么会不会对数据分析的效果造成影响？（比如，某些分析所依据的数据，既有问题修改之前的数据，也有问题修改之后的数据。）
- 对于某些产品（如房屋贷款）来说，销售人员在推销该产品时已经问过很多问题了。那么，刚才构想的那些问题，是属于一个新的系统，还是属于对现有系统所做的扩展？如果是新的系统，那么怎样避免销售人员重复询问原来问过的问题呢？
- 如果银行察觉到客户的状况发生了变化（如换工作、移居、离婚等），那么是否需要对卖给客户的产品重新进行评估？
通过上面这些事项，我们可以看到，如果员工向客户提出的问题过多，那么这套办法就将变成一套重复而僵化的流程，客户与销售人员都会觉得很烦。
刚才提出的那些事项，主要针对的是销售流程，而在IT应用程序的开发方面，也有很多因素需要考虑，例如：
- 新程序与现有程序或数据库之间的集成度应该有多高？
- 这个程序应该怎样与现有的安全系统相集成？
- 如何防止销售人员随意查看客户的详细财务信息？
- 有没有现成的工具可以用来分析数据？
除了上面这4项，还有很多IT方面的事务也有待考虑。
当前的IT应用程序开发，在需求收集方面有两种办法。一种办法是派一个人或一个团队，以书面或口头的方式，向利益相关者询问一些问题，并通过头脑风暴（brainstorming）或其他手段来提出业务构想。然后，团队会把这些想法写成文档，并在其中指出客户的需求。这份需求文档经过审批和签字之后，会交给公司的IT开发部门来实现。另外一种办法，是把需求用简短的文句写成一份清单，程序员直接根据这张清单来开发程序。软件每次会推进一小步，推进之前，程序员会与业务代表把这次迭代将要实现的详细需求确定下来。如果采用这种办法，那么软件只要有了进展，就会尽快提供给客户使用，并且会从客户那里持续获得反馈，开发者可以根据这些反馈来扩充早前的那份需求清单。
上面说的这两种需求收集办法，都建立在一系列的假设之上，如果这些假设不成立，那么软件项目就很有可能会失败。
第一个假设，是认为业务经理总是能够清晰地回答每一个问题。以早前讲过的银行为例。当我们正准备收集IT应用程序的需求时，很多经理其实根本还没有开始考虑这些问题。更糟糕的是，有些人会用一些模糊而暧昧的话来回答问题，他们想通过一种过于乐观和浮夸的语调，来把这些困难的问题通通掩饰过去。只要稍微收集一下需求，你就会发现，需要厘清的细节实在是太多了。然而很多业务经理都是那种不关心细节的人，你如果必须要这些细节问题，他们就会觉得不太舒服。
此外还有一些人，他们要求所有的需求都必须能够量化，这在一部分程度上是为了防止管理人员给出模糊的答案。例如，他们不喜欢“应用程序必须足够简单，以便于公众使用”这样的说法，而是要把话说成“用户必须能够在5分钟之内完成操作，用户的退出率必须小于5%”。其实量化的指标是很难确定的。用5%的退出率来衡量程序的易用性，这是否合适？为什么不用1%或10%呢？而且用户退出应用程序，或许还有其他一些原因，未必全都是因为该程序很难用。因此，这项指标的意义是不够明确的。这种指标还有一个缺点，就是会增加项目的开发成本。为了满足这些指标，必须有人在应用程序中编写一些代码，来捕获原始的数据，而且还必须有人来分析这些数据，以判断应用程序是否合格。如果应用程序没有达到预定的指标，那么项目就会延期，因为我们必须试着去修正这个问题。万一用户的退出率是6%怎么办？难道要取消这个开发项目吗？有的时候，我们应该把这些指标当成一项需求来收集，并且最好是能够将其变成推进项目的动力，而不要使其成为干扰项目的阻力。但要想做到这一点，首先必须有人真的愿意去关注并处理些指标。很少有哪位业务经理能够明确地把这些指标讲给你听，对于易用程度这种模糊的概念来说更是如此。即便有人说出了明确的指标，也很有可能是错误的，他们不是把指标定得太宽，就是把指标定得太严。于是在这个时候，就需要借助一些专业的知识了，也就是说，收集需求的人应该明白怎样的指标才算合理，并且应该帮助回答问题的人去提出合理的指标。
第二个假设是认为所有的利益相关者都会给出一致的回答。这显然不成立。经理与经理之间的意见不同，经理与工人之间的意见不同，总部与分支机构或部门经理之间的意见也不同。对于银行这个例子来说，经理之间很可能在“谁有权确定这些问题”这件事情上面有所分歧。销售人员的主管可能认为销售经理可以按照当地的实际情况来修改已经定好的问题，而营销主管或许完全不同意这样做。
第三个假设，是认为每一位重要的利益相关者都能够找得到。实际上，收集需求的人有时可能会漏掉某些重要的利益相关者，尤其是可能漏掉那些位于国外的利益相关者。而且有的时候，可能是有人故意要求他们忽略某些重要的相关方。对于银行这个例子来说，总部的管理层可能早就料到分行的人会有所抱怨，会说自己总要花时间向用户问一些他们不想回答的问题，于是，管理层就想提前把这条需求确定下来，以造成一种既成的事实，而不想去和分行的人正面讨论这个话题。
文化差异也是个值得考虑的问题。笔者曾经听到一位日本的业务经理，把西方的业务人员比作枪手，说他们“拔枪很快，但打出去的子弹太慢”。这句话的意思是说，他们可以把产品迅速推向市场，但却没有考虑诸多的细节问题，而且没有提供该产品成功所需的必要支援。此外，公司总是会把某一个人捧成英雄或打成替罪羊，而其他的人则在旁边看热闹，没有谁愿意站出来给人以支持。这对于IT应用程序的开发来说，是个很严重的问题，有的时候，我们明明应该与很多位利益相关者进行沟通，但实际上却只找了其中的一两个人来谈话。（另外，在很多非西方的文化之中，也有一个对需求收集不利的因素，那就是：当经理出错时，没有人愿意指出他的错误。）
收集需求的人员或团队会有一种倾向，他们总是自己来回答这些需求问题。他们很容易就会在不经意间过度地诠释自己所听到的话，或是自己内心先设立一种观点，然后再去听别人说话。如果你自己已经确信项目就是应该朝这个方向走，那么你只会愿意倾听那些与自己相符的观点。心理学家把这叫做认知偏误（confirmation bias）。
于是，我们就要谈到第四条假设，也就是认为高层和业务经理总是会阅读并理解需求规范文件（requirements specification），并且总是能够给出明智且周全的反馈意见。有一些项目会把软件成品的早期样品拿给业务经理去看，并希望从中得到反馈，对于这样的项目来说，认知偏误会以一种相反的形式表现出来，也就是说，经理会提前认定：这个产品已经能够满足早前所提出的需求，即便他们当前并没有发现这些功能，也依然会以为相关的功能位于该应用程序的其他部分，或是认为自己还没有了解该应用程序的工作原理。
任何一个商业项目，都必须估算开发成本和开发时间，并且要在这两者与项目所能产生的收益之间进行权衡，这就涉及第五条假设，也就是认为需求团队能够很好地估算应用程序的开发时间及运作成本，并且认为高层管理者对应用程序所应具备的功能有足够的了解，从而可以在各项决策之间做出良好的权衡。
笔者要谈的最后一条假设，与IT部门有关。现在我们所要开发的很多应用程序都面临着与其他IT应用程序之间的集成度问题，而且刚才所举的那个银行案例，更是个相当典型的例子。有的时候，要想打造出更高的集成度，就必须在项目前期投入更多的成本，这样做的好处通常会在项目后期体现出来，因为以后所要开发的内容，可以复用早前已经实现好的某些特性。以银行那个例子来说，我们可以选择很多种集成方案，比如，在各程序之间共用同一套单点登录（single sign-on）机制，以确保安全，或是把新程序所要用到的数据集成到数据库中现有的客户表里。如果采用后者，那么设计人员可能就需要决定：到底应该和数据库里的哪些客户表进行集成。比如，账户数据库、贷款数据库和保险数据库里面，都存放着包含客户数据的表，那么应该和其中的哪些表相集成呢？（大多数银行的客户表实际上都应该不止这三种吧？）于是，这就引出了最后一条假设，也就是认为业务经理能够明确地看到集成度的问题，以及各种集成方案的优点和缺点，从而可以做出周全的决策。
如果要做的项目很小，涉及的利益相关者很少，他们之间配合得比较好，而且要开发的IT应用程序也不太需要同其他程序进行集成，那么上述的6条假设就有可能是成立的。但如果项目的规模变大，而且应用程序之间的集成变得较为重要，那么上述6条假设则很难成立。这导致的主要结果就是IT应用程序无法满足业务需求。我们经常看到有些人在项目做到一半的时候去修改需求，这是因为他发觉项目不能具备自己想要的能力。这种做法可能导致项目延期或预算超支。（笔者在前言中说过：很多人以为需求发生变化的常见原因在于业务改变得很快，但笔者却认为，最常见的原因应该是，利益相关者发现项目正朝着自己当初从来没有想过的方向发展。）有的时候，收集需求的人自己也发现当初所拟定的假设是不成立的，于是，他们就开始堆砌各种需求，想要把每一种做法都囊括到项目里面。
本书将会提出另外一种与利益相关者进行接触的方式，使得我们可以构建出合适的需求。笔者所要讲的这种方式，建立在一个简单的道理之上，那就是：IT应用程序的需求，应该是设计流程所输出的成果。换句话说，我们不能像从树上摘苹果那样，仅仅去“收集”IT应用程序的需求，而是应该设计一套能够解决业务问题的方案，IT应用程序则是该方案之中的一部分。
银行的例子可以证实上述观点。银行的宏观需求，是在法律范围内销售产品，如果超出了这个边界，那就会令银行的信誉受损，而且还会令其遭受罚款。我们当然还可以用成本等方面的标准来扩充这条表述，但其核心的意思依然是要在法律范围内销售产品。实际上，许多公司的宏观标准都可以归结成像这样一句很简单的话。把公司想要做的事情说出来并不会太过复杂，真正有些复杂的，在于要把做这件事的办法也同时指出来。在本例中，实现该需求的办法，是设计一套业务解决方案，该方案会对现有的多个销售流程做出改动，并且会增加某些管理流程及营销流程。（管理流程是为了监测客户所给出的答复，营销流程用来设定销售人员提给客户的问题，并对收集到的数据进行分析。）为了给这套业务方案提供支持，我们需要设计一款新的IT应用程序，该应用程序对本方案起着至关重要的作用。
对于解决业务问题来说，设计这个词听起来可能有点虚。之所以会有这种感觉，部分原因可能在于：很多业务经理都喜欢更加自由随兴的办法，也就是先试试某个方案，然后在尝试的过程中再去修改它。笔者要说的是，用这种办法来探索通用的设计方案是完全可行的，我们会在1.2.1节中谈到这一点。但是，对于IT应用程序，尤其是大型的IT应用程序来说，这种办法却不太适合。因为IT应用程序是一种容易僵化而且容易出错的东西，笔者要告诉你怎样才能把它做得灵活一些，使其能够适应变化。也就是说，你只能在一定程度上把它做得柔韧一些。有一款知名的软件产品，以“灵活而又坚固”来描述它自己，意思是说：我们在塑造它的过程中，可以把该软件捏成任意的形状，然而一旦成形，它就会稳定下来。很多IT应用程序也应该达到这种地步。
现在我们就来看看，应该怎样把“收集需求”转变成“设计业务解决方案”，以便使我们接下来所要列出的那几条假设能够成立。任何一项设计工作之中，都有一个关键的阶段，笔者将其称为“设计猜想”（design hypothesis），这些猜想，是我们对该方案所提出的基本想法。银行那个例子的设计猜想是：在销售过程中，销售者向客户提问，并记录客户所给出的答复。设计流程中最花时间的部分，应该是对设计所做的细化，也就是要厘清它的实际内容及各种细节。设计的方式与“只顾收集需求”的方式相比，有一个显著的区别，那就是，它不会让人花很多时间去填表，而是会用相当多的时间去展示候选方案并倾听反馈意见。评价一件事物，要比创建一件事物容易得多。如果你直接询问他们的需求，他们可能很难把所有的需求全都列出来，但你如果把一两个备选方案拿给他们，那他们很快能就看出还有哪些需求有待实现，并且能够指出方案中的错误、问题及难点。此外，请各位利益相关者去审阅同一份设计，可以迅速地展现他们之间的观点分歧。设计提供了一套框架，使我们可以在该框架中找寻折中的办法。下面列出我们所要确立的几条假设：
- 假设一：清晰。我们并不指望他人能够给出清晰的需求，而是要求自己能够将解决方案的准确图景清晰地呈现给他人。
- 假设二：歧见能够消除。如果你把一份备选方案展示出来，那么别人就可以对这份方案进行评判，从而更有可能提出一些替代方案，这样做使得利益相关者可以在不直接批评同事的情况下，表达出自己的意见。把分歧摆在明处，这样解决起来更容易。
- 假设三：能够找到每一位利益相关者。在注重反馈的开放氛围之下，我们可以把设计方案的电子文档发给他人，从而更加容易地找到所有的利益相关者。
- 假设四：可以获得清晰的反馈信息。我们会请利益相关者精确地指出解决方案中的错误，这要比请他们来描述解决方案更容易一些。
- 假设五：能够将成本估算及权衡纳入设计流程。实际上，单从业务设计中是很难估算出成本的，你必须进一步把技术解决方案也设计出来，然后才能够做出精确的估量。第3章将会详细讨论此话题。所幸这一步所花费的时间，与项目的总时间相比并不算多，因而我们可以很快地拿出一些备选的业务解决方案及技术设计方案，使得公司能够据此做出明智的决策，挑选出时间和预算均不超标的方案。（比如，这些技术设计方案在可用性这一指标方面设置有不同的目标。）
- 假设六：业务经理能够充分理解各种集成选项，从而可以在这一领域内给出指导意见。大家稍后将会看到，我们在进行设计的过程中，能够给业务经理呈现出一些集成选项，这些可供选择的集成方式，都是从数据访问和信息传递的角度来描述的，而不会包含过多的技术词汇。
笔者把需求设计所产生的结果称为情境设计（context design），因为它给IT设计提供了情境。正如早前所说的那样，这种情境设计，一定要能够向业务经理呈现一幅清晰的图景，使他们明白当前要构建的这个IT应用程序到底是用来做什么的。
笔者所提出的这一整套设计办法，可以称为情境驱动设计（context-driven design）。
本章开头一共提出了三项主张，现在已经讲解了第一项主张，而剩下的两项（也就是要像工程学那样去做设计，以及要使各程序对架构起到推动作用），则需要在我们讨论完一般意义上的设计之后，再进行讲解。
