Как составить бюджет для вашего минимально жизнеспособного продукта
Существует ряд способов создай свой MVP, и каждый из них может иметь различную структуру ценообразования. Но здесь я пытаюсь изложить некоторые эмпирические правила того, как получить бюджетные ориентиры для определенных функций.
Большинство приложений будут иметь фиксированную стоимость запуска проекта, а затем дополнительные затраты. Вы хотите свести к минимуму фиксированные затраты, чтобы сфокусироваться на своей уникальной ценности. Многие магазины разработчиков имеют эту фиксированную стоимость с точки зрения выделения ресурсов на полный рабочий день для вашего проекта или, возможно, нескольких ресурсов (QA, UX, PM). Они не могут начать работу без выделения этого. Это приводит к долгосрочным проектам, месяцам, когда вы можете не увидеть ни одной функции до двух месяцев оплаты. Вы хотели бы, чтобы все шло быстрее, с небольшим прогрессом в ваших личных функциях. Магазины разработчиков часто имеют минимальную сумму проекта от 20 000 долларов или больше. И первое, что вы видите, будет отполировано, прежде чем вам будет разрешено протестировать функциональность, это то, что вы хотите. Это рецепт, чтобы сжечь много денег.
Создание шаблонов — еще один враг вашего бюджета. Экраны входа в систему, личные сообщения, страницы профилей есть в каждом приложении, и хотя они необходимы для запуска бета-версии, часто они не нужны при ограниченном бюджете. Вы хотите, чтобы команда сосредоточилась на новом коде. Оттачивайте свою уникальную особенность и создавайте только ее. Бюджет каждого из этих компонентов, упомянутых ранее, может составлять несколько тысяч. Просто настроить для первой версии. Спросите себя, действительно ли это необходимо для вашей презентации инвесторам или для демонстрации друзьям. Ответ, вероятно, «не сейчас».
Третья категория расползания бюджета — это исправление ошибок и полировка. Вы определенно хотите иметь полировку, когда делитесь своей идеей с другими, и она не должна ломаться. Но когда сами разберетесь со своим разработчиком, поймете, что будут проблемы. Будут баги, и вы не хотите платить за 100% надежный код в каждой поставке. Это искусственно увеличит бюджет и заставит разработчика ставить более высокую цену, потому что у вас высокие стандарты доставки. Вам нужен разработчик, который будет предоставлять высококачественный код, но только после того, как будут согласованы функции, созданы прототипы, доставлены, а затем утверждены. Это хорошее эмпирическое правило, чтобы оставаться в тесном цикле обратной связи с разработчиком, чтобы они чувствовали себя комфортно, делясь черновыми версиями, чтобы получить ранние изменения, если требования не были ясны или требования изменились.
Есть несколько причин расползания бюджета в MVP, и здесь мы рассмотрели несколько способов смягчить их и управлять ожиданиями, чтобы поддерживать более низкую общую стоимость. Это сложный баланс. Обратитесь, если вам нужна помощь в навигации или нужен кто-то, кто строит с учетом этих соображений.
