Привет! 

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

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

Условия эксперимента следующие:

Вы руководите несколькими командами разработки. Одна из команд (не единственная) состоит из 10 человек, делает классный и востребованный продукт для конечных клиентов. В состав команды входят:

• 7 инженеров—разработчиков (допустим, все фуллстеки, чтобы убрать из задачи сложности по непересекающимся стекам);

• UI/UX-дизайнер;

• системный аналитик;

• владелец продукта — ведущий специалист от Бизнеса, который определяет приоритеты доработок и пользу от новых фич.

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

Вроде бы стандартная история, которая раньше решалась объяснением Владельцу продукта сложности и нетривиальности задачи, которую выполнял конкретный инженер (в отличие от прочих задач, которые кажутся «аналогичными»).

Погрузившись в историю коммитов и побеседовав со всеми инженерами команды (в том числе и с тем, по которому «есть вопросы») вы получаете следующую картину:

1. Действительно, «проблемный» инженер выполняет задачи медленнее своих коллег. Причём действительно аналогичные по сложности задачи, подводных камней нет. Создаётся впечатление, что он пишет код примерно в два раза медленнее других инженеров той же команды.

2. Качество кода соответствует среднему по больнице. Ничего сверхъестественного там нет. Тесты пишутся, интеграционные взаимодействия, по возможности, реализованы через брокер очередей, ошибки журналируются и т.д. Всё в целом нормально, как и у других разработчиков.

3. Профессиональные навыки «проблемного» инженера также соответствуют ожидаемому уровню, и где-то даже превосходят средний уровень команды. Свою профессиональную область он знает хорошо, перфекционизмом страдает в меру, соблюдает принятые стандарты и паттерны разработки.

4. Другие инженеры избегают совместных задач с «проблемным» разработчиком. Объясняют это тем, что при возникновении спорных моментов в реализации фичи «проблемный» инженер спорит до посинения и не слышит аргументов других разработчиков. В конце концов всё равно делает по-своему, и это (иногда) приходится переделывать на code review. Каждый раз это скандал и трагедия. А если переделывать не приходится (то есть решение верное), это выливается в нетолерантную тираду «а я же говорил».

5. «Проблемный» инженер активно участвует во всех коллективных мероприятиях и обсуждениях внутри компании, в том числе и в тех, которые не относятся к предметной области команды. Это всевозможные публичные демонстрации других продуктов, обсуждение архитектурных и DevOps-вопросов, активности по созданию единого UI-набора (не задача этой команды) и т. д. По сути, высказывает свое мнение по любому вопросу, даже если вопрос не касается ни стека, ни задач команды. С другой стороны, он помогает развитию коллективных проектов компании.

6. «Проблемный» инженер никогда не жертвует личным временем ради решения задач команды. Другими словами, если ему задать вопрос в чате через полчаса после окончания рабочего времени, ответ будет только утром. Во время рабочего времени реакция на вопросы вполне нормальная.

7. Опять же, рассчитывать на помощь «проблемного» инженера в нерабочее время не имеет смысла. Если возникают какие-то проблемы в работе продукта и требуется привлечение разработки, то «проблемник» не ответит на звонки и сообщения в чате и не присоединится к решению.

Вы также побеседовали с самим «проблемным» инженером, его точка зрения следующая:

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

2. Проблему со своей продуктивностью видит и признаёт, но не может ее объяснить.

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

В качестве эксперимента, вы подробно расписали несколько задач на пару спринтов и вместе с проблемным инженером оценили сроки их реализации (оценки инженера были завышены, на ваш взгляд, примерно на 30-40%). Вы жестко контролировали сроки и качество реализации задач, по большей части всё было завершено в срок с приемлемым качеством.

Владелец продукта согласился, что скорость работы «проблемника» в период жесткого контроля выросла. Однако после окончания этого периода продуктивность снова упала.

Итак, дамы и господа, что бы вы сделали? Учитывайте и моральную, и практическую сторону вопроса.

Уволить проблемного инженера

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

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

• Самому «проблемному» инженеру не видать повышения. Он тратит свою время попусту и не растет в профессиональном плане.

Оставить всё как есть

• По-честному, парень ничего такого не нарушил. Работает положенное время, какие-то задачи делает, а значит и пользу приносит. Пусть и медленнее других.

• Может, ему и не нужно повышение. Он сам же выразился, «работает, чтобы жить».

Дать ему отдельный мини-проект (даже с вакансиями, чтобы набирал команду под себя)

• Возможность вырасти в плане менеджмента и архитектурного проектирования. Может, начнет по-другому относится к задачам?

• А как ему доверить проект? Он задачки-то не вовремя делает: чувства ответственности практически нет. Хотя, может, ответственность перед другими разработчиками (которых он же и набирал) заставит его по-другому относиться к работе?

• Не много ли чести делать столько приседаний ради одного проблемника? Каждому инженеру, по которому возникают вопросы, давать отдельный проект? Проще уволить.

Организовать постоянный контроль за сроками для этого разработчика

• Отвлечение ваших ресурсов на одного разработчика. Будете проседать по другим задачам.

• И с чего бы это такое особое отношение? Другие инженеры сразу заметят такой жестокий микроконтроль, и как отреагируют — неизвестно.

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

Ваше мнение?

Выбирайте, дамы и господа. Только помните, что на время чтения этой статьи на вас надета шапка руководителя разработки, и «проблемный» инженер — ваш подчиненный.

Если возникнут еще какие-то варианты, напишите их в комментарии.