Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий
Шрифт:
На 2-х недельный спринт и команду в 3–4 человека планируем минут 40–60. На месячные спринты или большие команды может уйти часа полтора. Я бы не советовал делать ретроспективы еще длиннее – это контрпродуктивно.
Иногда уместна пицца: задушевные разговоры за едой сплачивают команду и снижают уровень агрессии.
Один человек будет ведущим. Как правило – скрам-мастер или менеджер, если он совмещает эти роли.
Первые пару минут включаем команду в
Здороваемся, налаживаем контакт.
Альтернативные техники, которые мне нравятся:
1. 10-пальцевый опрос. Попросите всех выбросить на пальцах, насколько довольны текущим спринтом.
2. Happiness radar. Чертим матрицу 3x3. По вертикали – смайлики настроения. По горизонтали – Технологии, Люди, Процесс. Каждый ставит палочку, насколько удовлетворен каждым из аспектов. Стикеры нужны для фиксации предложений по ходу.
3. Проверка безопасности. Просим также на пальцах выкинуть, насколько каждый себя чувствует сейчас в безопасности.
Напоминаем цель ретроспективы. Если есть новые участники, не привыкшие к ретроспективам – рассказываем про формат и гарантируем безопасность. Рассказываем про «намеренно никто не гадит».
Далее просим по кругу рассказать о плюсах (хорошем) и минусах (плохом) на спринте. Начинайте не с новичков. Идеи приветствуются и фиксируются, но не критикуются.
Знаю пару ребят, которые ведут блокнотики и записывают туда всю бяку по ходу спринта. А потом зачитывают по пунктам. Боюсь, что если прочитать вслух блокнотик от корки до корки, – явится ноющий дьявол. Но раз им так проще – пусть пишут.
Модератор должен чувствовать настроение команды. Уметь разговорить. Уметь слушать. В споры не вступать. Не говниться. Не обесценивать предлагаемые идеи. Модерировать, если идет неконструктивный треп. Подталкивать к поиску решений. Параллельные потоки (когда параллельно обсуждается парочка-другая тем) и болтовню – закрывать. Вытаскивать тыкающихся в телефон наружу. Стараться выявить те проблемы, в которых команда старается не сознаваться даже сама себе.
Модерируем глупые споры, является ли озвученная проблема проблемой. Или про важность проблем. Вместо споров – просто фиксируем. Может, человеку это важно.
Это не каноническая техника ретроспектив. Но иногда я так делаю.
Я люблю порой посидеть на чужих ретроспективах. Одна из интересных проблем, с которой сталкиваешься в сработавшихся коллективах, – ребята не любят взрывать медленно тлеющие конфликты. Всех бередит, но по-тихому.
Например, между тестировщиком и программистом возникла вялая напряженность из-за того, что тестировщик очень тщательно и придирчиво все проверяет. А программист считает, что это излишние придирки и пиксель-дрючево. Но вслух никто ничего не высказывает. Так, срутся в комментах
Одна из интересных задач модератора – по косвенным признакам найти такой конфликт и вскрыть (взорвать) его. Еще дядька Макаренко завещал.
Впрочем, на ровном месте накалять не надо. И так, знаете ли, хватает!
Нам нужны идеи. Что поменять, чтобы стало чуть легче и светлее. На первой стадии годятся любые, самые безумные мысли. Критиковать идеи нельзя. Отсев будет дальше.
Тут важно выделить две фазы, как в брейншторме:
1. обсуждение проблем и генерация идей по устранению проблем;
2. выбор среди тех идей, которые будем реализовывать.
В идеале, на каждый наш минус придумываем две-три идеи по его устранению. Собираем, аккуратно записываем. Могут помочь техники из главы 11 по работе с факапами.
Далее из идей выбираем несколько (5±2) конкретных улучшений, которые команда готова сделать. Устройте голосование, если идей целая куча. Желательно успеть за следующий спринт.
Некоторые типы идей я отсеиваю. Или прошу переформулировать.
1. «Мы работали плохо, теперь давайте работать лучше».
Спасибо за лозунги. Но я не знаю, как это реализовать.
2. «Не жрать после 18:00» или «Проводить стендап за 10 минут ровно».
Богатая идейка! Больше похожа на правило.
Если бездумно добавлять правила – место кончится. Или будет вагон правил, которые не блюдут. А это дискредитирует власть. Или это будут правила, которые помнит только их автор. И ненавидит коллег за несоблюдение.
Переформулируйте на локальное и исполнимое: «Не жрать после 18:00 в течение следующего спринта», например. Вот это реалистичнее.
3. «Давайте будем закладывать больше времени на подготовку и архитектуру».
Во-первых, это тоже правило. Во-вторых, не люблю, когда добавляются буферы времени.
На это есть Закон Паркинсона: работа занимает все отведенное на нее время. И даже чуть больше. Сколько буферов ни закладывай – будет мало.
Давайте лучше адекватно оценивать задачи и делать дело так быстро, как это возможно, не?
4. «Давайте проверять после тестировщика – другим тестировщиком».
Ну уж нет! Чем больше проверяющих, тем хуже качество. Зачем мне стараться, если за мной перепроверят и под носом подотрут? Рассеивается ответственность.
Я хочу «встроенное» качество как можно ближе к центру создания ценности. Я хочу встроенное в программистов качество. И они это могут!
5. «Пусть менеджер нам кофе приносит. С козинаками. И веером нас обдувает».