Я до последнего уверен, что кризис это плохое время для старта нового бизнеса в 99% случаев и работа в подобных условиях может угробить классную идею, которая бы в обычное время взлетела с большей вероятностью. Если от моего совета что-нибудь зависит, то он звучит так: берегите себя, хорошо высыпайтесь и кушайте. В общем, набирайтесь сил для того, чтобы начать новый бизнес вместе с восстановлением экономики и обойти на повороте тех, кто потерял все силы на борьбу с обстоятельствами.
Эта статья для тех, кто не послушает и решит делать ИТ-проект прямо сейчас. В ней собран шестилетний опыт команды, которая разрабатывала технические прототипы для стартапов: от провала и невыхода продукт в релиз до продажи компании стратегу.
Итак, 5 простых правил, которые написаны слезами стартаперов. Если вы их не выполняете, то смело умножайте ваш бюджет х2.
- Если вам не стыдно за первую версию вашего продукта, вы запустились слишком поздно (с) Хоффман Рид, сооснователь Lindkedin
Базовое правило, которое нужно усвоить первым. В моем практике было два классных продукта, которые так и не запустились, потому что основатель боялся показать "сырой продукт" рынку (у каждого кто занимался стартапами есть обязательно такая своя история). Все закончилось тем, что разработка затянулась сначала на несколько месяцев, потом лет, а дальше проект потерял свою актуальность. Чем быстрее вы покажете свой продукт рынку, тем меньше вы потратите денег на собственные фантазии и быстрее начнете делать вещи, за которые реально готовы платить.
- 9 женщин не могут родить ребёнка за 1 месяц
Идеальный случай, когда один программист может сделать всю работу, обычно это фуллстек программист. Допустимо, когда работает бекенд-разработчик и фронт-енд разработчик. Дальше с добавлением каждого нового разработчика растут: количество багов в продукте, технический долг и стоимость разработки. Почему? Можно прочитать например, тут. Да, я понимаю, что построить команду из пяти разработчиков это не rocket science, но если она вам нужна на этапе запуска технического прототипа, то вероятнее всего вы что-то делаете не правильно.
- Продукт должен нравится не вам, а вашим клиентам
Кажется, что объективная и простая вещь, но почему-то и здесь умудряются набивать шишки. Чаще всего они заключаются в желании сделать красивее, моднее, вместо быстрее и дешевле. Как бы здорово не выглядел ваш продукт, но в результате придется все равно переделывать его под вкусы аудитории, которая будет платить деньги.
- Кто долго запрягает, тот быстро едет
Здесь речь про подготовительную фазу к разработке, а именно: проведение конкурентного анализа, проверку спроса, формирование гипотез для проверки и разработку задания. По опыту хорошая пропорция это 30-40% времени на подготовку и 60-70% на разработку. Стартовать без подготовки и вносить изменения "на ходу" всегда большой соблазн, вот только никогда это не заканчивается хорошо. В лучшем случае вы потратите кучу времени и проиграете в качестве проекта на переделках, в худшем при отсутствии подготовки вообще сделаете никому не нужный продукт. О проверке спроса и о том, почему программисты не умеют делать MVP я уже писал тут.
- Не нужно закладывать архитектуру на будущее
Часто при разработке технического прототипа хочется заложиться на будущее и сразу сделать архитектуру, которая "готова к масштабированию". При этом сделать это почти невозможно, поскольку на этапе разработки технического прототипа никто и близко не представляет, как система будет использоваться, какие будут ограничения и сценарии. На деле это приводит к усложнению и увеличению стоимости разработки, а переделывать все равно потом придется.
В качестве байки на эту тему приведу историю из фейсбук своего товарища:
Неделю назад, на одном проекте, в модуле работы с временем я увидел класс, считающий кол-во месяцев в году. С фабрикой, абстрактными методами и имплементацией, которая возвращает кол-во месяцев в году в зависимости от года. Кода строк на 100. "На*а?" спросил я чувака из команды. "У нас в большом кол-ве мест в проекте было захардкожено число 12, это не круто, magic numbers - это антипаттерн". "Ок, но почему просто не забить его в константу..?". "Ну, у нас уже была абстракция для кол-ва дней в месяце в году (високосный или нет), мы решили для месяцев сделать такую же". Звучит как шизофрения, а на деле - 8 коммитов в гите.
Предложение на 100 000$
Готов пообщаться пол часа с каждым, кто собирается делать технический прототип продукта или MVP. Людей без сомнений не бывает. За пол часа вы получите взгляд на проект со стороны и узнаете, как сэкономить деньги на разработке и повысить свои шансы получить венчурное финансирование для своего проекта в ближайшие 1 - 6 месяцев с помощью создания правильного технического прототипа.
Почему 100 000$? Это минимальная сумма (процентиль ~ 10%), которую вы сможете получить на российском венчурном рынке для развития проекта.
Требование к проекту:
- Возраст до 1 года
- Выручка до 1 млн. рублей/месяц
- Вы готовы работать над проектом на текущей стадии минимум 15-20 часов в неделю.
Для тех, кто уже «пробежал» стадию MVP и технического прототипа и ставит перед собой цели больше, то давайте знакомиться.