Что делать, если разработчик работает хорошо, но очень медленно
Всем привет! Меня зовут Александр Борщев, я тимлид в компании AGIMA. В нашей команде работают разработчики с разными темпами работы, а одной из ключевых задач тимлида является умение находить общий язык с каждым из них. В то время как с быстрыми разработчиками проблем с выполнением задач, как правило, не возникает, работа с теми, кто движется медленнее, может стать настоящим вызовом, особенно когда речь идет о соблюдении дедлайнов или в проданную оценку заказчику.
Некоторые разработчики могут намеренно затягивать выполнение задач по различным причинам: от лени до работы на несколько фронтов одновременно. В таких случаях, на мой взгляд, лучше всего рассмотреть возможность увольнения. Однако есть и те, кто не халтурит, а просто не может работать быстрее. В этой статье я хотел бы поделиться своим опытом работы с такими разработчиками, а заодно спросить о вашем.
Проблема, понятная каждому
Важно помнить, что специалистов, которые делают задачи одновременно быстро и качественно, найти бывает нелегко. Часто крутым профессионалам требуется чуть больше времени, чтобы выполнить работу — и это объяснимо. Поэтому скорость работы не определяющий фактор при подборе команды. И да, иногда нам всем приходится работать с людьми, чей темп несколько ниже, чем тот, которого мы ожидаем.
Особенно сильно это может влиять на команды, работающие по fixed price. Для них важно, чтобы все были максимально продуктивны и всегда укладывались в заявленные сроки, — от этого, по сути, зависит доход. Но есть и другие объективные факторы: некоторые люди сами по себе довольно спокойные и привыкли работать неторопливо. Мы не можем это изменить, потому что эта особенность как бы вшита в характер человека. Как правило, она компенсируется другими сильными качествами — стрессоустойчивостью или высокой внимательностью.
Однако разработка часто требует быстроты — сроки обычно жесткие. И если мы не можем «ускорить» человека, то можем по крайней мере минимизировать негативные последствия, чтобы добиться предсказуемых результатов. Ниже разберу основные способы.
1. Ставьте четкие задачи и просите декомпозировать оценку
Чем яснее будет сформулирована задача, тем меньше времени разработчик потратит на ее понимание. Вообще это полезно для всех, но особенно важно для тех, кто работает медленнее. Также стоит просить разработчика оценивать, сколько времени ему потребуется на задачу, и расписывать эту оценку детально. Это поможет ему составить план действий и лучше организовать работу.
2. Проводите регулярные встречи
Регулярные встречи один на один помогут выявить сложности, с которыми сталкивается разработчик. Возможно, проблема не в том, что он сам по себе медленно работает, а в том, что он испытывает трудности на каком-то этапе — например, на этапе тестирования.
Некоторые разработчики просто привыкли работать в одиночку и не знают, как просить о помощи. Дали задачу — значит, ее нужно решить, а попросить помощи особо не у кого. Со временем к этому привыкаешь и уже сложно обратиться к тимлиду или более опытному разработчику, даже когда возникают трудности.
Поэтому важно создать атмосферу, в которой команда будет чувствовать себя комфортно обращаясь за поддержкой.
3. Старайтесь ни на кого не давить
Не рекомендую быть чересчур строгим по отношению к разработчику. Это может привести к стрессу и выгоранию, что, в свою очередь, только замедлит процесс. Если человек привык и умеет работать неторопливо, заставлять его писать код быстрее или каким-то образом указывать на его медлительность — это очень скользкий путь. У большинства людей такой подход вызывает вполне понятные реакции:
хронический стресс и, как результут, выгорание;
потеря мотивации;
закрытость, недоверие и нежелание рассказывать о блокерах;
ухудшение качества работы как результат спешки.
Вместо этого, наоборот, стоит создавать здоровую атмосферу. Человек должен быть готов спокойно рассказать о проблеме (если проблема вообще есть), не боясь получить по шапке. Для этого стоит просто быть открытым:
откровенно обсуждайте проблемы;
давайте позитивную обратную связь;
способствуйте обучению и развитию команды.
4. Время от времени переводите людей с проекта на проект
Когда в компании несколько команд, можно перевести медленного спеца на другой проект. Во-первых, это, вероятно, поможет улучшить производительность, а во-вторых, так проще найти причины ситуации. Вот как это работает и почему полезно:
Новая среда и культура могут вдохновить разработчика на новые идеи и подходы, которые он не рассматривал ранее. Иногда смена обстановки может помочь разработчику переосмыслить свои методы работы и повысить мотивацию.
Обратная связь от новой команды поможет найти точки роста или новые, более эффективные инструменты. А всё вместе это может благотворно влиять на продуктивность разработчика.
Разнообразие задач помогает нащупать те темы, в которых разработчик чувствует себя как рыба в воде. Кроме того, если внимание иногда переключается с задачи на задачу, улучшаются навыки и растет уверенность в своих силах.
Обмен опытом позволит специалисту перенять лучшие практики и подходы у новых коллег, а это никогда не бывает лишним. Плюсом опять же потенциальный рост продуктивности — новые подходы и процессы могут помочь.
Идентификация проблем. Если разработчик работал медленно в одной команде и стал работать быстрее в другой, в первой, возможно, есть проблемы. Они могут быть связаны с коммуникацией или с постановкой задач, но проверить точно стоит.
При перемещении разработчика в другую команду важно обеспечить ему поддержку и менторство. Назначение более опытного коллеги в качестве наставника поможет ему быстрее адаптироваться в новой среде и получить необходимые знания для повышения своей продуктивности. Кроме того, нельзя забывать об анализе собственных решений. Если трансфер прошел успешно, через некоторое время стоит вернуться и проверить производительность. На основании этого можно сделать выводы о причинах промедлений.
5. Контролируйте оценки
Также можно использовать метод брейкпоинтов. Это когда оцененное время делится на несколько этапов, например, 25%, 50% и 100%. Хотя 100% подразумевает завершение задачи, важно понимать, что не все можно учесть заранее. Работать это будет так:
Оценили задачу на 30 часов.
Отработали 25% времени (7–8 часов), остановились и провели self-check.
На этом этапе мы либо пониманием, что задача выполняется в соответствии с оценкой, блокеров нет, пробуксовок тоже нет. Либо понимаем, что всё плохо, и мы, вероятно, не уложимся. Если видим риск не уложиться в оценку, пишем комментарий тегаем тимлида и руководителя проекта. В комментарии нужно объяснить причину проблемы и дать дооценку.
То же самое и с 50% (~15 часов). Здесь нужно уже более подробный self-check. При необходимо можно подключать тимлида для принятия решения. Нужно понять, не блокирует ли что-то вторую половину задачи. Это последний шанс сообщить тимлиду, что изначальная оценка была неверной, и попробовать согласовать с заказчиком дооценку или сдвинуть время дедлайна
Заключение
Работа с медленными разработчиками требует комплексного подхода. Если скорость специалиста вас не устраивает, нужно первым делом разобраться, в чем проблема. Это нормальный темп человека, в котором он, хоть и не спеша, пишет отличный код? Тогда проблема в сроках и дедлайнах. Возможно, достаточно просто перевести человека на другой проект или в другую команду.
В любом другом случае нужно искать корень проблемы. Он может быть в процессах, в коммуникации, в постановке задач, в самих задачах. Специалист может не подходить для тех обязанностей, которые ему поручили. А может быть, он просто-напросто филонит? Или работает одновременно на двух работах? Чтобы проверить все возможные варианты, можно перекинуть его на другой проект, внимательнее следить за оценкой задач, просто откровенно поговорить или всё это сразу.
Поделитесь своим опытом в комментариях. Что вы делаете, если кто-то работает медленнее остальных? Расскажите свои истории и дайте советы. А еще подписывайтесь на наш канал для тимлидов.
Что еще почитать
Базовый набор тимлида: от каких убеждений стоит отказаться, чтобы команда тебя не возненавидела
Стоит ли идти в тимлиды? История о том, как меня повысили и что я теперь об этом думаю
Как не сжечь команду дотла, или Почему Work-life balance — задача руководителя
