背景

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

角色介绍

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

起始

合作模式

我们的合作模式是甲方联系关系人抛出需求，关系人将需求传递来进行评审与确定方案以及报价给关系人，关系人在研发报价基础上与甲方协商附加回扣以及商务运作成本后报价，甲方确认报价后项目立项。项目结束后甲方将项目款项结算给关系人，关系人将研发费用结算到我这边。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：送给给跃跃欲试想从体制内跳出来折腾创业单干的各位大佬，且行且珍惜，技术与管理与运用公司与商务是错综复杂的，不是你技术好项目交付好就可以活下来赚到钱的。