软件需求最佳实践之需求的沟通与分析.doc

软件需求最佳实践之需求的沟通与分析 在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题根源之所在。 引言 关于软件项目所存在的问题，互联网上曾经流传着一幅漫画（如图 1 所示），它十分生动地展现了这些问题。也许很多人看完之后只是一笑置之，但如果我们认真剖析后面的东西，还是会给我们的工作带来许多启发的。 图 1 需求“迷途” 沟通失真 究其原因，这幅漫画给人最大的启示就是在需求沟通过程中产生了严重的失真，从客户的描述到项目经理的理解 、分析员的设计、程序员的编码、商业顾问的诠释，每个角色都根据自己的特点和需求对信息进行了不同的加工，从而导致信息的内容有了很大的改变。因此，对于软件需求工程而言，克服沟通失真就成了一个要点。 根据相关的研究显示，在信息的传递过程中，如果没有采取任何措施，那么在沟通过程中信息衰减可能的最大值高达 60%。而在软件开发过程中，需求信息通常要经历用户代表、需求人员、设计人员再到开发人员，因此最坏的情况下，开发人员获得的信息仅是原来的 8.4%（如图 2 示），这是一个十分可怕的结果。 图 2 信息失真 怎样才能够更好地避免这种问题的出现呢？其实关键的手段有两个： 文档：如果信息在传递的过程中仅靠口口相授的话，就难免发生遗忘、加工等情况，因此必须在这个过程中有效地利用文档，将达成共识的信息文档化。但这种方法只是用来辅助沟通的，而不是代替沟通 ，这一点在后面还会提到。 Review：在此有意使用了英文，因为国内常将其翻译为“评审”，但这一翻译却容易给人误导。评审在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。顾名思义， Review 就是再（ Re）看（ View）一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。而最简单、有效的 Review 就是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。 隐喻：经理叫来了小张，然后就下一阶段的工作做出了一些重要的指示和安排：“ $%#^@(*)#@……”。小张正要扭头走的时候，经理叫住了他，说到：“你简单地说说看，我刚才给你交待的任务有哪些”（看来管理人员早已掌握了这一招）。 提示：如果有一个测试人员对你说：“我前天仔细测试了一下你写的程序，发现一个问题也没有，恭喜你！”。你会怎么想呢？ a.觉得自己的程序写得很好！ b.觉得测试人员方法不得当或测试不细致。 我想大多数人都会做出“ b”的选择！可是到了需求评审时为什么却转了 180 度的弯呢？为什么期望需求评审时一点问题也没有呢？ “沟通失真”高度概括了其中所蕴藏的 问题，但如果我们细细地思考第 1、 2、 3、 4、 10 幅图（这五幅图中的景象与需求活动有很大的相关性），并将其两两比较就会得到一些有益的启发。下面我们就一起来看看。 客户：放大需求 当我们比较图 1 中的 1 幅和第 10 幅图时，就会发现用户在描述自己的需求时做了许多“添砖加瓦”的事。“用户要么不会说，要么就会添油加醋”的现象，在我的实践中是屡见不鲜的。而在这种现象的背后有什么潜在的原因呢？我认为至少有两方面关键因素： （ 1）客户希望支付的成本尽可能少，获得的效益尽可能多 这种思维对于任何一个客户、任何一个 人而言都是本能反应。而当用户对开发成本越不了解时，这种心态就会越强烈，更加担心自己“亏损”了；因此在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。 要有效地克服这个因素的困扰，核心的要点在于建立客户对开发团队的信任度，而建立信任度的要点有两个方面：一是需求人员必须提升自己的专业主义（关于这一点我将在后续的文章中说明）；二是需求人员要多站在用户的角度想问题，让用户感觉需求人员的目标是帮助自己解决问题，而非一味谋取利益。 （ 2）解决方案的选择权交给了不熟悉技术的客户 也就是用户经常会谈 解决方案，甚至许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（ What），而不太关心用户提出需求的真正动机（ Why）。但是这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而客户代表选择的解决方案不是最合适的话，就必将引发后续的需求变更。 案例 &场景： 在一次 CRM 软件开发的过程中…… 负责输入客户信息的用户向开发人员提出：“你看这个界面，光电话就有快 10 个输入框，太麻烦了，每次按 tab 键都按酸了。我希望把他们合并成两个，一个为常用电话，一个为其他电话”。“那有多个电 话怎么办？”，开发人员回应道。 “其他电话的输入框可以设置为多行的、较宽的，这样我可以输入多个，中间用逗号分开它！”。 “好的，没问题”。 …… 当经理看到了这些客户信息之后，向开发人员提出：“我需要一个功能，输入任何电话号码，自动找出相应的客户。” “啊……” 如果我们细究这个场景，分析一下负责输入客户信息的用户所提出的变更就会发现：“将 10 个电话输入框合并成两个”显然是解决方案，而真正的需求是“输入太麻烦了，每次按 tab 键都按酸了”。你或许就会想到如下所示的解决方案： 图 3 解决方案示意图 也就是说，默认情况上只显示左边的部分，当需要时点击“其它 >>”按钮就可以将右边的不常用输入 项显示出来。 总而言之，因为对于一个特定的问题可能的解决方案会有很多，因此用户可能在使用软件的过程中不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而要缓解这一现象的关键就在于在需求捕获的过程中多问“为什么”。 项目经理：控制需求 当我们比较图 1 中第 1 幅和第 2 幅图时，就会发现项目经理在沟通的过程中会导致需求产生偏差。由于国内许多软件项目经理们通常是一身兼多职，项目管理、需求分析、架构设计一肩挑，因此在需求捕获的过程中，总会“及时”地在脑海里勾勒出技术框架和路线，然后尽可能地控制 需求的范围。 就像这里，从图 1 中第 1 幅图看，客户需要的可能是一个“秋千”或者是“上树工具”，但不管真正的需求是什么，第 2 幅图中的解决方案却都无法有效地满足。如果要做“秋千”，不应该被树干挡住；如果要做“上树工具”，木板的数量显然太少了。 究其原因不难发现，需求人员首先从项目经理的视角按工作量对需求进行了控制：将“三层”板的工作量减成“一层”板，如果不小心控制掉的是对业务很重要的东西，那么最终一定会以变更的形式“回报”给开发团队的。然后需求人员又从架构师的角度进行了“改良”：不稳定的“全挂在一个树枝上 ”改成“挂在两个树枝上”，结果根本无法使用。因此具有多个角色的需求人员，必须在需求的过程中“戴正自己的帽子”，真正从理解业务的角度来捕获需求。 分析人员：技术加工 每次看图 1 中第 3 幅图时，就会想起这样的一幕： 案例 &场景： 分析员小张：“嘿，伙伴们！我有个提议，我们研究 Hibernate已经有一段时间了，一直没时间真正动手用一用。我看这个项目就不错，不算太大，就用它试试吧！”。 “好主意！”，大家纷纷表示赞同。 …… “约定时间已经过去 1 个月，现在项目进展到底如何了？什么时候可以 交付？”，客户方 CIO 质问到。 分析员小张：“现在主要困扰我们的是一些需求细节一直存在变化，开发团队又有了一些人离职，所以……”（真正的情况是：由于团队第一次使用 Hibernate，有些数据访问层的问题一直没有有效解决，导致进展不断失控。） 现在许多名称中包含“需求分析”、“系统分析”之类的职位，大多是由技术骨干担任的，因此在工作中很少从业务角度进行分析，更多还是追求技术框架、新技术。对于这种现象，究其根源，关键还在于“技术能力”对他们的未来发展更为重要，而“业务能力”却不是那么重要。但为了使需求工作有更好的提高，我会强烈呼吁那些 Title 上有“分析”之类名称的人们，加强业务分析吧！ 编程人员：断章取义 对于第 4 幅图，可以用一句生动的话来概括：“你要绳子，我给你了；你要木板，我也给你了；你为什么说这不是你想要的呢？”。我想程序员也有类似的问题想问自己的客户，“你要文本框，我提供了；你要一个表单，我也有了；你为什么说这个程序不是你想要的呢？”。这让我想起了这样一幕： 案例 &场景： 叮铃铃……，程序员小赵的电话急促地响起。小赵刚接起电话就听到了对面迫不急待地抱怨声“仓库管理员反应，入库模块 没法使用！你马上查一下，尽快解决一下！”。 小赵放下电话就开始 Checkout、 Builder、 Run、 Debug……等一系列操作。经过一番测试之后，小赵没好气地提起电话回复说：“这些客户真是笨！这哪有问题，肯定是操作上出了问题！我怎么用都是好的，你们客户服务的人也应该加强对用户的培训，别什么事都扔给我们！”。…… 可是，问题仍然没有解决！开发人员到了现场一看，终于发现了问题的所在：这是一套基于 B/S 的仓库管理系统，在入库时，仓库管理员首先需要录入入库单，然后填入“验收情况”，最后点击“入库”按钮。 但当仓库管理员录入完入库单，逐一验过入库货物之后再回到电脑前时，等待他的却是一个令其不知所措的问题， Session 超期！ 一肚子气的小赵一个电话就打到需求分析员小钱那里：“你们的需求是怎么写的！这么重要的东西也不写明白，我们怎么知道填完入库单后要验货那么长时间，才填写验收情况呀！”。 “哦，这也算是需求吗？如果这也算的话，那我们岂不成了业务人员了！”，小钱很强势地回答到。 这是需求吗？也许很多读者会有不同的看法！但如果缺乏对业务场景的了解，又如何能够真正理解需求呢？断了“业务场景”之章，必将导致 取出的“需求”之义有所偏差呀！作者简介：中国系统分析员顾问团软件工程首席顾问，中国软件技术大会杰出贡献专家，资深咨询顾问。主要研究领域为需求工程、系统分析与设计、软件估算，致力于推动软件工程方法论的落地应用。本文节选（并改编）于笔者新著《软件需求最佳实践： SERU过程框架原理与应用》（电子工业出版社博文视点）