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

Совет

Немного помогает, если у заказчика есть доступ на чтение баг-листов, и он видит, что команда нашла и исправила несколько сотен ошибок. Но утешение слабое, осадочек остается. Отправлять баг-листы нужно до того, как претензия созреет, а не после. Действовать от силы, а не от слабости. При этом должна быть определенная культура ведения баг-листов: смотрите главу «Правила письменной контрацепции». Однако лучше всего попадать в ожидаемое качество и давать гарантию на свою работу.

Говорят, в Царской России при испытании нового железнодорожного моста под него ставили всех строителей. А сверху пускали паровоз. Мосты век стояли. А разработчик – либо герой, либо – труп.

Нужно демонстрировать результат работы лично, ставить шкуру на кон! Это бодрит. Подстегивает ответственность и рост качества продукта. Боли, правда, будет больше. Но это полезная боль.

Согласуйте демонстрацию заранее. Если проект долгоиграющий – запланируйте стандартное время, в которое будете показывать спринты. Например, каждый вторник, 16:00. Времени резервируйте около часа. Нужна будет либо личная встреча, либо видеосвязь с демонстрацией экрана.

Со стороны бизнеса присутствует как минимум Product Owner. Пользователи и другие сочувствующие – допускаются. Со стороны разработки – вся команда. Понятно, что бывают исключения, но стремимся к этому.

Для начала я вкратце рассказываю, что успела команда за спринт. Вспоминаем цели спринта. Дальше, с экрана, показываю инкремент. Команда помогает, рассказывая, что, как и почему было сделано. В идеале каждый рассказывает про свой вклад. Разработчики помогают с ответами на технические вопросы и обоснованием решений.

Ради чего все это затевается: обратная связь в режиме реального времени. Пусть жесткая, но честная. По сути, обсуждается только первое впечатление, но оно не врет. WYSIWYG – What You See Is What You Get, или «если тебе кажется, что что-то не так, – скорее всего, тебе не кажется».

По опыту большая часть обратной связи будет конструктивной и позитивной. Особенно с англоговорящими заказчиками. Бояться демонстраций не надо. Надо готовиться. Продумайте чуть заранее:

▶ По каким путям проведете зрителей в продукте.

▶ Какие кейсы покажете.

▶ Какие могут понадобиться данные для демонстрации: контент, тестовые пользователи и так далее.

▶ Какие вопросы скорее всего возникнут. И как на них отвечать.

Позднее Product Owner может потребоваться время помедитировать, поразглядывать продукт, поиграться с ним. Но это он будет делать в одиночестве, сублимируя в бэклог. Возникшие вопросы ему будет не с кем обсудить, и, наверное, он будет предполагать только худшее. Но с этой проблемой он должен справиться сам.

Мы же зафиксируем обратную связь и пойдем с ней на ретроспективу.

Аварийное завершение спринта

Редко, но гадко. Бывает, приходится останавливать спринт. Дело идет медленно и не туда. Команда упарывается, нужных доступов нет, кризис у клиента или еще какая-нибудь гадость. Дергаем стоп-кран, останавливаем спринт. Проводим ретроспективу, решаем проблемы. Делаем рескоупинг (перепланируем спринт). Едем дальше. Таких форс-мажоров допустимо не больше 5 %. Ибо нефиг.

Допустим, на демонстрации Product Owner разнес вашу работу в пух и прах. Справедливо, методично. Или просто очень эмоционально: он оказался злобным, неуязвимым говнюком. Команда сидит подавленная. Кто-то курит прямо в опенспейсе. Провал. Полный капут. «Что я тут делаю?» – читается в глазах бородатых программистов. Пятница, вечереет. Ваши действия?

Рохля разведет руками. Распустит команду по домам. Ага, щас! Мы пойдем в ближайший бар. И будем всякую фигню думать. Про процессы. Технологии. И ме-е-неджера. Рано его руководить поставили.

Люди будут смаковать неудачу, искать причины провала. На минуточку, не в себе, а в руководителе продукта, менеджере, проекте или процессах. Сами выберут такую позицию, когда они – Д’Артаньяны, а остальные – нет. И будут ныть. Пару-тройку раз повторятся такие ситуации, и дело разладится.

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