第一階段

　　程序級外包，這個階段原格意義上來說還不能算是一種真正意義上的軟件外包，更準確地應該叫程序外包，因為那個時代的程序非常簡單，之所以外包主要是因為技術壁壘而尋找一些專業的人士處理一個程序算法之類的問題。

　　第三階段

　　從比較大規模的電腦軟件出現之后到現在都屬于這個階段，這個階段的軟件已經比較復雜，開發一套軟件是個系統的工程，不再是一兩個牛人能干得了的事，這個階段也誕生了很多的軟件工程和軟件項目管理方法論，同時也誕生了大量上規模的軟件開發外包開發企業，如東軟集團(600718,股吧)、新思軟件、柯萊特、萬洲軟件。

　　這個階段項目規模較大，參與的人員較多，一般來說少則幾人，多則幾十幾百人，對項目的管理控制要求比1.0時代高很多，這時候見得最多的是定制化的企業內部應用系統，各種定制化的ERP、CRM、OA、費用系統、訂單流轉系統等等。這類系統有個特點，那就是委托方一般非常了解自己想要什么，通常能夠提供非常詳細的需求文檔，大多數都會整理一堆的流程、表單之類的，配合一些文字說明。施工過程絕大多數采用瀑布模式即可，即需求確定之后進入封裝施工，直到開發完畢才將結果提交給委托方。前期溝通到位通常大差不差，如果溝通得不是很理想也可以適當修改，委托方也有足夠的耐心來等，畢竟沒有系統的時候世界照轉。

　　第三階段

　　隨著國家對大眾創業和傳統企業互聯網+轉型號召，一大批與互聯網相對較遠的人群踏入到這范疇，因缺乏技術積累，許多互聯網創業者或傳統企業老板在運作互聯網項目時經常卡在技術問題上，互聯網創業項目也好，傳統企業互聯網+轉型項目也好，一般對時間要求都很高，在沒有能力搭建并管理一個技術團隊時，選擇開發外包還是一種明智的選擇。

　　這個階段的項目大部分都有以下兩個特點：

　　a)時間緊

　　不像企業內部管理系統，早一天晚一天都不是什么問題，無非就是麻煩一點罷了。創業項目或互聯網+項目一般都會有最佳窗口期，錯過了這個窗口期基本上就是白干，所以容不得開發過程中有半點閃失。

　　b)自己也不知道想干什么

　　這句話稍有點夸張，嚴格來說，創業者或傳統企業老板中，大部份知道自己想要干什么，但是不知道該怎么干，也就是對于自己的想法，不知道怎么通過一個互聯網產品來落地，當然這其中還有一部分人真是不清楚自己到底要干什么。

　　c)項目沒有終結點

　　對于傳統管理系統項目最怕的就是沒有終結點，而對于創業項目或互聯網+項目最好是沒有終結點，有有終結點就意味著項目折騰不下去了。

　　云中計算有限公司根據這個階段業務的特點，在行業內于2015年首次提出極限交付”概念，經過一年多的實踐證明，使用極限交付”業務模式后，平均項目延時減少了近40%，成本下降了30%，客戶滿意度提升了62%。

　　極限交付”從概念上理解是極限迭代”加持續交付”，業務模式具體而言由以下幾點組成：

　　1、商務洽談階段

　　拋棄傳統軟件外包中業務人員不懂技術，大包大攬的陋習，在商務洽談階段除了最初的信息收集環節，其它工作均由最資深的技術專家級人員主導，這樣保證了快速確定業務的可行性，防止從根上就長歪了。

　　2、原型溝通階段

　　如果初步溝通可以達成共識，則進入到溝通需求，需求階段不以冗長的文檔為交付物，改由設計原型，只有原型是雙方最容易理解也最接近實際交付產品，此階段過后才會正式出具報價，這樣防止了先猜一個沒有任何依據的價格，然后雙方在框定的價格區間內打功能保衛戰。

　　3、密集施工階段

　　這是極限交付”與以往軟件外包差別最大的一點，雖然軟件工程方法論中早已提出螺旋開發模式和迭代開發模式，但由于交付繁瑣，所以一般采用瀑布模式居多，絕大多數委托方看到系統已經是在快完工的時候。

　　在云中計算公司內部，極限交付”系統要求合同簽訂后一周上線第一個版本，該版本雖然還只是雛形，但是可以完成用戶登錄、注冊等常見功能，并且具有主界面，在隨后推進過程中不停迭代交付，迭代周期非常短，一般能短到1天。就這樣，委托方就像站在一個巨大的玻璃房外面看著自己的房子一層一層往上蓋一樣，當發現有偏差時可以及時糾正，最大限度防止往上蓋多了需要返工帶來巨大的人力成本浪費。

　　3、迭代升級階段

　　運作好的項目最后都會組建自己的開發團隊，但這個過程不是一天兩天能完成的，在委托方未組建起開發團隊前，為了適應項目運營推廣步伐，需要對產品進行不斷升級。

　　在云中計算所倡導的極限交付”模式中，第一個版本交付后轉入到迭代升級階段，在這個階段需求并不是由委托方一次大量提出，而是以一個較短的周期(通常為兩周)確定下一周期需要做什么，確定之后又進入短時間的密集施工，直至一個周期結束。