远程协作-替代外包的最佳实践

远程协作-替代外包的最佳实践

本文提到程序员客栈并不全表示我是软文狗，因为我后面也会大量提到tower，但我完全不认识他们。

在做程序员客栈 http://proginn.com 之前总有朋友问我：“我需要做一个App找外包太不靠谱了，你能不能帮我找个人兼职一直帮我做下去，远程的也行啊。”确实当下在一般有经验的技术需求方的观念里，外包是越来越不靠谱了。但是受制于各种因素暂时也不能有自己的开发团队，前期兼职，甚至远程协作的兼职成为了一种出路。

经历过“程序员客栈”这个到今天为止一个纯远程协作的项目，我想就此谈谈“远程协作”这个将来也许会替代外包解决企业临时用人问题的最佳实践。本文会以我的实际经历讲三个案例：一个是外包为什么不靠谱；再是一个不成功的协作经历-我帮圈圈Android（一个校园社交网站）；还有一个成功的协作经历-程序员客栈。



外包为什么不靠谱

之前在“单独程序员做外包为什么会是坑 http://v2ex.com/t/176500#reply16”这篇文章中我已经大致谈过这个问题。

大体可以归纳为：

需求方

1. 需求不明确

当然我接触的外包都是已经有明确的需求文档，并且有估算人头和开发周期的excel表。在一大篇需求文档里面经常间杂有这样的内容：这个聊天完全模仿微信；登录完全模仿豆瓣；这个照淘宝购物车一模一样的做。简单几个字，开始双方都觉得没有问题，项目结题的时候双方都蛋疼直到最后闹翻。比如第一个栗子 “这个聊天完全模仿微信” 开发者就是做了个聊天，能够发表情、语音、图片。心里就想啊，我语音都做了并且也不是主要的需求，应该很好了。结果到了客户各种问题就来了：表情为什么不支持emoji，为什么网站不显示emoji，表情为什么不能自定义，为什么不能发视频，为什么不能发红包，他想要的甚至是红包支持银联...同样的道理“登录完全模仿豆瓣”，支持短信验证不，支持邮箱验证不，第三方登录支持QQ、微博不？这些都是需求不明确带来的大坑。不注意这些问题，你们就扯皮去吧。

2. 对于软件开发认识小白

a.低估开发难度，不理解软件开发周期，存在严重的催促习惯。好像本来2个月做的项目一个星期就能做完。感觉催、加人、加钱能解决问题一样。

b.搞不懂到底什么产品质量好质量坏：什么！你做个购物网站都要上十万？我在猪八戒上发布最多1万块好多人抢。我在淘宝上面买套态度几十块钱就够了，你们太黑了。

c.不知道会有bug这种东西存在，难以理解运维工程师这样的职业。遇到问题就怀疑合作开发者的人品。

d.客户不懂自己要什么，就是要自己看得爽，完全不管自己的用户爽不爽。我给你出了这么多钱，你做个网站空白处这样一大块一大块的。这里加个留言版，这里给我搞个投票…

3. 占便宜

a.你看，小王啊，我们网站聊天都有了，加个发语音的功能吧，这个肯定是需要的，也蛮简单的；我们官网的产品加个购买吧，就一个按钮，我知道谁买的就行了；我们网站都做好了，之前我们自己有个服务器环境都差不多的都是php，你帮忙部署一下吧，不要搞乱其他上面的网站。这种客户老是感觉加功能和拉屎倒茶一样简单。还理所当然 “我就是加这么一点，你帮我个忙” 或者责备 “项目给了你这么多钱，就这个小忙都不帮”

b.这个App真的非常简单，我们就不需要原型设计这个阶段了吧。直接开发，就按XXX直接抄过来，这样这个阶段钱我们就不出了。哦！你不懂是吧？要不要我再给你讲一遍？

总之，一般需求方问题总结起来就是：把自己局限的产品认识强加到开发者头上，不知道自己到底要什么。然后各种压榨成本把本来具有生命流程的软件质量都寄托于1.0版。出了问题就感觉开发者不负责。

开发者

1. 水平参差不齐，没有开发流程

最基础的一批人，就是觉得自己技术过关。所以接外包的态度是：你有什么项目啊，我这里什么都可以做的。没有具体流程，想怎么做怎么做。这是非常初级的外包者，这样的项目八成烂尾，纠纷不断。

2. 低估开发难度，没有进度安排

这种团队有了流程“产品原型->设计->后端前端 ->测试->售后”。但是安排不够，通常我们可以看到一个项目在产品原型、设计阶段都是好好的。结果到了开发环节各种问题就来了。这就是低估开发难度，没有进度安排带来的问题

3. 偷懒懈怠

开发者也是人，当然会各种偷懒。不然需要程序员鼓励师干嘛？当然也有一些是人品不好的，刷狡猾，忽悠客户不懂，一个企业展示网站自己收几万结果在猪八戒上面1000块给上面的人做了。

4. 接外包缺乏战略思维

不注意筛选行业市场，什么都做，导致什么都不精通，你做哪个方面就要做到那个行业外包的市场份额第一嘛，这才是有战略思想的外包事业。再高级一点，提高产品复用率，就做一个产品。

其他原因

项目层层外包，款项扣押严重。接单子的公司要扣一半左右，他们又二次外包出去，真正的开发者只拿到50%。我之前就碰到过一个微信公共号的开发，客户给了3w，结果转包两次，到开发者手里就只有7k。后来做完了才明白为什么客户老觉得开发者设计不满意，这也不行那也不好。



一个不成功的协作经历-我帮圈圈Android

2013年我做了一个校园社交网站“我帮圈圈”，需要开发Android。我们的技术是写java的没有写过Android。那时候招人来不及了，所以就搞了两套方案：一个是技术尝试边学边写；二是也去找有过开发经验的人来兼职写。最后找到一个一年多工作经验的童鞋。但是他不能保证每天都过来，所以干脆就让他远程兼职做开发。他做东西非常快，开始还是没有问题，结果过了个把月还是做不出来，原来他自己的公司任务加重了，所以就自动降低了我们这个App的优先级，没有时间做各种诉苦，最后还是烂尾了。

我们也有问题，那时候沟通工作也是扯淡，产品交流、工作管理就是用QQ。我们也没有做原型，直接都交给开发者，因为觉得简单啊。开发说不懂，然后这边就讲：“你不懂是吧？需不需要我再讲一遍。” 结果讲了四五遍还是不懂，做出来出入好大。后面反思：产品原型设计是怎么也不能偷懒的，就是要让开发者心里清楚各种情况，甚至要让他知道你们未来希望大大的。开发者是你的伙伴，不是小时工。



一个成功的协作经历-程序员客栈

程序员客栈这个产品到目前都是纯远程协作做出来的。最开始我一个人写代码，今年初上线。虽然自诩为全栈但是我知道自己是什么都会点但都不精通。现在我们团队iOS、Android、web+后端、设计、产品经理6个人一起远程协作，几个人都在大公司工作过，经验丰富，总算基本补齐了我们差的技能。

我们都知道做事情方向一定要坚定。但有时候到了局部，很多身临其境的推动力会让你稳不住阵脚，从而把队伍带偏犯错。在做我帮圈圈校园社交网站的时候发现学校里有很多外卖宣传单，我们那时也偶尔发传单宣传网站。所以就想：外卖是如此高频刚需，如果让大家点餐等饭的时间来社交吐槽，既有了SNS的盈利模式也增加了用户粘度，简直是天衣无缝的好点子。这个想法让我整整一夜没睡着，然后就傻里吧唧的开始做了。后面发现真的是扯淡，外卖做起来了社交不行了。外卖就是外卖，社交就是社交，一毛关系都没有，产品战线越长越容易奔溃。产品变动的过程中，那时我们按照传统的“产品经理->设计师->前端后端->测试”这样的流程来做探索，成本太大了，拖累死其他小伙伴，团队看到方向不坚定做外卖，都迷茫了，工作也累然后一个个的走了。后来我就给自己定了个规矩：就是当自己判断力不足的时候，一定不要瞎想点子，不要乱指挥。就像到了十字路口，都不知道前面的路了，总需要一个人先跑上前去看一看情况。需要有人当好这个探子，这样才是爱惜人力的表现。所以程序员客栈这个产品，前面遇到这样探索性的问题我就先顶上去做实验了。想也是，就好比你媳妇又做饭又搞家务又是工作，所以常常这个时候她就像是火药桶，一点就炸。开始不理解啊，后面慢慢理解了。这是累过头了，然后就乱。吴起兵法里不是也有写“凡行军之道，无犯进止之节，无失饮食之适，无绝人马之力。此三者，所以任其上令，任其上令，则治之所由生也。”大致意思是，带队要让大家休息好，吃得好，路要选得近。否则都不听你指挥了，不是故意和你作对，而是他们真的太累了。后来合伙人和我就总结出来了，产品的修改一定要慎重，不要拍脑袋。改之前一定要调研，屏蔽自己主观的意愿。多问几个为什么么。之前程序员客栈也有一个非常靠谱的后端小伙伴，我们不停的给他指派任务，结果他就不干了，东改西改，这都是不爱惜人力导致的，值得反思。当然我们团队也经历了一些人员的变动，由于我们经常和技术朋友交流，知道了解他们的情况，所以人员变动没有让我们的进度有很多耽误。

对于程序员客栈我们的大方向始终是坚定不移的：汇聚程序员，程序员来了为他们搞好服务。但是局部方向也经历了很多变动，这些变动让我们付出了代价。从“社区”切入，到“外包”切入，再到“解决方案”，最后才转到做好程序员的展示，见下图。当然，这里面看似产品形式上在不断变化，其实我们的骨骼并没有变化，不然这样的变动会导致项目流产。后来这些产品方向的问题得到产品合伙人的梳理才改善，定准了切入方向。
https://i.v2ex.co/P4q0n58f.jpeg


稳定的方向真的非常重要。创过业的小伙伴也许都有这样的体会：开始方向上偷懒，一说做什么就上了，结果一个阶段整天忙死，遇到困境然后又一闲好多天，不知道做什么，两眼望天花板。

我们方向定了之后再就是流程分工的问题了。由于人少人靠谱，我们就直接责任到人了，这个问题不是太严重。

还有一个进度问题，我们团队开发任务的安排基本是好的，不会太累，也不会闲着，这都得益于产品经理的良好安排。我们制定了详细的进度表，每周一次周会，大致这样：
https://i.v2ex.co/XK369rfM.png
https://i.v2ex.co/VkT58lu9.png


现在还发现一个问题，就是总结不够，比如产品经理提到了一个开发问题或者建议，记录到了tower，结果很多天过去了还是老样子。之所以出现这个问题主要还是“问题或者建议”没有转化为实际的原型，所以开发理解困难，理解了也不知道怎么下手。这是产品上太过于放手带来的问题。

远程工作需要做好经验总结，发扬成绩，纠正错误。只出主意，只摆问题不做具体产品原型，委派责任不清，或者有委托而无检查。这些都是远程协作中非常忌讳的，我们需要纠正。

在一步步解决上面的问题过程后我们做出来的Android 1.0直接就被豌豆荚评为了优秀。

工具层面：我们使用tower管理项目，用微信及时沟通。每周一用微信开会，本来准备使用skype但是发现远程会议光听声音不好，我们需要文字，为了方便大家翻看就用了微信，会后我们也在tower里面写会议总结。

当然，做远程协作最重要的还是人一定要靠谱，这是基础。以上我们能够很好的进行远程协工作，就是建立在这个基础之上。

我们远程协作其他的重要问题嘛。我觉得还是团队建设不够，各位小伙伴离太远，关心不了大家的生活，不能一起经常搞活动。待遇问题也需要逐步提高，这样所有人才团结。毛主席搞抗日民族统一战线的时候，并不完全是发动大家去打仗，而是把重要精力放在了“解决农民土地问题，解决工人阶级的待遇问题，解决学生自由抗议问题...”然后大家都团结起来打鬼子去了。邓小平搞改革开放，也不是一来就以经济建设为中心，而是先平反了好几年，肃反冤假错案。 所有团队组织一定要关心个人，解决个人面临的困难，一群人帮一个人肯定是办事既靠谱又快，然后大家才能一心发展，只有发展才能进步，只有进步才能更团结，把事情越做越好。



这次成功协作的经历也让我们有了新的总结。相比于前面失败的远程协作经历，主要还是表现在以下方面。最后也顺便总结一下，怎么做好远程协作？

1. 理解什么样的开发能远程协作

前期主力开发还是要掌握在自己手里，把部分责任清晰的工作用远程协作方式来进行：比如Android端或者iOS端等。不要全部放手外包项目，根据人员熟悉稳定情况，然后逐步安排所有远程协作开发工作

2. 开发者一定要靠谱专业

必须善于识别好的开发者。不但要看开发者的一时一事，而且要看开发者的全部历史和全部工作，这是识别开发者的主要方法。

3. 需求分工明确，规划清晰

总之需求、分工一定要明确，这样才不会有抱怨。项目开发流程以及进度安排等规划一定要清晰，这样才不会迷茫。

4. 使用先进项目管理工具，做好阶段性总结工作。力戒只安排，不总结。




最后发点小广告

欢迎加我探讨远程工作 或者也许能帮你远程搞定一个项目

[email protected]