虽然我们一再强调我们做的是「开发任务」众包平台，还是被不少人误解为「项目」众包平台，正好我们遇到的第一单就是一个典型案例，简单发篇博文分享一下。
4月29日我们开始召集众包平台的早期合作开发者，先以手动挡方式（微信+GitLab）验证基于「开发任务」的众包模式。
在召集博文中顺带加了个小广告：
如果您现在就有开发任务或者技术问题想尝试通过园子众包解决，也可以加企业微信，加好友时备注「众包需求方」。
5月5日有需求方加我们的企业微信，提了第一个需求，需求方很能 get 到我们的定位，提出的需求是一种典型的适合众包的「开发任务」—— 写 demo 代码。
具体需求是用 java 实现电子发票接口对接 demo，只需调用接口开出一张电子发票即可。
这样的开发任务只要做过一次，以后的n次都很简单，但是不管你技术多么厉害，第一次实现时，熟悉接口都要花费一段的时间，除非接口提供方已经提供了比较全面的 demo 代码。
在没有现成 demo 代码的情况下，如果当前开发时间很紧张，通过众包的方式找有经验的开发者快速实现一段可以跑通的 demo 代码，然后参考实现，有些企业或者开发者还是原意为此买单的。
这样的开发任务需求非常明确，接单开发者很容易理解，交付的代码也很容易验证，即使出现问题，风险也很小，所以交易很容易完成。
所以我们的众包平台切入点不仅是开发任务，而且是容易交易、风险小、顾虑少、周期短的开发任务，主要是与业务无关的 infrastructure 层面的代码。
这个 demo 代码的单子符合众包场景，有好几位合作开发者想接单，但在进一步沟通中，由于需求方无法提供接口的测试账号，需求方要求开发者自备测试账号，而只有企业才能申请到测试账号，这个门槛挡住了想接单的开发者。
由于那天正好是五一假期，很多开发者没有关注这个众包需求，第二天有开发者联系我们说他可以申请到测试账号，可以接单，但这时联系需求方，需求方已经自己找到了人接单。
虽然这次单子没能成交，但是通过这次的经历，部分地验证了写 demo 代码这样的开发任务通过众包完成有一定的可行性。
我们现在就是在采用原始的人工运营模式验证哪些开发任务适合众包，并发现其中的痛点问题，然后通过平台机制解决。