Продуктовая разработка — как сделать технический прототип, чтобы осталось еще на маркетинг

Я до последнего уверен, что кризис это плохое время для старта нового бизнеса в 99% случаев и работа в подобных условиях может угробить классную идею, которая бы в обычное время взлетела с большей вероятностью. Если от моего совета что-нибудь зависит, то он звучит так: берегите себя, хорошо высыпайтесь и кушайте. В общем, набирайтесь сил для того, чтобы начать новый бизнес вместе с восстановлением экономики и обойти на повороте тех, кто потерял все силы на борьбу с обстоятельствами.

Эта статья для тех, кто не послушает и решит делать ИТ-проект прямо сейчас. В ней собран шестилетний опыт команды, которая разрабатывала технические прототипы для стартапов: от провала и невыхода продукт в релиз до продажи компании стратегу.

Базовое правило, которое нужно усвоить первым. В моем практике было два классных продукта, которые так и не запустились, потому что основатель боялся показать "сырой продукт" рынку (у каждого кто занимался стартапами есть обязательно такая своя история). Все закончилось тем, что разработка затянулась сначала на несколько месяцев, потом лет, а дальше проект потерял свою актуальность. Чем быстрее вы покажете свой продукт рынку, тем меньше вы потратите денег на собственные фантазии и быстрее начнете делать вещи, за которые реально готовы платить.

Идеальный случай, когда один программист может сделать всю работу, обычно это фуллстек программист. Допустимо, когда работает бекенд-разработчик и фронт-енд разработчик. Дальше с добавлением каждого нового разработчика растут: количество багов в продукте, технический долг и стоимость разработки. Почему? Можно прочитать например, тут. Да, я понимаю, что построить команду из пяти разработчиков это не rocket science, но если она вам нужна на этапе запуска технического прототипа, то вероятнее всего вы что-то делаете не правильно.

Кажется, что объективная и простая вещь, но почему-то и здесь умудряются набивать шишки. Чаще всего они заключаются в желании сделать красивее, моднее, вместо быстрее и дешевле. Как бы здорово не выглядел ваш продукт, но в результате придется все равно переделывать его под вкусы аудитории, которая будет платить деньги.

Здесь речь про подготовительную фазу к разработке, а именно: проведение конкурентного анализа, проверку спроса, формирование гипотез для проверки и разработку задания. По опыту хорошая пропорция это 30-40% времени на подготовку и 60-70% на разработку. Стартовать без подготовки и вносить изменения "на ходу" всегда большой соблазн, вот только никогда это не заканчивается хорошо. В лучшем случае вы потратите кучу времени и проиграете в качестве проекта на переделках, в худшем при отсутствии подготовки вообще сделаете никому не нужный продукт. О проверке спроса и о том, почему программисты не умеют делать MVP я уже писал тут.

Часто при разработке технического прототипа хочется заложиться на будущее и сразу сделать архитектуру, которая "готова к масштабированию". При этом сделать это почти невозможно, поскольку на этапе разработки технического прототипа никто и близко не представляет, как система будет использоваться, какие будут ограничения и сценарии. На деле это приводит к усложнению и увеличению стоимости разработки, а переделывать все равно потом придется.

В качестве байки на эту тему приведу историю из фейсбук своего товарища:

Неделю назад, на одном проекте, в модуле работы с временем я увидел класс, считающий кол-во месяцев в году. С фабрикой, абстрактными методами и имплементацией, которая возвращает кол-во месяцев в году в зависимости от года. Кода строк на 100. "На*а?" спросил я чувака из команды. "У нас в большом кол-ве мест в проекте было захардкожено число 12, это не круто, magic numbers - это антипаттерн". "Ок, но почему просто не забить его в константу..?". "Ну, у нас уже была абстракция для кол-ва дней в месяце в году (високосный или нет), мы решили для месяцев сделать такую же". Звучит как шизофрения, а на деле - 8 коммитов в гите.

Готов пообщаться пол часа с каждым, кто собирается делать технический прототип продукта или MVP. Людей без сомнений не бывает. За пол часа вы получите взгляд на проект со стороны и узнаете, как сэкономить деньги на разработке и повысить свои шансы получить венчурное финансирование для своего проекта в ближайшие 1 - 6 месяцев с помощью создания правильного технического прототипа.

Почему 100 000$? Это минимальная сумма (процентиль ~ 10%), которую вы сможете получить на российском венчурном рынке для развития проекта.

Требование к проекту:

Для тех, кто уже «пробежал» стадию MVP и технического прототипа и ставит перед собой цели больше, то давайте знакомиться.