Коучинг разработчиков вместо прямых указаний
Узнайте, почему директивный стиль снижает ответственность инженеров. Освойте практические техники коучинга, которые помогут разработчикам в Scrum принимать самостоятельные технические решения.
Большинство лидеров получают повышение за успешное решение технических проблем. Когда они начинают руководить командой Scrum или на проект приходит опытный Scrum Master, инстинкт подсказывает раздавать готовые ответы. В моменте это кажется эффективным. Вы замечаете узкое место в архитектуре, говорите команде, как переделать базу данных, и работа продолжается. Однако каждый раз, отдавая указание или решая проблему самостоятельно, вы ослабляете команду. Руководство по Scrum четко указывает, что Developers являются самоуправляемыми. Они сами решают, кто, что, когда и как делает. Если вы ими командуете, самоуправление исчезает.
Скрытая цена прямых указаний
Когда вы руководите директивно, вы лишаете разработчиков чувства ответственности за результат. Если инженер внедряет именно ваше предложение, а релиз падает в полночь, это уже не его провал. Это ваш провал. Специалисты перестают глубоко вникать в архитектуру системы, краевые случаи и качество, поскольку привыкают, что им всегда подскажут следующий шаг. Со временем сильные специалисты уходят, а оставшиеся превращаются в пассивных исполнителей.
В Scrum именно Developers отвечают за создание плана на Sprint, формирование Sprint Backlog и обеспечение качества через соблюдение Definition of Done. Невозможно требовать ответственности за результат от человека, если вы сами диктуете ему каждый шаг.
Сильные вопросы вместо готовых ответов
Коучинг помогает людям самостоятельно находить решения. Вместо того чтобы объяснять разработчику, как переписать API, вы задаете вопросы, направляющие его анализ. Это меняет настрой специалиста с пассивного подчинения на живой исследовательский интерес.
- Какой риск вы пытаетесь снизить с помощью такой схемы базы данных?
- Как данный выбор реализации повлияет на наш Definition of Done?
- Если этот сервис откажет под высокой нагрузкой, где сбой проявится в первую очередь?
- Какой минимальный шаг мы можем сделать, чтобы проверить эту гипотезу до Sprint Review?
Обратите внимание, что ни один из этих вопросов не содержит скрытого приказа. Ловушка, в которую попадают многие коучи, заключается в наводящих вопросах вроде: 'Не думаешь, что здесь стоит применить кэширование?' Это директивное указание под маской коучинга. Настоящие коучинговые вопросы остаются открытыми и побуждают к глубокому анализу.
Право на самостоятельный поиск решений
Качественная инженерная работа требует продуктивных усилий. Если разработчик два часа ищет причину нестабильного теста или разбирается со сложным багом конкурентного доступа, у вас может возникнуть соблазн вмешаться. Сдержите этот порыв. Вмешивайтесь только тогда, когда поиск перерастает в тупик и раздражение, либо когда команда прямо просит о помощи.
Руководство по Scrum говорит о том, что Scrum Master служит команде, обучая ее принципам самоуправления и кроссфункциональности. Коучинг требует терпения. Нужно позволять людям совершать небольшие, легко исправимые ошибки в течение Sprint, чтобы они могли извлечь из них уроки на Sprint Retrospective.
Изменение подхода в ежедневной практике
Переход от указаний к коучингу не означает отказ от технических стандартов или сокрытие экспертных знаний. Это меняет лишь последовательность взаимодействия. Когда участник команды приходит к вам со сложным вопросом, выслушайте его до конца, прежде чем говорить. Спросите, какие варианты решения он уже успел рассмотреть.
Часто разработчики уже знают верный ответ. Им просто нужен собеседник, чтобы проверить ход своих мыслей. Задавая вопросы вместо готовых решений, вы формируете автономную инженерную команду, способную создавать ценный Increment без постоянной зависимости от вас.