前言
知乎我读到过这么一段话，我觉得写得很好：
一个单纯的想法，不是完整的需求。不同的App开发模式（模板化与定制化）、不同的App开发功能需求（简单与复杂程度）等等都会让一个App的报价得到从几万到几十万甚至百万元不等的区间。多说一句，在需求不明确、且需要实现想法的应用功能转化时，盲目的做App是一个试错成本很高的行为。
在我看来，这段话可以拿我修改一下：
一个单纯的想法，那甚至谈不上信息，更妄论业务。多说一句，在信息不明确、且需要整理业务的应用场景转化时，盲目的期望通过想法来开始做网站是一个试错成本很高的行为，因为做产品是用户在用，是用户教会产品怎么做，不是产品去教用户怎么做。
所以，要尽可能地收集用户信息。
了解用户
在某种程度上来说，用户其实对自己所进行的业务也是不了解的，有些被用户自身忽视的微小业务其实是不可或缺乃至关键的。但从模型检查来讲，如果我们能够得到业务相关的所有用户角色，可以很方便的检查模型，进行校验修改。
我手上在做的一个网站应用，是关于医院的一个免疫接种管理网站平台。详细的不便展开。但其中有一个被忽视的业务场景着实让我费了一些功夫，在即将上线的时候，紧急调整了页面功能。
免疫接种管理网站，就是为了结束纸质化、单一化的原免疫接种流程。在和相关方面接触的时候很明确的说明，网站开发的目的，就是让医务人员能将免疫接种的相关数据管理起来，不再依靠纸质文档来进行流程。
整理完业务后，我建立好了模型，医生、护士、还有相关管理人员都认可了这个业务模型，网站开发完毕后，正式上线就可以顺利结束纸质化。
正式上线的前五天，原来的相关表单参考完毕，已经基本没用了。我想到，之前患者手持纸质文档，但是纸质文档不可能每个患者都保存得很好，如果存在文档丢失的情况，又得去找医生打印。想到这里，我和我对接的人员随口聊到这一点，结果他说：没有的，补打都是在导诊台打印的。再一问，原来还有一些纸质文档要上交疾控中心的。之前忘了这茬了。因为根本没有考虑到导诊台。
我想，糟了。纸质化告吹了，而且又和文书管理平台没有做接口。。。
细问下去，导诊台也十分关键，而且从新产品的角度来讲，补打势必要有之前的相关数据的，不可能再是一张空白文档里。后面就是正常的加班，还是顺利进行了产品修改。
总结
业务模型肯定是围绕用户、流程而建立起来的。在业务建模的过程当中，我们甚至应当尝试跳过对接人员，尝试更多的了解可能的产品用户，收集更多的用户信息。这样才能有效的建立业务模型。