大人
作者
To B产品外包的那些坑,你知道吗?
857
2017-09-18 09:51
文章摘要:产品却是一个长期不断优化迭代的过程,因此产品的外包这其中存在太多值得思考和总结的问题。

      这些天,又在与外包团队进行各种产品问题的讨论纠缠,苦恼不堪。近些年由于To B SaaS市场、互联网创业发展迅速,产品外包在软件领域日益兴起,很多创业公司、传统IT企业、集成商、运营商都纷纷参与到产品外包的价值链中,有的扮演甲方发包项目,有的扮演乙方承包项目,有的则前脚作为乙方承接项目,后脚就作为甲方转包给下家。然而,相比项目的一次性而言,产品却是一个长期不断优化迭代的过程,因此产品的外包这其中存在太多值得思考和总结的问题。

       作为深处产品外包七八年的老兵,今天就围绕To B软件类产品外包存在的诸多矛盾,给大家分享下我在此过程中所经历的一些坑,其中涉及资金与服务的矛盾、产品与项目的矛盾、团队能力的矛盾、契约与人性的矛盾、沟通协作的矛盾等等。希望能给一些初入此行的产品经理们一些启示,引发一些共鸣。具体如下:

资金与服务的矛盾

“给多少钱,办多少事”在基于交易的外包中,这条真理常挂在嘴边,却也常纠缠不清。一切服务都和钱挂钩,给多少钱,提供多少服务,准备多少资源。为了避免扯皮,甲方往往会在合同中对服务有非常明确的要求,它不仅包括基本的功能需求、交付时间、产品质量验收标准,还包括客观的管理要求,即外包团队人数、人才能力(面试评测)、人才绩效考核标准,以及产品开发过程中有关设计、运营、维护等相关服务的详细要求。然而,理想很丰满,现实很骨感,产品外包中资金往往和服务不能划等号。主要有两种情况:

钱给少了,索要的服务过多

一方面,很多企业或者创业者,在产品外包时,总是会极力压低预算,能省则省,但他们的需求却有增无减。谁都想要价廉物美的商品,这当然可以理解,但万事都得讲个“度”。产品在研发过程中,需求变化在所难免,如果和乙方协商处理好就不存在冲突。但有些甲方不仅功能贪多求全,而且在签完合同之后,完全不考虑乙方的感受,想方设法的追加需求索要服务,甚至自己内部的汇报材料撰写,或者与项目不相干的事情也让乙方去做,这一点在政府客户中比较常见。这样的情况,对于乙方,有时候迫于客户关系,可能会做一些,但这样的需求多了,且收益包不住成本的时候,要么选择拒绝,要么偷工减料降低质量。如果甲方逼得太狠,乙方精力全在扯皮上,心累了直接撂挑子走人。

另一方面,也不乏很多外包团队,初期为了给自己赚吆喝,为公司业绩增添案例,从而不惜报超低价,只为能够拿下项目。一旦和这些厂商建立合作,后期风险可想而知,他们如果发现赚足了吆喝,且出现“入不敷出”的情况,就会立马减少投入,甚至消失的无影无踪。

钱给够了,得到的服务不够

相反,有时候甲方的资金很充足,但因为乙方为了追求利益最大化,主观上偷工减料;或者因为内部能力不足、资源调配,从而降低了服务标准,造成产品无法顺利完成。例如,乙方外包团队往往手里不可能只做一个项目,他会同时承接多个项目,这时候,乙方会根据项目的规模、紧急程度、重要性等,对资源进行重新分配,将好的资源分配给重要的项目。所以即使甲方给的钱充足,但和其他项目比起来,依然没有足够吸引力,所以乙方会对原本甲方的项目实施资源减配。这样的话,有可能原有项目上能力强的开发人员就有可能被抽调走,留下的人员还会存在被其他项目复用的情况。本来专注于一个项目的工程师,却被其他项目牵扯精力,可能一天只有0-10%的精力在甲方产品上,而且会不断被打断,影响工作效率,整个团队的能力和效率会下降一大截。即便是驻点在甲方现场的开发形式,也存在这样的情况,“人在曹营,心在汉”这句谚语用在这里可能比较贴切。

产品与项目的矛盾

甲方做的是自己的产品,而乙方做的是别人的项目。这两者本身就是相互矛盾的,甲乙方的立场目的完全不一样,乙方带着做项目的心态去做产品,是不可能完全把产品做好的。双方的关注重点完全不同,甲方更关注产品本身,希望作出一款用户需要的好用的产品,以此来打开市场提升销售业绩。而乙方只看重眼前的利益,做完一单是一单,收完钱就转移阵地。

周期的矛盾

做产品是没有完成之日的,是长期的,持续需要迭代演进;而做项目是有明确完成时间的,是短期且一次性的,一锤子买卖,做完就走,不会维护后续版本。开发人员都找不到了,怎么继续做优化迭代呢?当然可以协商做一期、二期,这样阶段性的项目,但这样的折中方案依旧避免不了这样的矛盾。

需求范围的矛盾

产品需求具有不确定性,是根据市场及客户需求不断新增、变化的;而项目需求是有明确项目范围的,虽然也有变更,但是是在成本、质量、时间的综合因素条件下决定的,范围相对可控。

用户体验的矛盾

做产品,用户体验是必备因素,即便是To B产品也在越来越追求好用的用户体验;而做项目,首先追求的是功能,用户体验是次要的。

目前很多外包团队不重视体验设计,所以缺少交互体验专员,前期也不会做详细的交互设计原型,认为只要功能实现即可交付,并且合同中也不可能细化到交互细节要求。另外很多时候,还以“体验见仁见智”或者“我认为挺好的”这样的主观口吻来搪塞。

许多乙方虽然在前期提供了大量的UI设计稿(图片),供甲方确认,但最终做出的产品还是会和期望相差太远。一方面,前期的图片比较零散并没有体验真实交互,另一方面,原型也不能面面俱到,总有疏漏之处,而乙方则以未事先说明且经甲方确认为由不予修改。

技术架构的矛盾

做产品,往往希望采用先进的架构,灵活的插件,以保证产品有较好的稳定性、扩展性、兼容性和使用体验,即便初期架构简单,后期也要重构。但很多乙方往往抱着其公司内部老旧的技术体系架构,坚持“一招鲜吃遍天”的打法,每天忙于拓展项目赚钱,完成功能是第一要务;而同时技术重构又需要花费大量的人力和时间,所以他们根本不愿意沉下心来去重构改进。

产品期望与团队能力的矛盾

人是产品能否成功的关键因素,在产品外包中,却常常因为乙方人才资源的匮乏导致做出的产品总是不尽如人意。好的人才往往聚集在大型互联网公司、国企,或者发展前景好的创业公司,而外包公司的人才水平参差不齐,这跟外包公司的业务性质和成本结构有很大关系。对于外包团队而言,人力成本是最大的支出占比,特别在当下IT人才薪水节节攀升的时代,外包利润缩水严重,为了谋取外包项目的最大利润,必需尽量压低项目的人力成本,这也成为了很多外包团队能力有限的主要原因。常见问题我总结为三个方面:

人少

乙方减少单个项目的人数投入,有的项目甚至只投入0.5-1个人,可谓是极度节俭。研发人员捉襟见肘,产品很难保质保量完成。当然不能仅通过人员数量来决定团队能力,就像《启示录》中提到的那样,宁愿选择5个专业能力强的高级工程师,也不愿选择30个能力一般的菜鸟。在我之前参与的一个产品外包项目中,曾经只有一个人主要负责开发,但因为能力强,基本可以保证交付的质量,但后期逐渐加人,反而出现了一些麻烦,还需要前期的人来填坑,不仅影响进度还造成了浪费。

人不行

人员能力不行,一直是很多甲方诟病的问题,总是抱怨乙方人员总是不能很好的实现他们的预期,诸如缺少基本的规范和逻辑、功能无法实现或者开发时间过长、文档撰写太差、沟通能力有限、项目管理能力有限等等。其实,不管什么团队,我们都想要优秀的人才,但薪水自然要求也比较高,对于乙方,平衡成本之下,不可能都做到高端配置。所以,乙方会根据甲方项目的规模、重要性、时间计划先后等因素,对多个项目的人力配备进行深入评估,招募和配置不同等级的人才。一般一个团队配置1-2个高级人才就已经很奢侈了,另外再招募一些应届大学生、或者中专、培训机构出来的人才,这些人的薪资要求很低,既可以达到甲方对团队人数的要求又可以降低成本。这里用“滥竽充数”这个成语再合适不过了。

人难管

1、频跳槽

外包团队的人员离职变动在IT行业中可能更加频繁,有些人今天刚报到,可能三天后就要离职。而这样的人员变动,影响最大的就是工作交接所带来未知风险,不仅需要花费时间去找到下一个合适的接班人,即便是找到了,人员还需要接手和适应的时间,整个周期下来,产品已经停滞两周了。那外包行业人员离职的主因是什么呢?我总结两点:

  • 工作苦逼没有归属感。外包项目一般都驻点在项目现场,人员工作地点不固定,常常更换,并且驻点时间往往少则三个月,多则一年半载,工作环境也由甲方提供的场所决定,好点的提供。

  • 多头项目没有自我提升时间,特别是能力不错的人才,由于能力较强,单位工作效率和产出较高,而这样的人往往公司会给他安排更多的项目去做,有的人甚至成了救火队员,哪里项目有问题,就派到哪里,到处奔波,身心俱疲。正所谓“能力越强,责任越大”,这个词在外包公司这里得到了很好的体现。长期这样,没有时间去自我提升,能力遇到瓶颈,不能与时俱进的更新知识,每天疲于应付项目,所以跳槽是迟早的事儿。

2、不服管

这个现象常常出现在甲方现场驻点开发的场景,正所谓“将在外军令有所不受”,外包团队长期驻点,缺少激励,士气低迷,且领导不在身边,没有约束力。所以经常出现工作积极性不高、工作时娱乐,不认真工作;并且人员存在逆反心理,主观不听从甲方的修改要求。这里的原因,主要是现场外包人员的个人绩效考核权利不在甲方,也就是工资不是甲方发,所以难以对其形成约束和激励。

沟通协作的矛盾

异地办公

很多外包团队与产品负责人需要在研发过程中,针对设计、成果等进行不断的讨论、协作。如果他们分属异地,即便现在有很多互联网沟通产品,也无法替代当面沟通的效果。有些产品仅靠几页草稿去开发,几个月后再看产品,质量可想而知。所以异地情况,我们一般至少保证每周及重要里程表组织团队见面,确认每周及阶段性进展成果及下一阶段计划。另外,定期邮件往来、QQ、微信、视频等即时通讯手段给予辅助。

沟通心态

有些甲方认为花钱后什么都不用管,应该得到全方位的服务,乙方应全权负责产品。这种情况下做出的产品往往没有好的结果。就好像把自己的孩子完全托付给别人寄养,几个月后的性情肯定是这个妈妈无法接受的。如果甲方在一些场合,以“上帝的姿态”做出过激的行为,可能会触犯工程师的尊严,引起乙方不满,甚至撂挑子不干。因此,保持一个“开放、平等、合作”的心态才是项目所必需的。

乙方的不主动沟通也比较常见。一种情况是甲方的需求有时比较模糊,乙方按照自己的想法实施研发,不事先与甲方沟通。另一种情况是甲方对技术不太精通,有些问题可能乙方早就觉察到了,但因为怕耽误工期或者投入成本太高,一直捂着不主动提出,等到最后产品上线终于出了问题,那时候的损失就很难控制了。

无效沟通

甲乙方的会议经常从早晨讨论到晚上,且非常激烈,但最终却没有结果,或者有结果第二天又推翻继续讨论。一来二去,既耽误了时间,又耗费了大家的精力。所以在会议召开之前明确会议主题和目的非常重要,会议中一旦出现偏离,立即打断,必须保证整个会议的讨论朝着一个结果有序进行。会后,形成会议纪要通告大家,重要问题最好签字确认,加强仪式感。虽然也会有推翻的可能,但至少在签字时,每个人都是报着对会议结果负责的态度。

甲乙管理机制的矛盾

开发管理方式冲突

对于很多互联网或者SAAS产品,多采用敏捷的研发方法,迭代的速度要求也是相当高的,少则一周,多则两到三周就出一个版本。而很多传统外包团队,依然更多采用瀑布式的开发方法,按部就班的输出需求文档、设计文档、项目计划、开发、测试,整个周期下来2个月之后才能看到成果,这时候也许市场早就没了。我不是说所有项目都要敏捷,但有些适合敏捷的项目就应该坚持敏捷。有些文档完全不需要撰写,写了也没人看。直接出原型给开发,要比文档效果更好。

乙方自有的项目管理工具仅在内部使用,不向甲方开放共同协作使用,例如Bug管理、文档管理等。所以,如果甲方发现软件某些问题,或者需要查看部分文档,还需要通知乙方接口人转达或者获取,非常影响协作效率。而且一旦遇到不靠谱的乙方,这些内部管理记录很多都没有规范的执行。因此,作为甲方,建立自有的项目管理工具体系对产品推进有益无害,既可提高沟通效率,也可及时监督项目进展,发现问题。

测试形同虚设

乙方对于开发完成的产品,常常不重视测试,甚至不做测试。开发完成之后,草草测试了事,或者直接甩给甲方,让甲方去验证发现问题。这一点经常让甲方负责人恼火,一个版本要多次的验证打回,再验证再打回,劳心费力,既浪费时间又没有进展,完全充当了乙方的测试角色。这里原因有很多,包括

  • 乙方公司规模较小,专业的测试人员只配备1-2人,有的甚至没有测试人员,或者有其他职位的人兼职,测试水平较差。如果乙方承接的项目较多,人力资源有限,有些项目时间紧,根本来不及测试就提交甲方。

  • 乙方公司的开发理念,重开发轻测试。有些公司领导依旧持有这种陈旧的思想,所以在招聘人员上,测试人员的数量和水平一直不被重视。而且,测试在公司的话语权和交付责任机制,并不是以测试为中心,出了问题也不会找测试问责。这也是造成了这一现象的原因。

内部管理不畅波及项目

有人的地方就有江湖,有时乙方内部的不合理管理和派系斗争,也会波及到甲方项目。例如内部开发人员与项目经理分属不同部门,之间存在工作量结算或者内部KPI考核的矛盾;或者内部提交开发的流程死板,都会影响内部资源的调配和项目推进。

契约与人性的矛盾

虽然合同在法律上规定了甲乙方的责任与义务,但很多时候并不是非黑即白的。特别是在中国,除了“一纸约定”去约束项目和规避风险,其实还有甲乙方的中国式关系、以及职业操守这样的灰色区域。这些我把它们归结为人性,也就是人际关系和诚信问题。有人的地方就有主观喜好,这种喜好会表现在对合同执行的干预作用,执行好的项目可能会被人为破坏,执行差的项目可能会被“润滑”、或者调和改进。

负面激化矛盾

甲方的诚信问题。因为乙方在实施过程中,没有遵循“潜规则”,使得甲方主要负责人不满意,从而在项目验收时,故意刁难、延迟验收,拖欠款项。乙方随即暂停工作,使得项目无法收尾。

乙方的诚信问题。因为乙方与甲方某位项目关键人关系不一般,且大包大揽,不问需求先承诺,甚至以虚假案例最终拿到项目,但之后发现没有能力承接,或者二次转包,最后做成了烂尾产品,即便关系好,合同上也说不过去。

正面化解矛盾

人际关系和契约有时候不一定是激化矛盾,有的时候也可以化解矛盾,成为矛盾的“润滑剂”。例如,在合同执行时,乙方对甲方不仅项目服务非常到位,关系也维护的很不错。之后甲方的需求因市场变化有所变更或者蔓延,这时候,乙方因为人际关系,可能在成本可控的情况下会更多的承担一些开发;而甲方也可能因为人际关系,提出增补合同,追加投资。

再如,项目验收时,即便有一些产品瑕疵,因为关系好,往往睁一只眼闭一只眼,就验收通过了,后期乙方再优化完善,不影响合同付款进度。





以上就是个人对于以往To B产品外包中趟过的各种坑的一个总结,也许你会问,这么多坑该怎么避免呢?如果你是甲方,给你几点建议:

不外包自己干

首先,想好外包的原因,是因为时间来不及、缺少技术、还是资金有限。如果仅仅是想压低成本,不建议外包,这个思路做不好产品,特别是核心部分更不建议外包。如果是因为时间紧又没有技术团队,可以考虑第一个版本外包,后续自建团队接手重构迭代产品。外包是为了寻找专业的人做你不擅长的事情,而不是仅仅为了少花钱,这一点谨记。

切勿贪大求全

MVP最小可交付产品的精益方法业界已经熟知,我就不在多说了。对于传统行业创业者,贪大求全的错误还是会犯,在产品外包中,就更要避免。如果要做移动端,你不需要iOS、Android、微信H5全做,你可以先做微信H5,成本小流量多,可以很好的验证第一版。

选择靠谱开发团队

首先,最好通过熟人关系,真实了解他们团队的能力及服务。其次,团队尽量选择和自己在一个地方,避免异地。再次,外包团队要稳定并专门负责自己项目,不能被其他项目牵绊。最后,就是项目负责人以及开发人员要有丰富的开发经验等基本考证了。

过程管理抓大放小

1、过程两头重点抓

  • 开始阶段要重点抓需求范围界定、和交互体验设计。需求双方一定要吃透,尽量不要有模糊不清的地方,对于不确定的部分可以不放到第一个版本开发。另外,建议输出高保真原型,并且对部分交互点给予说明。对于体验设计粗糙的原型一定要严格拒绝,重新打回重新设计,不能直接进入开发,要知道好的原型可以避免很多后期开发的风险。

  • 开始阶段的项目管理模式要双方明确并严格执行,比如接口责任人、沟通机制、管理工具的选择等等,以便为后期项目执行打下良好的基础。

  • 后期的验收标准、考核惩罚机制和验收执行要重点专注,验收标准尽量细化,覆盖产品功能、交互体验、服务、维护等多个方面,以及相关的考核细则都要在项目开始前明确,并写到合同中,以规避风险。

2、过程中间选择抓

“若事无巨细,皆以身亲之,则所得至寡,所失至多矣”,所以中间过程仅作节点提醒和适度监理即可,如果事事亲为,一方面,分散注意力容易忘记重点,另一方面,要给乙方团队一定的自由度,手深的太长,会影响团队原有的节奏,也容易打击团队的积极主动性。


评论