В процессе работы на проектах в сфере IT, в том числе при тестировании ПО, у менеджеров и руководителей команд возникает ряд типичных, часто встречающихся проблем. Эта статья призвана их систематизировать и предложить единый инструмент, который способен решить большинство из них.
Одна из самых распространённых проблем менеджера в QA – его команда допускает ошибки в работе. Причём ошибки могут выражаться как в «пропуске» дефектов программного обеспечения, так и в проблемах с таймингом и коммуникацией, нарушением общего проектного процесса. Это список можно продолжать бесконечно.
Ещё одна довольно частая проблема, с которой менеджер может столкнуться, – это взаимодействие с командой, когда руководитель перестаёт четко понимать, что происходит на проекте.
Зачастую дела идут вроде бы довольно неплохо: и команда хорошо справляется, и дефекты «находятся», и документация актуализируется, и отчёты приходят вовремя. Но внутренний голос будто подсказывает менеджеру – что-то не так!
Вот-вот наступит какая-то неприятная ситуация, перерастающая в глобальную проблему. Возможно, команде просто перестал нравиться проект, на котором она работает, и задачи, которые на нем решаются. Или вы чувствуете, что главному техническому эксперту на проекте надоело заниматься тестированием и он со дня на день придёт и «заявит», что решил уйти в разработчики. При этом, согласно принципу Паретто (речь о соотношении 20 на 80), этот технический эксперт как раз входит в 20% эффективных ресурсов, делающих всю важную работу на проекте.
Итак, перед нами стоят реальные проблемы проектного менеджмента, которые надо как-то решать, выявив перед этим, в чем их внутренняя сущность. Одним из эффективных путей их выявления и решения является проведение т.н. ретроспективы.
Что такое ретроспектива
Понятие Ретроспекти́ва (от лат. retrospectare – «взгляд назад») трактуется в Википедии так: взгляд в прошлое, обозрение того, что было в прошлом. Применительно к области IT: ретроспектива – это систематическая командная деятельность, направленная на анализ результатов, с целью улучшения эффективности работы команды в IT-проекте.
По сути, это инструмент, широко применяемых в гибких методологиях, который нацелен на улучшение работы проектной команды путем анализа текущих результатов.
Что конкретно даёт менеджеру ретроспектива?
- Возможность выявления не самых очевидных проблем, которые существуют в процессе работы на проекте.
- Повышение эффективности проектной команды, как следствие решения этих проблем.
- Устранение «усталости» процесса (очевидно, что если проект длится более года-двух, то однообразность процесса может быстро надоесть, и в этом случае ретроспектива поможет «разбавить» процесс).
- Право участия и принятия решений всем участникам команды без исключения.
Как проводить ретроспективу
В структуре проведения ретроспективы можно выделить четыре основных пункта:
- сбор мнений (позитивных и не очень);
- голосование и выделение основных проблем;
- принятие решений;
- фиксирование результатов.
Для того чтобы упростить сбор мнений, лучше заранее определить те области проекта, по которым необходимо «пройтись» (например, коммуникация, качество тестирования и описания дефектов и т. п.). Вначале нужно «собрать» все плюсы, затем все минусы. После этого проходит голосование за наиболее приоритетные, по мнению команды, минусы (т. е. важнейшие проблемы).
В процессе голосования можно ограничить либо количество голосов, либо число выделяемых проблем. После того, как приоритеты расставлены, начинается самое сложное – поиски путей решения важнейших проблем. Чаще всего это мозговой штурм, последовательно проводимый по каждой проблеме.
Как часто нужно проводить ретроспективу проекта?
Очевидно, что для успеха в этом процессе, необходима база для обсуждения. Иными словами, проект должен достичь определенной стадии. При этом временная характеристика не столь важна и определяется индивидуально (решающим фактором является размер проекта). Например, часто ретроспективу проводят по завершении спринта/итерации/фазы/релиза/закрытия проекта.
Так, например, ретроспективу можно проводить после релиза.
- Во-первых, очевидно, что сразу после релиза программного продукта команда ещё находится в «собранном» состоянии, что способствует генерации идей.
- Во-вторых, у команды есть возможность оторваться от выполнения задач по проекту, поскольку срочных задач уже нет.
- Ну и в-третьих, между релизами проходит достаточный промежуток времени для накопления потенциальных проблем.
Оптимальнее всего митинг по ретроспективе запланировать за пару дней или даже за неделю до события. Тогда у команды будет время для предварительного анализа своих собственных «ощущений», что позволит ускорить опрос на митинге. Отталкиваясь от практики, в среднем по времени процесс ретроспективы может занимать от получаса до 2-3 часов. Поэтому удобнее проводить ее днём, чтобы с утра никто из команды не «спал», а вечером не спешил домой или по своим делам.
До митинга либо непосредственно в его начале необходимо определить фасилитатора или «человека-маркера». Он следит за регламентом ретроспективы и поддерживает динамику собрания. В идеале – это должен быть человек, не относящийся к группе управления проектом. Важно, чтобы он фиксировал озвученные факты и проблемы без их искажения.
Кроме того, фасилитатор должен обладать активной позицией и способствовать «массированному» высказыванию участниками своего мнения.
Когда все участники ретроспективы в сборе, начинается опрос и запись мнений (можно либо писать на доске, либо пользоваться стикерами и клеить их на стол). В рамках команды довольно удобно просто пройтись по пунктам и выделить наиболее приоритетные для решения. Далее последовательно обсуждается каждая проблема и фиксируются возможные решения, после чего выбираются наиболее оптимальные и реализуемые.
На митинге могут назначаться и сотрудники, ответственные за выполнение данных решений.
После завершения митинга «жизненно» необходимо подвести итог.
Оптимальным вариантом является письмо, отправленное всем участникам ретроспективы. В таком итоговом письме следует зафиксировать результаты и ещё раз «проговорить» пути их решения. Кроме того, обязательно стоит поблагодарить людей, которые потратили своё время и пришли на ретроспективу.
