Недавно я просмотрел довольно интересную презентацию на тему руководства группой разработчиков программного обеспечения от Роя Ошерова. Презентация мне очень понравилась и в догонку я решил прочитать его книгу, на ту же тему. Из предыдущего опыта с автором я ждал многого.
Рулить группой программистов довольно интересное занятие, в особенности в ситуации, когда компания в лице менеджмента марширует под лозунгом Аджайла и самоорганизующейся команды, а на месте у руководителя нет полномочий принимать решения, плюс он завален всеми техническими проблемами. Как говорится: “денег нет, но вы держитесь”. Многие программисты и менеджеры ошибочно считают, что руководитель команды является основным программистом – цели и задача которого чинить косяки, помогать всем и без посторонней помощи допиливать релиз. Как ни странно, но такое я наблюдал как в своей компании, так и на интервью в другой компании, где вопрос ставился ребром: “сроки горят, денег нет, вариантов не осталось, ты руководитель, что будешь делать?”.
Автор обьясняет, что задача руководителя состоит в том, чтобы вырастить команду и как итог получить ту самую мифическую “самоорганизующуюся команду”. В команде должна быть дисциплина, ответственность и умение решать свои проблемы. Как же руководитель должен это все сделать, в описанной выше ситуации? В книге рассматриваются 3 состоянии команды: хаос, рост и само-управление. На каждой стадии руководитель играет разную роль и динамика команды меняется. Интересная заметка: как узнать если ваша команда находится на стадии хаоса? Задайте один вопрос: у команды есть “лишнее” время (на учебу и эксперименты)? Если нет, то вы в стадии хаоса.
Изначально руководитель занимает роль диктатора, цель и задача которого: ограничить количество и установить границу в плане доставляемой работы, тем самым получить время для развития команды. На этой стадии диктатор принимает все технические решения, даже если команда этого не хочет, например “мы используем гит для хранения и версионности кода”. Режим диктатора ни в коей мере не должен быть постоянным и служит исключительно одной цели – выбраться из хаоса. Стадия хаоса является самой сложной по многочисленным причинам. Первая причина психологическая: руководитель себя чувствует комфортно, работая героем: “я лично починил косяк в продакшене, все меня любят, начальство ценит и какой всплеск адреналина”, вообщем “я Дартаньян, а все пи…”
Вторая причина практическая: руководителю нужно выбить ресурсы – время, вызвав на ковер бизнес/начальство. Тут прийдется торговаться, бороться и говорить “нет”. Это занятие опасное для карьеры – она может быстро прерваться. Однако, если у команды нет времени думать, учиться и пробовать, то команда так и останется в стадии хаоса.
Следующая стадия – рост. В этой стадии руководитель занимает роль наставника, он должен проводить много времени с командой, как обучая, так и подталкивая индивидуальных членов команды к росту. Цель и задача этой стадии в том, чтобы команда не нуждалась в руководителе. Автор приводит много интересных тактик для роста. Одна важная тактика: когда член команды приходит с проблемой (технической или социальной), внимательно выслушав, руководитель должен задать один вопрос: “Что ты будешь по этому поводу делать?”. Автор отмечает, что вопрос может показать человеку грубым и отталкивающим, однако это заставляет “пациента” думать и решать свои собственные проблемы. Тут важно отметить, руководитель не должен оставить все на самотек, однако он не должен все время решать все проблемы – трюк в том, чтобы подтолкнуть человека к решению своих собственных проблем. Интересная заметка: если вы боитесь, беспокоитесь, не уверены, чувствуете себя не комфортно – это значит что вы учитесь! Вы вышли из зоны комфорта и попали в новое русло. Данная стадия нужна для того, чтобы все члены команды научились решать свои проблемы, научились учиться и выходить из зоны комфорта.
Не менее важный момент стадии роста это дисциплина! Нет не армейская, а дисциплина по доставке обещанного. Если команда не доставляет обещанные фичи бизнесу, то жизнь станет крайне сложной и вполне может вернуться на стадию хаоса. В этом плане, автор рекомендует использовать командный язык: “я доделаю фичу к 18:00 сегодня”, “я вышлю спецификацию после встречи сегодня в 13:00” и так далее. Теперь все программисты знают, что многие вещи не возможно доставить в определенный срок – например починить баг. Может баг простой, а может засосать на очень долго. С этого ракурса нужно использовать технику тайм-боксинга (ограничения по времени) и сказать: “я буду работать над этим багом 2 дня”. Если по истечению времени баг все ещё не отремонтирован, то можно остановиться и пересмотреть решения, как технические, так и ресурсные – добавить время, добавить программиста, перенести проблему на следующий релиз и тому подобное.
Последняя стадия – самоуправление. В этой стадии руководитель занимает пассивную роль – переставая на прямую управлять командой и отдавая бразды правления команде. Руководитель фокусируется на ограничениях вокруг команды, помогая из вне. Насколько я понимаю, эта та самая стадия, которая описывается в книгах по скраму (scrum), где нет руководителя.
Книга весьма интересная, но короткая – всего 200 страниц! Автор правильно подобрал название: “Заметки… “, а не «Полное руководство…». Также стоит отметить, что в книге есть опечатки и кривое форматирование. Как говорил Даниэль Суарэз: у вас есть все возможное время, когда вы пишете свою первую книгу, а после этого нужно укладываться в рамки. Не уходя от критики, книга разбита на две части: заметки от самого автора и вторая половина: гости. Вторая половина книги устроена простым принципом: один гость, одна глава. Хотя бывает, что один и тот же гость пишет две главы. Каждая глава большое напоминает быстрый рецепт к “выздоровлению” и местами отдает рекламой другого материала. Справедливости ради, некоторые темы достойны отдельной книги, но все же, возможно стоило сфокусировать, добавить авторов и расширить материал – хотя это спорный момент.
Итого:
+: Простое и доступное изложение
+: Детальное обсуждение проблем и решений
+: Чувствуется аутентичный опыт автора
+: Хороший возврат по затратам (ROI)
-: Книга короткая и хотелось бы больше сценариев по управлению командой
=: Книга хорошая и будет полезна многим программистам, в особенности тем, кто уже или собирается стать главой/руководителем команды разработчиков. Я советую посмотреть семинар, если вам он показался полезным то вперёд за книгой. Бэкап копия семинара
Название: Notes to software team leader
Авторы: Roy Osherove
Обложки:
