От чего завиÑит ÑтоимоÑть заказной…
Фраза Ð·Ð°ÐºÐ°Ð·Ð½Ð°Ñ Ñ€Ð°Ð·Ñ€Ð°Ð±Ð¾Ñ‚ÐºÐ° MVP может звучать как Ð·Ð°Ð¿Ñ€Ð¾Ñ Ð½Ð° технологию или коммерчеÑкое предложение. Ðо Ð´Ð»Ñ Ð¾ÑÐ½Ð¾Ð²Ð°Ñ‚ÐµÐ»Ñ Ñто прежде вÑего продуктовое решение: необходимо понÑть, что именно формирует ÑтоимоÑть. От качеÑтва Ñтого Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð·Ð°Ð²Ð¸Ñит, даÑÑ‚ ли разработка полезные доказательÑтва или лишь увеличит объем программного обеÑпечениÑ.
Ðиже на практике разобрано, от чего завиÑит ÑтоимоÑть заказной разработки MVP. Материал предназначен Ð´Ð»Ñ Ð¾Ñнователей, которым нужно принимать ÑÑные решениÑ, не ÑтановÑÑÑŒ инженерами. ЕÑли общий процеÑÑ MVP пока незнаком, начните Ñ Ð¿Ñ€Ð°ÐºÑ‚Ð¸Ñ‡ÐµÑкого руководÑтва по разработке MVP, а затем примените Ñту Ñхему к Ñвоему решению.
Ðачните Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ñ, а не Ñ Ñ‚ÐµÑ…Ð½Ð¾Ð»Ð¾Ð³Ð¸Ð¸
Первый вопроÑ: какие Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð¾Ð± объеме и риÑках формируют оценку? ИнÑтрумент, архитектура, модель, агентÑтво или ÑпиÑок функций не ответÑÑ‚ за ваÑ. ОÑнователь должен определить клиента, проблему, ключевой процеÑÑ Ð¸ доказательÑтва, которые оправдают продолжение.
Полезный бюджет ÑвÑзан Ñ ÐºÐ¾Ð½ÐºÑ€ÐµÑ‚Ð½Ñ‹Ð¼Ð¸ результатами, завиÑимоÑÑ‚Ñми, ожиданиÑми качеÑтва и обÑзанноÑÑ‚Ñми поÑле запуÑка, а не Ñ ÑƒÐ½Ð¸Ð²ÐµÑ€Ñальной ценой за Ñкран. Два продукта Ñ Ð¾Ð´Ð¸Ð½Ð°ÐºÐ¾Ð²Ñ‹Ð¼ опиÑанием могут требовать Ñовершенно разной работы. ПроÑтой внутренний процеÑÑ, клиентÑкий ÑÐµÑ€Ð²Ð¸Ñ Ð¿Ð¾ подпиÑке и продукт Ñ Ñ‡ÑƒÐ²Ñтвительными данными не должны получать одинаковые планы.
До обÑÑƒÐ¶Ð´ÐµÐ½Ð¸Ñ Ñ€ÐµÐ°Ð»Ð¸Ð·Ð°Ñ†Ð¸Ð¸ ÑоÑтавьте одноÑтраничный документ: целевой клиент, текущий обходной путь, желаемый результат, оÑновной Ñценарий, предположениÑ, ограничениÑ, иÑÐºÐ»ÑŽÑ‡ÐµÐ½Ð¸Ñ Ð¸ признаки уÑпеха. Он Ñтанет опорой, когда поÑвÑÑ‚ÑÑ Ð½Ð¾Ð²Ñ‹Ðµ идеи или оценки разойдутÑÑ.
Определите узкий, но завершенный результат
«Минимальный» не значит незавершенный. Клиент должен войти в продукт, выполнить важную задачу, получить полезный результат и понимать Ñледующий шаг. У вÑпомогательных операций — проверки, поддержки, иÑправлений, уведомлений и ÑƒÐ¿Ñ€Ð°Ð²Ð»ÐµÐ½Ð¸Ñ ÑƒÑ‡ÐµÑ‚Ð½Ñ‹Ð¼Ð¸ запиÑÑми — тоже должен быть ответÑтвенный, даже еÑли чаÑть работы выполнÑетÑÑ Ð²Ñ€ÑƒÑ‡Ð½ÑƒÑŽ.
Ð”Ð»Ñ Ð·Ð°ÐºÐ°Ð·Ð½Ð¾Ð¹ разработки MVP Ñформулируйте результат так: «Конкретный пользователь может выполнить конкретную задачу и получить конкретный результат при извеÑтных уÑловиÑх». Затем перечиÑлите вÑе, что Ñознательно оÑтаетÑÑ Ð·Ð° границами. Ðто отделÑет необходимое от привлекательных идей на будущее.
ИÑпользуйте краткую запиÑÑŒ решениÑ:
| ОблаÑть | Что зафикÑировать |
|---|---|
| Объем | Включенные Ñценарии и иÑÐºÐ»ÑŽÑ‡ÐµÐ½Ð¸Ñ |
| Ð ÐµÐ°Ð»Ð¸Ð·Ð°Ñ†Ð¸Ñ | Команда, Ñтапы и чаÑтота проверок |
| ÐкÑÐ¿Ð»ÑƒÐ°Ñ‚Ð°Ñ†Ð¸Ñ | ХоÑтинг, модель, поддержка и раÑходы на поÑтавщиков |
| Резерв | ИзвеÑÑ‚Ð½Ð°Ñ Ð½ÐµÐ¾Ð¿Ñ€ÐµÐ´ÐµÐ»ÐµÐ½Ð½Ð¾Ñть, ÑпоÑÐ¾Ð±Ð½Ð°Ñ Ð¸Ð·Ð¼ÐµÐ½Ð¸Ñ‚ÑŒ трудозатраты |
Ð¢Ð°ÐºÐ°Ñ Ð·Ð°Ð¿Ð¸ÑÑŒ полезнее длинного ÑпиÑка пожеланий: каждый пункт можно проверить — обеÑпечивает ли он оÑновной Ñценарий, Ñнижает ÑущеÑтвенный риÑк или Ñобирает нужные данные? ЕÑли нет, вероÑтно, он нужен уже поÑле MVP.
Отделите ÑтоимоÑть ÑÐ¾Ð·Ð´Ð°Ð½Ð¸Ñ Ð¾Ñ‚ ÑтоимоÑти владениÑ
ÐŸÐµÑ€Ð²Ð¸Ñ‡Ð½Ð°Ñ Ð¾Ñ†ÐµÐ½ÐºÐ° — лишь чаÑть обÑзательÑтв. Учтите иÑÑледование, дизайн, реализацию, теÑтирование, развертывание, мониторинг, поддержку, Ñторонние подпиÑки, работу Ñ Ð´Ð°Ð½Ð½Ñ‹Ð¼Ð¸ и будущие изменениÑ. У ИИ-продуктов возможна плата за запроÑÑ‹ к модели; у SaaS — раÑходы на биллинг, почту, хранение, аналитику и поддержку.
ПроÑите каждого иÑÐ¿Ð¾Ð»Ð½Ð¸Ñ‚ÐµÐ»Ñ Ð¾Ð´Ð¸Ð½Ð°ÐºÐ¾Ð²Ð¾ опиÑывать Ð¿Ñ€ÐµÐ´Ð¿Ð¾Ð»Ð¾Ð¶ÐµÐ½Ð¸Ñ Ð¸ иÑключениÑ. ÐÐ¸Ð·ÐºÐ°Ñ Ñумма может означать лишь то, что в одном предложении отÑутÑтвует работа, Ð²ÐºÐ»ÑŽÑ‡ÐµÐ½Ð½Ð°Ñ Ð² другое. Сравнивайте Ñценарий, уÑÐ»Ð¾Ð²Ð¸Ñ ÐºÐ°Ñ‡ÐµÑтва, ответÑтвенноÑть и получаемые доказательÑтва, а не только итоговую цифру.
СвÑзывайте резерв Ñ Ð½Ð°Ð·Ð²Ð°Ð½Ð½Ñ‹Ð¼Ð¸ неопределенноÑÑ‚Ñми. Конкретное понимание интеграции, набора данных или требованиÑ, ÑпоÑобного изменить план, полезнее общего запаÑа.
Ð’Ñ‹Ñвите риÑки до оценки работ
Ранние планы дают Ñбой, когда Ð²Ð°Ð¶Ð½Ð°Ñ Ð½ÐµÐ¾Ð¿Ñ€ÐµÐ´ÐµÐ»ÐµÐ½Ð½Ð¾Ñть маÑкируетÑÑ Ð¿Ð¾Ð´ фикÑированное требование. ПопроÑите команду отделить извеÑтную работу от предположений, которым нужны иÑÑледование, прототип или техничеÑÐºÐ°Ñ Ð¿Ñ€Ð¾Ð²ÐµÑ€ÐºÐ°. Цель не в уÑтранении вÑей неопределенноÑти, а в том, чтобы ÑÐºÑ€Ñ‹Ñ‚Ð°Ñ Ð·Ð°Ð²Ð¸ÑимоÑть не управлÑла вÑем проектом.
Типичные риÑки:
- Сравнение предложений Ñ Ñ€Ð°Ð·Ð½Ñ‹Ð¼ объемом. ЗафикÑируйте, как команда Ñто обнаружит и что предпримет.
- ИÑключение иÑÑледованиÑ, теÑÑ‚Ð¸Ñ€Ð¾Ð²Ð°Ð½Ð¸Ñ Ð¸Ð»Ð¸ развертываниÑ. Опишите ÑпоÑоб Ð¾Ð±Ð½Ð°Ñ€ÑƒÐ¶ÐµÐ½Ð¸Ñ Ð¸ реакцию.
- Игнорирование ÑервиÑов Ñ Ð¾Ð¿Ð»Ð°Ñ‚Ð¾Ð¹ по иÑпользованию. Опишите контроль и ответные дейÑтвиÑ.
- Выбор иÑключительно по Ñамой низкой цене. ЗафикÑируйте, как команда избежит Ñтого.
ОбÑуждайте не только вероÑтноÑть, но и поÑледÑÑ‚Ð²Ð¸Ñ Ñ Ð¾Ñ‚Ð²ÐµÑ‚Ð½Ñ‹Ð¼Ð¸ мерами. Сторонний ÑÐµÑ€Ð²Ð¸Ñ Ð¼Ð¾Ð¶ÐµÑ‚ быть надежным, но требовать запаÑного варианта. Модель может пройти демонÑтрацию и не ÑправитьÑÑ Ñ Ñ€Ð°Ð·Ð½Ð¾Ð¾Ð±Ñ€Ð°Ð·Ð½Ñ‹Ð¼Ð¸ данными клиентов. ТехничеÑки проÑтой процеÑÑ Ð¼Ð¾Ð¶ÐµÑ‚ оказатьÑÑ Ð½ÐµÐ¿Ð¾Ð´ÑŠÐµÐ¼Ð½Ñ‹Ð¼ Ð´Ð»Ñ Ð¿Ð¾Ð´Ð´ÐµÑ€Ð¶ÐºÐ¸. Ðти Ñ€Ð°Ð·Ð»Ð¸Ñ‡Ð¸Ñ Ð²Ð»Ð¸ÑÑŽÑ‚ на объем и порÑдок работ.
РуководÑтво по приоритизации риÑков MVP поможет, когда Ð²Ð½Ð¸Ð¼Ð°Ð½Ð¸Ñ Ñ‚Ñ€ÐµÐ±ÑƒÑŽÑ‚ неÑколько неопределенноÑтей.
Превратите план в проверÑемые Ñтапы
Избегайте Ñтапов вроде «бÑкенд готов» или Â«Ð¸Ð½Ñ‚ÐµÐ³Ñ€Ð°Ñ†Ð¸Ñ Ð˜Ð˜ завершена»: они отражают активноÑть, а не пригодный результат. Хороший Ñтап заканчиваетÑÑ Ð´ÐµÐ¼Ð¾Ð½Ñтрируемым результатом клиента или оператора и пиÑьменными критериÑми приемки.
Ð”Ð»Ñ ÐºÐ°Ð¶Ð´Ð¾Ð³Ð¾ Ñтапа задайте Ñценарий, иÑходные данные, ожидаемый результат, поведение при ошибке и ÑохранÑемые доказательÑтва. ОÑнователь должен видеть реальный процеÑÑ Ð½Ð° демонÑтрации и ÑопоÑтавлÑть его Ñ Ñоглашением. ВопроÑÑ‹ и Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ñ…Ñ€Ð°Ð½Ð¸Ñ‚Ðµ в общем журнале.
ПроверÑйте и доÑтупы. ÐšÐ¾Ð¼Ð¿Ð°Ð½Ð¸Ñ Ð´Ð¾Ð»Ð¶Ð½Ð° контролировать репозиторий, хоÑтинг, домены, аналитику, Ñторонние ÑервиÑÑ‹, дизайн-файлы и продуктовые данные — оÑобенно при работе Ñ Ð²Ð½ÐµÑˆÐ½Ð¸Ð¼Ð¸ ÑпециалиÑтами и платформами Ñ Ð¾Ð¿Ð»Ð°Ñ‚Ð¾Ð¹ по иÑпользованию.
ИзмерÑйте доказательÑтва, а не активноÑть
ЗдеÑÑŒ полезны детализированный объем, Ñвные предположениÑ, критерии приемки Ñтапов, оценка ÑкÑплуатационных раÑходов и раÑпределение ответÑтвенноÑти за запуÑк и поддержку. Выберите неÑколько показателей, прÑмо ÑвÑзанных Ñ Ð³Ð»Ð°Ð²Ð½Ñ‹Ð¼ предположением. Панель Ñо Ñлучайной активноÑтью может Ñоздать ложное ощущение Ð·Ð´Ð¾Ñ€Ð¾Ð²ÑŒÑ Ð¿Ñ€Ð¾Ð´ÑƒÐºÑ‚Ð°.
До запуÑка определите чаÑтоту анализа, ответÑтвенного за результаты, ÑпоÑоб Ð¾Ð±ÑŠÐµÐ´Ð¸Ð½ÐµÐ½Ð¸Ñ Ð¾Ñ‚Ð·Ñ‹Ð²Ð¾Ð² Ñ Ð¿Ð¾Ð²ÐµÐ´ÐµÐ½Ñ‡ÐµÑкими данными и уÑÐ»Ð¾Ð²Ð¸Ñ Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð¸Ñ ÐºÑƒÑ€Ñа. Данные могут подÑказать продолжить работу, Ñузить аудиторию, изменить процеÑÑ Ð¸Ð»Ð¸ технологию либо оÑтановитьÑÑ. Ð”Ð»Ñ MVP вÑе Ñти иÑходы допуÑтимы.
ОбновлÑйте приоритеты на оÑнове результатов, а не автоматичеÑки добавлÑйте Ñамую запрашиваемую функцию. Сначала выÑÑните, ÑвлÑетÑÑ Ð»Ð¸ Ð·Ð°Ð¿Ñ€Ð¾Ñ Ð¿Ð¾Ð²Ñ‚Ð¾Ñ€ÑющимÑÑ Ð¿Ñ€ÐµÐ¿ÑÑ‚Ñтвием Ð´Ð»Ñ Ñ†ÐµÐ»ÐµÐ²Ð¾Ð³Ð¾ клиента или предпочтением одного человека.
Ðффективно работайте Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´Ð¾Ð¹ разработки
ОÑнователю не нужно диктовать техничеÑкие детали, но нужна прозрачноÑть. ПроÑите команду проÑтыми Ñловами объÑÑнÑть требование, раÑÑмотренные варианты, компромиÑÑÑ‹, выбранный подход и уÑÐ»Ð¾Ð²Ð¸Ñ ÐµÐ³Ð¾ переÑмотра.
СоглаÑуйте короткие циклы обратной ÑвÑзи, рабочие демонÑтрации, критерии приемки и понÑтный путь ÑÑкалации. При Ñравнении внешних иÑполнителей руководÑтво по выбору компании Ð´Ð»Ñ Ñ€Ð°Ð·Ñ€Ð°Ð±Ð¾Ñ‚ÐºÐ¸ MVP поможет оценить доказательÑтва и владение результатом, а не качеÑтво презентации.
При здоровом ÑотрудничеÑтве обÑзанноÑти различаютÑÑ. ОÑнователь отвечает за знание клиента, приоритеты, коммерчеÑкие Ð¾Ð³Ñ€Ð°Ð½Ð¸Ñ‡ÐµÐ½Ð¸Ñ Ð¸ продуктовые решениÑ. ТехничеÑÐºÐ°Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´Ð° — за качеÑтво разработки, варианты реализации, теÑтирование, безопаÑноÑть и ÑкÑплуатационные рекомендации. СущеÑтвенные компромиÑÑÑ‹ принимаютÑÑ ÑовмеÑтно и фикÑируютÑÑ.
ПрактичеÑкий ÑпиÑок Ñледующих шагов
Перед новым вложением в заказную разработку MVP убедитеÑÑŒ, что можете ответить:
- Кто конкретно будет первым пользователем?
- Какой завершенный результат даÑÑ‚ продукт?
- Какое предположение проверÑет релиз?
- Что Ñвно иÑключено?
- ÐšÐ°ÐºÐ°Ñ Ð·Ð°Ð²Ð¸ÑимоÑть или техничеÑкое решение неÑет наибольший риÑк?
- Какие данные будут изучены поÑле реального иÑпользованиÑ?
- Кто отвечает за ÑкÑплуатацию, поддержку, данные, учетные запиÑи и решениÑ?
- Какой результат заÑтавит продолжить, переÑмотреть или оÑтановить работу?
ЯÑные ответы не уÑтранÑÑŽÑ‚ неопределенноÑть, но делают ее управлÑемой. Они дают дизайнерам и разработчикам контекÑÑ‚, чтобы предложить более проÑтые варианты, а не воÑпринимать широкий термин как указание Ñоздать вÑе ÑвÑзанное Ñ Ð½Ð¸Ð¼.
Сделайте минимально обоÑнованное вложение
Лучший план заказной разработки MVP не обÑзательно Ñамый быÑтрый или техничеÑки амбициозный. Ðто минимально обоÑнованное вложение, которое дает реальный результат, ответÑтвенно учитывает извеÑтные риÑки и Ñоздает данные Ð´Ð»Ñ Ñледующего решениÑ.
ИÑпользуйте документ Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð½Ð° протÑжении вÑей разработки. ОбновлÑйте Ð¿Ñ€ÐµÐ´Ð¿Ð¾Ð»Ð¾Ð¶ÐµÐ½Ð¸Ñ Ð¿Ñ€Ð¸ изменении клиентÑких данных, фикÑируйте причины Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð¸Ñ Ð¾Ð±ÑŠÐµÐ¼Ð° и требуйте демонÑтраций оÑновного ÑценариÑ. Ð¢Ð°ÐºÐ°Ñ Ð´Ð¸Ñциплина защищает и от преждевременной ÑложноÑти, и от опаÑных Ð´Ð»Ñ Ñ€ÐµÐ°Ð»ÑŒÐ½Ð¾Ð³Ð¾ иÑÐ¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ð½Ð¸Ñ Ñокращений.
Превратите решение в ÑфокуÑированный план MVP
MVPHub поможет уточнить объем, риÑки, подход к реализации и доказательÑтва, необходимые Ð´Ð»Ñ ÑƒÐ±ÐµÐ´Ð¸Ñ‚ÐµÐ»ÑŒÐ½Ð¾Ð³Ð¾ первого релиза.
ЗапиÑатьÑÑ Ð½Ð° беÑплатную конÑультацию Ñ MVPHubЧасто Задаваемые Вопросы
С чего начать заказную разработку MVP?
Сначала определите целевого клиента, нужный ему результат и непроверенное предположение, которое должна проверить разработка. Лишь затем выбирайте технологию или иÑполнителÑ.
Как нетехничеÑкому оÑнователю управлÑть заказной разработкой MVP?
Отвечайте за проблему клиента, приоритеты, Ð¾Ð³Ñ€Ð°Ð½Ð¸Ñ‡ÐµÐ½Ð¸Ñ Ð¸ критерии уÑпеха. ПроÑите техничеÑкую команду проÑтым Ñзыком объÑÑнÑть варианты и компромиÑÑÑ‹, а прогреÑÑ Ð¾Ñ†ÐµÐ½Ð¸Ð²Ð°Ð¹Ñ‚Ðµ по рабочим демонÑтрациÑм и фактам.
Как Ñохранить Ñ„Ð¾ÐºÑƒÑ Ð¿Ñ€Ð¸ заказной разработке MVP?
Определите один целоÑтный путь клиента и Ñвно зафикÑируйте иÑключениÑ. Включайте только то, что необходимо Ð´Ð»Ñ Ñ†ÐµÐ½Ð½Ð¾Ñти, ответÑтвенной ÑкÑплуатации, ÑÐ½Ð¸Ð¶ÐµÐ½Ð¸Ñ Ñ€Ð¸Ñка или обучениÑ.
Как понÑть, уÑпешна ли Ð·Ð°ÐºÐ°Ð·Ð½Ð°Ñ Ñ€Ð°Ð·Ñ€Ð°Ð±Ð¾Ñ‚ÐºÐ° MVP?
До начала разработки выберите поведенчеÑкие показатели, ÑвÑзанные Ñ Ð³Ð»Ð°Ð²Ð½Ñ‹Ð¼ предположением. Оценивайте выполнение реальных задач, повторное иÑпользование, качеÑтво, Ð¾Ð±Ñ€Ð°Ñ‰ÐµÐ½Ð¸Ñ Ð² поддержку и коммерчеÑкую готовноÑть, а не только мнениÑ.