写点什么

2023 年:我成了半个外包

作者:知了一笑
  • 2023-02-24
    浙江
  • 本文字数:2981 字

    阅读完需:约 10 分钟

2023年:我成了半个外包

边线业务与主线角色被困外包;

01

2022 年,最后一个工作日,裁员的小刀再次挥下;


商务区楼下又多了几个落寞的身影,办公室内又多了几头暴躁的灵魂;


随着裁员的结束,部门的人员结构简化到了极致,至少剩下的人是这么认为的;


说实话,对于当下的互联网行业来说,个人感觉两极分化的有点严重;


卷的,卷到鼻青脸肿,不知道 BUG 和需求哪个会先来;


不卷,感觉随时失业,不知道明天和裁员哪个会先来;


最近这几年,裁员的故事已经不新奇了;


比较热的话题反而是留下的那些人,如何应对各种此起彼伏的事情;


裁员,对于走的人和留的人来说,都是正面暴击;


走的人,虽然拿着赔偿礼包,但是要面对未来工作的不确定性,尤其是在当下的环境中;


留的人,要兜底很多闪现过来的事项,未来一段时间会陷入混乱的节奏中;


对于公司来说;


裁员之后如何应对业务,没有一丝丝迟疑,会做出了完全出于本能的决定;


内部团队能应对的就自己解决,解决不了就交给外包方处理;


整体的策略就是:核心业务领域之外的需求,选择更低成本的解决手段;

02

公司裁员之后,本意还是想专注自己的核心业务;


至于为何要接其他公司的需求,这里就涉及很多社会上的人情世故了;


比如一些重要关系或者流水大的客户;


缺乏互联网方面的专业团队,合作时会偶尔抛出研发或其他方面的需求;


对于公司来说,接手吃力不讨好,不接手又怕影响客户关系维护;


最好的选择就是寻求外包解决;


基于公司的研发团队,替客户进行相关需求的落地把控;


虽然接收外包需求流水抽成不高,但是可以更加紧密的维持客户合作关系;


允许质疑外包的质量和效率,但是不能否认长期的整体成本;


在裁员之后,团队介入的外包项目越来越多,形成主线和外包业务五五开的魔幻局面;


外包项目的合作形式大致分为两种;



  • 甲乙双方:甲方的业务与公司主线业务相关联,通常由团队自己开发;

  • 甲乙丙三方:甲方的业务比较独立,乙方接手之后再转交给丙方开发;


在这种合作中,如果只涉及甲乙两方,流程还是顺畅的;


但是对于甲乙丙三方的合作模式,如果再关联其他对接方,简直就是离谱踹门而入,离谱想拆家;


在经历几次甲乙丙三方的合作过程中,对于夹板气的体会已经是铭刻在心了;


甲乙双方对于丙方来说,是提供需求单的甲方;乙丙双方对于甲方来说,是落地需求单的外包方;


合作过程中拉扯出个精分现象,都习以为常了;


下面基于甲乙丙三方合作的模式,来聊一聊外包所踩到的坑坑洼洼;

03

【如何选择外包公司】


在甲乙丙三方合作中,甲方交给乙方的业务,可能是基于信任关系,或者成本原因;


但是乙方想再找一个靠谱的外包团队,难度就会大很多;


乙方既然承接需求,最终都是想交付高质量的结果,从而加强双方的合作关系;


如果没有一个靠谱的外包团队介入,所谓高质量的结果根本无从谈起;


通常会先从过往的合作过且靠谱的外包团队中寻找,但是能找到的概率其实并不大,这里的影响因素有很多;


需求本身的复杂度,外包团队能不能承接,是一方面;


甲方对于需求落地的预期时间,与外包团队的介入时间是否符合,也是一方面;


乙方对于外包团队的报价能否接受,又是一方面;


如果合作过的团队中没有,则会优先从公司内部寻求推荐,比盲寻一个不知底的团队要靠谱很多;


这里存在一个关键的卡点因素;


虽然研发团队接触的外包人员多,但是碍于怕麻烦的心理,乐意介入的人很少;


所以需求最终交给一个新的外包团队的概率很大,也为后续的诸多问题埋下隐患;

04

【三方合作的流程机制】


首先还是先说一个基本原则,在复杂的协作中,明确流程是最基础的事项;


三方合作,实现需求,获取利益回报;


流程上看可能并不复杂,然而在实际协作过程中,又十分的曲折;


在明确协作的流程时,需要把握需求的三个关键阶段:排期、研发、交付;


这里阶段划分是站在研发的角度拆解,从项目经理或者决策层看又是另一个说法了;



在研发视角下,虽然依旧是围绕排期、研发、交付三个阶段;


但由于涉及三方协同,各个阶段的事项都会变的繁杂;


流程的推进和问题解决,都要进行三方的统筹协调,麻烦事也从不缺席;


排期阶段


  • 乙方接受甲方的需求单和报价,并寻求丙方做需求实现;

  • 丙方围绕需求单进行拆解,输出项目计划书以及报价,乙方认同后达成初步合作意向;

  • 乙丙双方就排期与甲方达成共识后,三方就各自的合作签订外包合同;


研发阶段


  • 丙方就需求完成设计,在甲乙双方评审通过后,正式进入开发阶段;

  • 丙方需要定期将开发进度同步给乙方,乙方确认后也需要定期汇报给甲方;


交付阶段


  • 理论上丙方在自测完成后,再交付给乙方进行验收;

  • 乙方在验收阶段承担的压力比较大,本着对客户关系负责的态度,需要实现高质量的交付;

  • 甲方验收通过后,进行线上部署并交付项目材料,最终完成合同的结算流程;


流程终究只是对协作的预期设定;


在实际的执行中,会有各种问题层出不穷;


很容易把各方都推到情绪的边缘,进而导致系列关联的效应问题;

05

【三方合作的沟通问题】


如果从三方合作的问题中,选一个最大的出来,不用证明都确定是沟通问题;


沟通不到位,问题容易说不清楚,解决问题的很多动作可能都是抓瞎;


由于三方的合作是远程在线模式,不是当面表达;


沟通频率本来就低,等到发现问题解决思路不对时,耽误的时间已经久了;


如果返工;


那排期又需要重新协商,又会引起一系列必要的麻烦问题;


这种情况,对于乙方的项目经理来说;


身处甲丙两方的极限拉扯之中,会经常在离职和跳槽的情绪中不断徘徊;


然而也不乏一些花哨的操作,将甲乙丙三方拉扯到一个协作群中;


如果甲方不介意乙方寻找外包实现需求,那么三方在群里及时沟通和解决问题的效率也会高很多;


但是大部分的甲方还是介意的,很多沟通都是由丙方到乙方,乙方再转述给甲方;


传话游戏玩到最后,驴头不对驴嘴的现象十有八九;


所以,很多的外包合作群中;


可能都是存在着甲乙丙三方人员,只是乙丙对甲方语调统一,以此避免信息传递的问题;

06

【需求落地的质量问题】


对于三方合作实现的需求,质量高不高?


比较肯定的回答;


可能有一定的质量,但是高质量的期望建议打消,说不定还有一丝惊喜;


质量依赖靠谱的外包合作方,这本身就是一件有难度的事,看脸和运气都没用;


专业负责的外包团队少有,所以其团队的业务有持续性;


在实际协作过程中出现的问题少,才可能更加专注于需求本身的落地实现上;


然而真实的现状是;


外包团队会在需求排期内尽快完成,投入越少,收益越大;


比如:实现一个需求,估时 30 天,费用 10W;


如果在 15 天内完成需求,相当于成本投入缩减一半,这样在 30 天内可能实现多个需求;


鉴于这种策略之下,很多需求的实现可能都是仓促的,质量上自然很难保证;


所以对于质量问题的把关,压力会给到乙方,在交付验收时做好时间差管理;



乙方预留一部分时间段,对丙方交付进行验收,如果出现问题及时修改,避免传递到甲方;


当然了,混乱验收和测试也是常见的骚操作;


不乏一些丙方拿乙方的验收当测试,乙方拿甲方的验收当测试,以此来降低自己的时间成本;


由此导致三方合作裂开,尾款结算的问题,甚至对簿公堂也不少见;


虽然不是三方负责人乐意见到的,但又是三方都很难把控的事;


最终结果就是,不但成本没少,事情还更多了;

07

业务需求外包,是比较常见的一种手段,只是过程与结果的把控难度较大;


对于甲乙两方来说;


可能是利益驱动,可能是社会的人情世故,从而建立了合作关系;


对于乙丙两方来说;


则是单纯的利益考量,从而形成了短期的合作;


然而对于那些身处甲乙丙三方合作的网友们,只能在内心轻轻的嘀咕一句:人在社会,身不由己



发布于: 刚刚阅读数: 5
用户头像

知了一笑

关注

公众号:知了一笑 2020-04-08 加入

源码仓库:https://gitee.com/cicadasmile

评论

发布
暂无评论
2023年:我成了半个外包_Java_知了一笑_InfoQ写作社区