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

01 。

2022年，最后一个工作日，裁员的小刀再次挥下； 。

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

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

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

卷的，卷到鼻青脸肿，不知道BUG和需求哪个会先来； 。

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

最近这几年，裁员的故事已经不新奇了； 。

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

裁员，对于走的人和留的人来说，都是正面暴击； 。

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

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

对于公司来说； 。

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

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

整体的策略就是：核心业务领域之外的需求，选择更低成本的解决手段； 。

02 。

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

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

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

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

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

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

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

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

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

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

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

• 甲乙双方：甲方的业务与公司主线业务相关联，通常由团队自己开发；
• 甲乙丙三方：甲方的业务比较独立，乙方接手之后再转交给丙方开发；

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

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

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

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

合作过程中拉扯出个精分现象，都习以为常了； 。

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

03 。

【如何选择外包公司】 。

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

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

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

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

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

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

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

乙方对于外包团队的报价能否接受，又是一方面； 。

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

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

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

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

04 。

【三方合作的流程机制】 。

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

三方合作，实现需求，获取利益回报； 。

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

在明确协作的流程时，需要把握需求的三个关键阶段：排期、研发、交付； 。

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

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

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

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

排期阶段 。

• 乙方接受甲方的需求单和报价，并寻求丙方做需求实现；
• 丙方围绕需求单进行拆解，输出项目计划书以及报价，乙方认同后达成初步合作意向；
• 乙丙双方就排期与甲方达成共识后，三方就各自的合作签订外包合同；

研发阶段 。

• 丙方就需求完成设计，在甲乙双方评审通过后，正式进入开发阶段；
• 丙方需要定期将开发进度同步给乙方，乙方确认后也需要定期汇报给甲方；

交付阶段 。

• 理论上丙方在自测完成后，再交付给乙方进行验收；
• 乙方在验收阶段承担的压力比较大，本着对客户关系负责的态度，需要实现高质量的交付；
• 甲方验收通过后，进行线上部署并交付项目材料，最终完成合同的结算流程；

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

在实际的执行中，会有各种问题层出不穷； 。

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

05 。

【三方合作的沟通问题】 。

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

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

由于三方的合作是远程在线模式，不是当面表达； 。

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

如果返工； 。

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

这种情况，对于乙方的项目经理来说； 。

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

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

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

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

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

所以，很多的外包合作群中； 。

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

06 。

【需求落地的质量问题】 。

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

比较肯定的回答； 。

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

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

专业负责的外包团队少有，所以其团队的业务有持续性； 。

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

然而真实的现状是； 。

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

比如：实现一个需求，估时30天，费用10W； 。

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

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

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

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

当然了，混乱验收和测试也是常见的骚操作； 。

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

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

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

最终结果就是，不但成本没少，事情还更多了； 。

07 。

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

对于甲乙两方来说； 。

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

对于乙丙两方来说； 。

则是单纯的利益考量，从而形成了短期的合作； 。

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

最后此篇关于2023年：我成了半个外包的文章就讲到这里了,如果你想了解更多关于2023年：我成了半个外包的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。