Обреченный на успех StartUp. Глава 2
От идеи к MVP
В этой главе я расскажу про процесс запуска MVP в The StartUp с аутсорс-командой разработки: как и кем готовились продуктовые требования, как велась передача этих требований, как проходила приемка и какие получились результаты.
Важно подчеркнуть один ключевой момент: для основателя стартапа не существовало понятия минимально жизнеспособного продукта (MVP) в привычном смысле. Для него аббревиатура MVP всегда ассоциировалась с "Most Valuable Player" — самым ценным игроком команды. Бизнес стремился к созданию полноценной и серьезной первой версии продукта, исключая любые полумеры. Для удобства в статье я буду использовать термин MVP, подразумевая первую полноценную версию продукта.
Что же получите вы, дорогие читатели? Ответ на вопрос: может ли хорошая идея стать успешным продуктом с первого раза?
Команда The StartUp
Внутренняя команда на момент запуска MVP состояла из основателя и операционной команды - молодых ребят, вчерашних студентов, нанятых на позиции аналитиков. Часть этой операционной команды и станет первой продуктовой командой компании.
Было решено запускать MVP по следующему процессу: команда The StartUp подготовит продуктовые требования, передаст аутсорс-команде разработки, команда разработки изолированно напишет весь код и передаст продукт на приемку. Этот процесс напоминал классическую модель Waterfall.
Первая продуктовая документация
Продуктовая документация, подготовленная импровизированной командой без продактов, аналитиков и дизайнеров, представляла собой схематичные мокапы и верхнеуровневые описания того, как должен работать продукт. Вся информация для документации была получена путем интервьюирования основателя, который рассказал, что и как нужно сделать, чтобы VIP-клиенты могли ставить ставки на большие суммы.
Документация, подготовленная со слов основателя, была передана команде разработки и команда отправилась писать код. Процесс не предполагал постоянную коммуникацию с внешней командой в процессе разработки.
Внешняя команда разработки
Общение между внутренней продуктовой командой и командой разработки велось и ограничивалось контактированием с одним человеком, чья функциональность была схожа с обязанностями СТО (Технического директора). Общение ограничивалось передачей схематичных требований, созвонами по точечным проблемам и обсуждениями финансовых вопросов.
Процесс в команде разработки для продакта, чаще всего, это черный ящик. Процесс в команде разработки на аутсорсе — это черный ящик в плаще невидимке. Мы могли бы спекулировать на тему процессов внутри команды разработки на аутсорсе, могли бы гадать и предполагать кто именно писал код и какой квалификацией обладали разработчики, но вместо этого мы будем опираться на факты.
Факт #1 : блокеры на первой приемке
После изолированной разработки операционной команде предстояло провести первичную приемку продукта и передать эстафету бизнесу. Операционная команда в распоряжение получила MVP продукта, который представлял из себя операторскую и клиентскую части. Операторы могли управлять запросами клиентов, вести чат и управлять спортивными событиями, а клиенты - делать ставки и общаться с операторами.
Процесс приемки включал тестирование пользовательских сценариев, фиксацию ошибок в Google-документе и передачу этих ошибок разработчикам для исправления.
В каждом пользовательском сценарии, при первом же взаимодействии с функциональностью, находились фатальные проблемы, превращающие функциональность в нерабочую. Результаты первой приемки намекали, что в аутсорс-команде разработчики не проверяли, как работает их код, а QA-специалистов либо не было вовсе, либо их квалификация оставляла желать лучшего.
После нескольких итераций исправления проблем продукт выглядел рабочим: очевидные пользовательские сценарии работали без видимых проблем. Было принято решение устроить приемку с участием бизнеса, потому что, кроме прочего, сроки реализации, согласованные бизнесом и командой разработки, уже прошли. Бизнесу нужен был результат.
Факт #2: бизнес крайне недоволен
Бизнесу не понравилось все, что он увидел на приемке MVP. Критике подверглось все: скорость, реализация, внешний вид всей функциональности. “Работать с этим невозможно”, - таков был вердикт в сухом остатке.
Стоит пояснить, почему провал достиг именно такого масштаба. При первичном тестировании продукта, которое обычно проводят разработчики или тестировщики (но не представители бизнеса), можно столкнуться с различными проблемами: неработающая функциональность (это “блокеры”), некорректно работающая основная функциональность (критические ошибки), проблемы с менее важной функциональностью (это так называемые "мажоры"). В хорошо отлаженном IT-процессе за начальную приемку обычно отвечают автотесты или ручные QA-специалисты, которые сверяют реализацию с требованиями. В таких условиях вероятность того, что блокеры и критикалы дойдут до бизнес-приемки, ниже.
В нашем случае, из-за отсутствия полноценных требований (а следовательно, и понимания, как должна работать конкретная функциональность), критические и серьезные проблемы были выявлены, в том числе, и на стадии бизнес-приемки. Только основатель компании понимал, как именно всё должно работать.
В конечном счете, приемка MVP основателем провалилась: продукт был признан неработоспособным (хотя все-таки поработал какое-то время в таком состоянии), результатом работы аутсорс-команды бизнес был недоволен и от дальнейшего сотрудничества с ней отказался.
Факт #3: аутсорс-команда осталась в выигрыше
Хотя сотрудничество и не продлилось, все обязательства перед этой командой были выполнены: аутсорс-разработчики получили оплату в полном объеме, как только бизнес “принял” функциональность.
Факт #4: полностью переписанный код
Можно ли сказать, что код аутсорс-команды совсем не работал? Нет. Несмотря на множество проблем в коде, с которыми не хотел мириться бизнес, первый клиент появился, и началась проверка бизнес-идеи.
Забегая вперед, скажу, что код, написанный внешней командой разработки, был полностью переписан in-house командой впоследствии, но это мы обсудим в следующей главе.
Выводы
Опыт создания первой версии продукта дал понимание, что для достижения поставленных целей, нужна своя собственная команда разработки с прозрачными процессами и профессиональными требованиями. Одних только знаний о рынке ставок (хотя и обширных) оказалось недостаточно.
Хорошо продуманная бизнес-идея — это важный элемент в создании успешного продукта. Но не достаточный. Грамотная реализация и команда компетентных специалистов — еще одна ключевая часть. Хотя и это не гарантирует успех на 100%, но гармоничное сочетание технической экспертизы и знания предметной области значительно увеличивает шансы на достижение поставленных целей.
P.S. RoadMap демонстрирует полноценное содержание всей эпопеи, а в канале мы обсуждаем и другие важные дела.