10X Developer 与 POC 陷阱

Source: Dev.to

遇见 10X 开发者

在我的网页开发职业生涯中，我在三个不同的项目里与三位“10X”（或“裂变”）开发者共事过。他们工作表现惊人：每个冲刺完成的工单数量超过整个团队的总和，日工作时长超过 12 小时，跳过周末，几乎不请假，最重要的是，他们能在不到一两周的时间里交付一个概念验证（POC）——这似乎是一种可能会被永远诅咒的“天赋”。

POC 英雄

10X 开发者与 POC 的关系往往始于一个宏大的功能需求。负责人提出做 POC、可行性分析以及用户验收测试。产品经理说：“但我们时间不多，”并看向 10X 开发者：“我们两周能搞定，对吧？”

开发者连续两周奋战，交付了一个“够用”的原型。它通过了测试，合并进主项目，功能被视为成功。

新的需求出现，同一位开发者又构建了另一个原型。这次原型未通过测试，功能被标记为不可行，从而节省了数月的开发时间——又一次成功。

随着时间推移，冲刺接连进行，10X 开发者被指派越来越多的 POC 工作。最终他们不再做 bug 修复、功能增强、升级或维护；他们现在只做 POC。每一个大小功能都需要 POC，而 10X 开发者负责完成。

从英雄到瓶颈

随着 POC 工作堆积，开发者实际投入到每个原型的时间越来越少。质量从“够用”下降到勉强可用，出现了聪明却垃圾的代码——难以理解且维护噩梦。一旦原型合并，开发者就转向下一个 POC，留下当前功能未完成。这些工作常常被重新分配给团队中的其他人（有时就是你）。

你会发现，那些本应“能够”处理边缘情况的原型在正常路径上都几乎无法工作。产品方相信原型已经考虑了未来的规格，但你清楚它只覆盖了当前的需求。

开发者与真实项目工作脱节，沉浸在永无止境的 POC 世界里，所有东西都像是全新绿地项目。他们的系统从不崩溃——总是别人的错误代码导致问题，而他们没有时间去修复，因为还有十个以上的 POC 在等着。现在，修复破碎部件的责任落在了你身上。

他们在一个季度内交付的功能数量超过了整个团队一年所交付的总和。与此同时，你用于稳定原型并将其投入生产的时间更少。10X 开发者向你保证它已经“生产就绪”，但这块“布”已经出现了多个洞。

团队疲劳与倦怠

最终，团队中的每个人都厌倦了要去拾起 10X 开发者留下的原型碎片。没有人愿意再与他们合作。曾经的异常表现者变成了基准线。人们开始燃尽，离开项目，每一次离职都让项目从还能忍受滑向彻底崩溃。

曾经繁荣的代码库和多彩的团队，最终沦为荒凉、被遗忘的土地。