Проектные техники из IT, которые стоит взять на вооружение event-менеджерам

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

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

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

И главное, что мы понимаем про ивенты, опираясь на весь этот опыт: ивент = проект.

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

Треугольник компромиссов

Что бы мы ни проектировали, ивент или IT-продукт, мы всегда имеем дело с «треугольником компромиссов».

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

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

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

Чем плох Waterfall?

Классический способ управление проектом называется Waterfall и нагляднее всего его иллюстрирует диаграмма Ганта.

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

У  «водопадного» планирования есть свои плюсы:

  • сразу есть чёткий план;
  • все знают, что делать с самого начала и до самого конца;
  • предсказуемый результат.

Но есть одна проблема: План никогда не срабатывает на 100%.

Почему? Изменения! В любой момент что-то может пойти не так.

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

  • изменения «хотелок» заказчика;
  • изменения в бюджете или в сроках;
  • изменения в ресурсах (уволнения, болезни и тп);
  • изменения из-за непредсказуемых проблем (технические риски и форс-мажор).

Результат может сильно отличаться от того, что планировали организаторы мероприятия.

Начали хорошо, а потом что-то пошло не так

Почему Agile?

Альтернатива классическому подходу — гибкое управление проектом на основе принципов Agile.

        Кто-то скажет: «Ну мы точно не работаем по Waterfall, значит, у нас Agile». Как бы не так.

Для начала стоит ответить себе на вопрос ― а есть ли у нас в принципе процесс управления проектом? Есть ли чёткие правила и регламент работ, которому вся команда следует на каждом проекте?

В манифесте Agile описаны принципы гибкого подхода. Вот наиболее популярные из них:  

  • Изменение требований приветствуется!
  • Приоритет – удовлетворение потребностей заказчика за счет регулярной и ранней «поставки» (каждые 1-2 недели) демо.
  • На протяжении проекта исполнители и бизнес должны работать вместе (одна команда).
  • Над проектом работает команда равных и мотивированных профессионалов.
  • Командная работа основана на поддержке и доверии.
  • Сначала самое ценное! Отсекаем максимум второстепенных деталей
  • Самоорганизация. Постоянный анализ и корректировка процесса.

Лучше всего отличие в подходе Agile от классического управления проектом иллюстрирует эта схема:

В Agile на каждом этапе есть готовый к использованию продукт

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

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

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

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

Процесс управление проектом в Agile

Основные методики Agile-подхода: SCRUM, Канбан и Lean.
Процесс управления проектом с применение этих методик выглядит примерно так:

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

Основные преимущества Agile-подхода:

  • идеален, когда нет возможности детально согласовать ТЗ и план  (например, стартуем прямо сейчас);
  • приспособлен к любым изменениям;
  • конечный результат в среднем более качественный и более ценный для заказчика (регулярно подстраиваемся под потребителя, а не следуем жесткому плану, который мог быть ошибочен)

Но есть и недостатки:

  • не все сотрудники «годятся» для Agile (требуется опыт, ответственность и инициативность);
  • бизнес/заказчик должен быть вовлечен на 100% и сам готов к гибкости (бюджет, сроки, требования);
  • нет зафиксированной цены  и детального прописанного ТЗ;
  • больше неопределенности (ТЗ постоянно меняется).

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

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

Однако, сам по себе Agile не требует обязательной «гибкости» в бюджете. Её можно достигать и за счет других составляющих (требований, сроков, качества и т.д.).

Нужно помнить, что  процесс можно и нужно менять, выбирая подходящие практики для конкретного проекта (собственно, в этом и вся суть Agile-подхода).

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

Пример гибридного процесса: для проекта в целом применяются классические практики – «визуализированное» ТЗ и план с дедлайнам и зафиксированной оценкой. А подпроекты в рамках него, например, сайт конференции или оформление площадки, управляются по методикам Agile (но с ограничением по бюджету), где главное ― итеративность, демо клиенту, сбор обратной связи и готовность к изменениям.

Инструменты для командной работы

При подготовке к своей ИТ конференци 404Fest на 1500 человек мы использовали простые и бесплатные:

  • Google Docs & Sheets  - совместный доступ и редактирование документов, таблиц.
  • Trello - канбан-доска в электронном виде. Любая задача проходит через четыре основные стадии: задача поставлена, задача выполняется, задача проверяется и задача выполнена. Инструмент позволяет составлять списки задач в виде карточек, привязывать участников команды к карточкам и  перемещать карточки между досками.

Если у вас крупные проекты и вы почувствуете, что вам недостаточно функционала Trello, существуют более продвинутые средства управления проектами. Наиболее популярные в IT –  Basecamp, Asana, Jira, MS Projects

Предсказуемые риски

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

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

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

Для этого составляется реестр возможных рисков, например:

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

Пропишите «План Б» на случай, если риск реализуется (mitigation plan). Оцените стоимость и время устранения последствий и заложите резерв в оценке времени на подготовку и бюджете мероприятия по каждому риску с учетом его вероятности.       

Как вариант, вы можете переложить риски на заказчика, но тогда пропишите это в реестре и согласуйте с заказчиком (в IT-проектах такой реестр рисков часто прикладывается к тексту контракта). Проводите регулярный мониторинг реестра рисков в ходе выполнения проекта. Возможно, появились какие-то новые риски, которые вы не учли?

Упрощенно принцип управления рисками звучит так: проверяй выполнимость самых сложных и рискованных частей как можно раньше!

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

Когда не учли основной риск

Прототипируй это!

Согласно принципам Agile важно как можно раньше показать заказчику прототип проекта.

        Любая визуализация эффективнее длинных документов и ТЗ.

Их заказчик всё равно не будет читать. Вы рискуете через несколько месяцев подготовки узнать, что описанная вами концепция не соответствует представлениям заказчика. Макеты, наброски, 3D-визуализация, комикcы сценария — вариантов сделать прототип для ивента много.

Прототип — отличный инструмент для реализации масштабных проектов. Никто не будет делать 3 версии оформления стадиона итеративно, но сделать три макета или 3D-визуализации вполне реально. Заказчик наглядно видит, что он получит в конце и может внести правки на этапе прототипа. Это сильно экономит ресурсы и снимает риски.

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

Трекайте реальные затраты и реальный прогресс

В IT при работе над проектом мы постоянно отслеживаем (трекаем) время и деньги, потраченные на выполнение каждой задачи.

   Если мы потратили 50% денег или времени, а проект сделан только 10%, или растут затраты, а прогресс задачи не меняется — алярма!

Что-то идет не так. Надо проанализировать причины и расхождения с планом.

В ивент-менеджменте этот подход тоже можно взять на вооружение. Некоторые из инструментов управления проектами позволяют трекать затраченное время и ресурсы и формировать отчеты в автоматическом режиме. Но можно отслеживать эти показатели и вручную на основе ежедневных митингов команды.

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

Изменения — это хорошо

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

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

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


Больше идей и вдохновения: