软件需求实践之需求的沟通与分析

在信息技术飞速发展的今天，建设一个与时俱进的信息系统已经成为各国政府、企事业单位的重点课题之一。然而，在软件项目实施过程中，存在着进度超期、超预算、变更频繁等现象，甚至很多项目根本无法达到预期目标，更谈不上为业主创造真正的利益。归根结底，软件需求实践的共性弱点才是问题的根源。
引言
关于软件项目中存在的问题，网上流传过一幅漫画，生动地展现了这些问题。也许很多人看完之后只是一笑置之，但是如果我们仔细分析下面的事情，还是会给我们的工作带来很多启发的。
传播的扭曲
原因是这部漫画给我们的启示是，在需求传播的过程中存在着严重的扭曲。从客户的描述到项目经理的理解、分析师的设计、程序员的编码、业务顾问的解读，每个角色根据自身的特点和需求对信息进行不同的处理，导致信息的内容发生了很大的变化。因此，对于软件需求工程来说，克服沟通失真成为一个关键点。
根据相关研究，如果在信息传递过程中不采取任何措施，信息在传播过程中衰减的可能值高达60%。在软件开发过程中，需求信息通常会经过用户代表、需求者、设计者，然后是开发人员，所以最糟糕的情况下，开发人员获得的信息只有原来的8.4%(如图2)，这是一个非常可怕的结果。
怎样才能更好的避免这类问题？其实关键手段有两个:
文献化:如果信息在传播过程中仅仅靠口口相传，必然会被遗忘和加工。因此，在这个过程中必须有效地使用文档来记录已经达成共识的信息。但这种方法只是用来辅助交流，而不是取代交流，后面会讲到。
Review:此处有意使用英文，因为在中国经常被翻译成“Review”，但这种翻译很容易产生误导。在很多人心目中，评估就是得出一个是否通过的结论，这也是导致需求评估流于形式的罪魁祸首之一。顾名思义，复习就是(重新)再看一遍，其本质意义是通过重读尽早暴露错误。而最简单有效的评审是，在用户代表解释完需求之后，需求分析师用自己的语言再重复一遍，以确保沟通不失真。
比喻:经理叫来了小张，然后对下一阶段的工作做了一些重要的指示和安排:“$ % # @(*)# @……”。
小张正要转身离开，经理叫住了他，说:“简单说一下我刚才给你的任务”(看来管理层已经掌握了这一招)。
提示:如果一个测试人员对你说:“前天我仔细测试了你写的程序，发现没有问题。恭喜你！”。你会怎么想？
A .我觉得我的程序写得很好！
B .感觉测试者方法不当或者测试不细致。
我想大部分人都会做出“B”的选择！但为什么到了需求审查的时候，你就来了个180度大转弯？为什么期望需求评审不会有问题？
《传播的扭曲》高度概括了其中所包含的问题，但如果我们仔细思考第一、二、三、四、十张图(这五张图中的场景与需求活动有很大的相关性)，两两对比，就会得到一些有益的启示。让我们一起来看看吧。
客户:放大需求
当我们对比图1中的第1张图和第10张图时，会发现用户在描述需求时做了大量的“搭积木”。“用户要么不会说话，要么会添油加醋”的现象在我的实践中并不少见。而这种现象背后的潜在原因是什么？我认为至少有两个关键因素:
(1)客户希望付出尽可能少的成本，获得尽可能多的收益
这种想法对于任何客户，任何人来说，都是一种本能的反应。当用户不了解开发成本时，这种心态会更强烈，会更担心自己的“损失”。因此，在需求谈判中，会采取尽可能增加功能的方法来降低“损失”的风险。
要有效克服这一因素的困扰，核心点是建立客户对开发团队的信任，而建立信任的关键点有两个方面:一是需求人员必须提高自己的职业素养(这一点我会在后面的文章中解释)；第二，需求者要站在用户的角度思考问题，让用户感受到需求者的目标是帮助他们解决问题，而不是一味的求利。
(2)将解决方案的选择权交给不熟悉技术的客户
，也就是用户经常谈论解决方案，甚至很多需求团队在进行需求捕捉活动时，往往期望用户直接告诉他们做什么(什么)，而不太关心用户的真实动机(为什么)。但是方案的选择会交给不熟悉技术的客户代表，如果客户代表选择的方案不是最合适的，那么肯定会导致后续的需求变化。
案例和场景:
在CRM软件开发期间...
负责输入客户信息的用户向开发者提出:“你看这个界面，光手机上就差不多有10个输入框。太麻烦了。每次按tab键都是按酸。我希望把它们合二为一，一个用于普通手机，一个用于其他手机”。
“多部手机怎么办？”，开发者回应。
“其他手机的输入框可以设置成多行宽，这样我可以输入多个，中间用逗号隔开！”。
“好的，没问题”。
...
经理看到客户信息，向开发人员提出，“我需要一个功能，输入任意电话号码，自动找出对应的客户。”
“啊……”
如果我们仔细研究这个场景，分析负责输入客户信息的用户提出的改变，就会发现“把10个电话输入框合二为一”显然是解决方案，而真正的需求是“输入太麻烦，每次按tab键都会发酸”。你可能会想到下面的解决方案:
也就是说，默认情况下只显示左边的部分，需要的时候点击“其他> >”按钮，在右边显示不常用的输入项。
总之，由于一个具体问题有多种可能的解决方案，用户在使用软件的过程中可能会不断地找到其他可选的、更合适的替代方案，从而导致不必要的需求变化。缓解这种现象的关键是在需求捕获的过程中问“为什么”。
项目经理:控制需求
当我们对比图1中的第一张图和第二张图时，会发现项目经理在沟通过程中会导致需求的偏差。由于国内很多软件项目经理通常身兼多项工作，如项目管理、需求分析、架构设计等，他们总是在需求捕获的过程中“适时”地勾勒出脑海中的技术框架和路线，然后尽可能地控制需求的范围。
就像这里一样，客户需要的可能是一个“秋千”，也可能是一个“爬树工具”，但无论真正的需求是什么，第二张图中的解决方案都无法得到有效满足。如果你想“荡秋千”，就不要被树干挡住；如果要做“爬树工具”，板子数量显然太少。
不难找到原因。一、需求方从项目经理的角度根据工作量控制需求:将“三层”板的工作量减少到“一层”板。如果对业务很重要的东西被意外控制，最终会以变更的形式“奖励”给开发团队。然后需求者从建筑师的角度做了“改进”:把不稳定的“全挂在一根树枝上”改成“挂在两根树枝上”，结果是根本不能用。
因此，多重角色的需求者在需求过程中，一定要“戴上自己的帽子”，真正从理解业务的角度去捕捉需求。
分析师:技术处理
案例&场景:
分析师小张:“嘿，伙计们！我有一个建议。我们研究Hibernate也有一段时间了，还没来得及真正用上。我觉得这个项目不错，不算太大，就试试吧！”。
“好主意！”大家都同意。
...
“约定的时间已经过去一个月了。项目现在进展如何？什么时候能送到？”，客户CIO问道。
分析师小张:“现在困扰我们的是，有些需求一直在变化，开发团队中有人离职了，所以……”(真实情况是:由于团队是第一次使用Hibernate，数据访问层的一些问题没有得到有效解决，导致进度持续失控。)
现在很多名字里都有“需求分析”、“系统分析”之类的职位，而且大部分都是由技术骨干担任。所以在工作中，很少从业务角度进行分析，更多的是对技术框架和新技术的追求。对于这种现象，关键在于“技术能力”对他们未来的发展更重要，而“业务能力”就没那么重要了。但是为了更好地改进需求工作，我将强烈呼吁那些在标题上有“分析”名字的人加强业务分析！
程序员:断章取义
对于第4张图，可以用一句生动的话来概括:“你要绳子，我给你；如果你要一块木板，我也给你；为什么说这不是你想要的？”。我想程序员也有类似的问题要问他们的客户，“你要了一个文本框，我提供了；你要了一张表格，我也拿到了；为什么说这个节目不是你想要的？”。这让我想起了这样一个场景:
案例&场景:
丁铃铃...，程序员小昭的电话匆匆响起。小赵刚拿起电话，听到对面迫不及待的抱怨，“仓库管理员反应，仓储模块无法使用！马上查，尽快解决！”。
小昭放下电话，开始了检出、构建器、运行、调试等一系列操作。经过一番测试后，小昭没好气地打电话回答说:“这些顾客真是愚蠢！这有什么不好？肯定是操作有问题！我怎么用都好。你的客服人员也要加强对用户的培训。别把所有东西都扔给我们！”。
……
然而问题还是没有解决！开发人员到了现场，终于发现了问题:这是一个基于B/S的仓库管理系统，入库时，仓库管理员首先需要录入入库单，然后填写“验收状态”，最后点击“入库”按钮。然而，当仓库管理员输入入库单，逐一核对进货，再回到电脑前，等待他的是一个让他无所适从的问题。该会话已过期！
满腹怒气的小昭打电话给需求分析师肖谦:“你的需求怎么写？这么重要的事情我不明白。我们怎么知道在填写验收状态之前，填完收货单就要检查这么久？”。
“哦，这也是需求吗？如果这也算，那我们就不是做生意的人了！”佩妮坚定地回答。
这是需求吗？可能很多读者会有不同的看法！但是，如果我们不了解业务场景，我们如何真正理解需求呢？打破“业务场景”这一章，肯定会导致“需求”这个词拿出来的意义出现偏差！
作者简介:中国系统分析师顾问团软件工程首席顾问，中国软件技术大会突出贡献专家，高级顾问。主要研究领域为需求工程、系统分析与设计、软件估算，致力于推动软件工程方法论的应用。本文摘自(并改编自)作者的新书《软件需求实践:SERU过程框架的原理与应用》(电子工业出版社博文观点)