Подготовка мероприятия ― классический проект. С этой точки зрения между разработкой мобильного приложения и подготовкой бизнес-конференции не так уж много различий. И то, и другое ― про достижение заранее определенной цели силами проектной команды в условиях ограниченного бюджета, поджимающих сроков и меняющихся требований стекхолдеров.
Мы в Ивентишес не только создаем продукт, опираясь на принципы Agile, но и участвуем в организации двух крупных ежегодных конференций на 1000+ участников.
Ещё мы много общаемся c организаторами мероприятий, на которых используются наши приложения, посещаем профессиональные конференции и консультируем по вопросам ивент-технологий.
И главное, что мы понимаем про ивенты, опираясь на весь этот опыт: ивент = проект.
А значит, для ивент-менеджмента точно так же, как и для управления разработкой мобильного приложения, подходят принципы Agile.
Треугольник компромиссов
Что бы мы ни проектировали, ивент или IT-продукт, мы всегда имеем дело с «треугольником компромиссов».
Лебедь, рак и щука любого проекта ― время, бюджет и качество.
Если мы хотим быстрее результат, нам нужен бОльший бюджет, иначе страдает качество. Если урезается бюджет, нам нужно поступиться качеством, иначе рискуем не уложиться в сроки. И так далее.
На самом деле тут не хватает еще одного, четвертого измерения — требования. Если мы как организаторы или заказчик ивента задали безумные требования, то надо подкрепить их большим бюджетом, иначе пострадает всё остальное.
Чем плох Waterfall?
Классический способ управление проектом называется Waterfall и нагляднее всего его иллюстрирует диаграмма Ганта.
Применительно к подготовке мероприятия этот подход выглядит так. Мы сначала долго собираем требования заказчика. Согласуем и дорабатываем концепцию, пока не финализируем все договоренности, если мы – ивент-агентство и у нас есть внешний заказчик. Или долго и подробно обсуждаем и планируем мероприятие с командой, если заказчики — мы сами. Потом распределяем задачи внутри команды, и каждый делает свой кусок в установленный срок.
У «водопадного» планирования есть свои плюсы:
- сразу есть чёткий план;
- все знают, что делать с самого начала и до самого конца;
- предсказуемый результат.
Но есть одна проблема: План никогда не срабатывает на 100%.
Почему? Изменения! В любой момент что-то может пойти не так.
Классический подход не позволяет учитывать постоянные изменения и риски:
- изменения «хотелок» заказчика;
- изменения в бюджете или в сроках;
- изменения в ресурсах (уволнения, болезни и тп);
- изменения из-за непредсказуемых проблем (технические риски и форс-мажор).
Результат может сильно отличаться от того, что планировали организаторы мероприятия.
Почему Agile?
Альтернатива классическому подходу — гибкое управление проектом на основе принципов Agile.
Кто-то скажет: «Ну мы точно не работаем по Waterfall, значит, у нас Agile». Как бы не так.
Для начала стоит ответить себе на вопрос ― а есть ли у нас в принципе процесс управления проектом? Есть ли чёткие правила и регламент работ, которому вся команда следует на каждом проекте?
В манифесте Agile описаны принципы гибкого подхода. Вот наиболее популярные из них:
- Изменение требований приветствуется!
- Приоритет – удовлетворение потребностей заказчика за счет регулярной и ранней «поставки» (каждые 1-2 недели) демо.
- На протяжении проекта исполнители и бизнес должны работать вместе (одна команда).
- Над проектом работает команда равных и мотивированных профессионалов.
- Командная работа основана на поддержке и доверии.
- Сначала самое ценное! Отсекаем максимум второстепенных деталей
- Самоорганизация. Постоянный анализ и корректировка процесса.
Лучше всего отличие в подходе 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 позволяет не только быть готовыми к неизбежным изменениям (всегда что-то может пойти не так), но и принимать эти изменения как обязательную часть процесса.
Лучшие идеи рождаются не на этапе предварительного планирования, а в самый разгар подготовки ивента.
Если вы любите изменения, считаете их не просто неизбежным злом, а лучшей частью работы над проектом, у вас есть шанс сделать что-то по-настоящему стоящее.
Больше идей и вдохновения:
- Александра Жирновская: Инструменты вовлечения участников деловых событий
- Елена Конвисар о том, как тренды трансформируют пространства деловых мероприятий
