Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

3. Накидывание на вентилятор

Далее просим по кругу рассказать о плюсах (хорошем) и минусах (плохом) на спринте. Начинайте не с новичков. Идеи приветствуются и фиксируются, но не критикуются.

Знаю пару ребят, которые ведут блокнотики и записывают туда всю бяку по ходу спринта. А потом зачитывают по пунктам. Боюсь, что если прочитать вслух блокнотик от корки до корки, – явится ноющий дьявол. Но раз им так проще – пусть пишут.

Модератор должен чувствовать настроение команды. Уметь разговорить. Уметь слушать. В споры не вступать. Не говниться. Не обесценивать предлагаемые идеи. Модерировать, если идет неконструктивный треп. Подталкивать к поиску решений. Параллельные потоки (когда параллельно обсуждается парочка-другая тем) и болтовню – закрывать. Вытаскивать тыкающихся в телефон наружу. Стараться выявить те проблемы, в которых команда старается не сознаваться даже сама себе.

Модерируем глупые споры, является ли озвученная проблема проблемой. Или про важность проблем. Вместо споров – просто фиксируем. Может, человеку это важно.

4. Подрывай!

Это не каноническая техника ретроспектив. Но иногда я так делаю.

Я люблю порой посидеть на чужих ретроспективах. Одна из интересных проблем, с которой сталкиваешься в сработавшихся коллективах, – ребята не любят взрывать медленно тлеющие конфликты. Всех бередит, но по-тихому.

Например, между тестировщиком и программистом возникла вялая напряженность из-за того, что тестировщик очень тщательно и придирчиво все проверяет. А программист считает, что это излишние придирки и пиксель-дрючево. Но вслух никто ничего не высказывает. Так, срутся в комментах к баг-листам, вяло препираются «баг-не-баг», на что улетает вагон времени и нервов. Копится недовольство: друг другом, проектом, менеджером, клиентом или погодой за окном.

Одна из интересных задач модератора – по косвенным признакам найти такой конфликт и вскрыть (взорвать) его. Еще дядька Макаренко завещал.

Впрочем, на ровном месте накалять не надо. И так, знаете ли, хватает!

5. Идеи. Генератор добра

Нам нужны идеи. Что поменять, чтобы стало чуть легче и светлее. На первой стадии годятся любые, самые безумные мысли. Критиковать идеи нельзя. Отсев будет дальше.

Тут важно выделить две фазы, как в брейншторме:

1. обсуждение проблем и генерация идей по устранению проблем;

2. выбор среди тех идей, которые будем реализовывать.

В идеале, на каждый наш минус придумываем две-три идеи по его устранению. Собираем, аккуратно записываем. Могут помочь техники из главы 11 по работе с факапами.

6. Хороший план! Плохой план

Далее из идей выбираем несколько (5±2) конкретных улучшений, которые команда готова сделать. Устройте голосование, если идей целая куча. Желательно успеть за следующий спринт.

Некоторые типы идей я отсеиваю. Или прошу переформулировать.

1. «Мы работали плохо, теперь давайте работать лучше».

Спасибо за лозунги. Но я не знаю, как это реализовать.

2. «Не жрать после 18:00» или «Проводить стендап за 10 минут ровно».

Богатая идейка! Больше похожа на правило.

Если бездумно добавлять правила – место кончится. Или будет вагон правил, которые не блюдут. А это дискредитирует власть. Или это будут правила, которые помнит только их автор. И ненавидит коллег за несоблюдение.

Переформулируйте на локальное и исполнимое: «Не жрать после 18:00 в течение следующего спринта», например. Вот это реалистичнее.

3. «Давайте будем закладывать больше времени на подготовку и архитектуру».

Во-первых, это тоже правило. Во-вторых, не люблю, когда добавляются буферы времени.

На это есть Закон Паркинсона: работа занимает все отведенное на нее время. И даже чуть больше. Сколько буферов ни закладывай – будет мало.

Давайте лучше адекватно оценивать задачи и делать дело так быстро, как это возможно, не?

4. «Давайте проверять после тестировщика – другим тестировщиком».

Ну уж нет! Чем больше проверяющих, тем хуже качество. Зачем мне стараться, если за мной перепроверят и под носом подотрут? Рассеивается ответственность.

Я хочу «встроенное» качество как можно ближе к центру создания ценности. Я хочу встроенное в программистов качество. И они это могут!

5. «Пусть менеджер нам кофе приносит. С козинаками. И веером нас обдувает».

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

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

Надо помогать команде самостоятельно справляться с проблемами, а не быть еврейской мамочкой. Следите за тенденциями.