公司從成立至今也做了不少專案了，有大的，有小的，有短期的，也有一直長期合作的。而碰到的客戶也是形形色色的，有拖欠尾款的，有做了一半不做的，也有合作很愉快的。所做的大部分專案都已經上線運營，受到了客戶的好評，但是也有一些需要反省和總結經驗教訓的。

專案一：傳統企業的行業產品，移動端應用和PC端管理系統

甲方：為此集團下新成立的網路技術公司，人員配置包括一個產品經理，三個設計，兩個開發

開發方式：異地遠端

這個專案是我們公司成立後接的第一個專案，屬於那種中長期按人按月付費的專案，因為是剛開始自己幹，首先要以生存為前提，同時抱著磨練團隊和積累經驗的心態接下了這個專案。

甲方公司是集團公司下屬的，因此資金不是問題，甲方的負責人也是集團公司下派的，可以說對網際網路是一竅不通，而配備的人員也都是剛畢業或者才工作沒多久的，產品需求還是個半成品，對於包括我們剛開始做外包這種在內的這樣一群小白來說，專案進展情況不說也知道，那就是極度艱難和緩慢。這就造成甲方讓我們的開發人員得時不時的飛過去參與產品需求的討論以及甲方技術團隊的管理，雖然是甲方出這個費用，但是實在是耗時耗力，可能也是傳統企業的思維造成的，討論必須得見人，遠端溝通他們不放心。

這個產品在開發的過程中慢慢的發現它的行業複雜性，不但開發難度在增加而且需求變更也越來越頻繁，有時竟然誇張到一版APP做好後，公司老闆的一句話，大部分頁面設計得推倒重來，也是仗著甲方專案資金充裕，敢這樣折騰。其中有一件事情著實讓我大開眼界，甲方讓我們幾個技術飛過去討論產品方案，本以為過去是在一個小會議室看PPT，然而我們太天真了，去了才知道參加的是集團領導和幾個集團小領導的大會議，各領導輪流發言，你來我往，整個會議是群情激昂，會議室也是煙霧繚繞，既沒有任何方案展示，也沒有確定一些功能需求，最終也就沒有任何結論，做了一堆無用功。這種用傳統企業思維來管理網際網路企業本身就是有問題的，網際網路公司要的是創意、效率和快速解決問題的能力，而這種大規模的耗時的且無意義的會議是最忌諱的，這也給甲方的網際網路技術公司和最終的產品失敗埋下了隱患。

經過5個多月的磕磕絆絆和反覆修改，第一版產品終於上線了，可想而知，市場推廣效果和反應並不理想，甲方提出的需求和行業痛點也不是使用者真正想要的，使用者數量始終上不去。

經驗總結：由於是我們的第一個專案，接的比較倉促，有些方面考慮的不周全，所以在合作過程中有時很被動，做了一些超出乙方開發範圍內的工作。同時甲方公司的經驗不足，開發需求不明，造成了一定程度的時間和資金的浪費，而我們作為乙方理應在開發過程給予適當的引導，這點做得還不夠好。再接這種專案的時候，前期合同必須得簽好，寫好分工，然後需求必須得明確，避免開發過程中的返工和扯皮。不過這次開發經歷的確對我們的團隊來說是一次很好的歷練，磨合了團隊成員間的合作，增強了技術和問題解決能力，同時為以後的專案開發打下了堅實的基礎。

專案二：智慧家居產品APP端

甲方：智慧家居技術企業

開發方式：異地遠端

這個專案是通過關係介紹的，專案資金談的也還可以，需求和設計也很給力，所以很放心的就接下來了。在做一期的時候很順利，按時完成甲方的需求和功能要求，做過此類專案的都知道，最麻煩的就是硬體除錯，有時也得飛過去做現場聯調，不過通過大家的努力，一期按時上線，甲方也很配合，每部分資金都按時到位，初期合作很順利。

一期上線後，開始確定二期的需求並簽訂合同，二期主要是功能上的新增與升級，基於一期的合作，因此對甲方非常放心，沒有強制要求先支付預付款，不過這的確成了這個專案的一大敗筆。剛開始的時候，開發這塊按照需求緊鑼密鼓的進行著，沒有發現任何異樣，慢慢的發現有些變味了，當初定的需求部分需要進行一些改動，好吧，鑑於之前合作很愉快，忍了，改吧，然後又出現有個功能邏輯重新做，算了，已經做這麼多了，繼續給做吧。最後好不容易把二期的功能硬是改完，bug也修了，測試也都通過了，正在等著給打錢時。甲方公司提出，他們的客戶對一個功能不滿意，需要再做一些改動，改完就給錢，我們差點都要罵娘了，最後沒辦法，自己籤的合同，跪著也要做完。本想著這次改完終於可以拿到錢了，沒想到又出現了一些么蛾子，就這樣，反反覆覆，一會小改一點功能，一會改幾個bug。錢也不給，就這樣拖著，最後等來的卻是晴天霹靂，由於甲方產品推廣不理想，運營成本太高，並且無人接手，公司直接倒閉了，這二期的錢徹底打了水漂，本想著飛過去走法律程式，但是由於中間有關係在那，然後又覺得太耗時耗力又費錢，同時手頭還有專案脫不開身，最後只能不了了之，當是交學費了，算是買了一個大大的教訓。

經驗總結：無論籤幾期合同，無論這個專案中間有沒有關係，一碼歸一碼，預付款一定得要，這是最起碼的，如果開發中期能再要一部分那就更好，首先要保護好自身的利益不受侵害，以免吃啞巴虧。像我們這種小公司真的折騰不起，親測有效。

專案三：政府某部門相關係統完整解決方案

甲方：某技術服務公司

開發方式：同城遠端開發

這個專案是甲方委託我們的技術團隊開發的，自身無任何技術開發人員，只是進行需求採集的中間角色，合同也是和甲方簽訂的，專案款分期支付。專案前期，我們主要與甲方以及政府部門相關人員進行溝通，梳理專案需求，確定最終的實現方案，一切還算順利，我們先出的UI設計圖，涉及的產品包括Android，IOS，微信公眾號，PC端網站和管理系統，以及爬蟲系統。

其實這個專案開始的時候，我們也是有心裡矛盾的，和一些同行瞭解過，做政府的專案可能事情比較多，溝通成本太高，有時還需走動走動。但是中間有個甲方，我們想著只和甲方按合同辦事，因此就放鬆了警惕。隨著各個端開發的進行，問題也就隨之而來了，政府部門領導覺這裡不好了，那裡得改改，就給甲方施壓，甲方就是靠這個生存的，因此只能陪笑，然後和我們溝通更改一些功能，最初一次兩次我們也都能接受，後來越來越頻繁，感覺籤的合同啥用都沒用，領導一句話，甲方就來找我們，最後只能以停止開發往回懟，讓甲方自己處理，因為開發週期越往後推對我們越不利，時間成本太高。

最後終於開發測試完畢，待政府部門驗收的時候，大問題來了，政府部門換了領導班子，剩下那30%的專案款眼看著就要拿到手了，又被收了回去。領導班子一換，甲方又得重新走動，各個產品重新演示和申請驗收，為了配合驗收，我們又對新的領導提出的一些需求做了一些改動，終於開始驗收的時候，政府部門又對當初的需求文件開始挑毛病，一個字一個字的摳，不過系統中確實有一些不足，雖然不影響整體功能，但是就是不能過審。就這樣你來我往的扯皮，5個月的工期，現在快一年了還沒有真正交付，沒辦法了，現在只能這樣耗著，這個專案到目前為止算是失敗的。

經驗總結：接政府專案一定要謹慎，除非你有很硬的關係，時間上真的耗不起，如果非接不可的話，前期預付款必須提高，降低自身的風險。其次，在稽核需求文件和簽訂合同的時候，一定要仔細再仔細的檢查，能做的要做的寫上去，不能做的系統中沒有的儘量不要寫，以免產生功能缺失，最後弄得兩敗俱傷。

雖然以上是一些不太成功的合作案例，但是這只是一些個案，大部分的甲方還是信守承諾，按合同辦事的。不過我覺得首先要做到自身的身板正，技術硬，不能欺騙客戶，客戶才能信任你，其次再要求客戶，這樣才能在這個圈子站穩腳跟，培養好的口碑，最終生存和發展起來。確實，外包專案是有一定風險的，稍不注意就會兩手空空，把握以下幾點保你不翻車或者少翻車，簽訂合同或者協議時要仔細、根據專案情況支付預付款，風險大的多要點，風險小的少要點、需求必須得明確，儘量避免改改改！以前沒在雲沃客上接過專案，後來聽同行介紹，這個平臺上的專案非常靠譜，不但專案屬實而且有資金保障，後來接了幾個專案，的確如此，打算常駐平臺，並將我們打造成優質的技術服務提供商。