机缘巧合，近距离接触了一个比较坑的外包团队，长了一丢丢扯皮的经验，写个小结，填坑。
了解对方开发情况
提前申请好 fabric、Bugly 等集成监控工具的账号，让对方开发过程中全程都集成这些工具，develop 版本和 release 版本用不同的 id，这样可以区分出 Bugly 中显示的崩溃是 release 版本中影响用户体验的 bug，还是开发过程中程序员为了测试故意触发的 crash。
Bugly 是可以精确记录崩溃发生的各种信息的，包括设备型号、系统版本、触发崩溃的代码等，这样在无法复现 bug 的时候也有证据和对方谈，不至于让对方赖账。
相对 Bugly 次日才能给出统计信息，fabric 可以做到实时统计，根据开发版本的应用活跃程度，可以对对方的开发过程有一个大概的估计，至少当你看见 fabric 显示 app 没有任何动静（app 启动次数、session length），那肯定对方是没在进行客户端调试的。
谨慎考虑技术方案
有些外包团队的技术人员，是毕业之后培训两三个月就上岗了那种，能力比较成问题，在技术的选择上也会很随意，可以尝试从以下几个角度来去把控：
- 通过 git 来时常查看他们的代码提交记录，不要让他们每次都把代码打包发过来，这样方便项目后续交接给其他人继续开发。
- 对于他们大量使用了，而自己又不太熟悉的第三方框架，多去查一下，看看这些框架有没有不成熟、或者已经不再维护的问题，否则框架本身出现 bug，后期可能一时移除不掉，他们又没有自己修改框架的能力。
- 技术上最好选择通用、最好可移植平台的方案。比如同等情况下，在 Win 桌面端尽量选择 C++ 而不是 C# 去开发，后期可以移植其他平台；后端尽量用 C++ 或者 Java 去实现，否则他们用 PHP 做了之后，以后找人接手项目也比较麻烦。
- 假如想要用 React Native 去做客户端开发，要考虑这样是不是相对原生开发可以省下接近一半的费用？如果可以的话，后期找人接手这个 RN 项目，短期是不是可以找得到会 RN 的人？
有效传递反馈意见
一方面，对方可能会有赖账的想法；另一方面，有些程序 bug 确实是偶发性的，不好复现。于是就可能出现，你说程序有问题，对方不承认的问题。所以要多注意：
- 在反馈 bug 的时候，通过 Bugly 等工具，告知对方，出问题的代码在哪
- 在不至于导致崩溃，但某些机型上又表现不正常的时候，尽量在测试时，全过程录视频，给乙方反馈的时候，直接截取出那一部分视频，就不存在推脱责任的问题
产品设计问题与 bug
在和外包团队接触过程中，遇到这样一个问题：有些动态的东西，比如滑动列表时隐藏搜索框，这些相对细致的内容，可能无法在原型设计中得到充分的体现。
而你又无法依赖对方的人员素质，来让他们自行优化这些细节。就要充分考量实际开发情况，在原型不方便体现细节的时候，用文档或其他方式进行充分的说明。否则最后产品做出来，你觉得某个地方不合理，是他们应该修复的 bug，但是由于原型、设计稿没有体现，他们可以认为这些是需求变更、二次优化，再找你收一次钱。
签订合同的时候，要严格定义出“交付项目的要求”，项目还没交付的时候，产品设计有问题（交互、逻辑等）算是双方沟通不够深入，项目交付之后，任何改动都是新需求，都要再算一次钱。又比如所有功能都开发完成，但是 bug 很多，用户体验极差，可不可以交付项目；以及开发过程完成后，需要产品成功上架 App Store 与国内各大安卓应用商店，否则你这边觉得东西做完了，之后屡屡被 App Store 审核团队拒绝，也没地方说理。
后续遇到新型扯皮，再继续更新……
