远程协作平台的设计要点,以及发展方向(下)

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

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

远程协作平台的设计要点,以及发展方向(下)_第1张图片
程序员与项目匹配.png

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

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

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

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

可以考虑的解决办法:

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

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

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

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

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

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

远程协作平台的设计要点,以及发展方向(下)_第2张图片
项目进展
远程协作平台的设计要点,以及发展方向(下)_第3张图片
开发流程
远程协作平台的设计要点,以及发展方向(下)_第4张图片
项目详情

远程协作平台的设计要点,以及发展方向(下)_第5张图片
我的项目列表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

你可能感兴趣的:(远程协作平台的设计要点,以及发展方向(下))