16.2　汲取知识

前不久，我们承接了一个项目，其中一个模块需要做两个系统的集成。一开始，做该集成开发的工作人员有两个，过了一个月，其中一位离开了公司。又过了一个月，集成仍然迟迟不能发布，于是经理派我去着手解决这个问题。由于我只了解其中一个系统，对另一个系统，除名字之外我一无所知，我并没有立即打开繁琐的技术文档，而是向之前的开发人员了解需求。开发人员告诉我，没有正式的需求文档，只有一封潦草的邮件，其中关于集成需求的描述只有一句话：系统A和系统B的集成。

由于领域专家不在，我就坐下来和该开发人员进行了半个小时左右的沟通，慢慢地我发现该开发人员对需求并不太理解，我提到的很多细节问题他不能如愿作答。此时，他对需求的理解就是：把系统A的一条记录发送到系统B，然后生成一条新记录，由于数据格式不匹配，二者之间需要定义一个映射。他在这上面花了很多时间做尝试，最后都被领域专家否定，他也不知道领域专家需要什么。

所幸的是，一天后，领域专家赶了回来，我直接找他了解需求，在长达2个小时的讨论中，我发现之前的交流存在一些问题：领域专家未能完全表达他的想法，也不知道开发人员能否按照自己的想法做出功能，而软件开发人员也不知道真正的需求是什么，双方并未有效沟通。

根据这次探讨，我了解到：由于系统A和系统B之前就有集成，后来系统B中的一个模块发生了变化，主要是为这模块的模型新添了一些属性，导致使用之前的映射不能创建一条完整的记录，为了在不修改系统A的前提下，要使之前的集成正常运行，我们要给那些属性配置一些默认值。

这次讨论之后，我看了下系统A和B集成的技术文档，然后画出一个简单的设计草图，如图16-1所示，你也许发现，它简单到了极点。

图16-1

需求比较简单，但在动手之前，我拿着设计草案又和领域专家进行了一次讨论，发现我们可以根据记录的某些属性，给出更为具体的默认值，比如，如果记录的一个属性优先级的值为“高”，那么新添加的这个属性影响我们最好设置为“重要”。而之前没有深入讨论这个的原因是，他觉得这样可能难于实现，所以自己也未朝这个方面多想。经过这次讨论之后，我们确定了设计方案图，如图16-2所示。

图16-2

Condition表示如果Module记录信息满足该条件，那么就是用此模板提供的默认值给记录赋值。真实的设计草图当然比这个复杂，这里为了讨论的方便，我们就到此为止，不再给出细节。

经过这两次的讨论，我和领域专家敲定了我们的需求，他也理解了我们能为用户做些什么，我们也知道他们想要什么。后来的事情就相对简单了许多，经过我两天多的苦力编程，终于顺利完成了开发。

这样，2个月未做完的需求我一共花了不到4天就做完了（包括讨论需求），这并不是我的技术能力比之前的开发人员好很多，原因在于。

开发人员在编写软件时，对需求和领域知识总是未引起足够重视，只专注于学习二者如何集成的一些技术问题，越是简单的需求越是不重视，导致做了很多无用的工作；

领域专家并非对领域的每一方面有着极其深入的了解，只有和他们进行深入讨论，他才会明白你能做什么，不能做什么，这样才能开发出比他们当初想象更为强大的功能。

提示：能够高效建模的人具有超强的消化领域知识的能力，也能帮助用户分析用户到底想要什么，消化知识需要的不是独立的单方面的行为，而需要开发人员去主导，开发团队和需求专家一起分析信息，消化知识，才能建立有效的模型。