为什么我要解雇项目团队中最天才，能力最强的程序员？

“你们不会理解我创造的一切。我 TMD 就是爱因斯坦，你们都是玩泥巴的小屁孩。”

我们的天才 Jekyll 医生愤怒地变身为 Hyde。(译注：《Jekyll and Hyde》是英国作家 Stevenson 的作品经典小说，善良的医生 Jekyll，他将自己当作实验对象，结果却导致人格分裂，变成夜晚会转为邪恶的 Hyde。)

他是在产品设计小组、开发人员、管理人员和试用用户面前说出的这句话。有个我们的项目赞助商询问产品何时可以修复严重缺陷。

天才都是反复无常的野兽。运气好时，和你共事的是个疯狂的天才，其他时候只是纯粹的疯子。大多时候，你很难区分。

这个故事关于我们一名天才团队成员的陨落，他对我们的产品架构有深入理解，有预测未来需求的不可思议的能力，有大量专业领域知识积累。

他是贡献最多的成员。他曾驾驭我们的旗舰项目。我们叫他 Rick 好了。

(译注：该名字取自一部美国著名的成人动画科幻情景喜剧《Rick and Morty》)

Rick 是团队里公认的天才。他是首席开发工程师及项目架构师。

任何时候任何人有关于代码的问题或任务需要帮忙，他们都会找 Rick。Rick 在办公室装了一块白板专门处理这种事情。白板上总留有无法擦去的凌乱痕迹，记录着过去的讨论。

无论什么时候出现特别有挑战性的问题，Rick 会处理它。Rick 电脑上安装了与生产环境服务器参数相同的服务器。他可以用这个服务器独立运行整个应用程序栈，同时在应用各个层面排查问题。

Rick 不依赖任何人。他喜欢孤军奋战在他的私人工作间。

Rick 从不需要别人造好的轮子。他什么都自己造，从无到有，因为自己造的轮子比其他凡人做的平庸之物要好太多。

很快，Rick 不再参加会议。因为太多代码需要编写，他没有时间参加会议。

Rick 关上工作间的门，白板也闲置了。他没有时间指导别人，因为他自己有很多事情需要解决。

Rick 身后开始积压工作。他造的轮子也开始出现 bug。这些压榨了他投入在新产品开发上的精力。

当然，这些 bug 出现是由于使用者操作不当，Rick 的工作没有任何问题。

在我们的项目仪表盘上，标志由绿色变成了黄色，黄色又变成了红色，红色的灯疯狂闪烁。任务一个又一个陷入不可用状态。所有人都在等待 Rick 处理。

(不必担心，Rick 会把这些全都解决掉。)

项目经理从赞助商那里获得了六个月的延期。六个月到了，生产准备预计还要七个月。等到一年过去了，生产准备两年了。

Rick 比之前更加高效地产出代码。他每周工作 7 天，每天工作 12 个小时。

每个人都知道只有 Rick 能拯救团队。大家屏住呼吸等待 Rick 创造特效良药，将项目起死回生。

每天，Rick 的孤立感和好战心都在增加。面具逐渐脱离，Jekyll 变成了 Hyde，

在项目最初商定的发布日期 2 年后，我参加了与项目团队的第一次会议。我注意到该项目有一段时间了，因为它在公司里声名狼藉，不过之前并没有参与进来。

我被指派进来，看看我们能不能拯救该项目。

我的第一场会议主题，便是前文提到的“爱因斯坦”。

嗯······

我看了源码。Rick 说得对，除了他自己，没人理解他创造的东西。这些全都是他自己思维的工作产物。其中一些很巧妙，大部分还是复制粘贴的。它们都很独特，并不是所有东西都有文档。

我给了我们的 CIO(首席信息官)一份报告。只有 Rick 能够维护这个产品。另外，Rick 每工作一天都会让项目交付延期一周。他对项目的破坏速度比创造速度要快。

我们和 Rick 坐下来讨论他在项目中的角色。我们评估了关注点。我们回避了他和爱因斯坦的比较。我们解释了新的战略。团队需要合作，从零开始构建一个新产品。

我们的努力必须限制在一定范围内，并且仅仅完成产品基础功能。整个团队贡献代码并可以提供技术支持。不再会有瓶颈。

Rick 对此作何反应?

Rick 还是一如既往风格，瞬间爆炸。

Rick 并不想理会这场闹剧。认为如果我们不能欣赏他的天赋，那就是我们的问题，而不是他的问题。Rick 预计不出一个月，我们会狼狈而归乞求他拯救我们。

Rick 向我们咆哮说我们庙太小，容不下他这尊佛。

很遗憾，这之后，Rick 拒绝了领导关于未来几个月的安排。他拒绝休息，也不同意工作移交他人。他屡次拒绝引入免费开源的框架来替代他自己的难以维护的定制工具。

他回退了其他开发者测试修复 bug 的代码变更。他宣称自己没有责任支持其他同事的工作。他不断公开藐视同事。

我们解雇了 Rick。

整整一周时间才尘埃落定。失去大将的军队需要一定时间来稳定军心。

然后我看到他们在白板前挤作一团。

(合作?Rick 从不懂这个词。)

他们开始合作，一起设计更简单的替代产品。

新产品没有华而不实东西，也没有根据五年后的产品路线来预计需求。

Rick 的产品动态工作流支持超过一万五千种排列。事实上，我们 99% 的用例只遵循其中三分之一的路径。团队对工作流硬编码。这移除了超过 30% Rick 的工作。

每个任务并不能使用定制的硬编码组件。他们把能购买到的组件替换掉定制的组件。

这移除了 Rick 上百小时的贡献。当然这也移除了上千小时的技术债务(technical debt)。

我们和项目赞助商协商达成一致，砍掉一些边缘功能。

这些边缘功能只服务于 5% 的试用用户组，但给在产品中占有四分之一的复杂度。

我们向试用用户组重新发布产品。产品包含 Rick 写的可稳定运行的 10% 的源代码，另外用几千行新代码替换掉了十五万行难以理解的代码。

整个团队六个月完成了五年的工作量。接下来几个月时间我们把试用版扩展为完整的客户版本。

我们不仅替换掉 Rick 造的轮子，而且超越他并全面推出了产品，所有这一切只用了不到一年时间。产品的大小和复杂度只有 Rick 所做的五分之一。

尽管产品组装时间很短，使用的客户翻了十倍，但产品的效率仍提升上百倍，而且几乎没有 bug。

团队回到 Rick 其他产品中，他们剔除了 Rick 的旧代码。

团队协作三个月就重新发布了 Rick 三年时间开发的产品。

团队中不再有 Rick 这种人。我们也不再看到这种从无到有造轮子疯狂的天才。但我们的生产力居高不下。

Rick 是非常有天赋的开发者。他能够解决复杂的商业逻辑问题，可以创造复杂精妙的结构来支持他的高级设计。但 Rick 不能解决的问题，是如何使团队高效工作。

(建筑工程队长是很酷，但摩天大楼是团队盖起来的。图© Warner Bros)

Rick 的存在，在某些方面是有破坏性的。

首先，他创造了个人崇拜的依赖。所有问题都变成 Rick 的问题，他变成一个神话。开发者习惯放弃尝试，只等着 Rick 解决。

其次，他写的代码不易维护。他从不写文档或测试代码，他的聪明才智也无法阻止失败。他对自己可靠性的信仰让他忽略了常识。

然后，他个人有破坏性。团队成员不想和他交流想法，因为他总是批判他们。Rick 只尊重它自己，以他自己的方式工作，让其他人感觉渺小。

最后，他缺少个人责任感。所有失败都不是他的错。他坚信这一点，这也阻止了他从错误中学习和进步。

我并不认为 Rick 从开始就这个样子。我看到的是，他最糟糕的样子。他经历了数年愈演愈烈的加班，面对了同事和客户逐渐增加的苛刻要求。

很遗憾，Rick 走远了。他的经理也有责任。事实上，原来的管理团队承担了责任，他们首先离开了。

不幸的是 Rick 走的太远了，以至于他不能回到正轨。即使再多的辅导、反馈、休假或指派其他项目都无法改变他的不良行为习惯。

在这一点上，整个团队知道他不好的地方。但个人崇拜的依赖如此强烈，每个人相信 Rick 是唯一的救命稻草。

其实一直都有其他选择的。

团队力量和每个单独成员的天赋无关，而是有关于他们的合作、斗志和相互尊重。

组建团队要注重发挥每个人的价值，让每个人都发挥自己的最好水平。

团结一心，他们就可以应对 Rick 都无法触及的更大的挑战。

注：一些细节(比如人名)已经处理。我的同事中没有叫 Rick 的。

--- 完 ---