前言

知乎我讀到過這麼一段話，我覺得寫得很好： 一個單純的想法，不是完整的需求。不同的App開發模式（模板化與定製化）、不同的App開發功能需求（簡單與複雜程度）等等都會讓一個App的報價得到從幾萬到幾十萬甚至百萬元不等的區間。多說一句，在需求不明確、且需要實現想法的應用功能轉化時，盲目的做App是一個試錯成本很高的行為。

在我看來，這段話可以拿我修改一下：

一個單純的想法，那甚至談不上資訊，更妄論業務。多說一句，在資訊不明確、且需要整理業務的應用場景轉化時，盲目的期望通過想法來開始做網站是一個試錯成本很高的行為，因為做產品是使用者在用，是使用者教會產品怎麼做，不是產品去教使用者怎麼做。

所以，要儘可能地收集使用者資訊。

瞭解使用者

在某種程度上來說，使用者其實對自己所進行的業務也是不瞭解的，有些被使用者自身忽視的微小業務其實是不可或缺乃至關鍵的。但從模型檢查來講，如果我們能夠得到業務相關的所有使用者角色，可以很方便的檢查模型，進行校驗修改。

我手上在做的一個網站應用，是關於醫院的一個免疫接種管理網站平臺。詳細的不便展開。但其中有一個被忽視的業務場景著實讓我費了一些功夫，在即將上線的時候，緊急調整了頁面功能。

免疫接種管理網站，就是為了結束紙質化、單一化的原免疫接種流程。在和相關方面接觸的時候很明確的說明，網站開發的目的，就是讓醫務人員能將免疫接種的相關資料管理起來，不再依靠紙質文件來進行流程。

整理完業務後，我建立好了模型，醫生、護士、還有相關管理人員都認可了這個業務模型，網站開發完畢後，正式上線就可以順利結束紙質化。

正式上線的前五天，原來的相關表單參考完畢，已經基本沒用了。我想到，之前患者手持紙質文件，但是紙質文件不可能每個患者都儲存得很好，如果存在文件丟失的情況，又得去找醫生列印。想到這裡，我和我對接的人員隨口聊到這一點，結果他說：沒有的，補打都是在導診臺列印的。再一問，原來還有一些紙質文件要上交疾控中心的。之前忘了這茬了。因為根本沒有考慮到導診臺。

我想，糟了。紙質化告吹了，而且又和文書管理平臺沒有做介面。。。

細問下去，導診臺也十分關鍵，而且從新產品的角度來講，補打勢必要有之前的相關資料的，不可能再是一張空白文件裡。後面就是正常的加班，還是順利進行了產品修改。

總結

業務模型肯定是圍繞使用者、流程而建立起來的。在業務建模的過程當中，我們甚至應當嘗試跳過對接人員，嘗試更多的瞭解可能的產品使用者，收集更多的使用者資訊。這樣才能有效的建立業務模型。