谈及外包的经验，我的第一次外包在头两年的某一天，和她一起去商场的时候，接到一个朋友的电话，朋友给我介绍了一个大项目。 需求少，钱少，难度低，口气不小，我很心动，想赚easy money。 稍后再看，这次外包踩了大小坑，想好好记录。
前期沟通
电话第二天，与外包项目的用户轻松联系后，他们寄来了十几张App接口的样品。 也许是软硬件结合，通过App接口展示硬件信息和数据统计，以及相关信息的CRUDDemo。 功能不少，但开发时间有限，要求月底前完成App Demo和后台系统，参与会议展示。 对方多次强调项目的优势。 正好处于风口，资源配置各方面都很齐全。 除了没有软件技术团队外，目前只有硬件团队。 软件方面零星只有两三个，但不能再利用。
Tips:
在这里我犯了第一个错误。 我以为只是Demo结束了，但它背后完全是一个巨大的项目。 由于项目的大小、类型和复杂性的错误评估，我很好地控制了整体，没有考虑整个项目的详细情况。 结果，后来引起了很多问题。
在评估项目时，我们通常会低估项目的复杂性，高估我们处理琐碎细节的能力。
组成队伍
要推进项目，一个人是做不到的。 因为每个最终APP、Web和后台都有关系，所以我首先找了可靠的后台开发朋友。 然后，在项目正式开始之前，一起寻找并确定其他合作伙伴。
Tips:
在外包合作过程中，优先寻找可靠、技术过硬、有责任感的人。 虽然外包项目大多技术不复杂，但由于合作方式的特殊性，经常异地异步工作，需要有较强责任感的人。 否则，在项目开发过程中，如果找不到人，或者交流没有反馈，就会变得被动。
项目报价
关于项目必然是谈钱，但是关于报价，对方开放有两种合作方式。 一种是技术入股方式，另一种是外包方式报价。 因为是第一次合作，所以我认为采用第二种方式是最安全的，但最终还是把袋子掉了比较安全。
因为是第一次外包，所以很兴奋。 我马上在网上查了外包的报价方法和注意事项，最终决定根据团队成员的工作日薪乘以系数进行报告。 没想到，他们觉得高了，整个合作都僵在那里。 介绍项目的朋友答应去调解，之后.接下来就没有了。
Tips:
根据外包项目的公司、项目背景，遇到技术准入必须慎重。 当然现在外包平台很多，一切都基本上是流程化、规范化的，直接是项目和钱的交易，这样的问题也越来越少。
按照故事的正常节奏，我的外包在第一次体验中夭折了。 两周左右，转机来了，对方的负责人打来电话，说要我们当面沟通。 然后，技术负责人和社长一起来，介绍了项目的背景、公司、技术团队的情况半天。 我意识到这个项目不仅仅是Demo。 最后，我们承诺找时间详细传达需求，评估报价。
olor:rgb(51,51,51); font-size:16px">等到沟通完需求要报价的时候，对方想要一个打包价格，而不管每人每天的算法，又扯到这个项目很大，会分几期开发交付，第一期想让双方以磨合的姿态来合作。意思是你们也别想着开高价了，我们第一次合作先便宜点，磨合一下摸摸底，觉得不错的话后面合作再谈。因为我也是第一次接外包，缺乏经验，在这个磨价的过程中，脑子一热不小心就答应了对方的要求。等到协商完毕确定好报价，发现只有第一次给出的每人每天报价的一半，才意识到我们还是图样图森破。
Tips:
这里是第二个错误，报价过程中要尽可能坚持自己的报价条件和底限，如果对方说出最低价格这种话，绝不能给出一个自以为的最低报价，不然就容易弄成菜市场的讨价还价，最终会被磨的和自己预期差距很远，可以跟对方认真沟通，谈钱一定不能图省事。价格贵也是质量的保证，可以象征性地少一些，但务必控制范围。
签订合同
不管怎么说，既然给出了报价，本着学习涨姿势的态度，咱就干吧。需要拟订合同时，没看到合适的，最终在网上找了一个软件外包开发合同模板，大致改了一下，将就用着。
关于外包合同有很多需要注意的地方，这里就只简单说一点：合同的条款一定要一条条地过，确保自己能完全掌握和理解每一条的内容及背后的含义，确保不要对自己埋有坑，当然也最好不要坑对方。
Tips:
当然现在外包行业发展越来越成熟，外包流程和项目也越来越规范，也诞生了像云沃客这种成熟的众包平台，甚至不再需要合作双方私下签订协议，服务方和需求方都能把精力专注于项目上，而把背后的一些琐碎之事和问题交由平台来规范管理，省心很多。
签合同远赴对方公司，中午正热时坐了个顺风车过去，下了车一看太阳都快下山了，高楼不见了，眼见之处都是低矮的民房，大爷大妈懒洋洋地支起了小吃摊，第一感觉是从深圳到县城了。对方是一个传统的公司/工厂，这意味着什么互联网、软件开发等等都可能是对牛弹琴，如果对方没有一个专业懂行的对接人员，这个项目的进展将会非常艰难，后面的事情也正出乎我所料。
Tips:
尽可能详细地了解对方公司、项目情况及相关人员背景，如果出现对接人员素质与项目不相符的情况，尽早向合作方提出疑问，把问题抛向对方，不要让这种问题影响项目的进度和后续工作的开展。
合同签完，需要再次详细沟通需求和评估开发计划，我和团队同伴远赴对方公司开会。沟通需求的过程中对方少不了加需求，甚至是一个独立的模块，相当于工作量莫名就多了几分之一。对方含糊其词，说这是一个非常重要的模块，没有这个模块就不是一个完整的系统，当初以为这是默认大家知道的事情云云。好在先前拟订合同的时候，我把主要功能和相关模块都写在了合同的开发内容一款里面，赶忙把合同拿给对方看，对方哑口无言，后面继续沟通是加时间、加人力还是精简功能。
Tips:
拟订合同时，一定要写清楚开发内容和主要功能，尽可能详细准确，避免后续因为添功能、改功能扯皮，毕竟口说无凭、白纸黑字才是硬道理。
项目开始
合同签完，按照合同约定对方需要先支付 30% 的项目款作为一期款，因为这些都是明确写到合同里，整个付款过程中很利索，唯一的问题是对方需要提供发票，后面找了朋友公司代开搞定。
软件增值税票税点一般是 6%，税费也会是一笔不小的支出。最好在报价时沟通好税费及发票相关事宜。
Tips:
最好等到预付款 or 第一期项目款到账后再启动项目，避免不必要的麻烦。
报价时将税费和发票考虑进去。现在众包平台也大多解决了这个问题，用户不必再操心这个。
项目准备
等到相关流程都走完，需要对方提供产品原型的时候，对方硬是石滚碾不出个屁来，憋了很久什么东西也提供不出来，我们艰难地跟他们普及了设计稿和原型稿的区别后，他们疑惑地表示：这种东西不是应该由你们来搞定吗。只好边跟他们说清楚，边给对方提供几个原型示例和原型工具。
回过头看看，整个项目过程中对方除了给出一个非常粗糙的概念需求文档，任何文档输出都没有，在前面沟通需求时提出让对方把相关需求文档整理给我们，他们表示这种东西都在自己脑子里没有时间整理。
没有输出的文档，后续的工作便没有了依据，而所有的依据，也只是在详细沟通需求的时候，我们自己整理的需求列表文档。
Tips:
文档的输出非常重要，详细的需求文档与设计文档是后续项目开发中的必备利器，没有这些，整个项目成了巧妇难为无米之炊，而且这些也会是项目开发完毕验收的标准之一。
项目前期
项目还没正式开始，对方又出幺蛾子了，对方对接人员由技术主管变更为另一个下级技术负责人，估计他们内部都没有仔细沟通过，就直接让我们和他对接，上来第一句便是找个时间沟通下需求，这边不太清楚细节。拜托，细节都在你们老大那里了，求我们心理阴影面积...
所有的输出文档只有在我和第一任对接人沟通需求时，整理的需求列表文档，这意味着它是经过第一任对接人陈述并由我们消化整理的，而第二任对接人如果再以它为参照的话，这里面的需求理解因人而异，项目变数更多、前景堪忧。想到这些，我们只好再次奔赴过去详细沟通需求。
Tips:
项目对接人的变更算是一个意料之外的问题，也更显前面所述的文档的重要性。越快越早地形成详细清晰的文档直接决定了项目后续的走势和进度。
在等原型的这段时间，风雨飘摇的项目又出了新纰漏：原本协商好的我们只需要负责软件系统开发（包含各端 App、Web 管理系统、后台系统），对方负责硬件生产及硬件系统开发，后来他们硬件开发人员离职，想把硬件系统开发这一块也交由我们。我们想都没想，就直接拒绝了。
Tips:
尽管接下硬件这块又有钱赚了，但这不是我们团队的强项，需要另找专业人员，相当于给团队和项目增加风险和不确定性。专注于做自己擅长的一面，不为团队和项目累加风险和不确定性，也是一种责任心。
写在最后
还没写到项目正式开始，就已经罗罗嗦嗦一大篇了，后续记录一下项目开发过程中的坑和教训，未完待续，欢迎交流。