【非技术】谈谈业务-6W+H

Eric Evans的那本著名的DDD的副标题是“软件核心复杂性应对之道”。而Martin Fowler在为此书写的序的第一句话就说：“很多原因都会造成软件开发的复杂性，然而其核心则是由于问题领域本身的复杂性”。在Eric Evans自己写的前言中有一段话应该说到了广大开发人员的心坎上：

“然而许多应用程序最大的复杂性不在技术方面，而是在领域本身，用户的活动或业务方面。如果在设计中没有处理好领域复杂性，那么基础设施技术再好也不管用。一个成功的设计必须系统地处理软件的这个核心方面。”

副标题、序和前言里的话，无不透露着领域或者业务之于软件是否成功的重要性。在我从业以来也深感一个软件的成功与否与技术越来越远，好的技术无疑可以更快、更出色的完成任务，但是如果我们努力的方向错了，那开发出来的软件当然是个失败之作。无奈的是我们中大多数人都是计算机或计算机相关专业出身，而所服务的公司大部分都是为某个行业服务的。

就拿我自己来说，从事石油行业开发的几年来，最头痛的事不是碰到哪个技术问题无法解决，更多的是和用户谈需求，如何将公司石油专家的分析报告转化为软件等等。我在一方面恶补石油专业知识外，大量的学习需求获取等方面的知识。下面我以我自己的切身经历为主线，来谈谈技术人员如何处理业务的。而且，我觉得这适用于一切行业软件开发。

传统的开发模式

在传统的开发模式中，石油专家分析出在工作中需要什么样的报表、图形（曲线图、柱状图等）、图件（地质构造图等），然后我们软件人员就巴拉巴拉的实现这些功能。最后开发出来的软件就是一个类似Word 2003的软件，一大堆菜单，点开一个菜单显示一个东东。最后软件也就变成了菜单的罗列，新版本也就是加上更多的菜单，市场宣传文稿列的也是功能列表。这样的软件有几大弊端：

1、软件使用越来越麻烦，用户需要的功能迷失在菜单的海洋里。

2、软件模仿成本低。菜单的罗列很容易被竞争对手模仿，你开发了一个功能别人只要看一看马上就可以模仿出一模一样的功能出来。

用例

后来我接触到用例兴奋异常，彷佛发现了软件开发的真谛。不过用例（Use case）这个词儿在古老的中文里应该不存在，理解起来也非常抽象，实际上我们可以把用例当作中文的“事儿”。一个用例描述的就是用户完成的一件事儿，而软件正好就是帮助用户完成事儿。比如你到ATM上取钱这是一个事儿，而取钱是要分很多步骤的，对于软件开发人员来说就是要有很多一个个连续的屏幕才能完成这个事儿，你做一大堆零散的屏幕是没有用的，只有将这些屏幕有机的组合在一起完成用户的这个事儿才有价值。

对于我来说，我开发一大堆图表也是没有价值的，只有这些图表有机的组合在一起来帮助用户完成一件事儿才更有价值。

在我接触到用例后我以为我已经掌握了“软件核心复杂性的应对之道”。但是在和用户交谈后却发现，使用用例的方式与用户交谈并不是想象的那么简单，还是需要我们非常了解用户做的事儿，然后再好提问。而人们往往对抽象的东西理解起来困难，而对真实存在的东西理解起来就容易多了。用户更擅于提出这样的需求：我们需要一个a曲线、b报表、c地质构造图。

6W+H

遇到这种情况该怎么办？那我们好像又回到了功能列表的堆积。

其实既然用户擅于提出实实在在的东西，我们就以这个为突破口，然后反推到用例上去。但是在用户提出一个实实在在的东西的时候，我们应该提几个问题，我将这几个问题称之为5W+H：

What?这个东西是什么？

Who?谁会用到这个东西？

When?什么时候会用到这个东西？

Where?在哪儿会用到？

Which?你们现有的哪个软件已具备这样的功能？最好还要了解到用户对目前使用的软件里的这个功能的感受。

Why?为什么会用到这个功能，这也是最核心的部分。谢谢Ivony…的提醒，汗。

在向客户提出以上6个问题后，我们再来自问：How?如何实现这个功能？

在针对每个功能（或东西）经过上面6W+H的问题后，我们再进行归纳，进行数据分析：

Who相同的放在一起

When相同的放在一起

Where相同的放到一起

经过这样一归纳基本上就可以归纳出一个不太完整但是比以前好的多的用例了。

然后我们要找到用户所提到现有的具备该功能的软件仔细进行研究（当然这个不是每个都有的）。

最后根据上面的5个提问作出你的设计。

演练

下面就根据6W+H的方法来演练一个简单但又真实的示例。

客户：我需要一个油井开采曲线

我：油井开采曲线？这是一个什么曲线呢？

客户：哦，油井开采曲线就是以时间为横轴，然后绘制油井每一天的各种指标，比如产油啊，产液啊，动液面啊等东西。

我：哦，原来是这样的啊，那这个曲线一般哪些人会用呢？

客户：我想在我们这儿工作的都会用到吧，因为这是个基本的曲线。

我：哇，这么多人用啊，那要好好做啊。那您们一般什么时候会用？

客户：天天用啊，一般我们上班的第一件事儿就是打开这个井的开采曲线。（嗯，这里有戏）

我：这么多人用，又这么常用，看来真是个好东西。那你们一般用在哪里，也就是说用它来干啥？为什么会用这个功能？

客户：我们天天打开这个曲线实际上就是为了瞧瞧这个曲线正常不，看看曲线平稳不，比如今天突然发现某口井的产油突然降低了，从图上看出的也就是产油这条线突然掉下去了，我们就要找更多的资料来分析分析。不过在写汇报的时候我们也需要这个曲线，将其粘贴到PPT里面去，以前都是我们用Excel作的，太麻烦了，现在有软件就好多了。

到这里，应该欢喜了。原来用户需要这个曲线大部分时候就是瞧瞧曲线是否平稳，那我们光开发这个曲线还不能解决最大的问题。一个油田分很多区，一个区有几百口油井，有的更多，一般一个工程师会监管一个区或者多个区，如果让工程师每天一个个的查看每一口油井的曲线，然后看看是否平稳这不是一个好方法，我们首先得做一个报警的东东，用明了的方法告诉工程师哪些井异常了，那我们就让计算机来帮用户“看”哪些井的指标发生了大幅的波动。

当然，关于这个曲线还有更多的需求可以挖掘，不过这里只是举例为目的。

后记

我不知道是否将我心中所想描述清楚了，也不知道是否对您有所帮助。不过我一般是按照这种方式来与客户“斡旋”的。请记住6W+H~~

关于技术之外的思考还可以参见我的另外一篇文章：最近老在触动我心底的一些东西