今天正式結束了最後一個軟件外包項目，也就意味著傳統的軟件外包模式在我們公司劃上了不圓滿的句號，以鉅虧的結局宣告現有的軟件外包模式已經走入了死衚衕，新的軟件服務模式即將打破傳統，進入新的發展模式階段。在討論新的模式之前，很有必要剖析這個鉅虧10多萬的軟件項目。
一、大坑從只有1頁的需求開始
做過軟件外包項目的大體都有這樣的體驗，客戶提出一個很簡單的需求，然後讓你報個價。而這個時候大部分軟件外包公司都會報一個相對高一點的價格，防止後期需求有變化而能維持利潤。這個項目同樣如此，需求就是一個簡單的說明，是要做一個電商的商城，只不過是多了經銷商的功能，而且附了經銷商的分成方式。咋一看需求不復雜，加上我們有現成的商城模版，即使做成APP+H5的模式，我們如果報20萬，應該是有得賺的。而恰恰是這種需求模糊的預估報價模式，為整個項目的失敗埋下了巨大的禍根，而這也是傳統外包模式的最大弊病之一，對於開發公司及甲方客戶都是及不公平的事情，這樣的方式會縱容甲方能省事就省事，所有的鍋由乙方開發公司來背。
二、4個月的需求確定，讓項目一步一步邁入深淵
9月份籤的合同，我們就派產品經理跟蹤服務客戶的需求原型確認。一般的需求原型有一個禮拜都差不多完成了，但是這個項目需求整整做了4個月，甲方以各種理由推翻我們做的需求原型，不斷往裡加東西，美其名曰細化需求，直到12月底才算終於確定一版。而這個時候出來的需求原型，跟原來已經豐富了相當多的內容。但是，由於前面已經簽了合同，跟甲方客戶討論增加費用的時候，已經沒有可能了。這個時候有兩個選擇，我們可以中止合同，或者要求增加工期和費用。善良的我們沒有去麻煩客戶，結果引來了後面巨大的麻煩。傳統的外包模式弊病之二，籤合同之前需求儘量模糊，籤合同之後需求儘可能的細化和增加，然後以合同要挾，不讓增加費用。
三、極低的預付，然後分階段付款模式，虧損從此開始
這個合同本來想用新開發合作模式來籤的，結果甲方不同意，因此採用了折中的合同模式，介於傳統及新模式之間的方案。按傳統的外包模式，低於60%的預付，我們都不能接的，但是採取的是折中模式，所以正式開發之前，我們只收了35%的錢，也就是7萬元。4個月的需求分析及UI設計，剛好也就花了這麼多成本。意味著開發之後的錢，我們得墊，這個是非常危險的，從開發正式開始的時候我們已經在虧錢了。正常的商業邏輯是，這個時候我們應該再次叫暫停，但是我們還想僥倖。
傳統外包模式弊病之三預付60%乙方肯定不會虧本和吃虧，較低的預付乙方100%是虧本和吃虧的，因為甲方會有各種理由延期支付剩下的款項。四、開發過程中去掉一些功能，補充一些需求，以及極其刁難的階段付款要求，項目陷入泥潭
2020年2月份，正式開發開始了，我們自己投入了4個人，加上外部投入了4個人的力量，我們想盡快拿到開發款，但是我們又陷入了甲方的圈套。首先，在開發中，去掉了一些已經確定的需求，我們知道程序的邏輯是相通的，去掉一些功能必然會影響一大片，而不像甲方所說的不就是刪除嘛，多簡單。在基本功能做得差不多，同時進入基本功能測試時，甲方要求主流程跑通，才能付錢，但他們測試的時候可是玩命的在測試，測得那叫一個細。這個時候，我覺察到了不對勁，主流程跑通，不就是大部分功能都做完了嘛，也就是甲方變著法要把所有做完了才能給錢，而不是分階段給錢啊。坑，一個大大的坑，我居然跳進去了，一個老江湖居然上了這麼大的當。交涉中，甲方的一個說法“我只要結果，至於你們付出的勞動和成本，我們不關注”，我聽到這個之後，我知道，這個項目我栽了，我要再做下去，我將萬劫不復，至少還得賠2個月的人工，而且最後還不一定拿到錢，對方有各種理由和藉口，讓你不斷付出成本，陪他優化，陪他細化，就像需求細化4個月之久一樣。到3月22號的時候，我們的開發成本已經超過10萬了，也就是說這10多萬的成本，我們已經虧掉了。但是如果我繼續陪他玩下午，我將虧至少20多萬，所以當斷則斷，我們堅決停止了開發，止血。
傳統外包模式弊病之四甲方想要項目儘可能的完美，但不會增加費用，還會不斷拖延付款；乙方則想盡快交付，不允許有任何新的需求和改動，這種矛盾的產物必然是雙方不滿意，產品質量不好。至此，我的最後一個軟件外包項目就這樣虧了10多萬。
其實，在做這個項目的時候，我們的新軟件開發模式已經成型了，但是慣性和客戶的要求，讓我沒有堅持新的開發模式。從這方面看，這個項目的失敗讓我堅信了新的開發模式將在未來發揚光大，下面我一條一條的講解新模式如何克服以上的弊病，讓甲乙雙方得到雙贏：
1、需求評估，只有預估價
針對目前大部分甲方客戶，初始需求都很模糊的狀況，我們的新開發模式下，只會出一個預估價，這個預估價不是最終付款價，只是給客戶有個大概的成本預估，最終價格有可能更低，也可能更高，完全跟甲方後面需求原型確定後的功能多少有關。
2、需求製作，按時付費
為了避免客戶故意拖延需求以及需求無限擴大的問題，所有產品經理的需求製作成本，我們有一套公平公正的計費模式，可以實時統計產品經理的工作時間，客戶根據產品經理的工資和工作時間付費就可以了，工作量少就少付錢；如果非要做4個月需求，付4個月的工時費就可以，我們也不會虧本。
3、詳細設計，精確算出最後的成本和開發時間
需求原型確定後，這個時候算是真正計算價格和工期的時候，我們會有一套詳細設計工具，把需求拆分到小時級別的任務，根據人員的成本和工時費用，再預留一些測試和聯調週期，能精確的計算出實際的成本和確定的完成日期。甲方只要根據這個價格和工時付錢就可以。
4、按周驗收，按周付費
這個模式前期要收20%的押金作為預付，但是開發開始後，甲方需要每週都來驗收開發好的功能，並且驗收合格後才進入下一個任務和模塊的開發。並且每週驗收完成之後，都需要支付本週的錢，否則將停止開發。這樣，甲方的充分參與，將大大提高項目的質量和成功率。而乙方由於按周付費，即使虧了，也就是損失一週的錢，能把損失降低到最低。
5、按時計費，工期約束；
區別於傳統的60%預付開發費模式；也不限制甲方需求的變動和更改。反正所有的費用按實際發生的時間和人工來計算，好比自己的開發人員一樣，甚至比自己的開發人員還好管理，比如不用交社保，不用佔場地，業績直接跟工作時長掛鉤，不用領導吩咐就能主動熱情的幹好工作。所以甲方可以隨便加功能，減功能；也可以把項目做成極其的細緻，質量要求極其高，反正增加人手和時間就行了，按照實際發生的有效工作時間付費。這樣才能真正做一個有質量的好產品，這樣才不會爆發甲乙雙方的立場衝突。
一個存在20多年的外包舊模式，從一開始的暴利，到目前的人人喊打，項目完了雙方都恨得牙癢癢，說明這個模式走到了盡頭。新的軟件開發模式必將顛覆現有模式，給軟件開發公司及客戶一個公平公正的商業環境。
原創不易，希望我的分享能幫到大家，有說得不對的，儘可能拍磚，有認同的多點贊和轉發。
閱讀更多 軟件開發不求人 的文章
