执行者（Actor）的意义

一个老头找到PS可乐公司，告诉他们的主管说：“我可是你们的忠诚客户啊！我喝过的可乐罐排成线，可以从苹果园排到通州。现在我老了，我对你们的可乐下一个版本提出如下需求：第一，我有胃病，下一个版本不要放碳酸气；第二，我有糖尿病，下一个版本不要放糖。”PS可乐公司的主管很感动，哇，这么棒的顾客，把需求提得那么具体，省去我们调研需求的好多时间，好，下个版本就这么办！

会有这样的场景吗？不会的。老头老太太可以买可乐喝，甚至可以买给自己的狗喝，PS可乐公司不会拦着。问题在于，老头老太太提的要求，或者他们的狗提的要求，PS可乐公司不会放在重要的位置来考虑，因为可乐的目标客户是年轻人。可惜，很多时候我问开发人员：“可乐卖给谁？”得到的回答大多是“卖给消费者”、“卖给想喝可乐的人”——对做出好卖的可乐没有帮助的、正确而无用的废话。

我啰嗦这么一大堆，其实就是想说，从“可乐可以喝”到“年轻人喝可乐”，多出来的这个“人”背后的意义不简单。

软件系统也一样。如图1所示，需求的表达方式，从“系统提供定义推广规则的功能”变成“投注站老板使用系统来定义推广规则”，重要的意义就在于发现了执行者（Actor）这个小人。电脑开着，投注站老板上洗手间去了，有人路过也可以使用投注站系统来定义推广规则，但“定义推广规则”这个用例所包含的各种功能需求和非功能需求，更看重的是投注站老板的意见，而不是路人的意见。

图1 用例和执行者：卖给谁和卖什么

和之前的需求技术相比，用例技术（包括执行者和用例）的不同之处就在于发现了“卖”——需求是研究软件怎样好卖的技能。以前有观点以为执行者映射了权限管理，意味着系统需要有权限控制，其实这是一种误解。一罐可乐打开在那里，猪路过也可以喝，可乐本身并没有“防猪”的权限管理，但猪仍然不是执行者，因为猪不是可乐的目标客户，PS可乐公司不会因为猪喝得不爽就改变可乐的功能和性能。当然，如果你做的是这样一种“可乐”，猪喝了可乐可以长得更快，那就是另一回事了。不过，你能想到“猪喝的可乐”，不也是拜了执行者思维之赐吗？

从所有人到一群人

为什么卖给谁这么重要？因为竞争使得产品分类越来越细，不再有针对所有人的产品了。在原始人眼里，喝水是很简单的事情，靠着河就喝河水，靠着泉就喝泉水。随着市场的发展，喝水变得越来越复杂，如图2所示。

图2 不断分化的水，每一种水针对不同的人群

软件的分化也是如此，见图3。程序员想用QQ完全可以用，没人拦着，但他们的意见对QQ的需求影响有多大呢？

通过可乐、投注站、喝水等几个生动的实例，展示了理清软件功能主要为谁服务的重要性。随后得出了结论：需求要具体，设计要抽象。或者说，需求，要把产品当项目做；设计，要把项目当产品做。

执行者（Actor）的意义

一个老头找到PS可乐公司，告诉他们的主管说：“我可是你们的忠诚客户啊！我喝过的可乐罐排成线，可以从苹果园排到通州。现在我老了，我对你们的可乐下一个版本提出如下需求：第一，我有胃病，下一个版本不要放碳酸气；第二，我有糖尿病，下一个版本不要放糖。”PS可乐公司的主管很感动，哇，这么棒的顾客，把需求提得那么具体，省去我们调研需求的好多时间，好，下个版本就这么办！

会有这样的场景吗？不会的。老头老太太可以买可乐喝，甚至可以买给自己的狗喝，PS可乐公司不会拦着。问题在于，老头老太太提的要求，或者他们的狗提的要求，PS可乐公司不会放在重要的位置来考虑，因为可乐的目标客户是年轻人。可惜，很多时候我问开发人员：“可乐卖给谁？”得到的回答大多是“卖给消费者”、“卖给想喝可乐的人”——对做出好卖的可乐没有帮助的、正确而无用的废话。

我啰嗦这么一大堆，其实就是想说，从“可乐可以喝”到“年轻人喝可乐”，多出来的这个“人”背后的意义不简单。

软件系统也一样。如图1所示，需求的表达方式，从“系统提供定义推广规则的功能”变成“投注站老板使用系统来定义推广规则”，重要的意义就在于发现了执行者（Actor）这个小人。电脑开着，投注站老板上洗手间去了，有人路过也可以使用投注站系统来定义推广规则，但“定义推广规则”这个用例所包含的各种功能需求和非功能需求，更看重的是投注站老板的意见，而不是路人的意见。

图1 用例和执行者：卖给谁和卖什么

和之前的需求技术相比，用例技术（包括执行者和用例）的不同之处就在于发现了“卖”——需求是研究软件怎样好卖的技能。以前有观点以为执行者映射了权限管理，意味着系统需要有权限控制，其实这是一种误解。一罐可乐打开在那里，猪路过也可以喝，可乐本身并没有“防猪”的权限管理，但猪仍然不是执行者，因为猪不是可乐的目标客户，PS可乐公司不会因为猪喝得不爽就改变可乐的功能和性能。当然，如果你做的是这样一种“可乐”，猪喝了可乐可以长得更快，那就是另一回事了。不过，你能想到“猪喝的可乐”，不也是拜了执行者思维之赐吗？

从所有人到一群人

为什么卖给谁这么重要？因为竞争使得产品分类越来越细，不再有针对所有人的产品了。在原始人眼里，喝水是很简单的事情，靠着河就喝河水，靠着泉就喝泉水。随着市场的发展，喝水变得越来越复杂，如图2所示。

图2 不断分化的水，每一种水针对不同的人群

软件的分化也是如此，见图3。程序员想用QQ完全可以用，没人拦着，但他们的意见对QQ的需求影响有多大呢？

例图3 软件的分化，MSN、QQ、旺旺针对不同的人群

所以，通过思考执行者来理清楚“这个功能主要是为谁服务”非常重要。不过，思考出这个小人不容易，特别是当要开发的系统所服务的组织不是一个有明显岗位分工的正式组织（例如国土资源局），而是一个松散人群（例如玉米、房奴、驴友）的时候。经常有开发人员问：如果只是做一个网站展示企业和产品信息，要不要建模呢？确实，象完成作业一样做一个展示企业和产品信息的网站容易，可是，网站要做到能给企业带来利润，企业下次还找你，那就需要做艰苦的调研和建模。光是“网站给谁看”这个问题，就已经使很多人栽倒了，给“春哥”和给“著姐”看的网站能一样吗？

给执行者命名的时候，要拒绝淡而无味的命名，以及正确而无用的废话。看看对执行者的命名，就可以看出开发人员是否具备探索需求所需的市场思维。有时为了想这个小人的名字，要绞尽脑汁，这样的需求才有味道、有价值。

起淡而无味的名字，原因除了开发人员对涉众缺少调研之外，其他原因也可能是开发人员忍不住“透过现象看本质”——“单证人员”等各种人员都可以从“用户”继承下来，这犯了从设计的角度找需求的错误。设计时可以用“用户”，这样许多特征都可以复用，但做需求时是不考虑复用的。

图4 拒绝淡而无味的命名

我们去小吃摊上买馄饨，老板给我们饺子或锅贴，还辩解说“都是面和菜肉的组合”，这样可以吗？我在之前的文章中说过：利润＝需求－设计。小吃摊老板的赚钱之道就是用少量的材料（设计组件）灵活组合出不同的需求（用例）卖给不同的顾客。

需求要具体，设计要抽象。或者说，需求，要把产品当项目做；设计，要把项目当产品做。

从一群人到一个人

既然需求要具体，定位到目标人群后，有时甚至还要定位到一个人，假装这个用例专门为他而做。

例如，某个功能为男性提供，那么如何调研详细的需求？是对男性群体做大规模调查，还是从CSDN员工里随机抽取一位男性来深入访谈、观察？一种方法是问：哪个男人最像男人？得到具体的人物“春哥”，然后，假装这个用例就是专门为春哥而做，这就是交互设计中用到的Persona方法。

如果一下子想不出来哪个最像，可以通过比较，慢慢逼近答案。例如，说“客户是医院”还不够，还要问，“协和医院”还是“大兴中医院”更像你的系统所服务的医院？

做这样的思考是很有意思的：哪一种水果最像水果？橙还是枣？从科学的角度说这两种水果是平等的，但我们说到水果时，想到更多的是橙还是枣？哪一种方便面最像方便面？哪一种CT机最像CT机？哪一个SNS网站最像SNS网站？哪一个程序员最像程序员？

目前，介绍GoF23个设计模式的书非常多。大多数书籍在讲述时按照创建型、行为型、结构型的顺序进行。在这23个模式中，有一个模式经常会放在前言先行介绍，作为例子展示设计模式的魅力，您知道是哪一个吗？也就是说，哪一个设计模式最像设计模式？

从台上人到台下人

再继续往下探讨，执行者的原意是“演员”，演员在台上如何表演，由台下各类观众的口味综合决定。软件的需求也是一样，由各类涉众的利益综合决定，通过执行者和系统的交互演绎出来。将执行者和涉众分开之后，涉众一定是人，执行者可以不是人，也就是说，银幕上演的是喜羊羊和灰太狼，也同样要考虑观众的口味，而用例之前的需求技术所使用的“用户”这个词，相当于把演员和观众混在一起了。关于执行者、涉众和用例的进一步探讨，留待下文“这个圈圈不简单”。