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

Одна из самых распространённых проблем менеджера в QA – его команда допускает ошибки в работе. Причём ошибки могут выражаться как в «пропуске» дефектов программного обеспечения, так и в проблемах с таймингом и коммуникацией, нарушением общего проектного процесса. Это список можно продолжать бесконечно.

Ещё одна довольно частая проблема, с которой менеджер может столкнуться – это взаимодействие с командой, когда руководитель перестаёт четко понимать, что происходит на проекте. Зачастую дела идут вроде-бы довольно неплохо: и команда хорошо справляется, и дефекты «находятся», и документация актуализируется и отчёты присылаются вовремя. Но внутренний голос будто подсказывает менеджеру – что-то не так! Вот-вот наступит какая-то неприятная ситуация, перерастающая в глобальную проблему. Возможно, команде просто перестал нравиться проект, на котором она работает, и задачи, которые на нем решаются. Или вы чувствуете, что главному техническому эксперту на проекте надоело заниматься тестированием и он со дня на день придёт и «заявит», что решил уйти в разработчики. При этом, согласно принципу Паретто (речь о соотношении 20 на 80), этот технический эксперт как раз входит в 20% эффективных ресурсов, делающих всю важную работу на проекте.

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

Понятие Ретроспекти́ва (от лат. retrospectare – «взгляд назад») трактуется в Википедии так: взгляд в прошлое, обозрение того, что было в прошлом. Применительно к области IT, наиболее оптимальным определением представляется следующее: Ретроспектива – это систематическая командная деятельность, направленная на анализ результатов, с целью улучшения эффективности работы команды в IT-проекте. По сути, это инструмент, широко применяемых в гибких методологиях, который нацелен на улучшение работы проектной команды путем анализа текущих результатов.

Что конкретно даёт менеджеру ретроспектива?

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

В структуре проведения ретроспективы можно выделить четыре основных пункта:

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

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

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

Как часто нужно проводить ретроспективу?

Очевидно, что для успеха в этом процессе, необходима база для обсуждения. Иными словами, проект должен достичь определенной стадии. При этом временная характеристика не столь важна и определяется индивидуально (решающим фактором является размер проекта). Например, часто ретроспективу проводят по завершении спринта/итерации/фазы/релизу/закрытию проекта.

Так, например, ретроспективу можно проводить после релиза. Во-первых, очевидно, что сразу после релиза программного продукта команда ещё находится в «собранном» состоянии, что способствует генерации идей. Во-вторых, у команды есть возможность оторваться от выполнения задач по проекту, поскольку срочных задач уже нет. Ну и в-третьих, между релизами проходит достаточный промежуток времени для накопления потенциальных проблем.

Оптимальнее всего митинг по ретроспективе запланировать за пару дней или даже за неделю до события. Тогда у команды будет время для предварительного анализа своих собственных «ощущений», что позволит ускорить опрос на митинге. Отталкиваясь от практики, в среднем по времени процесс ретроспективы может занимать от получаса до 2-3 часов. Поэтому удобнее проводить ее днём, чтобы с утра никто из команды не «спал», а вечером не спешил домой или по своим делам.

До митинга либо непосредственно в его начале необходимо определить фасилитатора или «человека-маркера». Он следит за регламентом ретроспективы и поддерживает динамику собрания. В идеале – это должен быть человек, не относящийся к группе управления проектом. Важно, чтобы он фиксировал озвученные факты и проблемы без их искажения. Кроме того, фасилитатор должен обладать активной позицией и способствовать «массированному» высказыванию участниками своего мнения.

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

После завершения митинга «жизненно» необходимо подвести итог. Оптимальным вариантом является письмо, отправленное всем участникам ретроспективы. В таком итоговом письме следует зафиксировать результаты и ещё раз «проговорить» пути их решения. Кроме того, обязательно стоит поблагодарить людей, которые потратили своё время и пришли на ретроспективу.

Какие трудности и проблемы возникают при проведении ретроспективы?

  1. Низкая эффективность ретроспектив, что может быть вызвано несколькими факторами, такими как пассивность либо безынициативность команды или её непостоянство. Это может проявляться, например, в невыполнении решений принятых на ретроспективе. Как этого избежать? Если вы инициатор проведения ретроспективы, то постарайтесь по-настоящему заинтересовать её участников, в том числе за счёт выполнения финальных решений. Когда команда осознает, что это приносит пользу проекту в целом, то активность и желание участвовать значительно увеличится.
  2. «Высасывание проблем из пальца» либо их «размывание». Решение: Если сложно определить проблему, но очевидны её симптомы, все члены команды должны помочь в её четком формулировании.
  3. Выявление ложных проблем. Выявления таких проблем как «медленный» интернет и неудобные стулья у команды тестирования не должны играть ключевую роль по результатам ретроспективы. Во избежание такой ситуации, необходимо строго следовать регламенту проведения ретроспективы, и стараться «направить» её участников на обсуждение тех областей, которые являются наиболее критичными для проекта и процесса в целом.
  4. Появление в команде разногласий и ссор, нарушение психологического равновесия. Для решения нужно правильно определить эмоциональный пик дискуссии и вовремя «тормозить» наиболее активных участников, не доводя обсуждение до точки конфликта.
  5. Поиск «виноватого». Как бы ни развивалась дискуссия, нельзя искать виновного. Любая проблема – это проблема команды, и решать ее надо вместе.

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