В сложившихся условиях неопределённости и паники важно уметь сосредоточиться на повышении эффективности своих команд.
Лучшие практики по оптимизации проектного менеджмента на долгосрочную перспективу показывают: чтобы бизнес продолжал приносить запланированные результаты, QA-менеджерам и руководителям команд стоит периодически задавать себе следующие вопросы:
- «Как мне успешно вести проект и непрерывно улучшать свои показатели?»
- «Как оперативно отслеживать и гибко реагировать на изменения внешних и внутренних условий: бизнес-целей клиента, ситуации на рынке, атмосферы внутри команды?»
- «Есть ли на проекте скрытые проблемы, которых я не вижу, но которые могут принести существенный вред?»
В этой статье опытные специалисты в области QA компании «Точка качества» делятся, как метод ретроспективы помогает увидеть часто встречающиеся проблемы и как решить большинство из них.
Инструмент для решения типичных проблем на проекте
Вдобавок к получению ответов на вышестоящие вопросы, проведение ретроспективы повышает для менеджера в QA прозрачность процессов на проекте и при этом вовлекает во внутреннюю культуру улучшений всю команду.
В зависимости от целей выделяют три вида ретроспективы:
В ней участвует и принимает решения вся проектная команда без исключения (тестировщики, разработчики, бизнес-аналитики, дизайнеры и т. д.).
Проводится в рамках конкретной проектной команды или внутри команды по тестированию отдельно от разработки и других подразделений. Она может подготавливать участников к общей ретроспективе либо проходить как отдельное мероприятие для улучшения процессов и решения специфических проблем.
- Внутренняя ретроспектива.
Менеджер может проводить ретроспективу для себя после окончания работ на проекте, чтобы проанализировать и структурировать свой опыт «по горячим следам». Это позволяет закреплять и применять успешные практики управления в будущем.
В зависимости от размера проекта, команды и количества проблем частота проведения ретроспективы может варьироваться от одного раза в неделю до одного раза за весь срок проекта (например, при его завершении). Но наиболее эффективной она является при регулярных повторениях, например, раз в две–три недели по окончании итерации.
Кроме того, ретроспектива может проводиться:
- в конце определённой фазы проекта;
- после каждой итерации (для Agile-программ);
- при завершении проекта;
- в любой момент при возникновении проблем.
Как правильно настроить процесс и что учесть для получения максимального результата? Читайте далее, чтобы узнать.
Процесс проведения ретроспективы
Стандартно ретроспектива начинается с этапа «открытия», который помогает настроить команду на рабочий лад, чтобы каждый участник мог спокойно и конструктивно высказывать своё мнение и вместе с остальными членами команды работать над поиском оптимальных решений.
Для этого применяются warm-up-техники и игровые элементы (карты, кубики), так как геймификация положительно сказывается на результатах. На этапе сбора мнений каждому участнику предлагается вспомнить прошедший отрезок времени (итерацию, релиз) и ответить на три вопроса:
- С какими задачами команда справилась удачно?
- Выполнение каких задач не было успешным?
- Какие ошибки можно исправить?
Это наиболее распространённый вариант, но существуют и другие. Например, подход Starfish предлагает основываться на следующих пунктах:
- Start doing: что нужно начать делать.
- Stop doing: что нужно прекратить.
- Continue doing: это хорошо работает, нужно продолжать делать.
- More: этим активностям нужно уделять больше внимания.
- Less: на эти активности нужно тратить меньше времени.
Собрав таким образом обратную связь от всех участников проекта, общая картина становится очевидной, и определить сильные и слабые стороны становится проще. Также становятся ясны ценности команды и можно проверить, приятен ли социально-психологический климат, есть ли скрытое недовольство.
Далее следует самый продолжительный этап ретроспективы, когда участники обсуждают каждую проблему и генерируют идеи, как её можно решить. Однако прежде чем перейти непосредственно к поиску вариантов решения, стоит сосредоточиться на самых главных для проекта трудностях, отсеяв мелкие и незначительные.
Сделать это можно с помощью голосования, когда каждый участник выбирает от одного до трёх пунктов, наиболее важных для него самого и для проекта. Количество голосов зависит от размера команды и объёма собранного материала на предыдущем этапе.
Проблемы, набравшие наибольшее количество голосов, признаются высоко приоритетными. Затем команда фокусируется на их обсуждении и старается найти наиболее выгодные пути решения (обычно это происходит в формате brainstorm).
По окончании обсуждения составляется план действий, где каждой приоритетной проблеме соответствует набор конкретных шагов. Также очень важными моментами плана является назначение ответственного и ожидаемой даты исправления для каждого пункта.
После этого остаётся провести закрытие ретроспективы, поблагодарив всех участников за их вклад в улучшение процессов, и убедиться, что все результаты задокументированы. Для фиксирования обсуждений можно использовать любой удобный инструмент. Главное, чтобы у каждого участника был доступ ко всем материалам и артефактам ретроспективы.
Процесс проведения ретроспективы
Ретроспектива длится от 1 до 3 часов, в зависимости от размера команды и продолжительности итерации. Чтобы сделать мероприятие более продуктивным, каждому участнику стоит заранее подготовить свои пункты и собрать идеи улучшений.
Важно сделать ретроспективы интересными, чтобы они не стали очередной рутинной задачей, а команда была мотивирована на конструктивное обсуждение и совместный поиск лучших решений. Например, можно использовать такие виды практик, как голосование для выбора Captain Sprint – человека, который лучше всего проявил себя во время спринта; обсуждение по методу «Шести Шляп»; геймификация с помощью Лего и другие.
Грамотное управление обсуждением поможет участникам не уходить в сторону от целей ретроспективы и не тратить время зря. А умение разряжать обстановку и решать конфликты позволит всем высказываться свободно и держаться в рамках конструктивного диалога.
Кроме того, назначение ответственного и обсуждение сроков по всем задачам стимулирует участников команды воспринимать договоренности ретроспективы всерьез и прилагать больше усилий для их реализации.
Периодически полезно пересматривать договоренности и анализировать их (сделано/не сделано, сработало/не сработало). Поэтому часто очередную ретроспективу начинают с обзора плана действий с предыдущей встречи и его обновления.
Помните, что выявление «слабого звена» и причины неудач участников проекта не поможет сфокусироваться на поиске решения. Лишь
QA-команда, которая действует как единый механизм и осознаёт это, способна добиться наилучших результатов.
Ретроспектива не панацея от всех проблем на проекте. Это полезный инструмент, который при грамотном использовании поможет сделать работу проектной команды более прозрачной, следить за положительным «климатом» в коллективе и выявлять слабые места до того, как они перерастут в серьёзные проблемы.
Нужна профессиональная помощь с тестированием ПО?
Напишите нам!
