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