Обреченный на успех StartUpГлава 2. От идеи к MVP
В этой главе я расскажу про процесс запуска MVP в The StartUp с аутсорс-командой разработки: как и кем готовились продуктовые требования, как велась передача этих требований, как проходила приемка и какие получились результаты.
Важно подчеркнуть один ключевой момент: для основателя стартапа не существовало понятия минимально жизнеспособного продукта (MVP) в привычном смысле. Для него аббревиатура MVP всегда ассоциировалась с "Most Valuable Player" — самым ценным игроком команды. Бизнес стремился к созданию полноценной и серьезной первой версии продукта, исключая любые полумеры. Для удобства в статье я буду использовать термин MVP, подразумевая первую полноценную версию продукта.
Что же получите вы, дорогие читатели? Ответ на вопрос: может ли хорошая идея стать успешным продуктом с первого раза?
💁 Команда The StartUpВнутренняя команда на момент запуска MVP состояла из основателя и операционной команды - молодых ребят, вчерашних студентов, нанятых на позиции аналитиков. Часть этой операционной команды и станет первой продуктовой командой компании.
Было решено запускать MVP по следующему процессу: внутренняя команда подготовит продуктовые требования, передаст аутсорс-команде разработки, команда разработки изолированно напишет весь код и передаст продукт на приемку. Этот процесс напоминал классическую модель Waterfall.
📄 Первая продуктовая документация Продуктовая документация, подготовленная импровизированной командой без продактов, аналитиков и дизайнеров, представляла собой схематичные мокапы и верхнеуровневые описания того, как должен работать продукт. Вся информация для документации была получена путем интервьюирования основателя, который рассказал, что и как нужно сделать, чтобы VIP-клиенты могли ставить ставки на большие суммы.
Документация, подготовленная со слов основателя, была передана команде разработки и команда отправилась писать код. Процесс не предполагал постоянную коммуникацию с внешней командой в процессе разработки.
🧑💻 Внешняя команда разработкиОбщение между внутренней продуктовой командой и командой разработки велось и ограничивалось контактированием с одним человеком, чья функциональность была схожа с обязанностями СТО (Технического директора). Общение ограничивалось передачей схематичных требований, созвонами по точечным проблемам и обсуждениями финансовых вопросов.
Процесс в команде разработки для продакта, чаще всего, это черный ящик. Процесс в команде разработки на аутсорсе — это черный ящик в плаще невидимке. Мы могли бы спекулировать на тему процессов внутри команды разработки на аутсорсе, могли бы гадать и предполагать кто именно писал код и какой квалификацией обладали разработчики, но вместо этого мы будем опираться на факты.
1️⃣ Факт #1: блокеры на первой приемке После изолированной разработки операционной команде предстояло провести первичную приемку продукта и передать эстафету бизнесу. Операционная команда в распоряжение получила MVP продукта, который представлял из себя операторскую и клиентскую части. Операторы могли управлять запросами клиентов, вести чат и управлять спортивными событиями, а клиенты - делать ставки и общаться с операторами.
Процесс приемки включал тестирование пользовательских сценариев, фиксацию ошибок в Google-документе и передачу этих ошибок разработчикам для исправления.
В каждом пользовательском сценарии, при первом же взаимодействии с функциональностью, находились фатальные проблемы, превращающие функциональность в нерабочую. Результаты первой приемки намекали, что в аутсорс-команде разработчики не проверяли, как работает их код, а QA-специалистов либо не было вовсе, либо их квалификация оставляла желать лучшего.
После нескольких итераций исправления проблем продукт выглядел рабочим: очевидные пользовательские сценарии работали без видимых проблем. Было принято решение устроить приемку с участием бизнеса, потому что, кроме прочего, сроки реализации, согласованные бизнесом и командой разработки, уже прошли. Бизнесу нужен был результат.
ПРОДОЛЖЕНИЕ НИЖЕ
👇#TheStartUp
