談起外包經歷，我的第一次外包源自前兩年某天陪著女友逛商場時，接到一個朋友的電話，朋友興高采烈地跟我介紹一個大專案：需求不多、錢不少，難度不大、口氣不小，我一聽心動了，原以為要賺一筆 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:
儘管接下硬體這塊又有錢賺了，但這不是我們團隊的強項，需要另找專業人員，相當於給團隊和專案增加風險和不確定性。專注於做自己擅長的一面，不為團隊和專案累加風險和不確定性，也是一種責任心。
寫在最後
還沒寫到專案正式開始，就已經羅羅嗦嗦一大篇了，後續記錄一下專案開發過程中的坑和教訓，未完待續，歡迎交流。