实践（Practice）
5. 建模会议会议是业务建模最重要的手段。尽管会议在中国总是背负着一些骂名，但是只要组织得好，它是一种相当有效的沟通（Communication）手段。建模会议是一种大范围的会议，换句话说，所有的相关人员都应该参加会议。因为在业务建模时期，主要的目的就是建立对系统的高阶需求，这就要求众多项目涉众的共同参与，以保证需求的广泛性。所以呢，建模会议的规模是相当大的。出资方、高级经理、经理、直接用户、开发人员，各方各面的人都应该参加或是派代表参加建模会议。
如果大家有过参加大型会议的经验都知道，越是大型的会议，它的决策效率就越低。这是正常的。因为一个人的时候，不需要沟通，决策效率最高。等到两个人的时候，他们需要沟通的时间来进行决策。等到三个人的时候，这个沟通并达成一致的时间就更长。如果人数到了四个人、五个人甚至一二十个人，那么大部分的时间都会花在沟通上。更何况，人和人之间还有观念不同、利益之争。所以呢，为了保证会议的效率和效果，应该遵循一定的规则：做好准备：如果你要开会，与会者连内容都不清楚，那你会怎么办。你必须首先花很多的时间来说明你开会的目的，是不是。要事先将会议的主题、议程连同会议通知发送给与会者，让他们先有个准备，会议开始时就能够迅速进入正题。
尽量邀请最多的人：我已经说过，如果建模会议不能够听取最广泛的意见，它就不是一个成功的会议。可是在现实中，这点往往难以做到。因为目标组织做为客户，往往都很"拽"，在没有充分认识会议的重要性之前，要做到全部到场简直就是不可能。而客观上也会有出差、休假、有要事等原因做不到这一点。这里，一方面你需要向目标组织的决策者阐明利害，让他们重视。另一方面，你也需要积极主动的邀请项目涉众参与。因为邀请所有的人是不可能的，所以就尽可能的多吧。
分出与会者的级别：我很喜欢那种有一个内圈、一个外圈的会议室。因为我邀请所有人是件无法做到的事情，所以我首先要保证核心人员能够全部到场，坐在内圈，然后才是次要的人员，坐在外圈。核心人员是和你的项目息息相关的那种人。比如，财务系统，财务主管就是核心人员。要保证核心人员全员到场，至于次要人员，越全越好。
从底层开始：中国人有个比较不好的习惯，就是老板说一的时候，他决不会说二。所以要先让底层先说话，然后才轮到中层，再到上层。开发人员是不说话的，他们要么听，要么引导大家说话。如果我们一开始就先让领导来训话一番，那底层的人也就不用再说什么了。
列举所有涉众的所有观点：首先要让大家能够对新的系统畅所欲言，然后把所有的观点都罗列在白板上。这里头可能会有一些观点会是非常荒唐的，但没有关系，尽管写上去。这是一个脑力激荡的过程，很容易产生出新的idea.主持的开发人员的主要工作就是引导和鼓励大家说出更多的想法，并记录下来。这里我们稍微离题一下，有人说中国人在会议上大都不愿意发表意见，我看在这种建模会议上不必过于担心此事。为什么呢，因为项目涉众不需要为他们的发言担任何的责任，说了，白说，白说谁不说。
将观点分类：想必你的项目涉众已经有些累了，创意也差不多了，你的白板估计也满了。但是你看看白板上的观点，有很多是重复的，有很多是类似的。所以你需要用逻辑的观念将这些观点归类整理。这个工作也可以由你引导大家去做。
确定优先级：对观点排出优先级也是非常重要的，它能够帮助你识别出重大的风险，并为你在制定迭代计划时提供指导。同样，这项工作也应该由项目涉众来确定。
调查主要业务逻辑：什么叫主要业务逻辑？包括了企业的主要业务流程、主要的业务规则、重大的算法。这些都是需要在一开始就十分明确的资料，需要在建模会议上了解清楚。当然，你不能对你的项目涉众说，"这个，接下来，大家谈一谈主要的业务逻辑吧。"下面的涉众一定摸不着头脑。你还是应该引导涉众，从涉众的话语中捕捉你需要的信息。
注意会议，人不是机器，是会累的。所以控制好会议的长度很关键。一般，这种会议会有四五个小时，根据统计，两个小时内的会议不会让人产生疲劳感。所以应该把会议分成几小段。另外，你还可以根据会议的进展来决定每小段会议参与的人数。因为，会议越往后，一些与会者就不太重要了。
避免细节：建模会议主要的目标是建立高阶需求。如果把过多的时间花在讨论鸡毛蒜皮的小事，那就会浪费大家的时间。而在此时调查需求细节是没有很大的意义的。因为你对很多的事情都还不了解，需要进一步的深入。这时候的细节对你并没有太多的帮助。
回避技术：我在一次建模会议的时候，遇到一位负责技术的涉众，他总是不停的询问系统的技术架构，推销他的设计理念。使得我不得不好几次重申，"技术问题我们会单独找时间谈。"我想，那位技术人员应该是有比较好的理念，也很希望能够表现一把，这点无可厚非。但是这个时候还不是讨论技术的时候，需求尚未明确，讨论技术实现不是本末倒置么？
做好记录：俗话说，好记性不如烂笔头。所以在会议上做好记录是非常关键的。因为这种会议的代价相当高昂，你的项目涉众不可能每天不干活，陪你开会的，就算他们肯，他们的老板也不肯。所以要充分利用好会议的成果，所以一个优秀的速记员绝对是必要的。另外，根据研究显示，如果使用录音机的话，会使得与会者心存芥蒂而不愿开口，所以，不要使用录音机。
6. 测试在需求的初始阶段提到测试可能会觉得有些奇怪。凡是项目，总会有一个标准来考核是否成功。这里的测试指的是考核软件项目是否成功的一个"执行性目标".这个目标将会是软件开发最终要满足的条件，软件成功与否的判定标准。很多企业在信息化建设的时候没有一个比较明确的目标。所以在被问道这方面的问题时，他的答案往往是我的目标是建成企业的ERP系统，建设企业的信息化平台等空洞的话。这样的软件怎么开发？连结束的标准都没有。是费用用完结束呢，还是决策者说停就停了呢。目标应该有一个可以量化的标准。例如，开发物流系统的目的是为了缩短产品周转周期，降低库存；开发供应链系统是为了加强和供应商的联系，降低库存。这些和具体业务有关的指标都是可以通过细化，用多种分指标来度量的，所以是可以做到的。
我们把这种目标称为测试就是要提醒开发人员，要把满足这种目标当作最终的测试。你的软件做得再好，不是涉众想要的，又有什么用？这是很浅显的道理，可是在实际中，涉众方和开发方往往因为一些具体的因素看不到这一点。其实，这个目标在上一篇中我们也讲过，那时我们是把它叫做愿景、范围。在本质上是一样的。
这种"可执行性目标"可以使用一些因素来衡量：7. 业务实体业务实体（business entity）是企业中的一些起到关键作用的类别。客户、供应商、员工、订单、凭证，这种业务实体的例子可以举出很多很多。业务实体往往会成为一个很关键的因素，因为在系统中，角色操作业务实体的行为往往会分配给业务实体，例如"根据订单计算价格"会成为订单的一个行为。这样，工作流程的实现往往是多个业务实体相互合作完成的。所以业务实体设计的好坏会对系统有很大的影响作用。
