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

談起外包經歷，個人第一次外包源自前兩年某天陪着女朋友逛商場時，接到一個朋友的電話，朋友興高采烈地跟我介紹一個大項目：需求很少、錢很多，難度不大、口氣不小，我一聽心動了，原覺得要賺一筆 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:

儘管接下硬件這塊又有錢賺了，但這不是咱們團隊的強項，須要另找專業人員，至關於給團隊和項目增長風險和不肯定性。專一於作本身擅長的一面，不爲團隊和項目累加風險和不肯定性，也是一種責任心。

寫在最後

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