解决软件服务定制化的问题，众包模式还需要接受哪些考验？

在实际应用中，软件服务的定制化需求如今已经不仅是必要的，而且是必须的了。就比如管理软件，随着信息化的快速发展，企业和个人对管理软件的依赖性与要求也越来越高，但现有的很多通用版管理软件往往不是功能太过单一就是相对比较复杂，与客户的实际需求并不能很好地匹配。

对于个性化的软件服务，定制开发的难点一般表现在，有经验能复用的开发者很难找，开发成本高昂，开发效率低，周期长，再加上需求者对定制化的想象空间往往有限，复杂的沟通和各种双方协议、流程等，无不使定制过程繁冗拖沓，不仅最后难以满足需求者的定制化标准要求，时间、金钱、人力通通都堆积成了浪费掉的成本。

现在，众包模式流行起来，近几年，众包模式在国内有了越来越多的尝试者，并且不断把领域细分、做垂直化，比如创意众包、知识众包、物流众包，以及以“解放号”为代表的软件服务众包，也有越来越多的用户看到了众包模式的优势和价值，选择通过众包来完成项目。尤其是软件服务，在社会资源的供给之下，通过“社会生产”不仅给与了个性化的满足，更是大大降低了成本。

要知道，对于需求方而言，要找到有自己这种有个性化经验的开发者并不是一件容易的事情。如果开发者有过类似经验，已经写过类似代码，不必重写代码，那相对就容易得多。“复用”成为降低成本的根源，而只有愿意做众包的开发者足够多，“复用”的命题才可成立。对于垂直化众包服务平台“解放号”就做到了这一点，4万名在线开发者正在与日增长，通过“复用”思路来整合开发者资源，精准的标签刻画来智能匹配合适的开发者则成最大卖点。

然而，考虑到软件服务的特殊性，对众包模式又有了更加苛刻的要求，软件服务众包平台能否满足需求则成为平台运营的关键。

软件需求方最顾虑什么？无外乎以下几方面：

第一，怕不能按时、保质保量履约。因为发包方对其客户有一个时间和质量的承诺，如果到时接包方不能提交，虽然发包方不损失钱财，但是可能会损失在客户方的信用。所以，发包方不敢在管理上“大撒把”。

第二，害怕开发者能力不行，还胡搅蛮缠。如果遇到能力不强、胡搅蛮缠的人确实比较难处理，这在公司招聘时也会出现这种人，能力不行被辞退了还告公司的都有。

第三，企业需求方不敢把众包当成普遍的提交方式，因为害怕PM向外洗钱。

第四，需求方担心平台流程不严谨，害怕钱被轻易的支付出去了。

 

这些顾虑都考验着众包模式的靠谱性，对于此，“解放号”的解决之道可以最大化的控制和规避这些问题。

一是作业过程用工具来管理。用Task+、Git工具严格监控开发者的工作，并需要向需求方报日进展报告，让需求方像管理自己的队伍一样管理平台的开发者。做到透明、协同，知此知彼。

二是能力和人品用数字刻画+人脉背书+工具来甄别。这方面，“解放号”的做法是，用数字化内容来刻画开发者，比如他们在平台上完成的任务、订单及其评价，上传的代码、发表的文章等等，通过这样的深度刻画和合作经历，让开发者用历史去挣钱；另外就是人脉背书，人脉关系和信用机制为企业选人保驾护航。另外，企业需求方的PM对于这种新人的合作要勤用Task+、Git、“话题”工具，及早发现问题，尽快终止合作，这样即不浪费金钱、也不耽误时间。如需仲裁，大家留痕说话。

第三个问题处理上则是用透明监督。“解放号”平台上需求方的BUM可以随时看到每个订单的过程细节，包括这个订单是怎么签的、执行过程中发包方PM和接包方的沟通记录、发包方和接包方关于任务分配和验收（基于Task+）、接包方提交物的上载和协同记录（基于Git），甚至可以看到这些提交物被PM采用到项目中的记录，可做到透明监督。

第四就是对风险控制的要求了。当然作为需求方，支付会是其最重要的控制风险的手段。对于“解放号”的支付服务，有几个关键要素将保障了这些订单对于企业管理者是清晰的：一、所有订单的发起都是经过BUM确认的，而这些BUM也是企业管理者授权和认可的人；二、所有待支付的订单都是可以查依据的；三、所有支付指令都是PM发起、BUM确认的；四、这些订单都是属于某项目，有利于企业项目成本核算；五、每个订单的支付时间、支付路径平台都是记录的，而且由平台直接支付中标开发者（中标开发者当然是实名认证的）。

可见，软件服务定制化对众包模式的挑战需要可靠的严谨的科学的保障措施来做出应对服务。在众包环境下，只有交易对于双方尽量公平才能把交易的规模扩大，也只有这种交易的过程充分透明，企业才会把众包当成一种基本项目提交方式。这样的话，逐渐的企业也可能会尝试把企业转变为以基本的管理者和员工为核心，以外部合同工人和兼职工人为补充的一种灵活可靠的组织形式，而这反过来又会进一步扩大对社群的发包，从而形成由开发者、企业及客户组成的IT服务生态系统。这种大循环的补给，带来的也将是众包模式的大成熟和大普及。