Проектный подход в разработке MVP
Когда инхаус — не вариант
Для наглядности мы попросили компанию А поделиться историей создания экспериментального сервиса.
Компания А занимается развитием сервиса бронирования гостиниц, отелей, хостелов.
Крупные игроки, с которыми раньше сотрудничала компания А, покидают рынок. Теперь отельерам для размещения своего объекта нужно подключать интеграции. Компания А задумалась о создании своего B2B-сервиса, который позволил бы непрофессиональным отельерам получать прямые бронирования.
У команды А есть ИТ-направление для развития основного сервиса. Но на разработку и развитие экспериментального продукта команде не хватает ресурсов. Найм квалифицированных ИТ-специалистов и формирование проектной команды не только займёт несколько месяцев, но и нагрузит core-направление дополнительными интервью и онбордингом.
У Компании А есть выбор: усилить текущую команду через аутстаф или передать разработку сервиса полностью внешнему исполнителю.
Рассмотрим доступные варианты:
-
Аутстаф ИТ-специалистов поможет закрыть конкретные компетенции в моменте для достижения целей проектов. Например, в разработке, тестировании, аналитике. Инхаус-команда полностью отвечает за управление и результат.
-
Аутсорсинг — подключение внешней команды для разработки одного из элементов сервиса или системы. Например, подрядчик пишет только фронтенд, а остальное на клиенте. Две ИТ-команды взаимодействуют на протяжении срока проекта.
-
Аутсорсинг всего сервиса, разработка под ключ — когда поставщик реализует весь проект своими силами. ИТ-команда поставщика взаимодействует с бизнес-заказчиком и инфраструктурными ИТ-специалистами, которые помогают интегрировать конечный продукт во внутренние системы.
Команда А сильно ограничена во времени: нужно запустить и тестировать продукт к сезону отпусков, а это всего через пару месяцев. Команда решает передать разработку на аутсорс полностью, чтобы снизить нагрузку на инхаус-специалистов.
Создайте конкурс на workspace.ru — получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь — выберите и сэкономьте до 30%.
Создать конкурс →
Продукт или проект?
Команда А понимает, что за три месяца невозможно реализовать весь функционал сервиса. Поэтому приоритезирует часть из них, формируя 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 вы придёте в точку Б, которую на входе оговорили и согласовали.
Недостаточное планирование и неправильное распределение ресурсов могут привести к серьезным проблемам и задержкам в проекте.
Часто люди недооценивают сложность и объем работы, необходимой для завершения проекта, и поэтому планируют слишком оптимистично. Непредвиденные трудности тормозят проект.
— «The Mythical Man-Month: Essays on Software Engineering», Фредерик Брукc
Содержание
Фикс-прайс допускает компромиссы относительно качества продукта как раз из-за условий строго определенного бюджета и правил. При этом бывают разные ситуации, например, старт в срочном порядке, который предполагает выделение и планирование времени специалистов, ускоренные темпы работы. T&M предполагает оплату по факту выполнения работ, и подрядчик заинтересован в предоставлении качественного результата. Ведь в обратном случае длительного сотрудничества не произойдет.
Как поступить: озвучить такой риск и зафиксировать процент отклонения на уровне договора, чтобы обе стороны были осведомлены.
Итак, наша встреча с Компанией А прошла успешно: команда согласилась на старт работ по T&M. У Команды А было понимание, какими функциями в целом должен обладать сервис, были референсы и примеры. Чтобы зафиксировать и распространить это понимание на всех участников, а также сформировать функционал MVP, мы предложили этап предпроектной аналитики до начала первого спринта.
Планируем — через аналитику
Разберем еще две характеристики проекта: цели и ресурсы. Чтобы прийти к конечному результату, нужно понимать, что хотим получить на выходе, с помощью каких ресурсов — затрат специалистов на выполнение задач.
В этом нам помогают проектная документация и техническое задание. И вот чтобы собрать все контексты и требования в одном месте, учесть ожидания, не упустив ничего важного и не добавив лишнего, мы в Holyweb проводим предпроектную аналитику.
Состоит из двух этапов:
Бизнес-аналитика — помогает компаниям создать продукт, который будет в равной степени решать задачи бизнеса и проблемы пользователя. Этот этап помогает выявить проблемы и возможности бизнеса, определить цели и задачи проекта, а также оценить потенциальную выгоду от его реализации. Здесь же проводятся исследования рынка, конкурентов, определение целевой аудитории и ее потребностей.
Из этого формируются сценарии, которые должны быть реализованы в конечном продукте. На проекте бизнес-аналитик выступает связующим звеном между заказчиком и командой разработки.
В результате такой работы получаем документ с бизнес-аналитикой.
Системная аналитика
Системная аналитика занимается разработкой технических требований к системе на основе результатов бизнес-анализа. Она определяет функциональность системы, ее структуру и взаимодействие компонентов, а также выбирает подходящие технологии для реализации проекта. Системная аналитика помогает перевести требования бизнес-аналитики на технический язык, чтобы передать в разработку — в виде ТЗ. Разработчики используют такой документ для оценки и в качестве дорожной карты. Поэтому важно правильно снять требования с заказчика и зафиксировать их в формате технических спецификаций.
Один из плюсов аналитики — получение экспресс-оценки, которая позволяет прогнозировать загрузку специалистов с учетом сроков проекта.
Предпроектный анализ позволяет клиентам сформировать реальные ожидания по стоимости проекта, сократить сроки его реализации. Его следует рассматривать как инвестиции, которые в долгосрочной перспективе приносят измеримую экономию.
Например, может оказаться, что какие-то процессы лучше автоматизировать, а какие-то нет. Станет понятно, какие функции вынести в MVP, а какие — в бэклог.
Сначала команда А хотела отказаться от аналитики: ведь на руках есть референсы. Но оказалось, что сроки на разработку сильно ограничены, нужно успеть за несколько месяцев. Требовалось не только оперативно собрать команду и стартовать, но и описать требования, декомпозировать задачи, строго придерживаться календарного плана. В таких условиях отказаться от аналитики — поставить под угрозу рентабельность сервиса.
Поэтому Команда А согласилась и только выиграла от этого решения.
От реализации до финала
Время самого длительного этапа — работы над проектом. Требует слаженных действий команды и грамотного управления. Но на первый взгляд может быть непонятно, каким правилам следует команда при работе и коммуникации.
Где зафиксированы договорённости
Договор как основной юридический документ фиксирует взаимоотношения между компаниями, и проект может быть объектом этих взаимоотношений. Но мы не можем указать в договоре все детали, которые важны в процессах. В зависимости от проекта мы выбираем, где эти подробности будут закреплены.
Например, в SLA (соглашение об уровне услуг) определяем условия предоставления услуг, включая качества, время реакции на запросы и другие параметры.
Техническое задание (ТЗ) — это документ, который содержит требования к разрабатываемому продукту или услуге. В ТЗ могут быть определены роли и ответственности команды разработчиков, а также указаны конкретные специалисты, отвечающие за определенные участки работы.
Устав проекта может быть частью ТЗ. Он обеспечивает общее понимание проекта и обозначает зоны ответственности между спонсором проекта, основными заинтересованными сторонами сторонами и проектной командой. Устав проекта обычно ссылается на более подробные документы, такие как требования к проекту.
Как планировать загрузку
Экспресс-оценка, которую получили после аналитики, позволяет наглядно отобразить загрузку команды на календарном плане. Задача руководителя проектов — координировать и контролировать работу специалистов так, чтобы не отклоняться от заявленных сроков.
В этом помогают такие инструменты визуализации, как диаграмма сгорания, диаграмма Гантта.
Как работать над проектом
Особенность проектов в IT — вовлечение большого числа участников, среди которых и технические специалисты, менеджеры, руководители. Важно обеспечить согласованность и понимание через слаженную и гибкую коммуникацию.
Примеры: стартовое обсуждение проекта, еженедельные собрания, презентация проекта.
В документах — например, в уставе проекта — фиксируем, сколько длится спринт, как часто проводим демо и встречи, на которых получаем фидбек и корректировки.
Работаем спринтами — короткими интервалами, в течение которых реализуем заданный объём. В результате получаем готовый инкремент продукта — завершенный конкретный этап в разработке.
Возможен вариант, когда за рамки спринта выносим некоторые работы: например, аналитика, проектирование или дизайн. Это позволяет не терять время внутри спринта и корректно оценивать временные затраты, а также гарантирует поставку готового инкремента продукта.
Как завершить проект
Перед спринтом формируется документ о релизе. В рамках документа указываем, какие задачи отдадим реализованными, а по каким будем проводить аналитику или дизайн, версии компонентов, особенности тестирования. Дальше запускается стандартный флоу скрама: задачи двигаются от этапа разработки до ревью и тестирования.
К концу спринта и ближе к дате релиза все задачи по разработке должны быть сделаны, команда тестирования начинает регрессионное тестирование.
За день до установки релиза проводим демо заказчику, получаем фидбек и проводим релиз.
Могут быть отклонения от такого сценария, например, когда в рамках релиза планируем работы, связанные с другой командой. Тогда дополняем документ План установки релиза, где прописываем последовательность и сроки запуска.
Жизнь после релиза
Неужели на этом всё?
Да, работы по проекту завершены и заказчик получил готовую MVP. Но это не значит, что продукт не получает дальнейшего развития.
Задача команды теперь — опираясь на обратную связь и гипотезы расширять функционал продукта, улучшать производительность, закрывать задачи из бэклога.
На смену чёткой структуре проектного подхода приходит продуктовая разработка с большей неопределённостью.
Теперь вы знаете, как проходит разработка MVP продукта на аутсорсе. Это только один из нужных вариантов, выбор которого зависит от возможностей бизнеса.
Будем рады обсудить ваш опыт в комментариях. Если вы передавали разработку продукта внешним командам, какие плюсы и минусы обнаружили для себя?
Полный текст статьи читайте на CMS Magazine прочитано 16308 раз