远程协作开发日志（1）学习Uber做供需匹配

据上篇文章总结，我们先看看如何学习Uber做工序匹配：

匹配算法－快速响应，优良服务，顾客体验的正循环

对于司机而言，派单是比抢单更轻松的方法。
Uber在派单之前用来匹配“乘客需求－司机供给”的模型，每个订单通过算法（包括,最短到达时间，是否可用、以往评价等因素），决定了司机和车辆的推荐顺位。

1. 通过算法找到能够最短到达的司机
2. 司机看不到目的地，因此也无法拒载。（潜在问题是，司机如果对目的地那片区域如果不熟悉怎么办？除非算法里自动匹配司机过往的行车记录，有类似行车记录的司机才进行推荐，否则将造成司机找不到路，行车体验很差的结果。Uber目前推出的最短路程游戏就是解决这个问题的。）

远程协作的匹配

我们程序员客栈要做的，就是尽量精准快速地匹配用户的开发需求和开发者，类比下来，我们需要解决这么几个问题：

1. 开发需求和开发者之间的“最近路径”应该由什么量化指标来确认？
   GPS定位＋道路地图，是Uber能做到最近路径匹配打车者和合作司机的关键因素。
   那么开发需求和开发者之间的“最近路径”应该由什么量化指标来决定呢？
   从目的出发，最近是为了对于司机和乘客双方而言，都能够最快实现需求（司机－接活赚钱，乘客－出发）。
   因此我们开发也从目的出发：为了让开发者能够尽快上手开发，开发者（司机）离开发需求（乘客打车需求）的距离，应该从：

• 开发者对于需求（开发分类，功能，行业）的了解程度，学习，以及沟通成本越低越“近”；

字段：个人的方向／语言，技能树，作品的功能，行业标签；

2. 派单推荐顺序参考因素：

• 是否接单：不派单给暂时处于不接单状态的签约开发者，节省派单时间降低用户等待；针对长期不接单的签约者（3个月），建议暂时解约。
• 过往接单率：过往派单后半个小时内接单的比率。
• 过往用户评价：1-10分打分评价。
• 个人每天能够投入的开发时间；

派单的时候，不公开价格信息，确保开发者不会因为价格歧视而拒接。

总结：

先筛选出与用户发布的需求在以下几个方面最吻合的开发者：

方向（iOS ,Android, Web)

语言（对于发布方而言是选填）

关键功能（对应开发者过往作品功能）

行业（对应开发者过往作品行业）

然后按照以下方式排序：

1. 是否接单
2. 过往成交率
3. 过往用户评价
4. 个人每天能够投入的开发时间

开发者签约时需要填写的信息：

1. 作品，作品的功能，行业属性
2. 个人方向，语言，技能树
3. 是否接单，每日可工作时间多少

系统自动计算的开发者属性：

1. 接单率
2. 用户好评率

发布者发布任务的时候需要填写的信息：

1. 目前所有发布信息
2. 发布需求的关键功能，行业，语言（可选）
3. 时间要求

系统自动计算的发布者属性：
1.发布成功率
2.开发者好评率