Сборник ошибок «Как убить свой стартап»
Реальные фейлы из нашей практики по созданию мобильного приложения с технической командой на аутсорсе. Пишу и плачу.
Не буду углубляться в полемику создания идеи для стартапа, писала уже об этом на vc.ru. Убеждена, что какая-бы идея не была и если у нее есть цель, здравый смысл, нет прямых аналогов, то вариант один - проверить все в действии. Поэтому, я перейду сразу к проектно-техническим аспектам.
Команда и MVP. Ошибка № 1 и 2.
Если идея проекта «родилась сама собой», как это обычно и бывает, то все ее детали по реализации, ценности, позиционированию и анализу конкурентов мы уже прорабатывали с командой.
Скажу сразу, что серьезного опыта до этого у меня, как у фаундера, не было. Более того, будучи еще офисным планктоном, я даже не удосужилась почитать литературу перед запуском или хотя бы посмотреть канал Y Combinator на YouTube. Это моя нулевая стартовая ошибка.
При подборе команды, кроме профессионализма, принципиальными аспектами для меня были: отсутсвие снобизма, мышление на опережение, позитив, страсть к своей профессии и путешествиям, надежность. Так в проект FREEKIN' присоеденились две девушки под задачи: спец по маркетингу и развитию и UX/UI дизайнер. Было ли это правильно? О, нет! Ошибка № 1.
Начинать IT-стартап без СТО - все равно что доить корову в ладошку. Большая часть будет мимо. И это наш случай
Втроем мы закрыли блоки по позиционированию, неймингу, лого, прототипированию и дизайну приложения, прорисовали всю логику экранов, написали ТЗ и, как нам показалось, были готовы искать команду на девелопинг. Когда по факту начинать весь этот путь мы должны были с толковым СТО, который бдил бы границы MVP, пресекал излишний дорогой «креатив», полностью забрал на себя контроль разработки и думал о тех будущем приложения.
В нашем же случае и составе команды, сложилось все так, что в процессе креатива нас захватила жадность, и мы напрочь не думали об MVP (минимально жизнеспособном продукте). Мы хотели все и сразу. Ошибка № 2.
Вместо кучи фич и супер-крутого «хай тек» продукта нужно идти исключительно путем MVP и его проверки в реальном бою.
В самой известной стартап книге «Lean startups» много об этом говорили, только прочитала я ее слишком поздно.
Сейчас же мы четко на себе прочувствовали, что:
- Скомпоновав яркое, простое и в идее и в исполнении MVP, вы быстрее всех самых быстрых выйдете на рынок и начнете ахреневать от происходящего.
- Сэкнономите при этом не только время, но и бюджет. Много и сразу – не есть хорошо.
- Соберете данные от реальных пользователей и сделаете pivot (поворот) в сторону более масштабируемой версии.
Мы сделали 3-ий pivot в процессе углубления в проблемы людей и тенденций, сфокурсировавшись на основной боли свободных путешественников при поиске нетуристических, некоммерческих и аутентичных мест в мире. Как решение мы выпустили мобильное приложение с интерактивной картой и обязательной модерацией. Но мы и дальше будем тестировать подходы.
P.S.: на мой взгляд, MVP не должен стоить более чем 10 000 $. Если он получается у вас на дороже, то убирайте все, что можно убрать, чтобы войти в эти рамки. Скорее всего вы распыляетесь по фичам.
P.S.S: а поиски СТО по разным причинам продолжаются до сих пор… Сим-салабим-рахат-лукум СТО прекрасненький найдись!
Разработка и ТЗ. Ошибки № 3, 4 и 5
Так как тех экспертизы на нашей стороне не было, то мы искали команду под задачу на аутсорсе. На тендеры, просчеты, личные встречи-знакомства и обсуждения деталей ушло более 4 месяцев.
Внешне задача не казалась сложной: мы хотели найти команду под ключ (не фрилансеров), которая имела бы успешный опыт создания мобильных приложений с картами и была бы комфортна по цене/коммуникациям.
В итоге, у меня сложилось впечатление, что подобные стартапы (здесь я имею в виду разработку любых мобильных приложени/сайтов) выходят на рынок быстро только тогда, когда сами фаундеры их и пишут, либо когда задействованы мешки денег и нечеловеческая удача.
Только с 5-ой командой из уже отобранного нами ТОПа агентств мы ударили по рукам. Предыдущие претенденты отвалились из-за того, что в процессе аудита и проработки нюансов мы просто переставали быть уверенными в их профессионализме. И это были агенства по рекомендациям.
Ошибка № 3 - выбор девелоперов:
Без знакомства с учредителями и наличия в портфолио рабочих приложений на сторах (!) связываться даже не стоит. Не ведитесь на все остальное.
Из нас просто стали потрошить деньги, на нас "забивали", и даже сделали плацдармом для стажеров, как мы выяснили позже. В итоге, мы получили настоящие нестабильные "макароны" в коде, краши, плохой отклик и т.д. и т.п.
Кстати, если у вас планируется не самый простой по функционалу и нагрузке продукт, то очень не рекомендуем выбирать фреймворк React Native кто бы что ни говорил. Это деньги на ветер. И мы в это вляпались по настоятельной рекомендации разработчиков.
С самого начала разработки я могла неделями лично не мониторить процесс из-за занятости, что и привело меня к ошибке № 4.
Без ежедневного (!) контроля и макимального участия в разработке со стороны фаундера/команды вероятность на выходе получить печальный (и дорогой) результат возрастает в 1 млн раз.
Вот вынесенный опыт:
- Скрупулезно составляйте и проверяйте техническое задание. Девелоперы адаптировали написанное нами ТЗ под свой формат и требования, не детализировав и не проработав наперед многие вещи. Таким образом, были созданы многие фичи, которые вследствие работали некорректно и вообще не имели ничего общего с тем как, что и для чего это все изначально задумывалось. Дабл фейл.
- Требуйте общения с инженерами напрямую, а не только через проджект менеджеров. СТО разработчика должен присутствовать на коллах и объяснять все лично фаундеру, оценивать работы "в моменте" обсуждения. Ну и неплохо было бы предварительно потратить 50 часов на изучение теории по разработке мобильных приложений.
- Разбивайте работы и оплату на маленькие спринты по 30-50 часов разработки. Не платите дальше, пока есть непринятые работы.
- Тестируйте каждый раз сами лично приложение с разных устройств, да так, как будто ваша жизнь зависит от этого.
- Никогда не подписывайте акты приемки работ без 100% уверенности в их качестве. Заставляйте девелоперов исправлять ВСЕ несоответствия и баги, включая верстку по пикселям.
У нас разработка растянулась на 1 год +, тогда как должны были уложиться в 4-5 месяцев. В итоге, мы расстаемся с этой командой и уходим к другой для завершения стабилизации продукта.
Это только в теории кажется, что все легко и быстро, пока сам не попробуешь что-то создать, не выслушаешь 100500 "у вас ничего не получится, слишком сложная ниша и модель" и не набьешь столько же своих шишек.
Я напишу про следущие ошибки нашего стартап-разрушения после того, как выплакаюсь по этим.
Кого заинтересовало, то пост на vc.ru о нашем приложении можно прочитать здесь >>>
Peace 'n' love we want, peace 'n' love we'll get
Есть предположение, что React Native тут был ни при чём. Скорее, всему виной ошибка №3 :)
Может быть, может быть :) Но ни VR ни AR нам на реакт нативе не смогут забомбить, так по крайней мере сказали все.... А вы разбираетесь? Может, проконсультируете немного меня по некоторым нюансам? Пожалуйста? )
Согласен. Если загуглить ТОП апов, сделанных на Реакт полностью или частично, то можно среди них увидеть Скайп, Пинтерест, Инста и т.п.
Твоя самоирония и стиль - это супер! Давай уже весь список ошибок, там явно больше 10 будет))))
на описание всех ошибок мне и жизни не хватит....
У меня были похожие ошибки, только даже более широкий круг) тоже начинал с компании на аутсорсе. Понял, что это полная хрень, если твой продукт это и есть твой стартап. На аутсорс можно отдавать какие то задачи для разработки / внедрения в действующий бизнес. Но не когда нужна разработке апа, на котором и строится весь твой стартап. Пока это понял, просрал 2,5 млн руб и полтора года. Сейчас вся команда внутри проекта. Расходов меньше, скорость выше, и продуктивность и качество разработки в разы выше)
Согласна на все 100%. Надо было искать, но некомпетентность в сфере IT, стартапов и разработки вылилась в хороший поджопник :) В итоге вы нашли идейную команду по разработке и платили им вместо аутсорса?