前言
我们已经做了1000多项目,经常被朋友们问的问题是,技术外包怎么防止被坑?
朋友们反馈的坑,基本可以分为以下几类:
1:报价有坑:一个项目,报价从1万到10万都有,完全不知道谁靠谱
2:可信度有坑:半途中突然失联,连钱都不要了就是找不到
3:进度有坑:3个月的计划6个月才做完
4:可用性有坑:做完了一大堆bug,完全无法用
在我看来,所有的坑都来自于信息不对称。
1)企业方想要的产品 vs. 开发者以为的产品

2)企业方以为的工作量 vs. 开发者真实的工作量

3)外包方的初始承诺 vs. 外包方的真实信誉

有这么多信息不对称,难道还不能准备一个弹弓吗?
接下来喵姐我就和你说说,作为企业方或者产品负责人,我们应该怎么做准备,防止被坑(或者坑人)
一、了解一个产品的流程和结构


二、整理清楚产品文档,再去询价和工期
这是降低对产品和工作量的理解差异,确保之后开发成功的最基础和最重要的工作。
一个能够得到较准确报价的产品文档应该包括这些内容:
1)产品架构图

2)产品结构图

3)核心流程图

4. 功能拆解图

二、尽量找到有良好口碑记录的外包方,并去核实口碑的真实性
几种方式:
1)最推荐:在公正客观的第三方平台上,找到有真实交易记录的第三方评价。
如何判断评价是否真实:
-
a. 评价详细说明了哪些地方值得推荐,该开发者的特点是什么,自己的观点是什么
-
b. 不是千篇一律的”好“,或者无意义的评价
2)通过朋友推荐,尤其是开发者推荐的靠谱的外包商
3)通过朋友推荐,尤其是有过真实合作经验的朋友推荐的外包商
在对比的时候,最好可以从 专业,沟通,以及进度控制能力三个方面来考量。
三、尽量找有类似产品开发经验的外包方
比如你要做一个电商类产品,那么最好外包方就已经有此类产品的开发经验,这样确保对方熟悉所需的技术架构,能够少踩一些坑,更高效地开发。
四、一定不能偷懒不管产品进度,起码每周要进行进度跟踪
即使找到了一个靠谱的外包合作方,想要一劳永与也是不可能的。
每周至少一次的进度会议,了解各个成员的进展,如果有意外,可以尽快了解然后安排对应的计划。而不至于到要上线的时候,才发现进度延后,从3个月拖到了6个月。
五、一定要经过专业测试才能确定交付结款
遇到很多次,企业方为了省钱干脆就自己做测试,找几个其他部门的员工来自己测了就上了。殊不知,这样产生的经济损失将远大于做完专业测试后才上线!
如下图,作为产品设计方,你最容易想到的一定是典型最短路线1,这条线自己是很容易测试到的。但用户却是会遍历所有可能路径 2 - 5.
一旦有一条逻辑不通,用户就可能因为无法实现核心业务而离开你。

而产品一旦上线,要修改就一定有时间延迟:
- web 产品的修改起码有1天,一般在凌晨用户最少时才能修改;
- APP类产品的修改依据审核时间而定,1-7天不等。
在这段时间内,问题越多,用户离开的风险就越大。因此,上线前做好专业的测试,短期看起来要花多点时间,多点钱,长期看来却是真正省钱和省时间的做法。
测试完再上线,上线后才结算。这样能够确保结算前就能尽量解决外包方留下的坑,避免后期撕逼,影响产品的发展。
基本上,做到以上几点,能够很大程度上避免踩坑,降低风险,确保开发的质量和进度~
在我看来,所有的坑都来自于信息不对称。
1)企业方想要的产品 vs. 开发者以为的产品
2)企业方以为的工作量 vs. 开发者真实的工作量

3)外包方的初始承诺 vs. 外包方的真实信誉
网友评论