初创企业如何选择技术外包公司，把控自己的项目

 1、 异地恋引起的沟通问题是否甚至大过技术问题？

 不会。你就用QQ就可以解决所有沟通问题。但可能在合同洽谈过程中，你需要面对面的交谈，察言观色，那是另外一回事。

2、合同中产品交付于资金交付的比例(334) 没有多大作用。原因很多，比如：

• 你其实不知道项目究竟进度到哪里了。比如：产品上线支付30%，看起来很舒服吧？但上线的标准是什么？一堆的bug我也可以扔到线上去呀！
• 承包方能够轻松的控制工作量，以保证其工作量不会大于你的付款额度。归根结底，你不懂行，太好骗了。
• 最后，大不了承包方后续的款项不要了。但给你扯一个烂摊子，你哭都哭不出来。

3、甲方可以通过哪些行动或者其他合作，真正给外包团队在产品功能实现、质量提升等方面带来帮助？从而最终对项目带来积极影响？ 我喜欢这一点。看得出来题主是用心在求教。 以下长文：

甲方首先需要做的是认真而细致的厘清需求，并形成文档。 这里的文档不是指你的APP界面，是用蓝色还是粉色打底，是用什么做图标，这个按钮放在上面还是下面……而是指你功能。比如：用户名不能重复。 但上述表达够简洁，却很不明了！ 我认为最好的需求文档是可测试化的（参考：《项目管理：文档可测试化》），你可以把“可测试化”理解为“可验收”。也就是说，你最后怎么验收这个功能？仍以“用户名不能重复”为例，大致应写成：

进入用户注册页面，注册一个用户，用户名为：自由飞 再次进入该用户页面，再次使用用户名“自由飞”进行注册 注册无法完成，弹出错误提示：用户名重复。

如果你觉得这样纯属有病，请再仔细阅读《项目管理：文档可测试化》。 如果觉得这样制作需求文档有难度，可以稍微降低标准，但切记：宁愿啰嗦一点，不要奢望心有灵犀。

然后，承认需求变化。拥抱变化不仅仅是说给程序员听的，需求方也一样。两种极端的做法都是没意义的：

• 非常仔细的制定需求，试图一次成功
• 完全不上心的发布需求，开发过程中随意的更改

前者，程序员当然非常欢迎，但这几乎是不可能的；后者，程序员会在心里把你艹上一万遍啊一万遍！ 最佳的做法，就是承认需求变化。换言之，你可以改需求；但你改了需求就应该加钱加时间！ 程序员最不能接受的其实是改了需求不认账！代码的改动不是你想象的那么容易的，你以为就像在word上复制粘贴一样，是吧？ 完全不是这样的。你可以把修bug当做需求更改，代价是一样的：

在我花了两周的时间找到一个bug的位置之后，我以为我终于明白了为什么会说：“维护和开发的花费比是80:20”。但这只是我以为——现实更加残忍：差 不多一个月后，我又花了一个星期的时间，找到了另外一个bug的根源，正是我fix前一个bug所产生的。我泪流满面，有没有？脑子里一下就蹦出个词： “按下了葫芦浮起了瓢”！总之，如果fix前一个bug就会导致后一个bug；如果fix后一个bug，就会导致前面的bug。 引自：架构之路（一）：目标

但这样又引申出一个复杂的问题，预算增加和项目延期。这无疑是甲方最害怕的事情，好比买一个东西，“不怕不识货就怕货比货”，我货比三家总不会吃多大亏；但现在说好的价钱，东西买回来用了一半，你说得加钱？！这事撂谁心里都不舒坦。

就我的经历来看，比较好的解决方式就是：按人天计价。外包公司给你出人开发，一个人一天多少钱，最后据实结算。 当然，你会担心他们磨洋工。所以一个更优化的配置是再从另外一家外包公司雇（或者通过猎头招聘）一个项目经理过来负责管理。 一般来说，基于正常的职业道德、以及管理者和被管理者之间的天然矛盾，他们不太会串通，至少不会过分。如果这样他们都沆瀣一气，你真的要反思一下自己的人品了，是不是自己压榨得太狠了？

最后，特别重要的一点：仔细验收。我看到太多这样的甲方，验收的时候马马虎虎敷衍了事，反正还有一笔尾款押着的嘛！ 所以验收就是懒洋洋的坐在沙发里，看乙方在电脑上“啪啦啪啦”的演示而已；如果不是自己的事，晚上再去卡拉OK洗个脚，就OKOK啦，皆大欢喜。 等回头上线用起来的时候，左边一个问题，右边一个bug，简直没法用，赶快给乙方打电话，乙方……实在搞不定大不了尾款我不要了！ 当然，成功验收的前提是什么？回到最初我们说的：认真而细致的厘清需求，并形成文档。没有文档，你怎么验收？你也只能看着乙方“噼里啪啦”的给你验收一通而已。

总结一下，就是几点：

1. 自己要花心思明确需求，尽可能的减少误会和返工
2. 确实不得不返工的，要给人家返工费
3. 最好在大框架下，按人天据实结算
4. 可以的话，引入第三方管理监督
5. 认真细致的验收