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