本文所述为真实项目经历，细节已作匿名处理。写这篇文章不是为了抱怨，而是为了说明一个观点：技术人员的生命不应该浪费在和无能甲方的无意义纠缠中。
前言#
那天下午闷热难耐，杭州八月的暑气让人透不过气来，连知了都叫得有气无力。几个老同事约了在城西一家川菜馆聚餐，说是要尝尝他们家新出的毛血旺。菜还没上齐，话题就转到了工作上。
我正夹着一筷子土豆丝，有人忽然问：“听说你不做乙方了？”
我把酒杯中最后一口呲到嘴里，慢慢咽下去：“是的，离职的时候就决定了，彻底告别乙方交付。”
“为什么？”
我放下酒杯，看着桌上那盘红艳艳的水煮鱼，想了想：“人生苦短，不应该把时间浪费在和这群小丑婆婆妈妈上。”
回到家，我坐在书桌前，窗外的梧桐树绿得发亮，蝉鸣声此起彼伏，忽然想起了2023年9月开始的那个制造业项目。那是我做过的最荒诞的项目，没有之一。本来说6个月交付，结果做了整整一年。每一天都让我怀疑人生，但最让我怀疑的不是技术，而是甲方那套令人叹为观止的组织结构和管理体系。
古人说做事如做人。我觉得这话对了一半。做乙方项目确实是做人，但问题是，这完全是鸡同鸭讲，夏虫语冰。大家活在不同的世界里，说着不同的语言，却要假装彼此理解。
合同只是一张废纸#
23年9月，我接了个制造业集团的数据中台项目。合同厚得像《资治通鉴》，上面写得清清楚楚：CentOS 7.6，CDH 6.3.2。我当时想，这不就是个技术活么，按部就班做就完了。没想到这是个哲学活，还是存在主义那种。
项目启动会那天，甲方会议室里摆了一圈绿萝，长得特别茂盛。“项目负责人老师”翘着二郎腿，一脸春风得意，像刚中了彩票似的：“咱们重新考虑了一下，Ubuntu可能更合适一些。”
我愣了，手里的笔停在半空，就像孙悟空被念了紧箍咒：“等等，合同上明明白纸黑字写的是CentOS啊。”
“项目负责人老师”摆摆手，笑得很灿烂：“哎呀，合同嘛，都可以商量的。我们技术团队研究过了，说Ubuntu更先进一些。”
我心里咯噔一下。技术选型这种事情，本来就是按SOW执行的常规操作，根本不应该占用任何项目工时。数据中台项目的重点应该放在数据建模、实时计算、业务价值挖掘上，而不是在这些基础设施上纠缠。这就像你去饭店吃饭，菜单上明明写着红烧肉，上菜的时候服务员跟你说：“咱们觉得白切肉更健康，你看行不？”
甲方签合同的时候一个样，项目启动又是另一个样。做乙方的都知道，真正的项目从来不是按合同来的，合同只是个开始，就像相亲只是个开头一样。
问题是甲方的组织保障完全是一团浆糊。“项目负责人老师”根本不懂技术，他是个新手项目经理，刚从业务部门转过来，眼神里总是带着那种”反正我不懂技术”的纯真无邪。他最大的技能就是把压力往下传递，开口闭口就是”你们什么时候能出活”，像个传声筒。更要命的是，他连基本的项目管理都不会，开会从来没有议程，就像街头大妈聊天；沟通完了从来不记录，全凭大家的记忆力；做决策更是想一出是一出，比抛硬币还随机。
技术选型永远是政治问题#
操作系统搞定了，CDH版本又成了新战场。人生就是这样，解决了一个问题，马上又冒出三个问题，像打地鼠游戏。
SOW明确写着6.3.2，但”项目负责人老师”又开始”深度思考”了：“6.3.2是不是太新了？5.16更稳定吧？”
我说：“合同上写的是6.3.2。”
“合同可以调整嘛，技术选型要慎重。""项目负责人老师”一副为项目负责的样子，“你们再做个详细的版本对比分析，下周汇报。”
但我知道真实原因：他们对新版本没有把握，怕出问题要承担责任。更关键的是，他们根本没有技术判断能力，只能让我们做分析，然后拖延决策。这就像一个不会开车的人，非要指挥司机走哪条路。
争论持续了一个月。期间，我们搭建了两套测试环境，BA做了详细的版本对比，ISV工程师天天加班测试各种场景，累得跟狗一样。我向上级汇报时只能说：“技术选型还在优化中。”
最荒诞的是，我们每周要准备不同角度的对比分析：性能对比、安全对比、兼容性对比、维护成本对比。“项目负责人老师”看完总是说：“你们分析得很专业，我们内部再讨论讨论。“这就像你给一个色盲讲彩虹有几种颜色。
甲方给你马缰绳，让你跑千里马#
技术选型的问题解决了，数据接入的大戏开始了。数据中台要发挥作用，就得接入各个业务系统的数据。听起来很简单，实际上是一场生存游戏，而且是极限生存的那种。
项目启动后第二个月，我开始拜访各业务系统的开发团队。“项目负责人老师”作为项目负责人要陪同，但每到关键的技术问题，他就说：“这个我不懂，你们技术人员沟通。“然后就开始玩手机，或者看窗外的风景。
第一站是ERP系统。
我去拜访”ERP系统负责人老师”，一开口就直奔主题：“咱们需要JDBC直连你们的备库，这样数据传输会比较快。”
“ERP系统负责人老师”立马摇头，脸色都变了，就像看到了鬼：“不行不行，数据库绝对不能给外部系统直接访问。”
我耐着性子解释：“数据中台要处理海量数据，需要高带宽传输。用接口的话效率实在太低了。”
“那你们到底需要多大带宽？""ERP系统负责人老师”瞪大眼睛，就像听到了天文数字。
“至少千兆专线。”
“ERP系统负责人老师”差点从椅子上跳起来：“千兆？我的天，我们现在的接口才100M，你们这是要搞啥？挖矿吗？”
这就是典型的认知差异。甲方技术人员习惯了传统的系统对接，一天跑一次批处理，传几M数据就够了。他们根本理解不了数据中台的数据量需求。项目的核心应该是构建数据湖、设计实时计算架构、挖掘业务价值，而不是在数据传输的基础问题上纠缠不清。
最后给了我们一个总线接口，老大爷似的慢慢说：“每秒1M带宽，这是我们的底线了。”
ISV工程师在旁边听得直翻白眼，私下拉着我说：“1M每秒是啥概念？咱们要传几十G的历史数据，这得传到啥时候去？”
我苦笑着拍拍他：“这就是乙方的宿命，用最原始的工具干最现代的活。“这就像用算盘来计算火箭轨道。
客户说”顺便”，就是工作量翻倍#
11月份，“项目负责人老师”笑眯眯地找到我，一副很随意的样子，就像邻居大妈找你借个打蛋器：“哎，咱们能不能顺便做个数据看板？就几个简单图表，应该不复杂吧？”
听到”顺便”二字，我心里的警铃就开始响了，就像防空警报。做乙方这些年，我总结了一个铁律：客户说”顺便”的时候，通常意味着工作量翻倍。但脸上还得笑着问：“什么需求啊？”
“项目负责人老师”掰着手指头：“也就是显示个生产数量啊、设备状态啊这些基本指标，很简单的。”
BA听了做了需求分析，眨巴着眼睛跟我说：“按这个需求，评估2周开发量。“按照乙方的经验，这种需求至少要乘以2，因为客户永远不会一次性把需求说清楚。就像剥洋葱，一层一层剥，越剥眼泪越多。
果然，一周后，“项目负责人老师”又来了，搓着手说：“哎呀，能不能加个趋势分析？就是看看数据的走势，应该不难吧？”
两周后，“项目负责人老师”眼睛亮晶晶的，就像发现了新大陆：“能不能支持多维度查询？用户想从不同角度看数据。”
最后的”简单看板”变成了完整的BI平台。工作量从2周变成了2个月，但项目时间没有相应延长，就像马拉松变成了百米冲刺。
人生苦短，不与小丑为伍#
2024年9月，项目终于交付了。整整一年！比原计划整整晚了6个月。这在乙方项目中已经算是灾难级的延期了，但甲方验收还算顺利，我们也总算完成了任务。就像马拉松跑了42公里之后，又被要求多跑10公里。
但那天晚上，我躺在床上想了很久。
这个项目让我看清了乙方交付的本质，以及甲方那套令人叹为观止的组织体系：
我们永远在为甲方的无能买单。他们不懂数据中台，却要做数据中台；组织能力混乱，却要搞复杂项目；管理水平低下，却要指手画脚。每一个愚蠢决策的后果，都要乙方来承担。这就像一个不会游泳的人坚持要跳水，然后让救生员负责他不会淹死。
我们永远在为甲方的胆怯背锅。技术方案不敢定，出了问题怪乙方建议有误；需求不敢确认，变更了怪乙方理解不深；责任不敢承担，延期了怪乙方执行不力。甲方永远是受害者，乙方永远是替罪羊。
我们永远在适应甲方的垃圾流程。权责不清的组织架构，低效混乱的决策机制，朝令夕改的管理方式。我们要花大量时间去理解他们的内部政治，适应他们的管理风格，满足他们的奇葩要求。
最让我愤怒的是，这个行业把这种现象合理化了。什么”客户就是上帝”，什么”服务意识要到位”，什么”要有同理心”。
放屁。
上帝不会蠢成这样。真正的服务是提供专业价值，不是无原则迁就。同理心应该是相互的，不是单方面的奴颜婢膝。
那一刻，我做了决定：彻底告别乙方交付。
不是因为做不好，而是因为不值得。不是因为能力不够，而是因为浪费生命。
尾声#
写到这里，外面开始下雨了，雨点打在玻璃上，像是在敲门。杭州的夏雨总是来得急，去得也快。我想起那天聚餐的时候，有同事夹了口菜，好奇地问：“那你打算干啥去？”
我当时想了想说：“肯定不再碰乙方交付了，也许我可以把自己的经验拾掇拾掇，也能帮助别人一二吧。”
其实心里已经有了答案。我要做自己认为有价值的事情。即使收入可能会少一些，即使风险可能会大一些，但至少我知道我的努力是有意义的。
后来我真的开始写这些东西，把那些荒诞的项目经历写出来。有人说这是在抱怨，我觉得不是。我只是想告诉那些还在乙方苦苦挣扎的同行们，你们不是一个人在战斗，这些荒诞不是你们的错，是这个行业的问题。
最近有个朋友问我：“你后悔离开乙方吗？”
我想了想，摇摇头：“不后悔。”
人生如梦，但梦要做得美一些。既然这辈子注定要做一些事情，那就做一些让自己觉得有意思的事情。
生命的意义不在于适应荒诞，而在于创造价值；不在于迁就无能，而在于追求卓越；不在于和小丑们纠缠不清，而在于做真正重要的事情。
因为我终于意识到，真正的荒诞不是项目本身，而是我们对这种扭曲关系的习以为常。
雨停了，空气很清新。我推开窗，深深吸了一口气。