В мире есть много людей с горящими глазами, которые не боятся брать на себя риск. У кого-то получается запустить успешный стартап за пару месяцев и привлечь инвесторов, а кто-то никак не выкатит MVP или вовсе прогорает. По подсчетам Startup Genome Report, 92% стартапов умирают после запуска.
Я участвовал в IT-стартапах. Как и все, наделал много типичных ошибок в первых проектах. Собрал для тебя самые распространённые:
1. Забивать на экономику
Когда тебе придёт в голову крутая и уникальная идея для проекта — не спеши писать код, для начала проверь экономику. У стартапа, как и у любого бизнеса, должна быть целевая аудитория. Проанализируй, кому будет необходим твой продукт, формат монетизации, конкурентов. Если конкурентов нет даже близко — задумайся, возможно на подобные продукты нет спроса. Продумай все траты и как ты их обеспечишь: своими силами или привлечёшь инвесторов.
Не забывай, что IT-стартап работает по тем же правилам, что и остальной бизнес. Они важнее кода, и их надо учитывать. Если совсем не шаришь в этом, могу посоветовать клёвую и небольшую книжку от Тинькова «Бизнес без MBA» — там есть всё, что нужно для начала.
2. Не заморачиваться с архитектурой и чистотой кода
Первое, что стоит сделать после оценки экономики продукта — это полностью проработать и задокументировать архитектуру приложения. Да, на это нужно немало времени, но зато ты сэкономишь себе уйму времени и нервов в дальнейшем. Если забьёшь и будешь прорабатывать архитектуру на ходу — гарантированно будешь переделывать существующий код очень часто.
Если вдобавок ты думаешь, что на чистоту кода можно забить, чтобы тратить меньше времени — это настоящее бинго, проект превратится в хаос. Как писал Б. Мартин: «Написание "грязного" кода тормозит процесс разработки на любом промежутке времени». Это реально так, проверено.
Проработай масштабируемую архитектуру. Пиши чистый и понятный код (линтеры в помощь). И потрать немного времени на покрытие тестами.
3. Отсутствие плана и минимального продукта
Этот пункт следует из прошлого. Когда у тебя есть полностью описанная архитектура, намного проще составить план, раскидать задачи и оценить сроки. Не будет плана — будет хаос и неопределённость.
Вообще, планов у тебя должно быть минимум два: на MVP и дальнейший план развития проекта. Да, проект можно запускать не когда он будет полностью готов, а когда он будет стабильно выполнять основные функции.
4. «Больше команда — значит лучше»
Многие стартапы набирают людей в команду без разбора и обжигаются на этом. Не бойся делать проекты в одиночку. Если ты понимаешь, что сам не справишься, то бери действительно нужных людей в команду. Если нужен специалист для одной конкретной задачи (например, провести маркетинговую кампанию), часто лучше привлечь кого-нибудь с фриланса.
5. Фокусироваться на деталях
«Готов логотип, но до сих пор не сделали веб-сервер для приложения». Знакомо? Если нет, не совершай эту стандартную ошибку. Сделать логотип или разбить приложение на микросервисы в kybernetes — это детали. Детали можно и нужно откладывать. У таких задач приоритет должен быть ниже, чем у основных.
Не пытайся использовать в своём проекте все самые нашумевшие библиотеки и другие инструменты, если их можно без проблем добавить в проект в дальнейшем. К примеру, не задрачивайся на микросервисы — сделай монолит с разбинием по модулям и здорово сэкономишь время. Если проект взлетит, при грамотной архитектуре этот монолит легко будет распилить на микросервисы.