Как за один день провести квартальную ретроспективу проекта внедрения ERP?

 

Меня зовут Елена Бакульманова, я достаточно давно занимаюсь автоматизацией бизнес-процессов, провожу обследования предприятий с целью автоматизации – в основном, это производственные предприятия. На моем счету порядка 10 завершённых ERP-проектов.

Я представляю компанию АртАйТи. Мы специализируемся на комплексных проектах внедрения 1С:ERP на производственных предприятиях. Помимо этого, у нас есть отдельное направление, занимающееся развитием корпоративных ИТ-систем на платформе 1С, таких как Управление холдингом, Бухгалтерия КОРП, ЗУП КОРП.

Хочу поговорить о таком инструменте как ретроспектива:

• Мы рассмотрим ретроспективу как инструмент развития команд в ИТ-проектах.

• Обсудим по шагам, как проводить однодневные ретроспективы.

• И я расскажу несколько примеров из нашей практики – как проведение ретроспективы нам помогло, что полезного привнесло.

 

Инструмент «Ретроспектива»

 

 

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

 

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

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

 

Ретроспектива – это ещё и инструмент командообразования, потому что она помогает команде синхронизировать понимание реализации проекта, наладить внутренний диалог.

Если в команде накопилось напряжение, в момент ретроспективы, как правило, всё это вскрывается – люди открыто обсуждают проблемы и находят варианты решения конфликтов.

 

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

• В текущий момент времени – для команды проекта.

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

• В конечном итоге – и для клиента. Потому что это улучшает реализацию проекта.

И, важные тезисы:

• На ретроспективе мы подводим итоги – делаем выводы, на основании которых пишем список корректирующих действий.

• Ретроспектива помогает в командообразовании – люди коммуницируют и лучше понимают друг друга.

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

 

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

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

• меняем технологию реализации будущих проектов.

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

 

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

 

 

Теперь поговорим про саму процедуру проведения ретроспективы.

 

Мы, в нашей компании, обычно проводим ретроспективу в двух случаях:

• по окончании каждого этапа проекта;

• или по окончании какого-то срока – например, по окончании месяца.

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

 

Сама подготовка к ретроспективе занимает минимум времени:

• нужно назначить встречу;

• организовать переговорную – желательно с ключом, чтобы можно было закрыться, и вас никто не отвлекал, потому что очень важно полное погружение в процесс;

• подготовить материалы для визуализации – флипчарт, маркеры, стикеры;

• и что самое, наверное, сложное – обеспечить доступность участников, вытащить всех участников проекта в один день, “оторвав” их от работы.

Обычно всё это готовит руководитель проекта – назначает встречу и организует саму ретроспективу.

 

Участники ретроспективы – это, как правило, вся команда проекта:

• руководитель;

• архитектор;

• аналитики;

• техлид;

• иногда разработчики – если мы анализируем этап разработки.

Кроме того, очень важная роль – это ведущий.

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

В нашей компании ведущий – это обычно директор департамента совершенствования. У нас есть такой волшебный департамент.

 

План однодневной ретроспективы

 

План проведения очень простой:

• инициация;

• анализ хронологии выполненных работ;

• субъективный анализ слабых и сильных сторон;

• анализ по точкам (анализ параметров проекта);

• выводы;

• и завершающая часть.

Все это занимает в среднем 6-7 часов – один рабочий день, но очень важно именно на один рабочий день всю команду освободить от других задач, чтобы люди не отвлекались. Мы даже телефоны забираем – когда люди заходят, они складывают телефоны в ящик.

Давайте пройдёмся по шагам.

 

Первый шаг – инициация.

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

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

 

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

• уложились ли мы в сроки этапа;

• каких результатов достигли;

• и достигли ли.

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

 

Следующий шаг – это субъективный анализ слабых и сильных сторон. Здесь всё более интересно.

Ведущий раздает стикеры. Стикеры должны быть двух цветов: более яркого и менее яркого.

 

Абсолютно каждый участник ретроспективы, включая младших аналитиков, должен сформулировать своё мнение о ходе проекта на тот период времени, который мы анализируем:

• На стикерах более яркого цвета каждый должен написать от 3 до 5 проблем – что ему мешало и было проблемой в рамках текущего этапа. И к каким негативным последствиям это привело.

• А на стикерах менее яркого цвета нужно, наоборот, написать от 3 до 5 позитивных событий – что было полезного в рамках текущего этапа.

 

 

Затем эти стикеры собираются и начинается поиск закономерностей – мы собираем стикеры и зачитываем их.

Например, есть проблема нехватки ресурсов – не хватило времени на решение какой-то задачи. Смотрим, почему эта проблема возникла и к каким последствиям она привела. Клеим стикеры с этой проблемой на флипчарт и записываем закономерности.

И далее обрабатываем все остальные стикеры – собираем из них закономерности и расклеиваем в отдельные подгруппы на флипчартах, чтобы была полная визуализация для участников ретроспективы.

Следующий этап ретроспективы – это анализ проекта по точкам. Здесь тоже всё понятно – мы анализируем точки проекта.

 

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

Мы анализируем:

• Сроки проекта – уложились или не уложились. Если не уложились, пишем на флипчарте, почему. Каждый из участников высказывается, почему это произошло, по его мнению.

• Трудоёмкость (часы) – соответствуют ли запланированные затраты ресурсов фактическим.

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

• Вовлеченность команды заказчика – есть ли в команде заказчика люди, которые саботируют процесс. Это очень важно, потому что с этими людьми нужно отдельно прорабатывать какие-то корректирующие действия.

• Взаимодействие исполнителя и заказчика – насколько мы друг друга слышим. Каждый из участников проекта должен высказаться.

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

• Содержание проекта, его функциональный объем – выдержали мы его или нет. Если превысили, то почему, и какие были первопричины.

• Работу с рисками – была ли она проведена.

• Процессы управления – мы анализируем: как мы планировали, как контролировали и как исполняли, соответствовало ли это нашим ожиданиям.

 

 

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

И все, что мы написали, расклеивается по стенам для полной визуализации.

Далее начинается следующий этап – мы просматриваем все, что написали в ходе нашего анализа и начинаем формировать выводы.

 

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

• Либо есть что-то, что нужно менять.

Опять же, все выводы записываются на флипчарт – зеленым положительные, красным отрицательные. Это важно, чтобы каждый из команды мог это осознать и дополнить.

 

 

В завершении:

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

• И очень важный момент, который мне больше всего нравится – каждый из команды должен обязательно высказаться, что полезного он сегодня на этой встрече узнал. Делимся впечатлениями.

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

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

В будущем это помогает более эффективно решать задачи, потому что люди начинают друг друга не просто слушать, а еще и слышать.

 

Примеры из практики

 

 

 

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

 

История №1: «Тот, кто нам мешает, тот нам поможет»

 

 

Первый пример – название говорит само за себя.

У нас был проект внедрения 1С:ERP в торговой компании. И когда мы согласовали функциональную модель и начали проектировать ТЗ, ко мне приходит руководитель проекта и говорит: «Мы вроде реестр доработок согласовали, все посчитали правильно, но по ТЗ часы получаются сильно превышены, мы уже процентов на 30 вылезли».

Мы решили провести ретроспективу чуть раньше, чем планировали. И когда стали искать закономерности, слабые и сильные стороны, несколько аналитиков, не сговариваясь, написали о том, что тратят большое количество времени на круговое согласование ТЗ с заказчиком.

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

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

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

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

 

 

 

История №2: «Разделять и властвовать»

 

 

Следующий пример – давнишний проект в машиностроении.

После запуска проекта срок этапа опытно-промышленной эксплуатации у нас на месяц превысил запланированные сроки. Это вызвало рост напряжения внутри команды – им пришлось на месяц дольше ездить в командировки. Кто ездит в командировки, понимает, о чём я.

Поэтому мы после этапа провели ретроспективу, пытаясь понять, почему не получилось, что удлинило проект, что стало первопричиной.

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

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

Некоторые задачи стояли в очереди несколько дней, и это только увеличивало объем необходимых корректировок. Кто запускал систему, знает, что за каждый день задержки исправления ошибки в базе пользователи нагенерят вам по 100 документов, которые тоже нужно будет исправлять. Такой постоянный рост количества ошибок приводил к перегрузу аналитиков.

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

 

 

 

История №3: «Как показывает опыт…»

 

 

Ещё один пример из практики – тоже из отрасли машиностроения.

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

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

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

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

До этого у нас был только этап «Интеграционный тест». А мы решили добавить опытную эксплуатацию, чтобы не мы показывали заказчику функционал, а заказчик сам, своими руками на боевых данных пощупал систему и дал нам обратную связь. Мы это обосновали и согласовали.

Этот этап принес огромное количество пользы. Мало того, что мы вскрыли большое количество кейсов, о которых нам молчали, мы ещё и нашли вспомогательные подразделения, о необходимости автоматизировать которые Заказчик просто забыл.

 

 

 

История №4: «Неочевидное решение»

 

 

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

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

На ретроспективе мы долго думали, что с этим делать, и один из аналитиков предложил: «А давайте привлечём главного бухгалтера? Она давно работает, должна помочь».

Руководитель проекта поговорил с главбухом, и она в последующем участвовала абсолютно во всех встречах, даже в тех, которые её не касались, потому что у нас параллельно шло два проекта – регучет и оперконтур.

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

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

 

 

 

Выводы

 

 

Итого, ретроспектива одним днем – это хорошая практика «присесть», подумать, проанализировать.

В ИТ-проектах мы иногда спешим – нам не хватает времени, и из-за этого мы упускаем очень важные моменты.

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

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

Ретроспектива – это тот же процесс, но в командном формате: мы анализируем, что можно было сделать лучше, и ищем способы более эффективно решать задачи и преодолевать проблемы.

Ретроспективу важно проводить сразу после окончания работ, не дожидаясь, пока детали сотрутся из памяти. Как только этап завершен или даже ещё в процессе подписания акта, стоит собраться и проанализировать ситуацию – пока всё свежо в памяти, а эмоции ещё не утихли.

Это помогает объективно оценить результаты, открыто обсудить проблемы и избежать замыливания восприятия.

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

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

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

Проводите ретроспективу одним днём – это полезная и удобная практика!

 

Вопросы и ответы

 

Кто и как контролирует выполнение задач, сформированных по результатам ретроспективы? Это же не часть проекта, а дополнительные задачи.

Обычно такие задачи контролирует руководитель отдела, отвечающий за данный проект.

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

Вовлекаете ли вы в процесс ретроспективы субподрядчиков, которых привлекаете к проекту?

На текущий момент у нас субподрядчики были только в разработке. В аналитике мы пока субподрядчиков ни разу не привлекали. А разработку мы анализируем только в рамках своих разработчиков.

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

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

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

Сколько человек участвует в ретроспективе?

Все зависит от проекта. На последнем проекте мы проводили ретроспективы на 7 человек – 4 аналитика, архитектор, техлид и РП.

Получается, что разработчики не всегда присутствуют на ретроспективе, но техлид всегда присутствует?

Да.

И затем техлид доносит до разработчиков принятые решения?

Если ретроспектива посвящена именно этапу разработки, мы приглашаем разработчиков, так как они напрямую участвуют в этом процессе.

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

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

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

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

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

Почему именно ретроспектива? Можно же обсуждать проблемы на регулярных летучках, планерках и так далее?

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

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.