10X 开发者与 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 开发者留下的烂摊子。没有人愿意再和他们合作。曾经的异常表现成为了新的基准。人们开始燃尽，离开项目，随着每一次离职，项目从还能忍受的状态滑向崩溃。

一个欣欣向荣的代码库和充满活力的团队，最终沦为荒凉、被遗忘的土地。