基于以上失敗以及成功案例的總結，我們把原來我們的項目監理，開發者，需求方要人工做到事情加到了產品流程里面，從產品設計上來提升項目的成功率：
1：人員匹配：基于作品經驗，項目成功率，用戶評分等8大因子的機器匹配，且匹配次數越多越精準。
這個匹配只能通過系統進行，系統推薦，人力操作的話，會非常麻煩，效率底下，反而不如在群里吼一聲來得有用。
而這里，引出另外一個迫切需要自動化的事情：簽約的自動審核。目前我們審核一名程序員簽約，包括：
- 考察了用戶是否滿2年工作經驗（目前我們只能通過履歷判斷，沒有這個標簽，或者系統不能從履歷中識別這個關鍵詞）
- 考察用戶是否有3個已上線作品（這個可以通過系統來進行）
- 研究用戶的代碼，判斷其代碼風格和質量是否滿足要求（在代碼規范沒有被廣泛接受之前，這個無法用機器判斷）
耗時起碼半個小時甚至更長，一名審核人員一天頂多審核20名開發者，再多就要增加人力了。這種無法通過互聯網的成本邊際遞減方法解決的問題，不是長久之道。
可以考慮的解決辦法：
1）獎勵已簽約開發者實名推薦，被推薦者成功完成首單后推薦者可獲得獎勵；被推薦者收到差評，該差評也同時影響推薦者。將審核有中央變成分散。
2）針對實名推薦的候選人，系統只檢查硬性條件：2年工作經驗，3個已上線產品。需要人判斷的交給推薦者來判斷。
2：項目管理的進一步細分：
增加協商流程環節，雙方確認共同工作時間，里程碑之后才進入到款項托管階段，托管完款項后，才進入開發階段。
不明確達成一致，并在平臺備案，就不進入開發，而這些都不需要平臺人力介入，需求方和開發者自行達成。開發中狀態細分成開發流程，每次里程碑的變動都及時通知到雙方，所有里程碑都完成了，也就完成項目了。
所有文檔托管在第三方安全云，雙方可以隨時調用查看。
如你所見，我們的項目，全部都在客棧上進行，因為實在很方便好用。
下一步，需要繼續考慮的是代碼托管的問題。
1：節省雙方的準備時間和精力
2: 以后可以及時對代碼進行機器審核，確保一定的代碼規范和質量。
3: 每次推送可以直接體現在項目進展上，雙方溝通更高效。
二、這個項目成功后，如何維護，如何再次開發？
然而所有這些，都只能提升某一次項目的成功率。
每次我向用戶介紹客棧，總會被問到這樣一個問題：
那我以后想升級怎么辦呢？交給一個新的程序員，他能接上么？
這個問題是挺讓人發愁的，沒有哪個開發者愿意去接受別人做了一半的活，很多時候，寧愿自己從頭做起。
不同的代碼風格和習慣會造成程序的繼承性和開放性大不一樣。
這個問題如果不解決，所有遠程平臺都只能做一次性的項目，無法和客戶長久甜蜜地合作下去。
我正為這個問題發愁的時候，一個大牛哥們開玩笑說起了最近比較得意的一件事情：
他們公司是google的合(wai)作(bao)商(fang)之一，最近發愁交給google的程序總是被對方的工程師打回來,說可讀性差，格式不對。
于是公司找他牽頭，想組成一個臨時小組，專門來審核提交給google的程序是否滿足對方的要求。
這哥們在github上溜了一圈，直接下載了google的代碼規范說明，以及代碼格式檢查器交給了公司，用兩個小時完成了公司預備用2個工程師1周的時間完成的事情。
Google一年那么多外包項目，對可繼承性和開放性的要求，絕對不比我們平常做得項目低，他的這種方式，對我們而言是不是也可行呢？
和另外一個做完整項目的創業團隊負責人聊了很久，他也建議我們統一代碼規范，這樣無論是誰寫的項目，另外一個熟悉同等規范的人要進行升級開發，維護都會比沒有規則的情況下，容易得多。
未來，我們需要可以考慮的，就是如何建立自己的代碼規范的問題。
遠程協作還有很多可以再深入研究的地方，我們能夠做的，就是不斷根據用戶的行為，進行總結，大膽設想，小心驗證，對的就推廣，錯的就糾正。
所以你會發現，程序員客棧這個遠程協作平臺，用得越多，變得越好用。
因為我們每時每刻都在學習，都在進化。
