雖然我們一再強調我們做的是「開發任務」眾包平臺，還是被不少人誤解為「專案」眾包平臺，正好我們遇到的第一單就是一個典型案例，簡單發篇博文分享一下。
4月29日我們開始召集眾包平臺的早期合作開發者，先以手動擋方式（微信+GitLab）驗證基於「開發任務」的眾包模式。
在召集博文中順帶加了個小廣告：
如果您現在就有開發任務或者技術問題想嘗試透過園子眾包解決，也可以加企業微信，加好友時備註「眾包需求方」。
5月5日有需求方加我們的企業微信，提了第一個需求，需求方很能 get 到我們的定位，提出的需求是一種典型的適合眾包的「開發任務」—— 寫 demo 程式碼。
具體需求是用 java 實現電子發票介面對接 demo，只需呼叫介面開出一張電子發票即可。
這樣的開發任務只要做過一次，以後的n次都很簡單，但是不管你技術多麼厲害，第一次實現時，熟悉介面都要花費一段的時間，除非介面提供方已經提供了比較全面的 demo 程式碼。
在沒有現成 demo 程式碼的情況下，如果當前開發時間很緊張，透過眾包的方式找有經驗的開發者快速實現一段可以跑通的 demo 程式碼，然後參考實現，有些企業或者開發者還是原意為此買單的。
這樣的開發任務需求非常明確，接單開發者很容易理解，交付的程式碼也很容易驗證，即使出現問題，風險也很小，所以交易很容易完成。
所以我們的眾包平臺切入點不僅是開發任務，而且是容易交易、風險小、顧慮少、週期短的開發任務，主要是與業務無關的 infrastructure 層面的程式碼。
這個 demo 程式碼的單子符合眾包場景，有好幾位合作開發者想接單，但在進一步溝通中，由於需求方無法提供介面的測試賬號，需求方要求開發者自備測試賬號，而只有企業才能申請到測試賬號，這個門檻擋住了想接單的開發者。
由於那天正好是五一假期，很多開發者沒有關注這個眾包需求，第二天有開發者聯絡我們說他可以申請到測試賬號，可以接單，但這時聯絡需求方，需求方已經自己找到了人接單。
雖然這次單子沒能成交，但是透過這次的經歷，部分地驗證了寫 demo 程式碼這樣的開發任務透過眾包完成有一定的可行性。
我們現在就是在採用原始的人工運營模式驗證哪些開發任務適合眾包，並發現其中的痛點問題，然後透過平臺機制解決。