远程协作平台的设计要点，以及发展方向（下）

基于以上失败以及成功案例的总结，我们把原来我们的项目监理，开发者，需求方要人工做到事情加到了产品流程里面，从产品设计上来提升项目的成功率：

1：人员匹配：基于作品经验，项目成功率，用户评分等8大因子的机器匹配，且匹配次数越多越精准。

程序员与项目匹配.png

这个匹配只能通过系统进行，系统推荐，人力操作的话，会非常麻烦，效率底下，反而不如在群里吼一声来得有用。

而这里，引出另外一个迫切需要自动化的事情：签约的自动审核。目前我们审核一名程序员签约，包括：

• 考察了用户是否满2年工作经验（目前我们只能通过履历判断，没有这个标签，或者系统不能从履历中识别这个关键词）
• 考察用户是否有3个已上线作品（这个可以通过系统来进行）
• 研究用户的代码，判断其代码风格和质量是否满足要求（在代码规范没有被广泛接受之前，这个无法用机器判断）

耗时起码半个小时甚至更长，一名审核人员一天顶多审核20名开发者，再多就要增加人力了。这种无法通过互联网的成本边际递减方法解决的问题，不是长久之道。

可以考虑的解决办法：

1）奖励已签约开发者实名推荐，被推荐者成功完成首单后推荐者可获得奖励；被推荐者收到差评，该差评也同时影响推荐者。将审核有中央变成分散。

2）针对实名推荐的候选人，系统只检查硬性条件：2年工作经验，3个已上线产品。需要人判断的交给推荐者来判断。

2：项目管理的进一步细分：

• 增加协商流程环节，双方确认共同工作时间，里程碑之后才进入到款项托管阶段，托管完款项后，才进入开发阶段。
  不明确达成一致，并在平台备案，就不进入开发，而这些都不需要平台人力介入，需求方和开发者自行达成。

• 开发中状态细分成开发流程，每次里程碑的变动都及时通知到双方，所有里程碑都完成了，也就完成项目了。

• 所有文档托管在第三方安全云，双方可以随时调用查看。

项目进展 开发流程 项目详情
我的项目列表

如你所见，我们的项目，全部都在客栈上进行，因为实在很方便好用。

下一步，需要继续考虑的是代码托管的问题。

1：节省双方的准备时间和精力
2: 以后可以及时对代码进行机器审核，确保一定的代码规范和质量。
3: 每次推送可以直接体现在项目进展上，双方沟通更高效。

二、这个项目成功后，如何维护，如何再次开发？

然而所有这些，都只能提升某一次项目的成功率。
每次我向用户介绍客栈，总会被问到这样一个问题：

那我以后想升级怎么办呢？交给一个新的程序员，他能接上么？

这个问题是挺让人发愁的，没有哪个开发者愿意去接受别人做了一半的活，很多时候，宁愿自己从头做起。

不同的代码风格和习惯会造成程序的继承性和开放性大不一样。

这个问题如果不解决，所有远程平台都只能做一次性的项目，无法和客户长久甜蜜地合作下去。

我正为这个问题发愁的时候，一个大牛哥们开玩笑说起了最近比较得意的一件事情：
他们公司是google的合(wai)作(bao)商(fang)之一，最近发愁交给google的程序总是被对方的工程师打回来,说可读性差，格式不对。

于是公司找他牵头，想组成一个临时小组，专门来审核提交给google的程序是否满足对方的要求。

这哥们在github上溜了一圈，直接下载了google的代码规范说明，以及代码格式检查器交给了公司，用两个小时完成了公司预备用2个工程师1周的时间完成的事情。

Google一年那么多外包项目，对可继承性和开放性的要求，绝对不比我们平常做得项目低，他的这种方式，对我们而言是不是也可行呢？

和另外一个做完整项目的创业团队负责人聊了很久，他也建议我们统一代码规范，这样无论是谁写的项目，另外一个熟悉同等规范的人要进行升级开发，维护都会比没有规则的情况下，容易得多。

未来，我们需要可以考虑的，就是如何建立自己的代码规范的问题。

远程协作还有很多可以再深入研究的地方，我们能够做的，就是不断根据用户的行为，进行总结，大胆设想，小心验证，对的就推广，错的就纠正。

所以你会发现，程序员客栈这个远程协作平台，用得越多，变得越好用。
因为我们每时每刻都在学习，都在进化。