Проектный подход в разработке MVP

Когда инхаус — не вариант

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

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

У команды А есть ИТ-направление для развития основного сервиса. Но на разработку и развитие экспериментального продукта команде не хватает ресурсов. Найм квалифицированных ИТ-специалистов и формирование проектной команды не только займёт несколько месяцев, но и нагрузит core-направление дополнительными интервью и онбордингом.

У Компании А есть выбор: усилить текущую команду через аутстаф или передать разработку сервиса полностью внешнему исполнителю.

Рассмотрим доступные варианты:

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

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

Продукт или проект?

Команда А понимает, что за три месяца невозможно реализовать весь функционал сервиса. Поэтому приоритизирует часть из них, формируя MVP — тестовую версию продукта с минимальными функциями.

А как быть, если после релиза потребуются доработки и обновления?

К разработке MVP применим и продуктовый подход, и проектный. Сейчас объясним, почему.

Разработка MVP (Minimum Viable Product) версии сервиса обычно относится к продуктовой разработке. Целью MVP является быстрое получение обратной связи от пользователей и проверка гипотез о продукте без затрат на разработку полного функционала.

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

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

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

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

Проектный подход и три ограничения

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

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

Формируется проектный треугольник: срок, бюджет, содержание. Разберём его подробнее:

Бюджет

Есть два формата оплаты: Fixed Price и Time&Materials. В первом случае при заказе услуги клиент платит фиксированную сумму, указанную в договоре. В итоговую стоимость закладывается коэффициент рисков. Ответственность за сроки и качество несет исполнитель единолично.

T&M предполагает, что заказчик оплачивает время, потраченное на решение задачи. В договоре фиксируется только ставка специалиста в час, ответственность за сроки и стоимость несут обе стороны. Чем более расплывчаты требования или чем чаще они меняются, тем выше стоимость и сроки. Подрядчик может обозначить превышение, а заказчик принимает решение: делать, как было согласовано изначально, или в процессе менять планы.

Как поступить:

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

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

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

Подрядчик может выполнить несколько этапов — например, аналитику или дизайн — по фиксированной стоимости, а остальные работы провести по T&M.

Сроки

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

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

Как поступить: при горящих сроках выбрать формат T&M, так как он позволяет закрыть больше задач в ограниченное время, а также изменить планы в процессе разработки. В случае с Fixed Price вы придёте в точку Б, которую на входе оговорили и согласовали.

Содержание

Фикс-прайс допускает компромиссы относительно качества продукта как раз из-за условий строго определенного бюджета и правил. При этом бывают разные ситуации, например, старт в срочном порядке, который предполагает выделение и планирование времени специалистов, ускоренные темпы работы. T&M предполагает оплату по факту выполнения работ, и подрядчик заинтересован в предоставлении качественного результата. Ведь в обратном случае длительного сотрудничества не произойдет.

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

Итак, наша встреча с Компанией А прошла успешно: команда согласилась на старт работ по T&M. У Команды А было понимание, какими функциями в целом должен обладать сервис, были референсы и примеры. Чтобы зафиксировать и распространить это понимание на всех участников, а также сформировать функционал MVP, мы предложили этап предпроектной аналитики до начала первого спринта.

Планируем — через аналитику

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

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

Состоит из двух этапов:

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

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

В результате такой работы получаем документ с бизнес-аналитикой.

Системная аналитика

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

Один из плюсов аналитики — получение экспресс-оценки, которая позволяет прогнозировать загрузку специалистов с учетом сроков проекта.

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

Например, может оказаться, что какие-то процессы лучше автоматизировать, а какие-то нет. Станет понятно, какие функции вынести в MVP, а какие — в бэклог.

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

Поэтому Команда А согласилась и только выиграла от этого решения.

От реализации до финала

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

Где зафиксированы договорённости

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

Например, в SLA (соглашение об уровне услуг) определяем условия предоставления услуг, включая качества, время реакции на запросы и другие параметры.

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

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

Как планировать загрузку

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

В этом помогают такие инструменты визуализации, как диаграмма сгорания, диаграмма Гантта.

Как работать над проектом

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

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

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

Работаем спринтами — короткими интервалами, в течение которых реализуем заданный объём. В результате получаем готовый инкремент продукта — завершенный конкретный этап в разработке.

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

Как завершить проект

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

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

За день до установки релиза проводим демо заказчику, получаем фидбек и проводим релиз.

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

Жизнь после релиза

Неужели на этом всё?

Да, работы по проекту завершены и заказчик получил готовую MVP. Но это не значит, что продукт не получает дальнейшего развития.

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

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

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

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

‍