談起外包經歷，我的第一次外包源自前兩年某天陪著女友逛商場時，接到一個朋友的電話，朋友興高采烈地跟我介紹一個大項目：需求不多、錢不少，難度不大、口氣不小，我一聽心動了，原以為要賺一筆 easy money，後面再看看，這次外包踩了大大小小不少的坑，遂想好好記錄一下。

前期溝通

電話的第二天，和外包項目需求方簡單溝通後，他們發來十幾張 App 界面的樣例，大概是些軟硬件結合、通過 App 界面展示硬件信息和數據統計，以及相關信息的 CRUDDemo，功能不多不過開發時間也有限，要求在月底前做完 App Demo 與後臺系統，趕著參加一個會議展示。對方多次強調項目的優勢：正處於風口、資源配置各方面都齊備，除了...沒有軟件技術團隊，目前只有硬件團隊，軟件這邊只有零星的兩三個，但不堪重用。

Tips:

這裏我犯下了第一個錯誤，我以為只是一個Demo完事，但這背後是一個完整龐大的項目，項目大小、類型和復雜度的錯誤評估，使我沒有很好地把控全局和考慮整個項目的細節，導致後面引發了很多問題。

在評估一個項目時，我們通常會低估項目的復雜度，而高估自己處理某些瑣碎細節的能力。

組建團隊

項目要進行，一個人是搞不定的，因為涉及到 各端 App、Web以及後臺，於是我首先找了一個靠譜的後臺開發朋友，然後等項目快正式開始前，再一起尋找和確定其它小夥伴。

Tips:

外包合作過程中，優先找靠譜、技術紮實、有責任心的人，外包項目大多技術不復雜，但因為協作方式的特殊性，大多是異地異步辦公，需要有強烈責任心的人。不然項目開發時，經常找不到人，或者溝通缺乏反饋就很被動了。

項目報價

談到項目必然會談到錢，關於報價這塊，對方很開放的有兩種合作方式，一種是技術入股的形式，另一種是按照外包的方式報價。我想著因為是第一次合作，采用第二種方式最為保險，畢竟落袋為安嘛。

由於是第一次接外包沒有經驗，心裏很忐忑，趕忙去網上查一些外包報價的方式和註意事項，最終決定根據團隊人員工作的日薪，乘以一個系數，報給了他們。不出所料，他們覺得貴了，整個合作就僵持在那裏。介紹項目的朋友答應去斡旋，然後...沒了下文。

Tips:

不同外包項目的公司、項目背景不同，遇到技術入股這事得慎之又慎。當然現在外包平臺很多，一切都基本流程化、正規化了，直接是項目與錢的交易，這種問題也會越來越少。

按照故事的正常節奏，我的外包初體驗夭折了。大概兩周後，事情出了轉機，對方的負責人打來電話說要當面溝通一下。然後技術負責人和老總一並趕了過來，扯了半天介紹了項目的背景、公司及技術團隊的情況，我意識到了這個項目不只是一個 Demo 這麽簡單。最後約定另找時間詳細溝通需求，以及評估報價。

等到溝通完需求要報價的時候，對方想要一個打包價格，而不管每人每天的算法，又扯到這個項目很大，會分幾期開發交付，第一期想讓雙方以磨合的姿態來合作。意思是你們也別想著開高價了，我們第一次合作先便宜點，磨合一下摸摸底，覺得不錯的話後面合作再談。

因為我也是第一次接外包，缺乏經驗，在這個磨價的過程中，腦子一熱不小心就答應了對方的要求。等到協商完畢確定好報價，發現只有第一次給出的每人每天報價的一半，才意識到我們還是圖樣圖森破。

Tips:

這裏是第二個錯誤，報價過程中要盡可能堅持自己的報價條件和底限，如果對方說出最低價格這種話，絕不能給出一個自以為的最低報價，不然就容易弄成菜市場的討價還價，最終會被磨的和自己預期差距很遠，可以跟對方認真溝通，談錢一定不能圖省事。價格貴也是質量的保證，可以象征性地少一些，但務必控制範圍。

簽訂合同

不管怎麽說，既然給出了報價，本著學習漲姿勢的態度，咱就幹吧。需要擬訂合同時，沒看到合適的，最終在網上找了一個軟件外包開發合同模板，大致改了一下，將就用著。

關於外包合同有很多需要註意的地方，這裏就只簡單說一點：合同的條款一定要一條條地過，確保自己能完全掌握和理解每一條的內容及背後的含義，確保不要對自己埋有坑，當然也最好不要坑對方。

Tips:

當然現在外包行業發展越來越成熟，外包流程和項目也越來越規範，也誕生了像雲沃客這種成熟的眾包平臺，甚至不再需要合作雙方私下簽訂協議，服務方和需求方都能把精力專註於項目上，而把背後的一些瑣碎之事和問題交由平臺來規範管理，省心很多。

簽合同遠赴對方公司，中午正熱時坐了個順風車過去，下了車一看太陽都快下山了，高樓不見了，眼見之處都是低矮的民房，大爺大媽懶洋洋地支起了小吃攤，第一感覺是從深圳到縣城了。對方是一個傳統的公司/工廠，這意味著什麽互聯網、軟件開發等等都可能是對牛彈琴，如果對方沒有一個專業懂行的對接人員，這個項目的進展將會非常艱難，後面的事情也正出乎我所料。

Tips:

盡可能詳細地了解對方公司、項目情況及相關人員背景，如果出現對接人員素質與項目不相符的情況，盡早向合作方提出疑問，把問題拋向對方，不要讓這種問題影響項目的進度和後續工作的開展。

合同簽完，需要再次詳細溝通需求和評估開發計劃，我和團隊同伴遠赴對方公司開會。溝通需求的過程中對方少不了加需求，甚至是一個獨立的模塊，相當於工作量莫名就多了幾分之一。對方含糊其詞，說這是一個非常重要的模塊，沒有這個模塊就不是一個完整的系統，當初以為這是默認大家知道的事情雲雲。好在先前擬訂合同的時候，我把主要功能和相關模塊都寫在了合同的開發內容一款裏面，趕忙把合同拿給對方看，對方啞口無言，後面繼續溝通是加時間、加人力還是精簡功能。

Tips:

擬訂合同時，一定要寫清楚開發內容和主要功能，盡可能詳細準確，避免後續因為添功能、改功能扯皮，畢竟口說無憑、白紙黑字才是硬道理。

項目開始

合同簽完，按照合同約定對方需要先支付 30% 的項目款作為一期款，因為這些都是明確寫到合同裏，整個付款過程中很利索，唯一的問題是對方需要提供發票，後面找了朋友公司代開搞定。

軟件增值稅票稅點一般是 6%，稅費也會是一筆不小的支出。最好在報價時溝通好稅費及發票相關事宜。

Tips:

最好等到預付款 or 第一期項目款到賬後再啟動項目，避免不必要的麻煩。

報價時將稅費和發票考慮進去。現在眾包平臺也大多解決了這個問題，用戶不必再操心這個。

項目準備

等到相關流程都走完，需要對方提供產品原型的時候，對方硬是石滾碾不出個屁來，憋了很久什麽東西也提供不出來，我們艱難地跟他們普及了設計稿和原型稿的區別後，他們疑惑地表示：這種東西不是應該由你們來搞定嗎。只好邊跟他們說清楚，邊給對方提供幾個原型示例和原型工具。

回過頭看看，整個項目過程中對方除了給出一個非常粗糙的概念需求文檔，任何文檔輸出都沒有，在前面溝通需求時提出讓對方把相關需求文檔整理給我們，他們表示這種東西都在自己腦子裏沒有時間整理。

沒有輸出的文檔，後續的工作便沒有了依據，而所有的依據，也只是在詳細溝通需求的時候，我們自己整理的需求列表文檔。

Tips:

文檔的輸出非常重要，詳細的需求文檔與設計文檔是後續項目開發中的必備利器，沒有這些，整個項目成了巧婦難為無米之炊，而且這些也會是項目開發完畢驗收的標準之一。

項目前期

項目還沒正式開始，對方又出幺蛾子了，對方對接人員由技術主管變更為另一個下級技術負責人，估計他們內部都沒有仔細溝通過，就直接讓我們和他對接，上來第一句便是找個時間溝通下需求，這邊不太清楚細節。拜托，細節都在你們老大那裏了，求我們心理陰影面積...

所有的輸出文檔只有在我和第一任對接人溝通需求時，整理的需求列表文檔，這意味著它是經過第一任對接人陳述並由我們消化整理的，而第二任對接人如果再以它為參照的話，這裏面的需求理解因人而異，項目變數更多、前景堪憂。想到這些，我們只好再次奔赴過去詳細溝通需求。

Tips:

項目對接人的變更算是一個意料之外的問題，也更顯前面所述的文檔的重要性。越快越早地形成詳細清晰的文檔直接決定了項目後續的走勢和進度。

在等原型的這段時間，風雨飄搖的項目又出了新紕漏：原本協商好的我們只需要負責軟件系統開發（包含各端 App、Web 管理系統、後臺系統），對方負責硬件生產及硬件系統開發，後來他們硬件開發人員離職，想把硬件系統開發這一塊也交由我們。我們想都沒想，就直接拒絕了。

Tips:

盡管接下硬件這塊又有錢賺了，但這不是我們團隊的強項，需要另找專業人員，相當於給團隊和項目增加風險和不確定性。專註於做自己擅長的一面，不為團隊和項目累加風險和不確定性，也是一種責任心。

寫在最後

還沒寫到項目正式開始，就已經羅羅嗦嗦一大篇了，後續記錄一下項目開發過程中的坑和教訓，未完待續，歡迎交流。

本文出自 “13397554” 博客，轉載請與作者聯系！

【避坑】初次接項目的血與淚，紮坑了老鐵