今天路由器爆炸了，完全无法工作了，只能直连光猫来上个网发点感慨。
这里谈论的外包是有约束条件的，不是外包公司，也不是外包公司的员工，而是一个正常工程师利用业余时间，晚上下班干点活，赚点外快的那种。
创业公司在项目开始，为了节约成本，一般会有懂行的核心人员来完成主要架构工作，把项目分好几个模块，有些模块像中国地图一样利用天然的山和河来分界，就比如服务器和APP之分，而我们就决定把APP的界面部分外包出去。
由于APP要控制硬件，所以APP的服务器接口以及和硬件的通信及协议都由我来写了，刚开始我认为凭借我对android的了解以及对项目的整体把控，即使请外包人员来做界面、与服务器数据交互，就不会有风险和问题，但是现实总是无情的打脸。
遇到的问题：
1、外包只愿意按图索骥，不会给你操心需求和逻辑
由于原型图是做市场的哥们兼职，我和MCU的哥们也只评审一下，其实我们三个都不是专业的产品经理，另外时间也不是很够，大家都忙的要死，抽出空来评审一下，也就只能把大问题解决了，真正开发中还是会遇到的各种细节问题，这些问题会造成2个后果
a) 流程明显不通顺。这会导致外包开发人员进度停止，如果是有自己的APP人员从需求到原型都在项目里的话，他会明显在前期提出更合理的流程。（我虽然也是老司机，但我重点在服务器和整体架构啊，精力和心思不全在这里）
b) 流程和操作细节通顺但是不符合用户操作习惯。这时候如果遇到老司机和负责人的外包，他会给你指出来让你修改，但如果遇到新手或者多一事不如少一事反正拿钱干活，你们让我干什么样子就什么样子，后期改动再加钱的外包，这样无疑造成了时间和金钱的成本。
为什么自己的员工就会负责的指出这些问题呢？
因为自己的员工一开始就明确的知道这个工作的开发和后期维护都是由他来做，如果前期他埋了太多的坑，后期维护的时候以及BUG率过高，都会给他带来一定职场危机，所以只要是个思维逻辑清晰正常的人，都会选择在前期认真负责的给你爆雷。
2、当确定技术方案或具体实现细节时，外包人员不在场，导致技术方案确定延期
曹刿说，一鼓作气再而衰三而竭，在做一件事的时候不能一鼓作气拿下全部，总有一种拖拖拉拉或者头上有把剑悬着的感觉，如果你适应了这种违和感，那么你离低效率和拖延症不远了。
为什么在确定方案的时候一定要开发人员在场？
因为你帮他规划的方案，在他那里大概率会走样，层级多的公司CEO颁布的各种新制度，最终到一线员工能执行百分之20就算不错了，创业团队肯定不能和大公司相提并论，但是都会面临这样的问题。
如果直接确定了技术方案给具体开发人员，那么就又会造成4个问题：
a) 开发人员的思维定势和擅长方面和你设计人员不一致，你觉得A方案简单，但是对于他来说B方案却更快一些。如果你强制让开发人员用A方案，对于项目来说，花费的时间成本更高，还容易埋下BUG造成隐患。
b) 对一个有自己主见并且恰好和你思维观念不一致的老司机来说，他会有抵触情绪并且还会尽力说服你更换技术方案，而他可能只站在自己的角度考虑，如果你改了方案可能涉及到你的服务器接口、涉及到你和硬件的交互逻辑、涉及到你控制服务器的命令转发等一系列麻烦蛋疼的事情。
c) 从外包人员的角度来说，他不思考照你这样设计的做，并且没有在实际操作的时候提出意见，哪怕你真的是在这方面经验十足，“人甚至不能同时踏入同一条河流”，每次具体开发的时候是否真的完全一样？这样会造成外行指挥内行的困境，没有充分发挥实际干活的人的主观能动性。到时候出问题他也不担责任，等项目最后才爆出这个雷的时候够你喝一壶了。
d) 从培养下属的角度来说，你剥夺了下属的独立思考能力，不利于下属成长，更会造成你大事小事事必躬亲的后果，让你烦不胜烦，沉浸于每天的忙碌之中无法自拔，无法进步，而且有可能最后还会像诸葛亮一样短命。
3、沟通成本太高。
特别是创业前期，又写代码又做架构还要时刻关注外包人员开发的各种细节，身心俱疲。你写好硬件的接口之后，写上注释给他调用，过程和逻辑讲解好几天，复杂的逻辑和操作，从来不关心，写到哪里问到哪里，你为了配合他要不停的放下手中的工作和思路给他讲解，为什么要放下自己的事情优先解决他的事情，因为工作中有一条原则，当你和别人配合一起完成的工作，要优先处理两个人沟通的部分，不耽误对方的进度，以免造成项目延期。当你沉浸在自己的世界里写下某行你自认为牛逼到能进微软谷歌的代码却不理别人时，他可能一封邮件把你告到经理那里去，让你这月的奖金泡汤。
