Разбираемся с проджект-менеджером Vide Infra в методах управления: различия, риски, преимущества
Когда вам предлагают работать над проектом по agile — что это значит? Анастасия, ведуший проджект-менеджер Vide Infra, объясняет, зачем нужны разные методологии управления и как выбирать между ними.
Что такое agile и каскадная модель?
Есть разные способы организовать работу над проектом. Принципиально отличаются решения, которые дают каскадная модель управления и agile-подход.
- Каскадная модель стала золотым стандартом в XX веке. Работа делится на этапы: планирование, дизайн, написание кода, тестирование, релиз и поддержка. Проект движется по ним, как автомобиль на конвейере — пока один этап не закончен полностью, к следующему не переходят.
- Альтернативный подход, который набрал популярность за последние лет двадцать, называют гибким или agile. Это семейство методов управления с общей философией: готовность к изменениям важнее, чем следование плану.
Какие риски у каскадной модели?
Каскадная модель предполагает, что на рынок выходит только полностью готовый продукт. Значит, все требования к дизайну, структуре и функциям должны быть известны на старте.
Без этого проект может застрять на каком-то этапе. Например, если требования к внешнему виду продукта остаются на уровне интуитивных представлений заказчика, то согласовать законченный дизайн будет тяжело. Пока дизайн не согласован, работа над кодом не начнется, релиз будет сдвигаться, а сроки и стоимость проекта — расти.
Что мешает определить требования продукта?
Недостаток информации. Во многих ситуациях заказчик и разработчики диджитал-продукта могут только предполагать, будет ли он востребован. Бывает, что потребности конечного клиента неизвестны вообще, поэтому легко ошибиться в требованиях.
Некомпетентная постановка задач. Мир не идеален. Бывают проекты, в которых не приложили достаточно усилий, чтобы прояснить требования.
Как agile обходит эти риски?
Гибкие методологии принципиально избегают окончательных требований к продукту. Среди множества методов и концепций agile на практике нам чаще всего пригождаются CustDev, MVP и работа итерациями.
CustDev
Customer Development — развитие клиента. Эта методология исходит из ненадежности любого знания о конечном потребителе, если оно не подтверждено данными. CustDev смещает акцент с вопроса “Каким должен быть продукт?” на “Что нужно клиенту?”.
Требования к функционалу и дизайну рождаются из гипотез: какие у конечного потребителя ожидания, потребности и проблемы. Проверить их можно только из реального взаимодействия пользователей с продуктом. Поэтому ключевой этап СustDev — сбор и анализ обратной связи. Она дает реальную информацию о пользователях, позволяющую ставить новые гипотезы, уточнять требования и совершенствовать продукт.
MVP
Чтобы понять клиента, нужно как можно быстрее сделать релиз рабочей версии продукта.
Чем меньше на это уйдет ресурсов, тем лучше — ведь гипотезы о клиенте могут быть в корне неверными, и продукт не будет востребован вообще. Поэтому создается MVP (minimum viable product) — минимально жизнеспособный продукт. Это функциональный прототип, который должен решать основные задачи пользователей, а в остальном может иметь какие угодно недостатки.
Релиз MVP позволяет проверить гипотезы и собрать фидбэк. На практике MVP редко выпускают на рынок, а используют для тестов на ограниченных группах.
Итеративность
После релиза MVP разработка продукта ведется циклами:
- Постановка гипотез.
- Разработка и релиз обновления.
- Сбор и анализ фидбэка о новой версии.
Продукт развивается от итерации к итерации. Если гипотезы не подтвердились: функции оказались не востребованы или не понравился дизайн, то изменение требований не затормозит проект — ведь уже есть доступная рабочая версия. Наоборот, требования должны меняться на основе изучении клиентов.
Когда agile наиболее эффективен?
Продукт новый или у него вообще нет аналогов. Мы используем методы agile для собственного продукта VideoApply. Это сервис асинхронных собеседований, очень удобный для поиска новых сотрудников. Сбор фидбэка после первого релиза помог нам существенно улучшить продукт — мы подробно писали об этом в кейсе.
Сейчас VideoApply на стадии бета-теста — любой желающий может пользоваться им бесплатно. Мы продолжаем изучать пользователей и уже узнали о задачах, которые не были очевидны — будем расширять функционал в следующих версиях.
Есть отлаженный механизм сбора обратной связи. Гибкий подход будет эффективен, если заказчик готов регулярно ставить и проверять гипотезы, а сбор и обработка фидбэка происходят оперативно. Так мы работаем над дизайном для Технониколь, крупного производителя строительных материалов. Они приходят с новыми идеями, мы предлагаем варианты решения, затем тестируем.
Когда нет необходимости в уникальных решениях. Некоторые заказчики обращаются к нам за приложениями для внутреннего использования. Им важна только стабильная работа и оптимизированный функционал продукта, а, например, на совершенствование дизайна и UX они не хотят тратить ресурсы. На таких проектах мы разраба��ываем и развиваем только базовые функции.
Когда agile может навредить?
Когда среднее качество недопустимо. Есть продукты, которые нужно спланировать от начала до конца, иначе они просто не получатся. Невозможно построить минимально функциональный дом, а затем обновлять его каждый год. Или продавать черновую версию ювелирных часов.
Пользователи заметят, если у сайта небрежный визуал или он плохо оптимизирован и тормозит. Впечатление от сайта становится впечатлением от компании и продукта. Для премиальных продуктов и озабоченных имиджем компаний это губительно.
Когда важен WOW-эффект. Чтобы впечатлить пользователей новаторским, эстетичным дизайном, зацепить их чувства, продукт должен сразу предстать во всем своем великолепии — иначе никакого эффекта не будет.
Когда нужно зафиксировать бюджет на этапе планирования. Agile позволяет быстро выйти на пользователей, затратив минимум времени и денег. Но конечный бюджет проекта планировать невозможно — потому что окончательные требования неизвестны в принципе.
Как защититься от рисков без agile?
Полагаться на опыт. Гибкие методы не нужны, если требования к дизайну, структуре и функциям продукта известны на начальном этапе. Опыт, экспертность, знание рынка позволяют разрабатывать продукт с помощью каскадного подхода, понимая, к какому результату приведет то или иное решение.
Уточнять требования. Даже заказчики с большим опытом в своей области не всегда могут конкретизировать свои ожидания от сайта или приложения. На этот случай есть инструменты проведения интервью и анализа компании, которые позволяют перевести интуитивные представления в конкретные требования.
Как понять, какую методологию применять?
Стоит исходить из того, чем ограничен проект. Если вы плохо представляете конечных пользователей и не можете определить требо��ания к продукту — agile. Если релиз сырого продукта будет неэффективным или навредит компании — каскадный метод.
К нам приходят очень разные клиенты с очень разными задачами. Мы выясняем, какой метод подходит конкретному проекту. Самое важное — на начальном этапе откалибровать требования заказчика, ожидания конечного потребителя и наши представления об эффективности.
Подпишитесь на нас, чтобы не пропустить новые детальные разборы кейсов, обсуждения трендов индустрии и взрывных идей. Также следите за нами в Telegram-канале и на сайте Vide Infra.
На связи!