POC, прототип и MVP: в каком порÑдке…

Фраза POC до MVP может звучать как Ð·Ð°Ð¿Ñ€Ð¾Ñ Ñ‚ÐµÑ…Ð½Ð¾Ð»Ð¾Ð³Ð¸Ð¸ или Ñметы. Ðо Ð´Ð»Ñ Ð¾ÑÐ½Ð¾Ð²Ð°Ñ‚ÐµÐ»Ñ Ñто прежде вÑего продуктовое решение: выбор подходÑщей поÑледовательноÑти разработки. От его качеÑтва завиÑит, даÑÑ‚ ли работа полезные доказательÑтва или лишь дополнительное программное обеÑпечение.

Это практичеÑкое руководÑтво объÑÑнÑет, в каком порÑдке Ñоздавать POC, прототип и MVP. Оно предназначено Ð´Ð»Ñ Ð¾Ñнователей, которым нужно принимать ÑÑные решениÑ, не ÑтановÑÑÑŒ инженерами. ЕÑли общий процеÑÑ Ð½ÐµÐ·Ð½Ð°ÐºÐ¾Ð¼, начните Ñ Ð¿Ñ€Ð°ÐºÑ‚Ð¸Ñ‡ÐµÑкого руководÑтва по разработке MVP, а затем примените Ñту ÑиÑтему.

Ðачните Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ñ, а не технологии

СпроÑите: чего должен добитьÑÑ Ð¿ÐµÑ€Ð²Ñ‹Ð¹ пригодный выпуÑк? ИнÑтрумент, архитектура, модель, агентÑтво или ÑпиÑок функций не ответÑÑ‚ вмеÑто ваÑ. ОÑнователь определÑет клиента, проблему, главный процеÑÑ Ð¸ доказательÑтва, оправдывающие продолжение.

Полезный первый выпуÑк завершает один клиентÑкий Ñценарий, а не изображает будущий продукт в миниатюре. ПроÑтой внутренний процеÑÑ, клиентÑÐºÐ°Ñ Ð¿Ð¾Ð´Ð¿Ð¸Ñка и продукт Ñ ÐºÐ¾Ð½Ñ„Ð¸Ð´ÐµÐ½Ñ†Ð¸Ð°Ð»ÑŒÐ½Ñ‹Ð¼Ð¸ данными требуют разных планов, даже еÑли опиÑываютÑÑ Ð¾Ð´Ð¸Ð½Ð°ÐºÐ¾Ð²Ñ‹Ð¼ ключевым Ñловом.

До обÑÑƒÐ¶Ð´ÐµÐ½Ð¸Ñ Ñ€ÐµÐ°Ð»Ð¸Ð·Ð°Ñ†Ð¸Ð¸ ÑоÑтавьте одноÑтраничный документ: целевой клиент, текущий обходной путь, желаемый результат, оÑновной Ñценарий, предположениÑ, ограничениÑ, иÑÐºÐ»ÑŽÑ‡ÐµÐ½Ð¸Ñ Ð¸ признаки уÑпеха. Он Ñтанет ориентиром при поÑвлении идей и разных оценок.

Определите узкий, но полный результат

«Минимальный» не значит незавершенный. Клиент должен войти, выполнить важную задачу, получить полезный результат и понÑÑ‚ÑŒ Ñледующий шаг. СопутÑтвующие операции — проверка, поддержка, иÑправлениÑ, ÑƒÐ²ÐµÐ´Ð¾Ð¼Ð»ÐµÐ½Ð¸Ñ Ð¸ учетные запиÑи — тоже требуют владельца, даже еÑли оÑтаютÑÑ Ñ€ÑƒÑ‡Ð½Ñ‹Ð¼Ð¸.

Ð”Ð»Ñ POC до MVP опишите результат так: «Конкретный пользователь выполнÑет конкретную задачу и получает конкретный результат в извеÑтных уÑловиÑх». Затем перечиÑлите намеренные иÑключениÑ.

ОблаÑÑ‚ÑŒ решениÑ	Что зафикÑировать
Результат	Один результат первого клиента
Граница	Явно отложенные функции
ДоказательÑтво	Поведение, оправдывающее Ñледующие вложениÑ
Владелец	ОтветÑтвенный за каждое открытое решение

Ð¢Ð°ÐºÐ°Ñ Ð·Ð°Ð¿Ð¸ÑÑŒ полезнее длинного ÑпиÑка желаний: каждый пункт можно проверить — обеÑпечивает ли он оÑновной Ñценарий, Ñнижает ÑущеÑтвенный риÑк или Ñобирает нужные данные? ЕÑли нет, вероÑтно, его меÑто поÑле MVP.

СоотнеÑите результат Ñ Ð½ÐµÐ¾Ð¿Ñ€ÐµÐ´ÐµÐ»ÐµÐ½Ð½Ð¾Ñтью

Прототип иÑÑледует опыт, POC — оÑущеÑтвимоÑÑ‚ÑŒ, MVP — ценноÑÑ‚ÑŒ Ñ Ñ€ÐµÐ°Ð»ÑŒÐ½Ñ‹Ð¼Ð¸ пользователÑми. Границы могут переÑекатьÑÑ, но Ð²Ð¾Ð¿Ñ€Ð¾Ñ Ð´Ð¾Ð»Ð¶ÐµÐ½ оÑтаватьÑÑ ÑÑным. Ðе превращайте ÑкÑпериментальный код в поÑтоÑнный только потому, что демонÑÑ‚Ñ€Ð°Ñ†Ð¸Ñ Ð²Ñ‹Ð³Ð»Ñдела убедительно.

Определите завершение заранее. Прототипу нужны реалиÑтичные Ñкраны и отзывы о задачах; POC — повторÑемые результаты на типичных данных; MVP — надежный Ñквозной Ñценарий, операции, поддержка и измерение.

При переходе оцените, что Ñохранить. Ð—Ð½Ð°Ð½Ð¸Ñ Ð¸ теÑÑ‚Ñ‹ обычно переноÑÑÑ‚ÑÑ, а код, архитектура, данные и интерфейÑÑ‹ могут потребовать оÑознанной переÑтройки.

Ð’Ñ‹Ñвите риÑки до оценки работы

Ранние планы проваливаютÑÑ, когда неопределенноÑÑ‚ÑŒ маÑкируют под фикÑированное требование. ПопроÑите отделить извеÑтную работу от предположений, требующих иÑÑледованиÑ, прототипа или техничеÑкой проверки. Цель — не убрать вÑÑŽ неопределенноÑÑ‚ÑŒ, а не дать Ñкрытой завиÑимоÑти управлÑÑ‚ÑŒ проектом.

• Объем раÑтет до проÑÑÐ½ÐµÐ½Ð¸Ñ Ð³Ð»Ð°Ð²Ð½Ð¾Ð³Ð¾ предположениÑ. Запишите ÑпоÑоб Ð¾Ð±Ð½Ð°Ñ€ÑƒÐ¶ÐµÐ½Ð¸Ñ Ð¸ реакцию.
• ЗавиÑимые функции обнаруживаютÑÑ Ñлишком поздно. Запишите ÑпоÑоб Ð¾Ð±Ð½Ð°Ñ€ÑƒÐ¶ÐµÐ½Ð¸Ñ Ð¸ реакцию.
• Команда улучшает внешний вид раньше пользы. Запишите ÑпоÑоб Ð¾Ð±Ð½Ð°Ñ€ÑƒÐ¶ÐµÐ½Ð¸Ñ Ð¸ реакцию.
• У операций за интерфейÑом нет владельца. Запишите ÑпоÑоб Ð¾Ð±Ð½Ð°Ñ€ÑƒÐ¶ÐµÐ½Ð¸Ñ Ð¸ реакцию.

ОбÑуждайте поÑледÑÑ‚Ð²Ð¸Ñ Ð¸ реакцию, не только вероÑтноÑÑ‚ÑŒ. Стороннему ÑервиÑу может понадобитьÑÑ Ñ€ÐµÐ·ÐµÑ€Ð²; модель может пройти демонÑтрацию, но провалитьÑÑ Ð½Ð° разнообразных данных; проÑтой техничеÑкий процеÑÑ Ð¼Ð¾Ð¶ÐµÑ‚ быть неподъемным Ð´Ð»Ñ ÑкÑплуатации. Это менÑет объем и порÑдок.

Когда конкурируют неÑколько неопределенноÑтей, поможет ÑÑ‚Ð°Ñ‚ÑŒÑ Ð¾ приоритизации риÑков MVP.

Превратите план в проверÑемые Ñтапы

Избегайте Ñтапов «бÑкенд готов» или Â«Ð¸Ð½Ñ‚ÐµÐ³Ñ€Ð°Ñ†Ð¸Ñ Ð˜Ð˜ завершена»: они показывают деÑтельноÑÑ‚ÑŒ, а не полезный прогреÑÑ. Хороший Ñтап заканчиваетÑÑ Ð´ÐµÐ¼Ð¾Ð½Ñтрируемым результатом клиента или оператора и пиÑьменными уÑловиÑми приемки.

Ð”Ð»Ñ ÐºÐ°Ð¶Ð´Ð¾Ð³Ð¾ Ñтапа определите Ñценарий, иÑходные данные, ожидаемый результат, поведение при ошибке и ÑохранÑемые доказательÑтва. ОÑнователь должен увидеть реальный процеÑÑ Ð¸ Ñравнить его Ñ Ð´Ð¾Ð³Ð¾Ð²Ð¾Ñ€ÐµÐ½Ð½Ð¾Ñтью. ВопроÑÑ‹ и Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ñ…Ñ€Ð°Ð½Ð¸Ñ‚Ðµ в общем журнале.

ПроверÑйте не только функции, но и доÑтуп. ÐšÐ¾Ð¼Ð¿Ð°Ð½Ð¸Ñ Ð´Ð¾Ð»Ð¶Ð½Ð° контролировать репозиторий, хоÑтинг, домены, аналитику, Ñторонние ÑервиÑÑ‹, дизайн и данные — оÑобенно при внешних ÑпециалиÑтах и платформах Ñ Ð¾Ð¿Ð»Ð°Ñ‚Ð¾Ð¹ за иÑпользование.

ИзмерÑйте доказательÑтва, а не активноÑÑ‚ÑŒ

Полезные данные включают завершение ÑценариÑ, повторное иÑпользование, Ð¾Ð±Ñ€Ð°Ñ‰ÐµÐ½Ð¸Ñ Ð² поддержку и подтверждение Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð·Ð°Ñвленной проблемы. Выберите небольшой набор, прÑмо ÑвÑзанный Ñ Ð³Ð»Ð°Ð²Ð½Ñ‹Ð¼ предположением. Панель Ñ Ð½ÐµÑ€ÐµÐ»ÐµÐ²Ð°Ð½Ñ‚Ð½Ð¾Ð¹ активноÑтью может Ñоздать ложное впечатление уÑпеха.

До запуÑка определите периодичноÑÑ‚ÑŒ и владельца проверки, ÑпоÑоб Ð¾Ð±ÑŠÐµÐ´Ð¸Ð½ÐµÐ½Ð¸Ñ Ð¾Ñ‚Ð·Ñ‹Ð²Ð¾Ð² Ñ Ð¿Ð¾Ð²ÐµÐ´ÐµÐ½Ð¸ÐµÐ¼ и уÑÐ»Ð¾Ð²Ð¸Ñ Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð¸Ð¹. Данные могут оправдать продолжение, Ñужение аудитории, изменение процеÑÑа, технологии или оÑтановку — вÑе Ñто допуÑтимые результаты MVP.

Ðе добавлÑйте автоматичеÑки Ñамую запрашиваемую функцию: Ñначала выÑÑните, повторÑющийÑÑ Ð»Ð¸ Ñто барьер целевого клиента или предпочтение одного человека.

Ð­Ñ„Ñ„ÐµÐºÑ‚Ð¸Ð²Ð½Ð°Ñ Ñ€Ð°Ð±Ð¾Ñ‚Ð° Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´Ð¾Ð¹ разработки

ОÑнователю не нужно диктовать реализацию, но нужна прозрачноÑÑ‚ÑŒ. ПроÑите проÑтое объÑÑнение требованиÑ, вариантов, компромиÑÑов, выбранного подхода и уÑловий его изменениÑ.

СоглаÑуйте короткие циклы обратной ÑвÑзи, рабочие демонÑтрации, критерии приемки и путь ÑÑкалации. При Ñравнении внешней помощи руководÑтво по выбору компании Ð´Ð»Ñ Ñ€Ð°Ð·Ñ€Ð°Ð±Ð¾Ñ‚ÐºÐ¸ MVP поможет оценивать результаты и владение, а не презентацию.

ОÑнователь отвечает за клиента, приоритеты, коммерчеÑкие Ð¾Ð³Ñ€Ð°Ð½Ð¸Ñ‡ÐµÐ½Ð¸Ñ Ð¸ продуктовые решениÑ. ТехничеÑÐºÐ°Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´Ð° — за инженерное качеÑтво, варианты реализации, теÑтирование, безопаÑноÑÑ‚ÑŒ и ÑкÑплуатационные рекомендации. Важные компромиÑÑÑ‹ решаютÑÑ Ð¸ фикÑируютÑÑ Ð²Ð¼ÐµÑте.

ПрактичеÑкий контрольный ÑпиÑок

До дальнейших вложений в POC до MVP ответьте:

• Кто первый конкретный пользователь?
• Какой полный результат даÑÑ‚ продукт?
• Какое предположение проверÑет выпуÑк?
• Что Ñвно иÑключено?
• ÐšÐ°ÐºÐ°Ñ Ð·Ð°Ð²Ð¸ÑимоÑÑ‚ÑŒ или Ñ‚ÐµÑ…Ð½Ð¾Ð»Ð¾Ð³Ð¸Ñ Ð½ÐµÑет главный риÑк?
• Какие данные проверÑÑ‚ поÑле реального иÑпользованиÑ?
• Кто владеет операциÑми, поддержкой, данными, учетными запиÑÑми и решениÑми?
• Какой результат приведет к продолжению, переÑмотру или оÑтановке?

ЯÑные ответы не уÑтранÑÑŽÑ‚ неопределенноÑÑ‚ÑŒ, но делают ее управлÑемой и позволÑÑŽÑ‚ предложить более проÑтые варианты вмеÑто попытки поÑтроить вÑÑ‘, ÑвÑзанное Ñ ÑˆÐ¸Ñ€Ð¾ÐºÐ¸Ð¼ термином.

Возьмите наименьшее обоÑнованное обÑзательÑтво

Лучший план POC до MVP — не обÑзательно Ñамый быÑтрый или техничеÑки амбициозный. Это наименьшее обоÑнованное обÑзательÑтво, которое дает реальный результат, ответÑтвенно управлÑет извеÑтными риÑками и Ñоздает данные Ð´Ð»Ñ Ñледующего решениÑ.

Поддерживайте документ решений на протÑжении работы: обновлÑйте Ð¿Ñ€ÐµÐ´Ð¿Ð¾Ð»Ð¾Ð¶ÐµÐ½Ð¸Ñ Ð¿Ð¾ данным клиентов, фикÑируйте причины Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð¸Ñ Ð¾Ð±ÑŠÐµÐ¼Ð° и требуйте демонÑтраций оÑновного ÑценариÑ. Ð¢Ð°ÐºÐ°Ñ Ð´Ð¸Ñциплина защищает и от преждевременной ÑложноÑти, и от небезопаÑных Ñокращений.

Часто Задаваемые Вопросы

Каков первый шаг при Ñоздании POC до MVP?

Сначала определите целевого клиента, нужный ему результат и неопределенное предположение, которое предÑтоит проверить. Выбирайте технологию и иÑÐ¿Ð¾Ð»Ð½Ð¸Ñ‚ÐµÐ»Ñ Ñ‚Ð¾Ð»ÑŒÐºÐ¾ поÑле Ñтого.

Как оÑнователю без техничеÑкого опыта управлÑÑ‚ÑŒ POC до MVP?

Возьмите ответÑтвенноÑÑ‚ÑŒ за проблему клиента, приоритеты, Ð¾Ð³Ñ€Ð°Ð½Ð¸Ñ‡ÐµÐ½Ð¸Ñ Ð¸ критерии уÑпеха. ПроÑите команду проÑтым Ñзыком объÑÑнÑÑ‚ÑŒ варианты и компромиÑÑÑ‹, а ход работы оценивайте по дейÑтвующим демонÑтрациÑм и доказательÑтвам.

Как Ñохранить POC до MVP ÑфокуÑированным?

Определите один полный клиентÑкий Ñценарий и Ñвно запишите иÑключениÑ. Включайте лишь работу, необходимую Ð´Ð»Ñ Ñ†ÐµÐ½Ð½Ð¾Ñти, ответÑтвенной ÑкÑплуатации, ÑÐ½Ð¸Ð¶ÐµÐ½Ð¸Ñ Ñ€Ð¸Ñка или обучениÑ.

Как понÑÑ‚ÑŒ, что POC до MVP уÑпешен?

До разработки выберите поведенчеÑкие данные, ÑвÑзанные Ñ Ð³Ð»Ð°Ð²Ð½Ñ‹Ð¼ предположением. Оценивайте выполнение реальных задач, повторное иÑпользование, качеÑтво, Ð¾Ð±Ñ€Ð°Ñ‰ÐµÐ½Ð¸Ñ Ð² поддержку и коммерчеÑкие обÑзательÑтва, а не только мнениÑ.