День 168. Вы уволили самого талантливого сотрудника. Теперь Вы довольны?

Несколько дней назад на medium вышел пост архитектора и ведущего разработчика Jonathan Solórzano-Hamilton, наделавший много шума и побудивший российских знатоков написать ответный пост на хабре.

Вот исходная статья: https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde

Вот ответный пост на хабре: https://habrahabr.ru/post/340370/

Ниже приведу перевод оригинальной статьи с некоторыми своими комментариями

Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы принимали

«Вы никогда не сможете понять того, что я создал. Я Эйнштейн, а Вы обезьяны»

Он заявлял это перед нашей продуктовой командой, разработчиками и менеджерами. Один из наших спонсоров имел опрометчивость спросить, в какие сроки будет исправлена серьезная проблема в продукте.

Гении — переменчивые натуры и настоящие звери. Иногда Вам может посчастливиться работать с сумасшедшим гением, но как правило Вы обречены иметь дело просто с сумасшедшим. И беда в том, что очень трудно бывает отличить одно от другого.

Эта история о падении одаренного члена команды с глубоким пониманием архитектуры продукта. Этот парень обладал удивительной, сверхъестественной способностью предвидеть возникающие требования и имел знания, присущие только ему.

Будем называть его Рик. Рик медленно убивал наш проект.

Он ценился руководством компании и был ведущим разработчиком и архитектором наших проектов. Как только у любого разработчика или аналитика возникал вопрос по продукту или написанию кода, он мог пойти за помощью к Рику. 

Какая бы задача ни вставала перед Риком, в конце концов, он успешно с ней справлялся. Наш сервер находился на рабочем столе Рика, он постоянно имел доступ к нему и мог оперативно исправить проблему.

Рик ни в ком не нуждался. Он привык работать в одиночку в своей комнате. Ему нравился такой подход.

Рик использовал только свой код. Все, в чем он нуждался, он мог написать сам. Стоит ли тратить время и использовать пустяковые библиотеки простых смертных?

Вскоре Рик перестал посещать митинги. У Рика не было на них времени, ведь перед ним стояло так много задач и так много кода следовало написать.

Рик повесил замок на свою дверь. Теперь никто не мог зайти к Рику и посоветоваться. Рик перестал делиться опытом и обучать своих менее опытных товарищей, ведь так много нужно было делать самому.

Бэклог, между тем, рос. На Рике становилось все больше и больше задач. Баги выскакивали в старых модулях и библиотеках, написанных Риком. На них приходилось тратить время и отвлекаться от новых задач и взятых на себя обязательств в новом проекте.

На нашем дашборде зеленые значки сменились на желтые. Желтые сменились на красные. В джире постепенно все задачи были переведены в состояние «Заблокировано». Задачи не могли завершить без вмешательства Рика. Все ждали его.

Менеджер проекта выторговал дополнительные полгода у спонсоров.

Рик взялся за работу пуще прежнего. Он начал выходить в выходные и оставаться на ночь в офисе.

Все знали, что только Рик может вернуть проект на нормальные рельсы. Каждый, затаив дыхание, ждал, что Рик каким-то чудом исправит ситуацию на проекте.

С каждый днем Рик становился все более раздражительным и изолированным. Руководство не могло продолжать в таком духе и для исправления ситуации пригласили меня.

Я оценил атмосферу в коллективе, дорожную карту проекта, посетил несколько митингов. Погрузился в исходный код. 

Рик был прав: никто был не в состоянии понять его кода. Он был очень своеобразным. Документация полностью отсутствовала.

Я пошел к генеральному директору, чтобы сообщить свой вердикт: только Рик может продолжить сопровождение этого проекта. При этом каждый день разработки Рика оттягивает время релиза продукта на неделю. По сути, Рик разрушает наш продукт быстрее, чем создает.

Мы сели с Риком и начали обсуждать его роль на проекте. Мы поделились с ним нашими опасениями. Мы объяснили ему нашу новую стратегию. Для разработки продукта нам нужно стать одной командой и ввести в проект новых разработчиков. Рик не должен оставаться узким местом.

Как Вы думаете, Рик на это отреагировал?

Именно так, как ему свойственно. Он взорвался.

Он больше не хочет работать на этом проекте. Если его никто не ценит и не понимает его гениальности, это их проблемы. 

Рик сказал, что через месяц мы приползем к нему на коленях и будем умолять вернуться на проект. 

После этого он несколько месяцев отклонял наши предложения, он отказывался взять отпуск или передать часть задач на других разработчиков. Он отказывался использовать опенсорсные решения, чтобы не тратить время на изобретение велосипеда.

Он откатывал изменения кода остальных разработчиков. Он продолжил публично принижать коллег.

Мы уволили Рика.

Все устаканивалось неделю. За это время потрясенная команда смогла отойти от шока и пришла к пониманию, что им придется поддерживать продукт без их гуру.

Затем я увидел их вокруг доски. Они обсуждали какие-то идеи и что-то чертили. Они работали.

Наш продукт поддерживал динамический workflow, содержащий несколько тысяч ветвлений. В реальности 99% кейсов попадали всего в три ветки. Ребята захаркодили этот участок и выкинули треть кода Рика.

Ребята выкинули десятки тысяч строк непонятного кода, написанного Риком. Тестировщики обнаружили, что часть функционала перестала работать.

Нам удалось договориться со спонсорами, что мы начнем с чистого листа и будем поддерживать тот код, который остался.

Так мы потеряли 5% клиентов, но сократили функционал продукта на 25%, а сложность кода — вдвое.

Ребята залатали дыры, написав несколько тысяч строк кода взамен 150 тысяч строк непонятной массы.

Мы становились командой. 

За полгода мы реализовали весь тот функционал, который разрабатывался в течение 5 лет. 

Рик так и не вернулся в нашу команду. Но продуктивность выросла в разы. 

Почему присутствие Рика было деструктивным?

Он создал культ зависимости. Каждый раз, когда перед инженером вставала какая-то сложная проблема, он переставал бороться с ней, а просто передавал ее Рику и ждал решения.

Рик никогда ничего не документировал и писал неподдерживаемый код. 

Его присутствие в команде действовало деструктивно на развитие разработчиков, поскольку все их идеи пресекались на корню.

Это была не его вина. К слову сказать, непосредственные менеджеры команды, в которой работал Рик, были уволены еще раньше.

Сила Вашей команды не в сумме талантов разработчиков, а в их совместной работе, упорстве и уважению к чужим идеям.

Ну что ж, хорошая статья. Прямо-таки из жизни. Хочу подчеркнуть следующее:

1. Звезды — большая ценность в любой компании. Если продукты компании достаточно серьезные, без звезд не обойтись. В таких случаях должен быть человек, который знает все и к которому можно обратиться с любым вопросом.

При этом, в разных компаниях соотношение звезд и обычных сотрудников, а также их влияние на результаты работы могут сильно отличаться. В БАРС Груп, например, меня всегда поражал относительно невысокий уровень инженеров (подтверждение моим словам легко можно найти в интернете), при общении даже с ведущими архитекторами и техническими директорами я замечал, что даже они многого не знают. Проще говоря, не было понятно, к кому можно подойти с серьезной проблемой.

При этом они сильны как команда. В каком-то смысле дополняют друг друга и, несмотря на относительно невысокую звездность разработчиков, реализуют крутые проекты.

В piano же, напротив, работают яркие индивидуальности. Каждый инженер уникален и в то же время имеет колоссальный опыт. Но не всегда мы дополняем друг друга и эта индивидуальная звездность не помогает решать командные проблемы.

2. Управлять звездами тяжело. Здесь политика разных компаний сильно отличается — кто-то, например, принципиально не берет звезд, а берет только тех, кто легко вольется в корпоративную культуру и не создаст проблем существующему порядку.

Мы же любим звезд и, возможно, уделяем им излишнее внимание. На некоторые задачи вполне можно было взять менее опытных разработчиков и вырастить их внутри компании. 

3. Необходимо понимать, что для успешной реализации проектов и разработки продуктов правильный менеджмент и положение вещей в компании значат больше, чем отдельно взятая звезда. Хотя бы потому, что не стоит делать ставку на одного человека. 

Приглашать звезд в команду или воспитывать своих можно и нужно, но только после того, как внутри компании процессы будут выстроены правильно — нацелены на эффективную работу и достижение прибыли бизнеса.

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
Был на сайте вчера в 17:59
Читателей: 17 Опыт: 784.319 Карма: 5.92687
все 18 Мои друзья