需求分析 涉众利益-上

从涉众利益着手改善需求质量（上）
潘加宇
需求之难
在一次交流会上，笔者被要求向开发团队展示如何在开发团队当前项目中使用用例方法。

在对项目基本没有了解的情况下，笔者通过和在场开发人员的对话，一步步地引导，最后推敲出了一份用例文档。

沉默了一会之后，开发团队的负责人对笔者说，“其实您找出的这些需求现在我们已经知道了，所不同的是，您是在设计之前知道的，我们是碰了很多壁、修改了许多代码之后才知道，如果我们当初能掌握您刚才展示的技能，就可以少做许多无用功…”
图1 需求问题的代价
Barry Boehm曾经用这样一张图来描述需求问题的代价。

如果需求出了问题，在后面的工作流可能需要几百倍的成本来修正它。

这还意味着，越沿着错误的需求往下走，在错误的方向上浪费的人力物力只会越来越多。

所以需求是软件公司最值得改进的环节。

这个道理大多数软件组织是懂的（当然，也不排除有的组织不懂，不过碰壁之后很快就会意识到）。

但真正的问题是：你想改进就能改进吗？很多时候团队也匀了时间来做需求，但开发人员没有掌握需求的相关技能，一拨人到了客户那里，也不知道具体该怎么做，随便看看，问一些问题，开个会，就不知如何往下走了。

这个时候开发人员可能会开始觉得：算了，还是编码比较有意思，不如把这个时间拿去编码吧！（后面多付出几百倍的成本又怎么样，反正我又不是老板！）从哪里开始改进？笔者这些年一直致力于帮助开发团队应用用例驱动的面向对象方法，在开始的一段时间里，在需求过程中，笔者主要强调用例的好处是帮助发现价值，怎样寻找用例，怎样写用例文档，怎
样正确使用扩展包含……但经过一段时间的积累后，发现开发人员往往在实施过程中过多地注重形式，甚至陷入玩弄技巧的泥潭。

现在，笔者认为，需求之所以难以改进，是因为它涉及到了人－人交互的环节，这些环节仅仅通过开发人员坐在电脑前面练习画图、写文档是无法改进的，必须先引入“人”味，让开发人员先把屁股坐到涉众那一边去，再来考虑用例等其他问题。

所以，涉众利益是改善需求质量的最佳入口点。

需求背后的涉众利益【2】
假设我要去商场买东西，需要500元现金。

好，现在我的目标是：获得500元现金。

我有两种方法可以获得：1. 拉开家里的抽屉，里面有超过500元的现金，我就从中拿500元；2. 如果抽屉里没有钱或者钱不够，我就拿上银行卡，到楼下取款机去取500元。

问题来了：为什么家里的抽屉拉开就可以拿，而楼下的取款机却找我要卡要密码？
图2 目标一样，但路径和步骤大不相同
背后的原因就是：虽然目标相同，但涉众利益不同。

家里的抽屉，只涉及到我和我家人的利益，如果利益没有什么冲突，直接拉开抽屉就可以拿（从另一面说，如果我和我家人的利益冲突得非常厉害，那么可能需要买一种长得很象取款机的抽屉才符合我的需求），而对于银行取款机来说，就不是这样了：用户在取钱时，涉及到了这样一些涉众的利益：
用户—希望操作方便；希望24小时服务；担心被多扣了钱。

银行—希望安全；希望节约运营成本。

法律—保护财产。

正是在这些涉众利益的交锋之下，目前我们日常生活中所看到的取款机的用例大概如下【1】：
基本路径
1. 用户插入银行卡
2. 系统提示输入密码
3. 用户输入密码
4. 系统验证密码合法、正确
5. 系统提示输入取款金额
6. 用户输入取款金额
7. 系统验证取款金额合法
8. 系统从用户账户扣除取款金额
9. 系统吐钞
10. 系统提示交易结束，退卡
扩展（略）
业务规则
4. 密码为6位数字
7. 取款金额应为100元的倍数；一次取款金额不能超过3000元；当日取款金额不得超过5000元；
我们从上往下看：
[1. 用户插入银行卡]。

为什么不是[用户输入16位的账号]？为什么银行要做那么多卡来免费给我们用（当然，那是以前，现在收费了）？这是为了照顾用户[方便]的涉众利益。

[2. 系统提示输入密码]到[4. 系统验证密码合法、正确]。

既然为了用户方便，还验密码干什么？银行不是口口声声说用户是上帝吗？为什么不把交互改成这样：1. 用户插入银行卡；2. 系统弹出钱箱；3. 用户取钱，推回钱箱；系统计算取了多少钱….？这是为了照顾银行[安全]的涉众利益。

业务规则[4. 密码为6位数字]。

既然设密码是为了安全，何不设10位或更长的密码？这又是[安全]和[方便]交锋后的妥协。

可以想像，如果有一天，“取款机黑客”魔高一丈，6位密码很容易攻破，这条规
则可能就会变成[4. 密码为8位数字]
[8. 系统从用户账户扣除取款金额]。

这是用户看不见摸不着的，为什么要写出来？还是涉众利益――如果不这样做，银行会吃亏。

业务规则[7. 合法取款金额应为100元的倍数]。

为什么要有这一条？如果能有1元2元的取款机，用户将会非常高兴（没有零钱坐公共汽车？到取款机那里取去！），但银行不高兴――成本太高了。

业务规则[7. 一次取款金额不能超过3000元；当日取款金额不得超过5000元；]。

为什么是这样？要是现在是下班时间，用户急着要现金，他的卡里有几万块，凭什么只能取几千块，要多取还得明天到柜台排队？银行的解释是为了保护用户的利益，防止被冒领，但银行有没有别的办法，是不是一定要通过这种一刀切的方式，以损害用户的利益为代价？在当下，银行可能不愿意也不需要去想，因为在我们下面要提到的“涉众排行榜”中，银行坐在第一排，用户坐在最后一排。

所以，我们就会得到这样的取款机，同时还要忍受到柜台取少许现金时，营业员“温馨提示”5000元以下“请”到取款机办理。

还有最后一点，如果法律不保护财产――假如某国宪法规定“公民有无条件共享他人财富的权力”，这个取款机可能就是违法的，应该做成象抽屉一样才合理。

由此可见，取款机应该如何表现，取决于各种涉众利益的交锋。

其他的系统也是一样。

认识到这一点，可以帮助我们单刀直入需求的核心，也使我们的需求过程因充满了“人”的味道而变得乐趣横生。

下面是另一个比较简单的例子，你能对照左边的涉众利益和右边的需求，从里面看到涉众利益的交锋吗？
UC1：注册
涉众利益用例文档（片断）
潜在会员――希望注册尽量简单；希望自己的信息不会被商店用于其他用途
商店――希望获得尽可能多的客户信息，特别是联系方法1. 潜在会员提交注册信息。

2. 系统验证注册信息充分。

3. 系统生成用户名和密码，保存注册信息。

4. 系统显示注册成功正在等待开放账户。

补充约束
1. 注册信息有：公司名、联系人、电话、传真、Email，以及联系地址。

2. 公司名、联系人、电话是必需的。

* 注册界面上应有保护客户隐私的承诺。

同时还可以看到，相对于具体的需求，涉众利益是稳定的。

回到取款机的例子，假设以后技术进步了，“插卡”改为“验指纹”或者“检查视网膜”，具体的需求变化了，但涉众利益没有变。

甚至用户放弃取款机，拿着银行卡请营业员帮忙办理，这个时候主执行者改成了营业员（操作营业受理系统），但用户的涉众利益还是没有变。

另外，涉众利益是能直接从涉众那里得到的主要素材。

当我们做需求启发时，寄望于直接从涉众那里获得具体需求是不现实的。

但不管什么样的涉众，他对自己的利益都是清楚的，有着自己的盘算的。

就算是婴儿，他也会通过哭和笑来表达自己满意还是不满意。

认识到这一点，我们就大可不必执着于从涉众那里直接得到需求，而是把启发的重点放在涉众利益上，然后自行推敲出需求，再去和他们确认。

下面一个稍为复杂的例子留给大家思考。

司机开车进厂装化肥，工作人员通过系统操纵地磅给车称重：
用例名：进厂称重
执行者：地磅工作人员（主）、地磅（辅）、档杆（辅）、车牌识别装置（辅）
涉众利益：
化肥公司老板――希望杜绝公司内部人员贪污；
货主――担心给少了化肥；
地磅工作人员――希望操作简便；担心承担责任；担心系统坏掉；
仓库装货员――担心称不准导致无谓的返工装包；
司机――担心等侯时间太长；
基本路径：
（假设您是需求人员，你怎么推敲出具体的需求？）
涉众带来的新视界
图3 用例是涉众之间达成的契约，以执行者为达成特定目标和系统交互的方式演绎
把用例看成是各种涉众利益交锋的结果，为捕获需求带来了新的视界。

它刷新了“客户”、“用户”等概念，强调了需求的来源不只是“客户”、“用户”，而是来自方方面面的涉众，而且这些涉众是排了座次的。

了解了这一点，我们可以来解决平时碰到的各种困惑：
“客户的说法经常自相矛盾，有时他说这样，有时他又说那样，到底怎样才是？”
“我去问客户他想要一个什么东西，他居然说他也不知道！”
“我这个东西非常的创新，我还不知道客户是谁呢！”
……
这些笔者将在下一篇文章中和大家讨论。

同时，还要和大家讨论的有：到底什么是涉众？如何寻找涉众？如何通过涉众分析尽量减少遗漏的需求？如何通过涉众利益恰如其分地表达真正的需求？如何通过涉众排序来过滤不合适的需求？……
补注
【1】在一些书和文章中，以ATM机举例时，作者会提到“系统”和“银行后台系统”的交互，这也是正确的。

本文为了简化问题，认为对“用户”来说，“系统”是一个整体。

同样为了简化问题，可能会有的验证卡有效、扣手续费、记录日志、打印凭条…等也略去。

【2】Stakeholder中文也有叫干系人、利益相关者、风险承担者的。