Что делать, если разработчик работает хорошо, но очень медленно

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

В статье Александр Борщев, тимлид AGIMA, разбирает пять управленческих приёмов: декомпозицию, регулярные встречи, работу без давления, перевод между проектами и контроль оценок.

Коротко

Наблюдение	Что проверить
Задача долго не начинается	Понятны ли результат, приоритет и первый шаг
Оценка растёт по ходу работы	Были ли учтены зависимости и неизвестные
Код качественный, но работа не заканчивается	Согласованы ли критерии готовности
Темп падает только на одном проекте	Хватает ли контекста и подходит ли предметная область
Сроки срываются системно	Нужны ли обучение, смена роли или пересмотр нагрузки

Проблема, понятная каждому

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

Особенно сильно это может влиять на команды, работающие по fixed price. В проектах с фиксированной стоимостью отклонение от оценки влияет на сроки и экономику проекта. Но есть и другие объективные факторы: некоторые люди сами по себе довольно спокойные и привыкли работать неторопливо. Мы не можем это изменить, потому что эта особенность как бы вшита в характер человека. Как правило, она компенсируется другими сильными качествами — стрессоустойчивостью или высокой внимательностью.

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

Сначала найдите причину

Возможная причина	Как проверить	Следующее действие
Неясная постановка	Попросить пересказать задачу и критерии готовности	Уточнить результат и ограничения
Ошибка оценки	Сравнить план и факт по этапам	Декомпозировать похожие задачи
Недостаток знаний	Посмотреть, где возникает ожидание или переделка	Дать наставника или время на обучение
Перфекционизм	Проверить объём работы сверх критериев готовности	Согласовать достаточный уровень качества
Перегрузка	Проверить параллельные задачи и встречи	Сократить незавершённую работу

Ставьте четкие задачи и просите декомпозировать оценку

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

Проводите регулярные встречи

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

Некоторые разработчики просто привыкли работать в одиночку и не знают, как просить о помощи. Дали задачу — значит, ее нужно решить, а попросить помощи особо не у кого. Со временем к этому привыкаешь и уже сложно обратиться к тимлиду или более опытному разработчику, даже когда возникают трудности.

Поэтому важно создать атмосферу, в которой команда будет чувствовать себя комфортно обращаясь за поддержкой.

Старайтесь ни на кого не давить

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

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

Вместо этого, наоборот, стоит создавать здоровую атмосферу. Человек должен быть готов спокойно рассказать о проблеме (если проблема вообще есть), не боясь получить по шапке. Для этого обсуждайте наблюдаемые факты:

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

Время от времени переводите людей с проекта на проект

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

Новая среда и культура могут вдохновить разработчика на новые идеи и подходы, которые он не рассматривал ранее. Иногда смена обстановки может помочь разработчику переосмыслить свои методы работы и повысить мотивацию.
Обратная связь от новой команды покажет, где специалисту не хватает контекста или инструмента. А всё вместе это может благотворно влиять на продуктивность разработчика.
Разнообразие задач помогает нащупать те темы, в которых разработчик чувствует себя как рыба в воде. Кроме того, если внимание иногда переключается с задачи на задачу, улучшаются навыки и растет уверенность в своих силах.
Обмен опытом даст специалисту другие способы декомпозиции и проверки решений. Плюсом опять же потенциальный рост продуктивности — новые подходы и процессы могут помочь.
Идентификация проблем. Если разработчик работал медленно в одной команде и стал работать быстрее в другой, в первой, возможно, есть проблемы. Они могут быть связаны с коммуникацией или с постановкой задач, но проверить точно стоит.

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

Контролируйте оценки

Также можно использовать метод брейкпоинтов. Это когда оцененное время делится на несколько этапов, например, 25%, 50% и 100%. Хотя 100% подразумевает завершение задачи, важно понимать, что не все можно учесть заранее. Работать это будет так:

Оценили задачу на 30 часов.
Отработали 25% времени (7–8 часов), остановились и провели self-check.

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

На отметке 50% нужен более подробный self-check. При необходимости подключают тимлида и проверяют, нет ли блокеров для второй половины задачи. Если исходная оценка неверна, ожидания и срок обновляют до дедлайна.

Заключение

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

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