Вернуться к блогу
7.11.2025
Hola, Amigos! На связи Артём Салеев, СТО агентства продуктовой разработки Amiga. Рискну предположить, что почти в каждой команде есть коллега, которому лучше не давать важных задач, а при идеальном раскладе вообще не трогать. Результаты от таких работников часто непредсказуемые, либо требуется время, чтобы тернистыми итерациями привести все к подобающему виду. В статье поднимем тему неэффективных сотрудников, разберем, что с ними делать, и как определить таких специалистов на берегу.
Это не обязательно ленивый человек. Часто — просто специалист, который перестал развиваться, привык работать «по накатанной» и не хочет разбираться в том, что выходит за рамки привычных задач. Он может быть хорошим исполнителем, но не создает ценности, и его вклад в продукт минимален.
Такие сотрудники не токсичны, но и не полезны. Они не тянут команду вниз напрямую, но тормозят развитие компании своим безразличием и посредственным качеством работы.
Отсутствие инициативы. Делает только то, что написано в задаче, просто «отрабатывает». Если появляется проблема — ждет, пока кто-то другой решит.
Токсичность. Критикует действия команды, но ничего не предлагает. Любой новый процесс встречает пассивным сопротивлением.
Непрозрачность. Никто не понимает, чем он занят и зачем. Задачи вроде бы есть, но результата не видно. Такой человек может неделями «разбираться» с чем-то, не выдавая понятного результата.
Закрытость. Не задает вопросов, не делится проблемами и не уточняет детали. Все делает в тишине, пока что-то не сломается. И тогда уже поздно.
Неэффективность. Формально он все выполняет, но почти каждую задачу приходится переделывать.
Главная проблема — не в нем, а во времени, которое на него уходит. Вместо развития продукта команда занята исправлениями и разбором ошибок. Сильные разработчики теряют мотивацию, сроки растягиваются, а эффективность падает. В итоге один неэффективный человек замедляет весь проект.
Систематическая неспособность закрывать задачи на ожидаемом уровне.
Частые нарушения дедлайнов или невнимательность к деталям.
Отсутствие инициативы и самостоятельности.
Отрицательный или конфликтный настрой в команде.
Игнорирование фидбэка и наставлений.
Бесполезных разработчиков вряд ли нанимают специально. Скорее из-за спешки, неопределенности и веры в первое впечатление. На деле, полезный разработчик не обязательно знает ответы на все вопросы, но может взять ответственность и умеет доводить дело до конца.
На собеседовании я смотрю не только, что человек знает, но и то, как он рассуждает, когда не знает. Если он спокойно признает пробел, предлагает, где посмотреть, и не теряется — значит, можно работать.
На что стоит обратить внимание при проведении собеседования:
Структура. Важно сохранять структуру собеседования, чтобы впоследствии иметь возможность сравнивать кандидатов друг с другом. При этом не исключаем вопросы возникающие в процессе общения, чтобы более детально изучить опыт собеседника.
Первое впечатление. Иногда сильные софты у кандидата могут быть заманчивы, но не будет лишним и посмотреть на то, какие у него харды. От тестового задания сейчас многие отказываются, поэтому мы нашли компромисс — небольшой life-coding на 15-20 минут.
Софт-скиллы. Обратная ситуация, когда у кандидата отлично получается справляться с задачами, но с ним очень тяжело настроить коммуникацию. Вследствие такие сотрудники могут стать неуправляемые или создавать токсичную атмосферу.
Опыт. На собеседовании важно просить кандидата подробно рассказывать о проектах, процессах в компании и задачах, с которыми он работал. Для заказной разработки это bare minimum. Важно, чтобы процессы не отличались кардинально, иначе это совсем другой темп работы, и уходит много времени на его обучение.
Ожидания. Краткое описание вакансии чаще всего верхнеуровнево показывает, с чем кандидат столкнется в работе. В найме всегда нужно честно и прозрачно рассказывать о процессах и предстоящих задачах, чтобы не создать ложных ожиданий.
Не всегда отсутствие желаемых результатов означает некомпетентность сотрудника.
Пока ИИ не занял наши места, мы все еще человечны и причины у нас тоже могут быть человечные. Бывают случаи, когда сотрудник хороший, но что-то в работе не клеится. Причин на то может быть, как снега зимой, но разберем, когда стоит прийти на помощь:
Совершает ошибки, но готов к фидбэку и здоровой критике.
Хочет работать над ошибками.
Проблема не в компетенции, а в фокусе.
Личные обстоятельства, на которые можно повлиять. Например, сложный график работы из-за разных часовых поясов.
Дать ментора, поставить понятные цели, сформировать друг у друга правильные ожидания. Лучше всего назначить контрольные точки: «через 2 месяца от тебя ожидаем…».
Дать конструктивный и аргументированный фидбэк. Не просто «ты слабый специалист», а «тебе нужно научиться/исправить/освоить…, но ты уже хорошо делаешь…».
Регулярный синк по результатам на контрольных точках.
Нет прогресса, несмотря на поддержку и наставничество.
Регулярные ошибки, несоответствие KPI/оценкам.
Затраченные ресурсы несоизмеримы с результатом.
Команда перестала доверять сотруднику или работу приходится переделывать коллегам
Своевременно фиксируем проблемы – документируем конкретные случаи, сроки и последствия.
Даем конкретный срок на улучшение – 2–3 контрольные точки с четкими целями и метриками.
Регулярный мониторинг – синки, отчеты, обратная связь по каждому этапу.
Если прогресса нет — готовим уход.
Работа над «бесполезностью» начинается еще на этапе найма — с того, как вы выбираете людей и как потом помогаете им раскрыться. Не спешите увольнять при первых недочетах: отсутствие результата не всегда значит некомпетентность. Иногда это про стресс, личные обстоятельства или перегруз. Дайте шанс: обозначьте конкретные контрольные точки, договоритесь о понятных целях, дайте честный и конструктивный фидбек. Если после поддержки и прозрачных критериев прогресса нет — значит, пришло время принять трудное, но честное решение. Главное — собрать команду, где каждый создает ценность и растет вместе с продуктом.
