一个远程协作的平台，如何设计才能不断提升项目成功率，让需求方和开发者都满意？
有需求方和我私聊，说他就一定要看到freelancer在镜头前工作才安心，要看到对方的屏幕一直在做自己的工作，否则就会担心自己的钱白花。
而在我看来，项目成功的关键远远不是这些表象，还有更多更深层的原因值得挖掘。
从15年1月份到现在，我们产品团队已经经历了12个月的远程协作，在web, iOS 以及安卓端发布了从1.0，到现在的2.2，共3个大版本（1.0，2.0，2.2），以及8个小版本的迭代更新，其他的小修改不计其数。
从客栈8月份开始内测，9月份开始正式上线远程项目，我们迄今已经审核了235个项目，通过了其中的123个，48个已经完成结款，项目由于需求方原因终止的23个，由于开发者原因终止的1个；项目失败两个，最终通过平台仲裁解决，根据实际开发者已完成的部分付款。
我们通过这所有项目在学习，成功是为什么，失败是为什么。
然后再把我们的学习心得融入到产品中去，通过平台系统，来提升远程协作的成功率。
接下来，总结我在以下几个方面的经验和想法：
一、如何做一次成功的远程项目？
二、这个项目成功后，如何维护，如何再次开发？
一、如何做一次成功的远程项目
先从失败的案例来分析。
案例1：一个产品原型制作项目，在PM根据需求方的要求制作万原型后，需求方拒绝确认开发完成，并给出以下反馈。
我拒绝了确认完成，主要原因是，我认为这个项目目前才进入正题，还没有到结束的时候。
对于目前这稿原型，我的看法是：
——复现了我在需求PPT里所描述的设想，有一些提升（主要是卡片详情页的设想），但离一个OK的原型还有不少距离。
换个角度来说，我觉得X先生目前做的工作，主要还是理解项目的思路、以及部分“动手”的工作。但是，坦率的说，我觉得还没有怎么“动脑”——即运用自己的专业知识，从产品的角度来检视初期的设想，修正不足、提出改进。
开发者对于需求方的要求觉得无法接受，本来以为只是要根据老板的意思来做个原型，结果老板说你来给我做创业指导吧，从痛点开始梳理为我把产品计划做出来，价钱么，给你个制作原型的价钱。
巨大的价值认知差异，加上不确定的需求和交割时间，导致开发者最终不愿再继续这个项目，项目失败。
Learning:
项目开始前，双方对于需求和工作，工期，金钱的认知必须在第三方的监督下达成一致。
所有达成的一致都应该被记录下来，供以后查询核对。
当需求方想要发起需求变更时，平台应该提醒ta这将带来的金钱和时间的变化，在ta认可后，再发布更新。
当然，这最好是不要发生。
案例2：最开始的时候，我们接过一个安卓开发的项目。当时在组里咨询了一些安卓开发者，对方虽然没做过，反馈应该不难。接过等我们把项目接下来之后，他们仔细研究了需求，发现完全不知道该怎么做，如果要做的话要重新学习，时间会很长。
我们只能在心里默默流泪，向需求方道歉，把这个项目拒了。
项目经验真的很重要，没做过和做过的，在效率上有天壤之别
learning:
通过客观因素来评分判断开发者与项目之间的相关度，而不是来自一方感性且不负责任的回复，“我觉得可以做吧”。
通过机器学习，不断提高匹配的正确度。
这包括：
成功的开发者和项目之前，有哪些可以标准化衡量的因子？如何通过越来越大量的案例，来验证调整这些标准化衡量的因子是否正确，权重如何。
还有一种失败，是项目长时间延期
这个归根结底来自于两方面因素：
1：需求变化导致延期
2：开发者对于开发难度，以及工作强度估计不准导致预期出错
3：验收阶段没有验收标准，导致需求方想到哪里是哪里，验收拖延很长时间。
4：需求方没有准备好导致开发推迟：没有准备好接口，文档等等。
对于双方而言，项目延期都是很痛苦的事情。
失败各有原因，而成功却是有着共性的。
这个共性其实不用我来总结，Basecamp的创始人，《rework》,《remote》二书的作者贾森.弗里德 和 戴维.海涅迈尔 早就已经总结给了我们：
远程协作成功的关键
1-即使员工遍布全美各地，每天也要有4小时的共同工作时间，其余时间可以自行安排。
2-眼见为实：视频共享来说明问题，好过只用文字或者图片
3-工作资料全员共享，任何人在任何时间都可以得到
4-做好的工作，要及时展示给工作团队来看，激励团队加速前进
5-只从工作成果来衡量，而非过程（纠结于对方到底花了多少时间是没意义的，你是愿意他不吃不喝不睡但就是完成不了你的任务，还是他轻轻松松就可以提前完成呢？）
纵观我们自己的远程经验，以及已经成功的48个项目，我们毫不意外地发现，他们的合作模式和上面这5条非常类似。
1：每日在客栈上提交当日进展，并定点在工作群里讨论
2：有疑问及时提出，并解决
3：碰到双方认知不一致（需求变更，工期等），提供客栈项目记录，交由平台来仲裁。本身更关注于如何推动项目进行下去，而不是扯皮。
（未完待续）
