商務程序不是需求

沒有一個項目不是重視需求調查的。從第一天開始，開發人員就拿著一個筆記本，把使用者都拉到會議室，詢問他們的商務程序是什麼樣的。知道了商務程序，開發人員剩下的工作就明確了，一條一條的去實現他們，系統就OK了。但是，商務程序可以代替需求嗎？

實際上，在商務程序的背後，有一個更加根本的因素——商業需求。商業需求才是真正的需求，商務程序只是一種實現手段而已。

開發人員詢問使用者：“你們的商務程序是什麼樣的？”這個問題其實是很難回答的。商務程序的制定首先是要最大限度的滿足商業需求。並且，商務程序要受到各種條件的制約，IT系統也是這個條件之一。開發人員問使用者商務程序是什麼樣的，使用者也要問開發人員系統的設計是什麼樣的，能達到什麼樣的效能指標，在這個基礎上才能制定合理的商務程序。

比如一家移動通訊公司，在處理新使用者入網的時候採用了一個這樣的流程，按流程先後順序：

1：首先把SIM卡和號碼在交換網路上做對應關係的註冊；

2：市場部把SIM卡存入一定的金額，發給銷售商，收取銷售商的貨款；

3：銷售商把卡賣給使用者，使用者填寫入網合約，SIM裝入手機可以立即通話；

4：銷售商把入網合約交給市場部，市場部資料錄入人員將使用者的資料錄入系統；

5：計費系統按照使用者選擇的資費對話單進行計費；

6、市場部按照使用者的消費情況給銷售商計算傭金和返利。

這個流程的制定並不是業務部門可以單獨確定的，他和IT系統有著很深的聯絡。使用者買到SIM卡以後，需要立即可以通話，但是由於IT系統的條件有限，無法做到及時向交換網路註冊SIM卡，所以就必須先把SIM卡和號碼在交換網路上做好，再發放到銷售點去。由於採用了這樣的辦法，又產生了一個新的問題：買到SIM卡的使用者可以立刻打電話，但是在資料錄入人員錄入使用者的資料之前，他們在系統裡是沒有資料的，也沒有計費策略，這是一段資料空白期。怎樣控制空白期的時間長度，怎樣對這些通話進行計費，怎樣防止空白期的惡意欠費。。。又形成了一個個新的問題，於是又要發明一個個商務程序來處理這個問題。

IT系統和商務程序是緊密關聯的，他們互相制約，也互相促進。如果希望先把商務程序定下來，再回頭去開發IT系統，這個難度是很大的。開發IT系統，需要把目光看的更深入一點：IT系統和商務程序是為什麼服務的。

IT系統和商務程序都是為了更好的實現商業需求。商業需求是企業為使用者服務、與夥伴合作的過程中產生的需求，每個商業需求都是關係到實際的商業利益的。比如說剛才那個使用者入網的流程，如果按照商業需求來看，他是為了滿足下面幾點：

1、使用者買到SIM，可以立刻裝到手機裡面打電話；

2、使用者的通話可以按照他選擇的資費策略進行計費；

3、使用者交的錢計入他的賬戶，通話費用從這個賬戶中扣除；

4、使用者填寫的合約歸檔，作為日後辦理相關事宜的依據；

5、營業員收的錢計入他自己的賬本，待稽核人員下班後核查；

6、市場部根據使用者的消費情況付給代理商傭金。

這幾點就是“入網”這個商務程序需要滿足的商業需求。企業在實現這些商業需求的過程中，一定是遇到了一些麻煩，於是希望有一個IT系統來協助自己。IT系統的開發人員要和企業使用者坐在一起，先把這些商業需求搞清楚。在這個基礎上，一方面要設計支援系統，另一方面要根據支援系統的情況來制定新的流程。最終實現自動化的商務程序，更好的滿足商業需求。

從商業需求中提取重要的元素，分析這些元素的行為和相互之間的關係，我們就可以得到一個重要的東西：領域模型。

領域模型應該來源於企業的商務工作，而不應該是IT系統的商務程序。

設計領域模型，最基本的方法就是抓住一些明顯的元素進行分析。更進一步，需要抓住一些隱含的元素。業務領域中有經驗的人員，他們在分析問題時候，有時候會隨手畫出一個草圖，寫下一些數值，或者查詢某個表單，這都是重要的領域元素。瞭解這些東西，可以使複雜的領域問題變得容易理解，使領域模型更加符合企業的實際情況。

當這個模型漸漸清晰的時候，開發人員和使用者就可以一邊進行IT系統的設計，一邊設計出更加合理高效的商務程序。有了一個個實際的東西擺在面前，使用者也能很容易的回憶起商務工作中一些重要的細節。比如看到這個租機合約，開發人員會問：“這個合約有什麼用處？”使用者回答說：“我知道一個用處，使用者辦理資費變更的時候，需要檢查一下這個合約，有些資費形式是合約不允許的。”

於是開發人員就在資費變更的流程中記下這樣的代碼：

IF NOT 使用者->合約->允許(資費) THEN
  EXCEPTION("使用者的合約禁止該資費")
END IF

下一步的工作，就是繼續將這個商業需求的細節搞清楚。“合約如何判斷一個資費形式是否允許，是判斷這個資費的收益率，還是判斷他的品牌類型。。。”

不要被表面的商務程序所迷惑，透過表面，看到背後的商業需求，你會發現需求原來非常穩定，這麼多年來其實變化不多。也不需要急於知道所有的細節性的需求，只要瞭解比較重要的20％的需求，其實就可以開始進行系統的設計和編碼了。把眼光放在商業需求上，最終的商務程序才能最大限度的滿足需要，IT系統也能面臨少一點的“需求變更”。