Ретроспективный анализ IT-проекта: 4 шага подальше от граблей

Отредактировано

Тот, кто не умеет анализировать своё прошлое, как минимум рискует получить проблемы в будущем. Но если вы привыкли учиться на своих ошибках, то сегодня мы поделимся опытом, как этот процесс упорядочить и получить от него максимальную отдачу.

11К открытий12К показов

Введение

Для начала стоит пояснить, что такое ретроспектива и зачем мы здесь собрались. Ретроспектива — это обзор неких событий с высоты прошедшего времени. Ретроспектива как инструмент руководителя позволит понять, как прошёл спринт (итерация, квартал, год), чему научились, на чём споткнулись и что надо улучшить, чтобы стать более успешными в будущем. Сколько будет событий, каких и с высоты какого времени смотреть, решают индивидуально при планировании мероприятия.

Ретроспектива поможет:

  • найти узкие, проблемные места в рабочем процессе или рабочей атмосфере;
  • определить, на каких этапах рабочие процессы наиболее уязвимы, а значит, понять, над чем стоит работать более внимательно;
  • оценить, насколько успешны ваши идеи по решению проблем;
  • проанализировать, повторяются ли проблемы из итерации в итерацию, или же все попытки исправить положение приводят к ещё большим потерям.

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

Для начала обозначим краткий план мероприятия:

  • подготовка участников;
  • подготовка ведущего;
  • проведение ретроспективы;
  • контроль выполнения договорённостей.

Теперь давайте разберёмся, зачем нужны все эти этапы подготовки.

Шаг 1. Подготовка участников

Ретроспективный анализ IT-проекта: 4 шага подальше от граблей 1

Когда проводить ретроспективу и какие вопросы задавать?

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

Следующий момент, требующий внимания до встречи, — это список вопросов. Это могут быть стандартные «что мы сделали хорошо?» и «что мы сделали плохо?» или другие насущные вопросы, которые могут прийти в голову. Например, можно узнать, какая в команде атмосфера. Не исключено, что кто-то ответит «у нас всё круто, твердая пятёрка», а кто-то из этой же команды поставит троечку с натяжкой. Вот вам и повод хорошенько всё обсудить.

Ещё несколько примеров вопросов

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

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

Точно не стоит спрашивать «кто виноват?». Как бы вам ни хотелось получить ответ на этот вопрос, задавая его вот так напрямую, вразумительного ответа вы не получите. Чего вы точно добьётесь, так это перекладывания вины и ответственности, нездоровую атмосферу в команде и тяжёлый осадок обид. Задавая вопросы, разбирая ответы и проводя саму встречу, стоит настроить себя на то, что все выложились по максимуму и сделали всё, что от них могло зависеть.

Превентивные вопросы

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

Какой от этого профит, спросите вы, если всё равно все соберутся и будут обсуждать то же самое? Не все люди умеют или любят разговаривать с другими. Не все могут сразу сформулировать свою проблему: будут рассказывать длинную предысторию, где в самом конце, возможно, промелькнёт то, что человек хотел сказать. Может случиться и так, что это будет попытка найти фантомную проблему там, где её нет, с аргументацией: «не знаю, что точно, но всё как-то не так». Время — деньги, поэтому я даю шанс людям предварительно высказать все мысли и эмоции на бумаге, сэкономив команде силы на ретроспективе.

Шаг 2. Подготовка ведущего

Ретроспективный анализ IT-проекта: 4 шага подальше от граблей 2

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

Для проведения вашей первой ретроспективы этой подготовки будет достаточно.

Подготовка второй и последующих ретроспектив

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

Как вспомнить прошедшие ретроспективы и их итоги?

Разумеется, не стоит надеяться на свою память, ни один человек не в состоянии запомнить все нюансы, тем более если прошёл год или больше. Тут нам на помощь приходит прекрасная таблица PDCA (цикл Деминга), которую нужно завести сразу после первой ретроспективы.

Мы её немного доработали, поэтому табличка состоит из пяти колонок:

  1. «Суть» поднятой проблемы. Желательно тезисно, чтобы при беглом просмотре было ясно, о чём идёт речь.
  2. «Plan» — планирование решения или возможные варианты развития событий.
  3. «Do» — что в итоге было сделано из запланированного.
  4. «Check» — здесь мы фиксируем, к чему привели наши действия.
  5. «Act» — есть несколько вариантов перевода этой части цикла, например «воздействие» или «корректировка». Это своеобразный итог всей строки.

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

  • если проблема решена, можно написать «Выполнено»,
  • если не решена, но выбранный путь кажется верным, можно написать «Продолжай»,
  • если же вы ни на шаг не приблизились к решению проблемы, пишите «Всё пропало». Эту грустную формулировку можно заменить на локальный мем, мы предпочитаем использовать открытый призыв — «Думай дальше…».

Шаг 3. Проведение ретроспективы

Ретроспективный анализ IT-проекта: 4 шага подальше от граблей 3

Все собрались в назначенном месте или в скайп-чате. Теперь нужно соблюсти небольшой регламент и озвучить, по какому поводу собрались. Лучше ещё разок напомнить, что сегодня мы обсуждаем проблемы, возникшие в первом квартале текущего года. Это поможет участникам ретроспективы настроиться на нужный диапазон воспоминаний и откинуть то, что было до или после.

Порядок выступающих

Всё зависит от масштабности вашего мероприятия. Если вы небольшая команда, которая работает над одним общим проектом, то порядок не важен. Можно по мере поступления ответов, в алфавитном порядке и тому подобное. Если у вас несколько проектов, то собирайте людей в проектные группы, а порядок распределяйте по принципу выше.

Итак, все организационные вопросы решены. Давайте начнём ретроспективу.

Как это обычно происходит?

Ведущий опирается на выписанные им выдержки из ответов. Он озвучивает суть проблемы и задаёт вопрос тому, кто её описал.

Что спрашивать?

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

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

Как фиксировать информацию?

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

Кстати, после того, как вы определились, выбранный вариант тоже нужно зафиксировать. Для этого нам понадобится третий лист ретроспективы — «Регламентируем предложения» («Наши планы», «Сделай так», «Итоги» и тому подобное). Именно сюда выносим согласованные предложения, назначаем ответственного и ставим контрольный срок исполнения.

Не забудьте, что сроки по каждому пункту надо обсудить с ответственным. Даже если речь идёт о разговоре с дизайнером и это дело пяти минут, всё равно ставьте срок. Это позволит не забыть о порученной задаче. Конечно, одной записи на листочке может быть мало. Ведь все люди что-то забывают, но к этому мы ещё вернёмся.

Остались вопросы?

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

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

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

Шаг 4. Контроль выполнения договоренностей

Ретроспективный анализ IT-проекта: 4 шага подальше от граблей 4

Ведущий ретроспективы должен отдельно написать себе список и конечный срок выполнения принятых решений. В свой календарь, ежедневник, доску канбан, смотря чем вы пользуетесь. Это нужно для оперативного контроля за решением поставленных задач. За пару дней до дедлайна я уточняю у ответственного, не забыл ли он о своём поручении. Бывает так, что задача уже выполнена, и сотрудник вот-вот собирался рассказать о результате. А бывает, что в ответ вы слышите «ой» и видите сверкающие пятки сотрудника. Значит, вы поступили правильно, спросив заранее и напомнив о задаче.

А что если принятое решение оказалось невозможно выполнить?

Например, ответственный за него человек уволился или просто до задачи так и не дошли руки. Тогда стоит вписать решение этого вопроса в свои задачи — повесить стикер на доску или создать задачу в Jira, например. Тогда вы точно о ней не забудете и рано или поздно придёте к её решению.

Выводы

Кому нужна ретроспектива?

Ретроспектива — это важная и нужная часть вашего продвижения на пути к глобальной цели. И тут совершенно не важно, разрабатываете ли вы модное приложение для блогеров или у вас строгий банковский продукт. Особенно на ретроспективу важно обратить внимание тем компаниям, которые выбрали для себя разработку в стиле Agile и двигаются короткими итерациями. Так вы точно не свернёте с намеченного пути и вовремя заметите, если где-то проседаете по срокам и ваш критический путь увеличивается.

Что будет, если не проводить ретроспективу?

Любите бродить вслепую, без понимания, насколько ваша стратегия верна и через какое время она приведет вас к успеху, — не тратьте время на ретроспективу.

Есть меткая цитата Сократа, которую любили повторять Ломоносов и Пушкин: «Народ, не знающий своего прошлого, не имеет будущего». Хотите учиться на своих ошибках с первого раза и перестать наступать на одни и те же грабли, ретроспектива — ваш выбор.

Да, возможно, кому-то это покажется скучным и занудным мероприятием. Но в целом, всё зависит от команды. Заодно вы сможете узнать, какая у вас царит атмосфера. Кто с кем больше соглашается, кто кого стесняется, и чем вообще занимаются люди, когда кто-то говорит: внимательно слушают или отстранённо смотрят в окно. Согласитесь, не всегда удаётся вот так собрать всех в одном помещении и заставить говорить на одну и ту же тему.

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

Следите за новыми постами
Следите за новыми постами по любимым темам
11К открытий12К показов