老铁在这里贴一个小游戏。
早期沟通
打完电话的第二天，和外包项目的需求方简单沟通后，他们发来了十几个App界面的样本，大概是CRUDDemo，软硬件结合，通过App界面显示硬件信息和统计，以及相关信息。功能不多，但开发时间有限。要求月底前完成App演示和后台系统，赶去参加一个会议宣讲会。对方一再强调项目的优势:走在前列，资源配置齐全，除了...没有软件技术团队，目前只有硬件团队，这里也只有两三个零星的软件团队，但是重用起来是难以忍受的。
小贴士:
我在这里犯了第一个错误。我以为只是一个演示，但背后是一个完整而庞大的工程。对项目的规模、类型、复杂程度的错误评估，让我没有很好的掌控全局，没有考虑到整个项目的细节，导致了后来的很多问题。
在评估一个项目时，我们通常会低估项目的复杂程度，高估自己处理一些琐碎细节的能力。
建立一个团队
项目不能一个人进行，因为涉及到app、Web、后台，所以我先找了一个靠谱的后台开发朋友，然后在项目正式开始前我会一起找和确定其他小伙伴。
小贴士:
在外包合作过程中，要优先寻找可靠、扎实、有责任心的人。大部分外包项目在技术上并不复杂，但由于合作方式的特殊性，大部分都是异地异步工作，需要责任心强的人。否则项目开发时，往往找不到人，或者沟通缺乏反馈，非常被动。
项目报价
说到项目，必然要谈到钱。关于报价，对方对两种合作方式都很开放，一种是技术入股的形式，一种是外包报价的形式。我觉得因为是第一次合作，所以采用第二种方式最安全。毕竟离开包包是安全的。
因为是第一次没有外包经验，所以很不放心。我赶紧上网查了一些外包报价方法和注意事项，最后决定按照团队成员的日工资乘以一个系数。不出所料，他们觉得贵，整个合作就僵持在那里。介绍项目的朋友答应调解，然后...仅此而已。
小贴士:
不同外包项目的公司和项目背景都不一样，技术入股需要谨慎。当然现在外包平台很多，一切基本都是精简规范的，直接关系到项目和钱的交易。这种问题会越来越少。
按照故事的正常节奏，我最初的外包经历就这样夭折了。大概过了两个星期，事情有了转机，对方负责人打来电话，说要当面沟通。然后技术总监和老板一起赶了过来，介绍了半天项目的背景，公司，技术团队。我意识到这个项目不仅仅是一个演示。最后约定另找时间详细沟通需求，评估报价。
沟通需要报价的时候，对方要一个套餐价格，不考虑每天每个人的算法，而且这个项目很大，会分几期开发交付。第一阶段，双方想以磨合的态度合作。意思是你想都别想要高价。先便宜点第一次合作，先感受一下，感觉好了以后再说。
因为是我第一次接外包，经验不足，所以在磨价格的过程中答应了对方的要求。当谈判完成，确定报价后，发现第一次只给了每人每天一半的报价，我们才意识到我们还在图森。
小贴士:
这是第二个错误。在报价过程中，要尽可能坚持自己的报价条件和底线。如果对方说的是最低价，我们绝对不能给出一个自以为是的最低报价，否则很容易导致菜市场讨价还价，最终和我们预想的相差甚远。可以认真交流，谈钱一定不要图省事。价格贵也是质量的保证，象征性的可以少一点，但是范围一定要控制。
签合同
反正既然报价给了，那就本着学涨姿势的态度来做吧。当我需要起草一份合同时，我没有看到合适的。最后在网上找了个软件外包开发合同模板，大致改了一下，就要用了。
外包合同需要注意的事情很多，所以这里只是简单的说一点:合同的条款一定要一条一条的过，这样才能保证你能充分的掌握和理解每一条的内容和背后的含义，保证你自己不挖坑，当然最好不坑对方。
小贴士:
当然，现在外包行业越来越成熟，外包流程和项目也越来越规范。像云沃克这样成熟的众包平台也应运而生，不再需要合作双方私下签订协议。服务者和需求者都可以专心做项目，把一些琐碎的事情和问题留给平台来规范管理，省心很多。
我签了合同，去了另一家公司。中午天热的时候我去兜风了。下了车，看到太阳快落山了，高楼大厦都不见了，看到的地方都是低矮的房子。舅舅舅妈懒洋洋地摆起了大排档。我的第一感觉是我从深圳到了县城。对方是传统公司/工厂，意思是互联网，软件开发等。可能是对牛弹琴。如果对方没有专业的对接人员，这个项目的进展会非常艰难，接下来的事情也出乎我的意料。
小贴士:
尽可能多的了解对方公司、项目以及相关人员的背景。如果对接人员素质与项目不符，尽快向合作方提问，把问题抛给对方。不要让这样的问题影响项目进度和后续工作。
签订合同后，我们需要再次详细沟通需求和评估开发计划。我和我的队友去另一家公司开会。在沟通需求的过程中，对方必然会添加需求，甚至是独立模块，相当于莫名其妙的增加了工作量。对方含糊其辞，说这是很重要的模块。没有这个模块，就不是一个完整的系统。一开始以为这是大家默认知道的事情。好在我早前起草合同的时候，在合同的开发内容部分写了主要功能和相关模块，很快就把合同给对方看了，对方无言以对。后来继续沟通是增加时间、人力还是精简职能。
小贴士:
在拟定合同的时候，一定要把开发内容和主要功能写清楚，尽量详细准确，避免后续因为添加或更改功能而扯皮。毕竟说没有证据，白纸黑字，才是硬道理。
项目开始
签完合同后，按照合同，对方需要支付30%的工程款作为首付款，因为这些在合同里都写的很清楚，整个付款过程非常工整。唯一的问题是对方需要提供发票，然后找朋友公司开。
一般软件增值税印花税票的税点是6%，税费也会是一笔很大的支出。报价时最好沟通税务和发票相关事宜。
小贴士:
最好等到收到预付款或者一期工程款后再开工，避免不必要的麻烦。
报价时要考虑税收和发票。现在众包平台已经大多解决了这个问题，用户再也不用担心这个了。
项目准备
当所有相关流程完成，需要对方提供产品原型时，对方就是屁都拿不到，半天什么都提供不了。我们有困难跟他们普及了设计稿和原型稿的区别后，他们疑惑地说:这种事情不是应该由你来处理吗？我必须向他们解释清楚，并向他们提供几个原型示例和原型工具。
回过头来看，整个项目过程中，对方除了一个非常粗略的概念性需求文档，没有输出任何文档。在前面沟通需求的时候，他们建议对方给我们整理一下相关的需求文档。他们说这样的事情都在自己脑子里，没时间整理。
没有输出文档，后续工作就没有依据，所有的依据都只是我们在详细沟通需求时自己编制的需求清单文档。
小贴士:
文档的输出非常重要。详细的需求文档和设计文档是后续项目开发的必要工具。没有这些，整个项目将无米之炊，这些将是项目开发后验收的标准之一。
项目前期
在项目正式开始之前，对方又出了一次幺蛾子。对方的对接人员从技术总监换成了另一个初级技术总监。估计他们内部没有仔细沟通，直接让我们和他对接。第一句话是找个时间沟通需求。我不知道这里的细节。拜托，细节在你老板那里，求我们心理阴影区。...
所有输出的文档只是我和第一个对接人沟通时整理的需求清单文档，也就是说是第一个对接人陈述的，被我们消化的。如果第二次对接的人以此为参考，对需求的理解会因人而异，项目变数更多，前景堪忧。考虑到这一点，我们必须再次回到过去，详细沟通我们的需求。
小贴士:
项目对接人的变更是一个意想不到的问题，也说明了上面提到的文件的重要性。越早形成详细清晰的文件，越快直接决定项目后续的走向和进度。
在等待原型的时候，暴风项目出现了新的纰漏:原本我们只需要负责软件系统开发(包括各个App、Web管理系统、后台系统)，对方负责硬件制作和硬件系统开发。后来他们的硬件开发人员走了，想把硬件系统开发交给我们。我们不假思索地拒绝了。
小贴士:
虽然接手硬件有利可图，但这不是我们团队的强项，需要另找专业人士，相当于给团队和项目增加了风险和不确定性。专注于自己擅长的事情，不为团队和项目积累风险和不确定性，也是一种责任感。
写在最后
我还没写项目正式开始，但是已经写了一篇长文了。后面我会记录项目开发过程中的坑和教训，未完待续。欢迎交流。