一.引言
為了使得閱讀過程生趣形象，先來分享兩個故事。
- 第一個是我親身經歷的事情：2013年一次偶然的機會，在工作中接觸到復旦大學的一個朋友，有天他帶我去復旦大學軟體學院的一個實驗室裡，這是一個5個人的研發團隊，他們正在做CRM系統(客戶管理+電話坐席系統)。我之前在軟體公司工作過，給客戶做過CRM產品，在我印象中專案的整套流程是：
1.客戶提出需求
2.產品經理對接，繪製產品原型
3.產品原型交給專案經理
4.專案經理開會討論需求，分配開發任務，制定開發計劃
5.開發完交付給測試人員
6.測試完交付給客戶
……
整套系統從0到交付給客戶，大概需要2個多月時間，如果後期有類似客戶也做一套CRM系統，那麼複製之前的那套系統，根據需求來修修改改，大概一個月時間完成。那個復旦大學實驗室的團隊leader告訴我們：“我們幫客戶做一套CRM系統，只需要一杯咖啡的時間，差不多20分鐘吧”。我被當時的場景所震驚，可能會記住一輩子吧。
- 另一個故事是在計算機刊文中看到的：在芬蘭有一家遊戲公司叫supercell，是世界頂級遊戲公司巨頭，開發過全球熱門遊戲，比如《部落衝突》《海島奇兵》《皇室戰爭》《荒野亂鬥》等等，但是公司規模不大，只有一百多人(對比國內的遊戲公司，動輒上千人的規模，有點慚愧)，他們自己開發遊戲，自己運營，同時也為全球很多公司開發遊戲，類似於遊戲外包。騰訊在收購supercell之前，啟動一個專案一般要組建百八十人的開發團隊，並且996工作節奏，大概需求N..天的週期。但是芬蘭supercell公司開發一款新遊戲，需要大概十個人規模的團隊，並且在非常快的時間內交付產品，後來騰訊眼饞了，收購了supercell。當時看到這裡同樣是震驚，怎麼有似曾相識的感覺…
二.客戶畫像
揣摩別人的心思是大忌，玩得好能得勢，玩不好要栽跟頭。和珅善於揣摩乾隆的心思，得勢一生。反例：李善長喜歡揣摩朱元璋的心思，愛耍小聰明，結果被誅九族…但是現在是民主文明社會，對於我們做產品的人就應該要善於揣摩客戶的心思，有時候恨不得想成為客戶肚裡的蛔蟲。
- 客戶有兩方面需求：一個是業務需求，一個是服務需求。簡單描述為：客戶在業務上需要使用系統平臺，能滿足他各方面的功能需求，介面通俗易懂，操作便捷，能夠7×24小時隨時待命，任何時候都不卡頓，資料只對他喜歡的人可見，不喜歡的人一律不可見，資料永遠不會丟失。凡是現實生活中享受不到的服務，他都想享受到，活在夢幻中是每個客戶的夢想。
- 客戶有兩個使用產品的方式，一種是定製化軟體，獨立部署在客戶的伺服器上；另一種是雲軟體，客戶開啟瀏覽器或者下載APP或者直接在微信中使用第三方軟體。分析下兩種方式的利和弊，客戶需要的是能滿足他業務使用，但是不想自己公司內增加一個軟體維護人員，希望委託軟體服務商來幫他維護軟體，如果是獨立部署模式，假如軟體出現故障或者需求要改動，他們聯絡軟體服務商儘快解決，軟體服務商回覆他：更新好了會通知您的。然後客戶就會陷入漫長的等待過程，所有涉及到軟體方面的業務全部暫停。如果軟體服務商給很多客戶部署了類似的產品，那麼一旦軟體中出現一個突發性的故障，軟體服務商只能挨個給客戶修復，改完這個客戶再到下個客戶。優先順序怎麼排呢？當然是大客戶優先，小客戶慢慢等著吧，那些小客戶就悲催了。如果是雲軟體模式，軟體中突然出現一個故障，這個故障會對所有使用該功能的使用者可見，即使客戶自己不向軟體服務商反饋，其他客戶也會向軟體服務商反饋的，軟體服務商會立馬修復，並且只需要修改一處，所有客戶都會更新，不用挨個客戶去修復。好比如：我如果想用辦公軟體，我寧願用釘釘，我也不願意用軟體公司給我定製的一套辦公軟體，即使釘釘每個月讓我付錢，我也願意…
- 至於軟體升級考慮，一般軟體一個版本的壽命平均不超過兩年，如果是獨立部署軟體，版本升級的工作對每個客戶都是重複性的工作，對軟體服務商會損失耗能，而云軟體只需要做一次工作即可。
- 至於資料隔離和安全考慮，不論是獨立部署軟體還是雲軟體，維護工作都是由軟體服務商來做的，資料沒辦法對軟體服務商隱蔽，軟體服務商還是能獲得到客戶的資料，只能通過簽訂保密協議等方式來規避。
- 綜上所述，從各個方面分析得出，雲軟體模式對客戶和軟體服務商雙方都是利大於弊。
三.常規軟體建設原理
一般性軟體建設的流程是(複製上面的)：
1.客戶提出需求 -> 2.產品經理對接+繪製產品原型 -> 3.產品原型交給專案經理 -> 4.專案經理開會討論需求+分配開發任務+制定開發計劃 -> 5.開發完交付給測試人員 -> 6.測試完交付給客戶 -> ...如果是類似的軟體，把之前開發的軟體複製一份，在此基礎上來動手術，改造成符合客戶需求的軟體，但是還是存在問題：如果新的軟體較老的軟體，流程上有大的變動，那麼新軟體開發是個大型外科手術，可能要修改核心功能和架構，要知道改造規模過大還不如重建的好，工程量就會增加了。
用通俗接地氣的文字，簡單介紹傳統軟體建設過程：
1.終端
最終呈現給客戶的是一個個操作介面（瀏覽器頁面，APP頁面等），每個頁面裡有各種資料欄位，欄位包含列表欄位，詳情欄位，表單錄入欄位（必填欄位或非必填欄位）；頁面中包含按鈕，提供使用者操作；頁面中包含彈框，我們可以稱之為子頁面；頁面中有對話方塊，用來和使用者進行資訊交流。總結為：最終給到客戶的是頁面和子頁面，欄位，按鈕，對話方塊和互動。
2.頁面和子頁面
在軟體中，通俗來說：一個頁面對應一個軟體模組。不過也包括，多個相關聯的頁面對應的是同一個模組，比如訂單列表頁面，訂單編輯和訂單詳情頁面對應的是同一個模組：訂單模組。在專案工程中這些頁面對應是具體的程式檔案，程式檔案控制著頁面的顯示。所以當客戶提出需求，需要開發某個頁面的時候，開發工程師要做的工作是：1.編碼出相對應的程式檔案；2.根據模組設計對應的資料表，比如訂單模組對應訂單表，但是此時資料表是空白的，沒有欄位，因為要經過下一步才能在表中增加欄位（普及一下：資料庫是一個儲存資料的機器，資料庫包含很多資料表，比如訂單表，車輛表，每張表裡有很多欄位）。你可以想象成當前只是定義好了tab名稱的空白Excel表格
3.欄位
需求模組對應頁面，那麼資訊資料對應的是欄位。欄位包含獨立欄位，關聯欄位。獨立欄位如姓名，身份證等，一個欄位表示一個具體的資料資訊；關聯欄位如銀行名和銀行編碼，銀行名和銀行編碼是一一對應關係，再例如：安徽省和合肥市，蕪湖市屬於關聯欄位，它們之間存在某種關係。另一類關聯欄位如：產品型別和產品規格，比如褲子和尺寸+腰圍，貨車和載重+噸位，它們之間本身並沒有直接的關聯，而是在具體的業務場景裡，人們主觀上把它們牽連到一起，最終形成了一種慣性思維，他們具有行業特有屬性，以至於提到貨車，自然會想到載重+噸位，但是載重+噸位也適用於其他的領域；開發工程師得到客戶給出的欄位之後，他們的工作是：1.把這些欄位定義為程式檔案裡的屬性，變數；2.在相應的資料表裡增加欄位。當前可以想象成定義好格式的Excel檔案，只是沒有資料而已…
4.按鈕
頁面和欄位是使用者獲取資訊的基本單元，使用者與軟體之間互動需要通過按鈕來傳達。按鈕包含：開啟，關閉，編輯，檢視，跳轉，事件操作(確認付款，稽核通過，稽核駁回等等)。資料資訊通過頁面來展示給使用者，但是頁面是靜態的，使用者需要動態的與資料資訊互動，通過按鈕可以實現建立資料，瀏覽資料，修改資料。開發工程師為每一個按鈕所對應的事件編碼相應的程式檔案，程式檔案裡包含很多功能函式，一個按鈕對應一個特定的功能函式，比如儲存按鈕對應一個功能函式，檢視按鈕對應一個功能函式…如果按鈕事件要修改資料，那麼功能函式裡所要做的工作是：1.從資料庫或者檔案裡獲取源資料；2.對資料加工處理得到新資料；3.新資料寫回源資料的位置；如果按鈕事件是需要與外部通訊，比如把資料傳送到省平臺，那麼功能函式裡所要做的工作是：1.從資料庫或者檔案裡獲取源資料；2.按照省平臺的要求，把資料組裝成對方要求的格式；3.把格式化後的資料通過網路傳送到省平臺的主機；4.省平臺回應接收成功，該事務完結。
5.彈框
彈框是頁面的補充，也可以理解為一個子頁面，彈框裡可以包含頁面+欄位+按鈕，在軟體裡，把彈框也當做頁面來處理，開發工程師所做的工作和上面的內容一樣。
6.跳轉
以上介紹了一個完整頁面所包含的內容，也介紹了開發工程師開發一個頁面所做的工作。一個軟體或者系統，通常由很多個頁面組成，頁面之間的關聯來自於現實業務間的關聯，業務的關聯性通過跳轉來呈現。開發人員視作一個頁面為一個開發單元，這也是軟體工程所提倡的，比如一個軟體工程由多人蔘與，把一個頁面作為一個開發任務，然後任務分配到每個人身上，這也是團隊協作開發的基礎模式。那麼開發完單獨頁面之後，頁面之間的關聯性在程式檔案中通過“傳參”的方式來達到契合。舉個例子：電商平臺裡，從購物車頁面進入到付款頁面，購物車頁面對應一個程式檔案，付款頁面對應一個程式檔案，付款頁面的程式檔案怎麼才能辨別出是某某使用者選擇了某些商品呢？其實就是：購物車程式檔案通過“資料傳參”的方式傳達到付款程式檔案，“資料傳參”攜帶有具體的使用者和具體的商品，這樣在付款頁面就可以對具體使用者和具體商品來處理，比如為孟康這個使用者建立付款單資料，修改商品的庫存等等……
7.資料倉儲
軟體的資料包含：業務資料，檔案資料，行為管理資料。
- 業務資料指每個業務場景對應的資料，這些資料通過不同的資料表來隔離（資料庫由多個資料表組成），比如運單相關資料組成一個資料表叫運單表，車輛相關資料組成一個資料表叫車輛表，資料表具有固定的格式，資料是按照矩陣方式來組成的，類似於上面的Excel表格，每一行代表一條資料，其中的某一列表示這條資料的屬性（屬性可以理解為欄位），比如使用者建立了一條運單資料，這條資料佔據一行，運單裡有裝貨地欄位，裝貨地就是這條資料的一個屬性。而資料可以包含很多屬性欄位，開發工程師根據使用者的需求來設計資料表，使用者提出的業務需求中需要哪些欄位，開發工程師就建哪些欄位（加欄位可以理解為在Excel中加一列）。使用者建立資料就是在資料表中插入一行資料，每一行資料對應唯一的ID，檢視資料就是從資料表中通過ID查詢一條資料，修改資料就是在資料表裡通過ID修改整行資料或者只修改部分屬性欄位。
- 檔案資料指軟體中非文字類資料，包含圖片，合同檔案，表格檔案等。這些資料不儲存在資料庫中，它們儲存在磁碟中，由使用者上傳而產生，這種資料很容易理解，一個檔案佔據一塊磁碟空間，不多解釋了。
- 行為管理資料指非使用者需求資料，包含使用者行為資料，系統檢測資料，許可權劃分資料等。使用者行為資料是使用者在軟體中的操作行為日誌資料，用於追蹤使用者的行為軌跡，日後在業務操作中產生糾紛，可以作為憑證。系統檢測資料是指系統檢測使用者提交的資料，或者外部傳送過來的資料，也包含系統自身檢測所產生的資料。許可權劃分資料指不用人員授權操作的資料，不同的人員只能授權軟體的部分頁面或者操作。
8.鳥瞰
通過上面的描述，基本瞭解了一個軟體工程的原理。軟體工程起源於客戶的需求，是一個工程的發起點。客戶的需求傳導到產品設計人員，產品設計人員繪製出產品草圖，然後給到開發人員，開發人員按照業務來劃分模組，然後每個頁面對應著不同的程式檔案，為頁面中每個按鈕和事件編寫功能函式，不同模組對應著不同的資料表，頁面中的欄位對應資料表的某個屬性，業務流程通過頁面跳轉來銜接，對應不同程式檔案之間使用“傳參”來達成契合。好了，軟體工程就按照這樣的模式有條不紊的進行下去，直到開發結束->測試結束->交付客戶。
四.思考和挑戰
上一章節完整描述了傳統軟體建設的方案，從客戶需求出發，然後按部就班的開發，再到交付客戶，是一個完整的閉環。環環相扣，每個環節都不能脫鉤，形成一種強耦合效應。
- 提出問題：那麼試想如果客戶的需求有變動怎麼辦？源頭有變動，那麼從源頭到尾部所有環節跟著變動，這也是當前軟體行業超過95%以上的專案所存在的問題（我也看過Windows作業系統的程式碼，他們的都是定製化的程式碼風格）。我們設想：如果客戶的需求模糊，或者未來隨時變動，那麼我們怎麼用最小的成本和最高的效率來應對呢？比如：1.某個頁面調整了，頁面裡的欄位刪除一部分，新增一部分；2.按鈕也改動了一部分，導致邏輯有變動；3.業務模式和流程變了，本來一筆建立完訂單後直接進入售後環節，但是現在改成了需要在建立訂單之後增加稽核的流程。如果發生諸如此類的需求變動，那麼頁面跟著修改，功能函式跟著修改，資料表結構跟著改動，頁面的跳轉方式也跟著改動…
- 發起挑戰：如果是按照傳統軟體工程模式，我想復旦大學實驗室就無法實現一杯咖啡的時間為客戶做出一套CRM系統。那麼他們是怎麼做到的？這個問題我思考了很多年，因為我所工作過的所有公司，開發軟體的模式都是傳統軟體工程模式，而且類似於復旦大學這種模式的開發資料肯定是不會外洩的，網上也搜不到，只能自己研究。於是這些年的工作經驗加上自己的思考，總結出一套“區域性試錯法”：我把每個環節想象成動態的，而非固定的，比如頁面中的欄位隨時會變動，那麼程式檔案中就不能使用“硬編碼”。硬編碼描述：比如頁面中第一列顯示客戶名稱，第二列顯示客戶手機號，那麼程式檔案中是按照固定格式來顯示頁面的，虛擬碼如下：
這種就屬於“硬編碼”，頁面需要顯示什麼，程式檔案中就按照固定的格式來編碼，如果頁面修改了，那麼程式檔案緊跟著也需要修改。“硬編碼”顯然無法適應未來的隨機變動，所以使用另一種模式：“動態編碼”。頁面中的欄位是動態儲存的，而程式檔案編碼時從動態儲存中獲取。比如我們建一張資料表用來儲存頁面中需要顯示的欄位，然後程式檔案從資料表中獲取到頁面需要的欄位，然後編碼出一個動態顯示頁面的程式檔案，虛擬碼如下show web page: # 顯示頁面 table first line:"客戶名稱" # 第一行顯示客戶名稱 table second line:"客戶手機號" # 第二行顯示客戶手機號 ...
“硬編碼”模式下，客戶需求變動之後，開發工程師需要修改程式檔案，功能函式和資料表。而“動態編碼”模式下，所有的欄位都是儲存在資料表中，程式檔案是從資料表中查出所有欄位，程式檔案根據不同的欄位型別來做不同的處理，一旦客戶需求變了，只需要修改資料就可以，這個工作量是非常小的，並且不需要開發工程師的介入，一個系統運營人員在後臺修改一下即可。前者的工作量以工作日為單位，並且需要開發人員來修改軟體專案，後者的工作量是以分鐘為單位，並且不需要開發人員的介入。show web page: loop query page fields: { # 迴圈從資料表中獲取 table <n> line:"fields.n.field" # 顯示從第1~N行的欄位 }
前面提到“區域性試錯法”，但是說到現在好像跟這個也沒關係，只提到“動態編碼”，其實還有其他的，具體請看下一章節。
五.SaaS平臺建設方案
從軟體專案的穩定性和可靠性來說，傳統定製化開發模式的軟體肯定是最好的，因為每一個頁面，欄位，按鈕和跳轉都是一一對應著程式檔案和資料表，但是社會發展迅猛，行業在不斷地變革，產品的更新迭代非常頻繁，所以它無法適應快速變化的客戶需求，無法用最小成本來改造軟體專案等等。
SaaS平臺又稱“多租戶雲平臺”，只要瀏覽器或者下載了軟體，在有網路的地方隨時隨地就可以訪問。市面上有不少這樣的產品，比如辦公軟體釘釘也屬於SaaS平臺，但是釘釘這款產品不適用多變的客戶需求，他做出來的產品是什麼樣子，客戶只能按照他的產品來使用，所以它屬於單一產品模式的SaaS平臺。財務軟體金蝶，一直想走SaaS模式，但是他走的依然是獨立部署模式，它的產品有多種形態，但其實是多個產品類似的軟體專案，不能算SaaS平臺。任何公司，任何軟體專案想轉型成“動態產品形態的SaaS平臺”都不是一件簡單的事，如果是重建專案還好，不用考慮老專案架構和老使用者使用的問題，不過從0開始建設不是一件容易的事；如果是有了一些年限的軟體專案想轉型的話，難度就更大了。
難歸難，但也並不是不可能，我的戰略是“區域性試錯法”，戰術包括“動態編碼”，“功能清單”，“選擇性跳轉”。簡單描述：我們按照傳統軟體模式來建設雛形版本，雛形版本可以根據自己公司業務需求而開發出的軟體。然後結合同行業的業務模式，分析出軟體裡每個模組中需求會隨機變動的部分，比如頁面的欄位會變動，頁面中會有不同的按鈕，業務流程和頁面跳轉會變動，或者只有某個公司特有的需求功能等等。根據這些隨機變動的業務需求，把我們把整個軟體架構設計成“功能元件化”模式，每個元件在有限範圍內可隨機修改（因為SaaS具有行業屬性，不能把製造業的SaaS平臺突然轉型為電銷類SaaS平臺），並且整個軟體是由各個元件組裝而成，而非整機模式。如果我們貿然把軟體專案裡的每個會變動的地方都改造成“隨機動態”模式，每一個改造都構成一個不確定風險點，整個軟體裡所有改造同時進行的話，不確定性風險會疊加形成巨大風險，最終會對整個軟體造成毀滅性的打擊。“區域性試錯法”是先區域性改造，等某個區域性改造得到充分考驗之後，再進入下一個區域性的改造。
通過模擬業務場景來闡述我的方案和思想：
1.首先架構改造，把整體架構模式改造成每個單獨元件服務架構模式。比如原先的架構是：先建一個叫“安捷智運”的專案，然後在專案裡建立“運單模組”，“車輛模組”，“財務模組”，各個模組使用“傳參”方式來銜接；但是新的架構模式是：建立“運單”微專案，建立“車輛”微專案，建立“財務”微專案等等。把以前的各個模組換成為了“微專案”，這樣有什麼好處呢？在同一個專案裡的各個模組之間關聯性很強，要求開發人員之間的配合度和契合度很強，但是換成微專案之後，每個微專案之間是相互獨立的，很方便擴充套件：比如貨執行業裡，各個貨運公司在運單方面的需求差異很大，那麼開發人員就集中火力投入到“運單”微專案裡，而其他的微專案根本不需要動。如果是傳統的模組化的架構，只要改一個模組，其他相關聯的模組都需要改動，而且不方便擴充套件。所以新的架構下的軟體，是由很多個微專案組成。
2.根據自己公司的業務需求開發SaaS平臺的雛形版本。俗話說：只有自己玩過，才知道坑有多深。這時候開發出來的版本是SaaS V1.0。
3.挖掘同行業的需求。有的公司用極少數的員工創造出巨大的產值，但是有的公司人員規模龐大卻產值很小。這種現象在網際網路公司裡太多了，貨執行業應該也存在這種情況，所以儘可能多的挖掘同行業的需求有助於提升產品的廣度和深度。這個環節非常重要，起到重要作用的人就是產品人員。產品人員能夠秒懂客戶的心思，並且能在客戶提出的基礎上給出具有建設性意義的思路，幫助客戶改善不良需求，引導客戶往更合理的方向發展，得到客戶的認可之後，能把肚裡所有的貨傳達給開發人員。傳統意義上的產品人員僅僅是把客戶的需求收集來，繪製出開發人員能看懂的產品圖，然後交付給開發人員。但是這遠遠達不到參與SaaS平臺建設的產品人員，產品人員不僅要能收集需求，還能發現客戶公司業務模式裡的問題，主動跟客戶溝通交流，引導客戶向更先進的業務模式去發展，使每個方案都具有創新性。建設SaaS平臺的初衷並不僅僅是給客戶提供服務，同時也是幫助客戶往更好的方向去發展。
4.得到同行業的需求之後，產品和開發一起分析客戶的需求和自己公司需求的差異。上面介紹過傳統軟體模式，需求方面的差異具體到軟體工程裡其實就是：頁面差異，欄位差異，按鈕差異，跳轉差異等。從這些差異中提煉出哪些方面是隨機動態的，並且根據輕重緩急來標註優先順序。
5.先從最簡單的開始：欄位差異。我們自己公司簡稱“安捷”，我們設想存在這樣一個客戶，這個客戶的業務需求覆蓋了同行業絕大部分公司的需求，這個客戶叫：安傑運輸有限公司（後面簡稱安傑），第一階段，假如安傑公司的業務模式和安捷一樣，但是頁面中欄位和安捷有差異，安捷存在的一些欄位安傑不存在，安傑存在的一些欄位安捷不存在。想象一種極端的情況：所有頁面的欄位都有差異。這時候我們來改造我們的SaaS平臺，改造的結果是：既能滿足安捷的業務需求，也能滿足安傑的業務需求。我使用的戰術是：動態編碼。程式檔案不使用硬編碼模式，所有欄位都是隨機動態存取。安捷的欄位和安傑的欄位都是在後臺配置的，安捷有一套欄位表，安傑也有一套欄位表。經過改造之後，終於實現了相同頁面但是欄位存在差異。
6.接著改造頁面的其他部分：按鈕，彈框和邏輯。安傑說頁面中很多操作無法滿足他們公司的需求，要在安捷的基礎上增加和修改一些按鈕或者彈框，比如運單頁面不僅要錄單功能，需要增加匯入運單的按鈕來實現匯入功能；在車輛管理頁面，不想用人工錄入功能，使用“一鍵”AI自動識別行駛證的功能等。這時候我使用的戰術是：功能清單。我們為每一個功能開發出一個對應的功能函式，然後提供功能清單讓客戶來選擇。這就要求系統裡有個功能函式庫，隨著接觸的客戶越來越多，需求越來越多，功能函式庫越來越龐大，功能清單裡的選項也越來越豐富。這個環節的工作量非常大，因為要為每個頁面提供功能清單，但是業務需求有輕重緩急，我們根據業務需求把頁面按照優先順序分為各種級別，對業務影響越大的越優先來處理。這項工作是伴隨著SaaS平臺的整個生命週期，我們會不斷地擴充我們的功能函式庫。
7.接下來改造業務的流程：跳轉。跳轉可以說成業務跳轉，也可以是頁面跳轉。安傑對我們反饋：他們的業務流轉需要調整，原來安捷的業務流程是：1.錄入司機和車輛資訊 -> 2.建立訂單 -> 3.訂單配車 -> 4.生成運單 -> 5.財務對賬 -> 6.省略部分環節… -> 7.上報到省平臺；但是安傑需要改動兩處業務流程：1.直接從表格匯入訂單，匯入完之後增加稽核的功能；2.有部分已完成的線下運單，可以直接匯入上傳到省平臺。安傑提出的流程需求，是目前安捷裡沒有出現過的業務需求，所以需要改造頁面跳轉，使得軟體系統滿足安傑和安捷兩種業務流程，但是我們的目標是：改造之後要同時滿足安傑和安捷，並且為後面其他客戶提出的流程改造留出可擴充套件性空間。這裡我使用的戰術是：選擇性跳轉。我們把所有業務環節的點設定為“跳轉點”，然後把所有“跳轉點”連成一條業務線，從左向右的方向，這是一條“超級業務線”，包含每家公司的“跳轉點”，是所有公司“跳轉點”的並集，然後給每個客戶提供“選擇性跳轉”，根據客戶自己的業務流程從“超級業務線”中選擇部分“跳轉點”來組成自己的業務線，但是必須遵守：選擇“跳轉點”只能按照“超級業務線”從左往右，不能沿著相反方向，這是不合邏輯的。
8.未完待續：總有我們想不到的問題，總有我們沒有遇到過的需求場景。不斷地遇到問題和豐富多變的需求造就了一款得到市場認可的產品。所以我們要放寬心態，敢於迎接各種問題和需求，在後面的研發過程中會不斷創造出新的戰術，未來可期…
六.感慨
一個SaaS平臺的建設是一個不斷累積的過程，累積大量的需求，累積各種功能函式庫，累積各種解決問題的戰術。需要工匠精神才能開發出一套市場認可的產品。它沒有終點，客戶在變，市場在變，SaaS平臺也一直在變…
本作品採用《CC 協議》，轉載必須註明作者和本文連結