分享层层分包的背后,是“傻逼”的循环嵌套【更新】

young
502阅读16评论1 年前

背景

近日,生意合作伙伴新介绍一条长期合作的业务线。合作初期,本着可以包住研发成本、大家先一起把整个业务线稳定下来的原则来做事。 按照这个原则,合作了两个比较小的项目。结果问题出在了第三个项目上,接下来要分享的内容也是基于这第三个项目。

角色介绍

  • “我”即是“我”-【我】- 软件公司
  • 合作伙伴-介绍人-【关系人】- 商务公司
  • 甲方-业务转包方-【甲方】- 广告公司
  • 甲方协作单位-项目合作方-【甲方附属】 - 文娱公司
  • 实际甲方-业务发起方-【大甲方】 - 传统企业

起始

合作模式

我们的合作模式是甲方联系关系人抛出需求,关系人将需求传递来进行评审与确定方案以及报价给关系人,关系人在研发报价基础上与甲方协商附加回扣以及商务运作成本后报价,甲方确认报价后项目立项。项目结束后甲方将项目款项结算给关系人,关系人将研发费用结算到我这边。PS:因项目都不大,周期在1-2周之间,加上合作基础原则,因此没有动工款以及分阶段结算的模式。

“业务”来了

某日(第二个项目结项中未结束),收到关系人来电,甲方有新的业务需要做,一个活动H5网页,展示分三部分【首页-商品页-表单页】,功能包括表单短信验证码、导出表单数据。 没有什么特殊的业务需求与技术风险难度,核算了成本价将报价报给了关系人,很快得到回复,开始研发吧,三天后交工。我这边直接需求丢给团队PM,大概讲了一下从关系人那收到的消息,让他自己安排动工。

注意:

  1. 我没有跟甲方沟通
  2. 我们不了解甲方这个行业特性与习惯
  3. 甲方设计稿此时未提供

研发

立项后,甲方在项目群里丢来了设计稿地址【百度云盘链接】,不清楚为什么,他们这个行业钟爱百度云盘,交着高昂的会员费,享受着卑贱的服务,同时给我们这种不苟且的友方带来了无法不接受的恶心感,之后才知道,当时的恶心不算什么,因为甲方会通过这种方式恶心+N次,因为设计稿在不停更新。粗略算过,三四个页面的设计稿,会更新不差10个版本。 如果邻居们也有遇到这样的情况,可以用 pandownload试试看,我用过还可以。 技术在收到设计稿之后,反馈设计稿尺寸有问题,甲方say你们有办法解决嘛? 电话甩过去,大致意思是设计稿的尺寸不是标准的比例,手机上会出现不满一屏的情况,要么设计改一下设计,要按照这个版本做,底部只能自动填充其他底色。 得到回复是按照这个设计做,设计改起来不方便。 OK,开工吧,前端又反馈,设计稿没标注、没切图,重点来了,甲方设计不会切图。。不会切图。。不会切图。。不会标注。。不会标注。。不会标注! 我能把甲方怎么样?并不能怎么样,安排我们设计切图,为了保证页面布局与设计稿一致,前端多用了一些大块切图,服务端接口开发完之后串联调试过后,拿过去给客户演示。

交付

甲方看到演示版,提出了几点:

  1. 页面的动效怎么没有?我当时给关系人讲按照你们的技术,随便加点动效就好了。
  2. 没有背景BGM,你们给找个免授权的BGM加上

看到这两个问题,各位看官你们怎么看? 如果觉得没什么难度的话,那么重头戏就来了。 PM在将这个问题反馈给前端后,前端头很大,因为最初没有说动效,所以都是大块的切图,现在加动效,需要把素材碎片化切出来,同时,他找了wowjs插件来做动效,整个页面又重新做了一版。 再交付! 甲方反馈,你们这个动效没规律呀?怎么上面的东西没出来,下面的东西就出来了?还有为什么滑动后下面一屏的布局乱了? PM跟甲方电话沟通又确认了一下动效的效果标准,前端表示无法精准控制素材入场顺序,wowjs库的bug,偶发! 甲方可不管你这些什么技术什么实现,他只需要他想看的! 但是我们前端始终不能很好地站在甲方立场看待这个事情和问题,导致效率很是不高。 彼时,存在问题1、动效顺序bug 2、机型适配。 前端讲如果最初就把这些说清楚,是完全可以控制很好地,现在改起来特别不好改(问题抛给了业务)。 又耗费2个工作日后将问题修复后交付。甲方又提出来,把title改一下,改后的文案太长,需要滚动起来!

甲方看过后觉得OK,拿去给大甲方看了,大甲方看过后觉得首页的按钮不是很明显、希望改明显一点,活动文案也调整一下吧、还有动效太多了去掉吧!动效去掉吧。。动效去掉吧。。动效去掉吧。。 好,问题一个一个来,我尝试了改图层与色系后截图给甲方,往返几次后,甲方觉得OK,自己发给大甲方后,甲方崩溃,安排自己的设计重新设计了按钮。甲方遗言是:“我让这边设计设计好吧,客户简直傻逼”。 设计出来后重新切图替换素材,搞定,动效去掉搞定,至此告一段落,交付发布上线。

结项

这个项目原核算成本为7个工作日,工期4个工作日。实际投入14个工作日,工期14个工作日。

分享

  1. 即便是“打关系”的项目,依旧不要让利太多,人都是惯性思维动物,敏锐发现每次项目的风险点是最好的自保手段。
  2. 乍一看业务简单、需求简单、细想也简单的需求,往往是风险点。
  3. 在项目立项前,除了当前项目的业务需求需要调研外,请仔细了解研究一下甲方所处行业,研习一下他们的习性,可以从【文化程度、日常工作内容与习惯、职位及职责划分、行业规范等】方面分析
  4. 每当你忍不住想骂甲方“傻逼”的时候,我想,他背后一定有个催使他的另一个“傻逼”。 出现这个场景,我们不见得没有责任,回归第三条,你是了解了项目业务与需求范围,但你是否了解甲方行业特性?
  5. 这类层层分包的业务场景,最大损耗是在业务传递与沟通上,这是造成研发成本上升的最大因素。如果规避这个因素,欢迎大家一起补充。

结语

此项目结项到目前为止已经过去了一段时间了,今天才发出来这个帖子是因为这段时间在这个业务线上又延续了新的业务,从新的业务上拿到了一些补偿。是否能拿到补偿也决定了此篇的主题基调。 世风日下、圈子小、人脉窄、没有自研核心产品、业务又少的我们,无奈之下只能面对解决这些问题与场景,调整好心态,每天都是崭新的一天,愿我们所有人都可以更好。 PS:送给给跃跃欲试想从体制内跳出来折腾创业单干的各位大佬,且行且珍惜,技术与管理与运用公司与商务是错综复杂的,不是你技术好项目交付好就可以活下来赚到钱的。

分享主题:
经历/经验
加载中…
精选评论
1 年前BIGray

前排板凳,坐等狗血详情👏

1 年前greatghoul

说出你的故事。

1 年前bigzhu

感觉看了一个悬念剧情片的简短预告.

瓜子板凳已经准备好

1 年前bigzhu

看完故事感觉至少你的 "大甲方" 不算太傻逼, 大多是中间商在瞎折腾.

外包度日时, 有过和你类似的经历. 中间商是某营销广告公司, 大甲方是大型外企, 项目是 HTML5 宣传展示页.

拿到需求后, 我团队的设计迅速给出了方案, 因为"大型外企的" 口味风格实在明显, 很好确定. 但被中间商否决, 于是按照中间商的奇思妙想各种折腾, 也有奇怪的动效要求, 我们也永远拿不到真实的甲方需求. 拖拖拉拉一年时间, 结果最后通过的交付的是我们一年前设计的初稿.

也就是说一年时间, 各种折腾的无用功, 都是在满足中间商的傻逼和自以为.

但这又是无可奈何的事, 毕竟拿到项目的是他, 不是我们. 别人的竞争力就在强悍的公关能力上. 转包层次越多, 被层层傻逼指挥的几率越大.

最终获利能包住这些折腾, 但为了满足傻逼的自以为是, 不得不捏着鼻子做毫无意义的工作, 简直让人沮丧.

这就是身为底层外包商最痛苦的地方.

当然更常见的是"大甲方"本身就是傻逼, 这种情况在我这个地方过于普遍. 这也是最终我放弃做外包的原因.

1 年前c'edar

瓜子板凳已经准备好

1 年前BIGray
注意:
我没有跟甲方沟通;
我们不了解甲方这个行业特性与习惯;
甲方设计稿此时未提供。

有句讲句,作为一个经常接外包的团队leader,你本该去“注意”以上你最应该“注意”的,而不是作为文章里提醒我们阅读的“注意”。你明知道以上你提到的都很重要,很疑惑你为什么没去做。跟甲方沟通一下,把设计图要过来看下,可能过程和结果都不见的如你所描述的悲催。😂

项目接入之前与甲方的沟通是非常重要的。包括:

  • 了解这个外包单的性质,是否是转包?甲方的付款能力?验收标准?
  • 需求明确程度:仅是个idea?有原型图?有设计稿?
  • 项目的要求:是否需要动效?文案谁提供?发布在哪里?是否需要后台?是否有相关的账号or接口?
  • 沟通的要素:跟谁对接?对谁负责?谁来验收?沟通误差怎么平衡?等。

不过写的很实际,确实很多人在接活的时候都不太注重这些。你的踩坑经验对大家很有用。已充电+置顶+转发支持。🤞

这个有几方面原因,不过我想最重要的一点是 人都是思维惯性动物,用自己已有的经验去面对任何项目的业务 有时会忽略其他层面的事情。

  1. 我没跟甲方沟通” 因为中间有关系人。当有人按照风火轮般速度(未收到设计稿要报价、晚了就签别家了、别家没有设计稿也可以报价 为什么你们不可以?)推进项目带节奏(想早点拿到¥)的时候自身节奏难免不受影响。
  2. 其次、甲方和关系人不太懂软件、我想这是不少居民遇到的甲方画像,他们没有系统的概念与认知,当甲方不按套路出牌的时候,项目接洽初期我们太按套路走甲方会不舒适、还会觉得其他乙方都可以 怎么就你事儿多?还能合作不?
  3. 关于交付标准与付款及项目性质等,因为有关系人的存在,也是有好处的。这些都不用担心、关系人关系人、关系不到能叫关系人嘛? 跟这类客户做事的一个原则是 只要按照大甲方的意思把东西搞定,剩下的水到渠成。出现以上问题的原因在于 甲方-我流程中业务需求的损耗与人员的不协调
  4. 人的精力是有限的、因为单子很小所以当时没太关注、大多数精力在其他事项上;交给团队成员去处理了、到最后成员都埋怨这是个傻逼客户 啥都不知道就知道改改改! 但是换个角度、我们还是得包容这类客户、正确认识他们、引导他们、寻找正确的合作方式、尽快度过磨合的阵痛期!
  5. 这个也不是绝对的什么标准答案,只是针对这类客户我想说的是,如果你也碰到这类客户了,一定要超出业务范围之外多了解了解客户行业信息,正确引导客户、探索需求背后的真正需求

1 年前灰喵

楼上说到了点上

1 年前Soli

『遗言』?

收到技术稿的时候,就感觉不靠谱了。

不过,就像后面说到的,能从新的业务中得到补偿,合作是长期的,有点业务赔点、有点业务赚点,能保证长期来说是赚的就不错了。

1 年前ychow

不错

1 年前杨露

学习了

1 年前Sherllo

👍外包应该都经历过类似情况。但苦于业务来源窄,很多时候又忍不住诱惑...

1 年前L.

弱弱的问。这……不是没啥事吗?挺顺利呀。

为啥说傻逼嵌套循环?

1 年前L.

犹豫了10分钟。。。既然提出了疑问,还是补充些背影信息比较好。

  1. 我也正在接一个外包项目,一个APP。当时甲方找到我的时候,我感觉我自己一个人做的话,可能得一两个月,太累了, 我做前端没那么快,手生。就找了个10来年经验的前端大神。我想着两技术大神合作顶多一个月就交差了。然后我给老板报3个月完成。。。。然后,然后,然后,一直搞到现在还没交差, 已经3个多多月了。

具体剧情就不讲了, 我想说的是, 这情况可能是外包项目的常态吧?

2. 之所以得到这么个悲观的结论, 是为我感觉不同背影和角度的人能对一件事理解一致真是比较难。就算是在公司办公室里, 产品跟技术经常理解不一致,,,技术内部的前端和后端也经常为了一个API应该是什么样的争论不休。。。

如果真的以外包为生,尽力把各方引向“正道”才对, 没有哪一方是“傻逼”.

合作过程中,前端问候需求“傻逼”十来遍;需求问候我“傻逼”十来遍;我问候甲方“傻逼”十来遍;甲方问候“大甲方”十来遍;

请问这是“傻逼”的多少次方?

10 个月前Growth

确定立项开发前,一定要确认设计稿,将设计稿给予前端是很重要的,因为前端能及时发现问题,比如设计未切图、标注等等