Как выбрать разработчика и не нанять слабого специалиста

Hola, Amigos! На связи Артём Салеев, CTO Amiga.

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

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

Кто такой бесполезный разработчик

Бесполезный разработчик — не обязательно ленивый или плохой специалист. Часто это сотрудник, который перестал развиваться, привык работать «по накатанной» и не хочет разбираться в задачах, выходящих за рамки привычной зоны ответственности. Он может быть хорошим исполнителем, но при этом не создавать заметной ценности для продукта и команды.

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

Признаки бесполезного разработчика

1. Отсутствие инициативы. Делает только то, что написано в задаче, и просто «отрабатывает». Если появляется проблема, ждет, пока кто-то другой ее решит. Не предлагает варианты и не пытается самостоятельно найти решение.

2. Токсичность и пассивное сопротивление. Критикует решения команды, но не предлагает альтернатив. Любое изменение процесса или новые задачи встречает негативно и старается работать по старым правилам.

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

4. Закрытость. Не задает вопросов, не уточняет требования и не сообщает о проблемах. Все делает в тишине, пока ошибка или техническая проблема не становится критичной. В разработке такой подход особенно опасен: чем позже команда узнает о проблеме, тем дороже ее исправление.

5. Неэффективность. Формально выполняет задачи, но результат регулярно приходится дорабатывать или переделывать. Ошибки повторяются, сроки растягиваются, а на контроль и исправление работы у других сотрудников уходит дополнительное время.

Чем опасен такой сотрудник

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

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

Чек-лист «ред флагов»

Если вы пытаетесь понять, действительно ли разработчик не справляется с работой, обратите внимание на повторяющиеся признаки:

1. Систематическая неспособность закрывать задачи на ожидаемом уровне.

2. Регулярные нарушения дедлайнов или невнимательность к требованиям и деталям.

3. Отсутствие инициативы и самостоятельности при решении рабочих задач.

4. Постоянно отрицательный или конфликтный настрой в команде.

5. Игнорирование обратной связи, замечаний и рекомендаций по работе.

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

Как не нанять бесполезного разработчика

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

На собеседовании я смотрю не только на то, что человек знает, но и на то, как он рассуждает, когда чего-то не знает. Если кандидат спокойно признает пробел, предлагает, где найти информацию, и не теряется перед незнакомой задачей — значит, с ним можно работать.

На что стоит обратить внимание при собеседовании разработчика

1. Структура собеседования. Важно сохранять общую структуру интервью, чтобы впоследствии можно было объективно сравнивать кандидатов между собой. При этом не стоит превращать собеседование в жесткий сценарий: вопросы, которые возникают по ходу разговора, помогают глубже разобраться в опыте и подходе кандидата к работе.

2. Первое впечатление и профессиональные навыки. Сильные софт-скиллы кандидата могут быть убедительными, но важно оценивать и его технические навыки. От тестовых заданий сейчас многие отказываются, поэтому мы нашли компромисс — небольшой live-coding на 15–20 минут. За это время можно посмотреть, как человек думает, ищет решение и реагирует на возникающие сложности.

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

4. Опыт и реальные проекты. На собеседовании важно просить кандидата подробно рассказывать о проектах, процессах в компании и задачах, с которыми он работал. Для заказной разработки это bare minimum. Важно понять, насколько его предыдущий опыт соответствует вашим процессам: если подходы и темп работы сильно отличаются, много времени может уйти на адаптацию и обучение.

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

Что делать, если хороший специалист «выпал»

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

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

1. Совершает ошибки, но готов к фидбэку и здоровой критике.
2. Хочет работать над ошибками.
3. Проблема не в компетенции, а в фокусе.
4. Личные обстоятельства, на которые можно повлиять. Например, сложный график работы из-за разных часовых поясов.

Что делать, если разработчик временно снизил эффективность?

1. Дать ментора, поставить понятные цели и сформировать взаимные ожидания. Лучше всего заранее определить контрольные точки: например, «через два месяца от тебя ожидаем вот такой результат». Так сотруднику понятно, что именно нужно изменить, а руководителю — по каким критериям оценивать прогресс.
2. Дать конструктивный и аргументированный фидбэк. Не просто «ты слабый специалист», а конкретно объяснить: «тебе нужно научиться / исправить / освоить вот это, но при этом ты уже хорошо делаешь вот это». Такой подход помогает понять проблему и дает человеку возможность ее исправить.
3. Регулярно обсуждать результаты на контрольных точках. Не ждать окончания обозначенного срока, а периодически синхронизироваться по прогрессу, сложностям и результатам. Если ситуация меняется, цели и формат поддержки тоже можно скорректировать.

Что делать, если нет результата

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

Бесполезный разработчик или просто не подходит компании?

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

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

Перед тем как считать сотрудника бесполезным, стоит проверить несколько вещей:

1. Совпадают ли ожидания. Сотрудник понимает, какой результат от него ждут и по каким критериям оценивают его работу?

2. Подходит ли опыт. Работал ли он раньше в похожем формате, с похожими задачами и уровнем ответственности?

3. Хватает ли ресурсов. Есть ли у него доступ к необходимой информации, коллегам, инструментам и времени на выполнение задач?

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

5. Есть ли динамика. Даже если результат пока не идеальный, становится ли работа лучше после обратной связи и поддержки?

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

Как оценивать работу разработчика

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

При оценке разработчика я бы смотрел на несколько показателей:

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

2. Самостоятельность. Может ли разработчик разобраться в задаче, найти решение и вовремя попросить помощи, если столкнулся с проблемой.

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

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

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

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

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

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

Как понять, что пора принимать решение

1. Нет прогресса, несмотря на поддержку и наставничество. Сотрудник получает обратную связь и понимает, что нужно изменить, но ситуация не улучшается.
2. Регулярные ошибки и несоответствие ожидаемым результатам. Одноразовая ошибка — не повод делать выводы. Важнее систематические проблемы с качеством работы, сроками или достижением согласованных KPI.
3. Затраченные ресурсы несоизмеримы с результатом. Если на контроль, исправление ошибок и дополнительное обучение сотрудника команда тратит больше ресурсов, чем получает результата, это уже повод пересмотреть ситуацию.
4. Команда перестала доверять сотруднику или регулярно переделывает его работу. Если коллегам приходится постоянно проверять и исправлять задачи, это влияет не только на эффективность самого разработчика, но и на весь проект.

Алгоритм действий

1. Своевременно фиксируем проблемы. Документируем конкретные случаи, сроки, ошибки и их последствия. Это помогает опираться на факты, а не на субъективное впечатление от работы сотрудника.
2. Даем конкретный срок на улучшение. Определяем 2–3 контрольные точки с понятными целями и измеримыми результатами. Сотрудник должен понимать, что именно от него ожидается и в какие сроки.
3. Регулярно мониторим результат. Проводим синки, обсуждаем прогресс и даем обратную связь по каждому этапу. Если ситуация улучшается, это тоже важно фиксировать.
4. Если прогресса нет — принимаем решение. Если после поддержки, понятных целей и нескольких контрольных точек результат не меняется, стоит рассмотреть дальнейшие варианты сотрудничества, включая расставание с сотрудником.

Вывод

Работа с «бесполезностью» начинается еще на этапе найма — с того, как мы выбираем людей и как потом помогаем им раскрыться.

Не стоит увольнять разработчика после первой ошибки или неудачного месяца. Мы все иногда выпадаем из рабочего ритма — из-за стресса, перегруза, личных обстоятельств или просто потому, что новый проект оказался совсем не таким, как мы представляли. Пока ИИ не занял наши места, мы все еще люди.

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

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

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

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