“我创造的东西你们这辈子也别想弄明白，我就是爱因斯坦，你们就是那没进化完的猴子！”
我们的常住天才，最终化身成了「邪恶博士」。
在一众产品设计团队、开发者、管理层和预发行客户面前，他就这么爆发了。我们的一位产品赞助商还真敢冒冒失失问我们这个使产品黄了的问题什么时候能解决。
天才如野兽，他们变化无常，阴晴不定。有时候你运气好，跟个疯狂的天才共事，但是有些时候，你就纯粹是在跟疯子打交道。还有些时候，你都分不清到底跟你一起工作到是天才还是疯子。
这个故事是关于一个极具天赋的团队成员失宠的历程。他对于我们的产品结构有着深刻理解，能够准确把握未来需求，且具备相当扎实的专业知识。
他是我们的顶级人才，是我们旗舰项目的领头人，我们把他称为 —— Rick 。
你可不想这样的人待在团队里。
Rick 被公认为是团队的大神，他是我们软件项目的首席开发者和架构师。任何人有关于代码的问题或是某个任务需要帮助时，他们都会去找 Rick 。
Rick 在办公室里安装了一个大白板，就只用于这个目的，上面总是有着过去讨论时留下的杂七杂八的痕迹，不太能擦掉。
无论何时，只要有极具挑战性的问题，Rick 都会去处理。Rick 在他办公桌上安装了一个跟我们生产服务器规格相同的服务器，他可以独立运行整个应用程序堆栈，同时对每一层进行故障排除。
Rick 工作不需要别人，他宁愿在自己的私人工作空间里独自工作。
Rick 也不需要任何人建造的任何东西。他可以从头构建他需要的一切东西，因为凡人给他提供的东西都太微不足道了。
很快，Rick 就不再参加会议，他没时间开会，因为要编码的东西太多了。
Rick 关上了办公室的门，白板也卸了。他不再有时间给他人培训，他自己的问题还解决不过来。
Rick 身后的事情不断积压，他之前创建的工具不断冒出 bug ，这些使得他无暇顾及新产品的开发。
当然这些 bug 出现是因为用户打开方式不对，他的工作怎么会出现问题，当然不会。
我们的项目板上，绿色标志变成黄色， 黄色变成红色，红色开始一闪一闪亮晶晶了。我们的任务状态一个接一个变成“受阻”，人人都在等在 Rick 出面。
不要担心，Rick 会处理的，所有的他都会处理好。项目经理从赞助商那里获得了半年的宽限时间，六个月之后，又拖了七个月，一年之后，又拖成了两年。
Rick 敲代码的速度比以往更快，他一个星期工作七天，每天工作十二个小时。每个人都知道，只有 Rick 才会拯救团队于水火之中，人人都屏息以待，期望 Rick 能发明出灵丹妙药，让这个项目起死回生。
Rick 日渐孤僻、焦躁不安。面具最终脱落下来，他化身成了邪恶博士。
比最初约定的发布日期晚了两年之后，我同这个项目组第一次会面。我听说过这个项目已经有一段时间了，因为这个项目在我的公司中已经变得臭名昭著，但是当时我还没有被派去处理参与该项目。
我被公司派来看看这项目还有没有救。我参加该项目的第一次会议就是我上面提到的“爱因斯坦会议”了。
我仔细查看了源代码。Rick 说的没错：他造的东西确实没人能理解，除了他自己之外。这就是他大脑工作方式的外在展现。有些相当聪明、有很多不过就是复制、粘贴，所有这些都非常另类，完全无法记录下来。
我带着这份裁定结果去见了我们的首席信息官，告诉他，只有 Rick 能够维持这个产品。并且，Rick 多在这个项目上工作一天，交付日期就多往后推一个星期。与其说他在创造这个项目，他破坏这个项目的速度更快。
我们跟 Rick 坐下来谈了谈他在这个项目中的作用，说了说我们的顾虑，对他将自己比作爱因斯坦避而不谈。我们解释了新的策略，这个团队得通力合作，重新创建一个新产品。这样，努力的范围非常有限，只提供用于生产的最基本的必须产品即可。整个团队都要群策群力，不再有瓶颈出现。
Rick 什么反应呢？当然是炸了。
Rick 可不想成为这个闹剧中的一部分。如果我们欣赏不了他的才华，那是我们的错，而不是他的错。他说不出几个月，我们都得哭着求他回来帮我们。Rick 对我们怒目而视，叫嚣着我们连最起码欣赏天才的脑子都没有。
在这之后，Rick 连续几个月拒绝领导层的主动示好。既不休假，也不让把工作分配出去。我们多次试图引入免费开放源框架取代他那难以维护的定制工具，但统统遭到拒绝。他将其他开发者修改的代码恢复原状 —— 包括已经修复漏洞并完成测试的代码。他坚持不会为支持其他人的工作负责，继续不断在公开场合 diss 他的同事。
我们把 Rick 给开了。
大约一个星期之后这事儿才尘埃落定。失去了让他们欢喜让他们忧的团队领袖，整个团队先是受到了震动，随后花了一段时间才重整旗鼓。
之后，我便看到他们共同聚集在一块白板面前。
合作。这是 Rick 从未见到过的场景。他们通力合作，设计了一款替代产品，比之前的简单多了。它没有那么多花里胡哨的东西，也没有达到五年前产品预期的要求。
Rick 开发的产品支持了超过 15000 种设想的动态工作流。而在现实生活中，使用我们产品 99% 的情况都是三种方式之一。我们的团队将该工作流进行了硬编码，这便去除了 Rick 将近三分之一的工作。不是每个任务都要进行定制的硬编码处理，他们剔除了能够买到而不是建造的定制依赖。
这也就去除了 Rick 上百小时的工作，但是也同样避免了上千个小时的技术负债。
项目赞助商也一致同意我们将用于某些极端情况下的功能去除掉。因为这只为我们 5% 的预发行用户群服务，但是却占了该产品复杂程度的四分之一。我们重新发行了这款产品，包括了 Rick 10% 最初的代码，这些代码相当稳定，还包括了几千行新代码，代替了 Rick 之前 15 万行的一些不知所云的东西。
这个团队在半年的时间里，完成了五年的工作。在接下来的几个月里，我们将该项目从试运行状态推进到成功发布客户端。
我们不只替代了 Rick 之前建造的东西，还超过了他，完整地发布了该产品。所有这些在一年的时间里完成。我们最后的产品，不论是大小还是复杂性，都不到 Rick 当时构建的产品的五分之一。完成速度是他的几百倍，并且组装时间短，服务人群是之前的十倍，却几乎没有 bug 出现。
此后，这个团队又转回身去鼓捣 Rick 其他的产品了。他们同样扔掉了他之前的旧代码。
Rick 之前开发了一款产品，三年都没弄明白，他们团队用了三个月，共同开发并发布了出来。
团队里虽然没有 Rick 这种人了，我们也不再有“鬼才”从头创建产品，但是我们的生产率却已经不能更高了。
Rick 是个非常有天分的开发者，能够解决复杂的商业逻辑问题，创建纷繁复杂的结构来支撑他那高级的设计，但是却无法在解决在一个团队中如何有效合作的问题。
建筑大师固然很厉害，但是摩天大楼可是由团队构建起来的。Rick 的出现从以下几个方面来说是具有破坏性意味的：
首先，他创建了一个依赖的邪教，所有的问题在最后都会变成 Rick 的问题， 助长了个人迷信色彩。开发者们不再尝试自己解决，就那么干等着 Rick 。
第二，他不写可维护的代码。从来不记录也不测试，所以尽管天资聪颖，仍一败涂地。他对自己的才华的盲目自信战胜了一切。
第三，他这人性格就带有破坏性色彩。团队成员不愿向他坦诚自己的意见或建议，因为他动辄就会训斥他们。Rick 尊重的人只有他自己，除此之外，他藐视一切。
第四，他缺乏责任意识。哪次失败也不关他的事，他始终坚信这一点，所以无法从错误中汲取教训。
我不相信 Rick 一开始就这样的。我见到的不过是他最差的自己。这也是由于年复一年的加班工作、以及来自客户和同事的各种批评指责造成的。
Rick 堕落至此实在惋惜。他的上级有责任，事实上，最初的管理团队都有责任：他们放任他而去。不幸的是，Rick 走得太远，他不能也不会被带回正道了。苦口婆心劝说、让他放假休息亦或是把他派到别的项目上，对他来说都已于事无补了。
到了这份上，整个团队意识到他确实有毒。但是这个团队成员对他依赖性太强，以至于人人都觉得他是他们唯一的选择。
要记住，永远都有别的选择。团队的优势不是在于个人的才华发挥作用，而在与整个团队间通力合作、坚忍不拔、互相尊重。团队建设要注重彼此尊重、互相激发出最好的那面，做最好的自己。众志成城方可攻坚克难，互相帮助远比依靠一个 Rick 要走的远。
作者：Hamilton
来源：36 氪
原文：https://medium.freecodecamp.or … 28fde
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/256969.html