Ретроспектива это в бизнесе

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

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

Мы рассказываем, зачем еще использовать ретроспективный анализ и кому он нужен в первую очередь, в чем отличие анализа от ретроспективы и даем пошаговую инструкцию, как проводить ретроспективу в проджект-менеджменте.

Нет времени читать статью? Найдите ее в нашем телеграм-канале и сохраните себе в «Избранном» на будущее.

Что такое ретроспективный анализ?

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

Ретроспективный анализ можно выполнять за прошлый месяц, полгода, год или другой период

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

• объективно оценить работу команды;
• понять, какие ресурсы не задействовали;
• найти виновников неудач и наградить лучших;
• сделать выводы и учесть их при будущем планировании;
• с умом потратить ресурсы — деньги, время сотрудников, мощности станков.

Но не все так безоблачно: у ретроспективного анализа есть недостаток. Заключается он в том, что на полученные результаты влияли события прошлого — например, резко дорожала валюта и таможенные пошлины. В связи с этим у бизнеса росли затраты. Теперь валюта и пошлины упали. А значит и затраты станут меньше.

Вывод: нельзя полностью опираться на прошлые данные. Найденные в ходе ретроспективного анализа решения нужно адаптировать к современным условиям.

Где применяют ретроспективный анализ?

Ретроспективный анализ проводят в экономике и маркетинге.

В экономике

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

Результаты анализа используют для планирования бюджетов: сколько надо денег на закупки в новом периоде, если в прошлом потратили 20 000 000 рублей, как сократить возросшие в том месяце инвестиции, сколько заложить на премии и т. д.

В маркетинге

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

Еще анализ нужен, чтобы посмотреть, каких успехов достигла прошлая маркетинговая кампания и на что ориентироваться в текущей. Например, цена клика была 25 рублей — значит, надо либо стремиться к такой же цене, либо к пониже, но никак не к больше.

Так оценивают любую маркетинговую кампанию и на базе полученных сведений планируют новую. Удачные приемы внедряют, а неудачные обходят стороной.

Что такое ретроспектива?

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

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

Разница между двумя терминами в том, где применяется анализ и ретроспектива

Во время ретроспективы:

• Находят, что следует улучшить. Например, дизайнеры постоянно затягивают с правками, но не специально. Просто получают их через два отдела, а не напрямую. На ретроспективе делают вывод: нужно сократить эту цепочку.
• Мотивируют участников. Команда посчитала прибыль проекта. Тут же прикинули: а если бы сделали быстрее, то прибыль была больше — могли получить премии. К следующему проекту все замотивированы работать лучше и качественнее.
• Обмениваются опытом. Если разработчик Вася адаптировал часть кода до одной строчки и на ретроспективе рассказал, как ему это удалось, остальные прокачали знания и стали умнее.
• Находят провалы. Команда честно призналась, в чем сплоховала. Сделали выводы и придумали, что предпринять, чтобы провалы не повторились.
• Планируют ресурсы. Например, выяснили, что презентацию могут провести два менеджера, а не три. Еще экономнее платить за подписку ПО на год вперед — будет скидка.
• Обмениваются идеями. Все рассказали, как, по их мнению, надо подходить к задачам. Лучшие идеи отобрали, чтобы использовать в качестве постоянной практики.

Зачем нужна ретроспектива в проджект-менеджменте?

Когда команда закончила проект, могут быть проблемы:

• Все выгорели, нет сил браться за новую работу.
• Проект допилили кое-как из-за всеобщей низкой производительности.
• На старте поставили KPI, но по факту так их и не достигли.
• В конце проекта получили те же замечания, какие заказчик уже озвучил ранее.
• Кто-то уволился, позиция не закрыта, а пора браться за следующий проект.

Вывод, который делает проджект-менеджер: в команде не все в порядке, надо что-то делать. Тут как раз и пригождается ретроспектива. Ретроспектива помогает создать план улучшений. Что важно — план согласован всеми участниками команды, а значит, ответственность за его выполнение общая.

Вот какую ценность несет ретроспектива в проектном менеджменте:

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

Пошаговая инструкция: как провести ретроспективу в проджект-менеджменте

Шаг 1. Выбрать инструменты

Во время ретроспективы используют обычную доску, стикеры и кнопки. Доску делят на четыре части: «Плюсы»,«Минусы», «Проблемы», «Решения». На стикерах пишут, что хорошего, плохого произошло во время работы над проектом, какие проблемы встретились и как их можно решить.

Потом стикеры распределяют по доске. Где-то стикеров будет больше, где-то меньше, но это неважно. Что важно, так это объективно оценить прошлый опыт.

Иногда ретроспективу проводят удаленно. Тогда нужны специальные веб-сервисы. Например, Google Docs, Trello или специализированные EasyRetro и Lucidspark. Последние две платформы — платные интерактивные инструменты. Можно пользоваться и бесплатно, но тогда команде доступно всего три доски.

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

Шаг 2. Определиться с техникой

Помимо обычной доски с четырьмя разделами «Плюсы», «Минусы», «Проблемы», «Решения», есть дополнительные техники: «Звезда», «Парусник», «Радар». Рассмотрим их подробнее.

Звезда

Команда изображает звезду с пятью лучами. На каждом луче аспект, который требует обсуждения:

• «Прекратить». Сюда попадают стикеры, на которых фиксируют все, что не приносит команде пользу. От этих вещей избавляются.
• «Меньше». Здесь крепят стикеры с тем, что требует от команды много сил, но пользы не приносит либо приносит, но мало. Договариваются тратить на это меньше сил и времени.
• «Продолжать». Это стикеры с удачными приемами, практиками и методами. Их команда сохранит для будущих проектов.
• «Больше». На стикерах перечисляют, от чего все получают пользу. Эти практики и приемы активнее используют в будущих проектах.
• «Начать». Стикеры с полезными идеями, действиями и приемами, которые надо начать использовать, чтобы команда работала лучше.

Техника «Звезда» оценивает прошлый опыт и ставит цели на будущие проекты

Парусник

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

Техника «Парусник» выглядит как игра. Если сотрудники не могут расслабиться во время встречи и раскрепоститься, техника — то, что надо

Парусник содержит следующие аспекты:

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

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

Командный радар

Технику «Радар» используют, если у команды есть ресурсы улучшать работу поэтапно

Радар изображают как круг или многоугольник с осями. Оси делят радар на сектора. Каждый сектор — рабочий процесс или ситуация, которые требуют обсуждения. Дальше команда в каждом секторе ставит оценку от 1 до 10 по следующим правилам:

• 1–3 — этот момент работает относительно неплохо, а если начать улучшать, на команду особо не повлияет;
• 4–6 — если менять что-то в этом секторе, изменения будут заметны и помогут команде достичь цели;
• 7–10 — если менять сектор, изменения окажут мощное влияние на всю команду, процесс и результат.

В работу выбирают сектора, которые получают самые высокие оценки, но не больше 2–3. Их обсуждают и планируют, как улучшить.

Шаг 3. Пригласить коллег

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

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

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

Шаг 4. Составить правила

Правило надо донести до коллег и следить, чтобы все их выполняли. В первую очередь определяют:

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

Шаг 5. Начать дискуссию

Когда все собрались, ретроспектива начинается. Единого формата нет: можно раздать стикеры и маркеры, чтобы коллеги записывали идеи, а потом крепить стикеры на доску. Можно устроить блиц-решения — когда за 60 секунд команда брейнштормит предложения.

Стандартно собрание состоит из четырех частей:

1. Сбор данных. Все обсуждают прошлый опыт, высказывают мнения, обсуждают результаты.
2. Генерация идей. Предлагают, как и что менять, чтобы работа команда улучшилась.
3. Выбор решений. Команда голосует, какие идеи брать в работу и применять на практике
4. Заключение. Команда проговаривает план, чтобы ничего не забыть, и расходится.

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

Подытожим

1. Ретроспективный анализ — это исследование прошлого опыта по отношению к текущим результатам. Проводят в экономике и маркетинге. Цель анализа — изучить прошлый опыт. А конкретно — найти удачные решения и применить их в будущем, обнаружить неудачные и больше никогда их не применять, выявить и скорректировать проблемные места.
2. Ретроспективный анализ схож с ретроспективой. Ретроспективу проводят в проектных командах, чтобы обсудить прошлую работу и составить план на будущее.
3. Чтобы провести ретроспективу, надо выбрать инструменты, составить регламент встречи, выбрать технику, оповестить коллег, всем собраться и начать. Результат удачной ретроспективы — план улучшений на будущее.

Источник: lpgenerator.ru

Ретроспектива: как и зачем ее проводить?

Проведение ретроспектив – это активность, которую каждая agile-команда проводит для того, чтобы решать свои проблемы. Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.

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

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

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

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

Тем не менее, существуют такие вещи как good practice или best practice. Это практики, которые многие используют и которые многим помогают. Возьмем, например, code review: хорошая это практика или плохая? Одним командам она помогает. Другие пытаются ее использовать, и ничего хорошего из этого не выходит.

Так происходит потому, что эта конкретная практика, не хороша и не плоха как таковая: ее можно оценить только в контексте конкретной команды и ситуации.

Хотя бы поэтому невозможно сказать заранее, даст она какое-то преимущество или нет. Сode review – это один пример. На самом деле этот эффект характерен для любой практики – никогда нельзя знать заранее, насколько она будет эффективна в той или иной ситуации.

Цели и результаты

В основе ретроспективы лежит концепция цикла Деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы – к ее окончанию получить план изменений. Но важно понимать, что это не план окончательных изменений в процессе – это план эксперимента на ближайший период. Мы что-то пробуем, а потом смотрим, что из этого вышло, и на основании этого принимаем решение.

Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan.

Ретроспектива, как и любая командная встреча, должна иметь какую-то цель. Цель ретроспективы – получить план процессного эксперимента. Однако многие команды этого не понимают. Например, на ретроспективе команды порой пытаются придумать какие-то глобальные решения своей проблемы, и упираются в то, что у них не получается этого сделать.

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

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

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

Что такое действия? Это конкретные задачи с известными исполнителями. Причем если выполнить действие должен тот, кого нет сейчас в комнате, из присутствующих выбирается человек, который берет на себя ответственность объяснить отсутствующему, что и как нужно сделать, а также проконтролировать результат. В итоге за каждое действие отвечает кто-то из присутствующих на ретроспективе.

Какие бывают ретроспективы?

Вообще ретроспективы разумно подразделять на несколько типов:

• ретроспектива в самом общем смысле слова;
• ретроспектива по качеству;
• ретроспектива по проблемам;
• ретроспектива по какому-либо отдельно взятому вопросу.

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

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

В чем проблема?

Какие в процессе ретроспективы могут возникнуть дисфункции, и как с ними бороться? Вот одна из дисфункций: команда считает, что у нее нет проблем, ее рабочий процесс достаточно хорош, и не видит смысла в его улучшении. Как правило, это не так. Но команде этого просто так не объяснить.

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

Еще одна дисфункция – когда на ретроспективе говорит в основном кто-то один или 2-3 человека, а все остальные сидят и молчат. На самом деле этим людям есть, что сказать. Просто, если все внимание на себя забирает, к примеру, лидер команды, он начинает доминировать, а остальные просто слушают.

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

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

Формат ретроспективы: наши предложения

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

Вместо того, чтобы выставлять жесткий тайминг и последовательность действий, мы предлагаем просто расчертить доску на 4 основные области и заполнять ее по ходу обсуждения:

• Плюсы. Что шло хорошо в прошлой итерации?
• Минусы. Какие проблемы были в прошлой итерации?
• Идеи. Какие идеи появились по ходу ретроспективы?
• План. Какие улучшения мы запланируем на следующую итерацию?

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

После обсуждения плюсов, минусов и идей команда переходит к составлению плана, куда попадают не просто результаты обсуждения, а (как уже было отмечено) конкретные действия («Выполнить…», «Обсудить…», «Сформировать…») или правила («Задачу Х выполнять с использованием подхода Y»). Не стоит при этом пытаться выработать пути решения всех возможных проблем команды – для эффективной работы на следующей итерации достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполним и только демотивирует команду.

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

• agile
• scrum
• управление проектами и командой

• Блог компании ScrumTrek
• Управление проектами
• Agile
• Управление e-commerce
• Управление продуктом

Источник: habr.com