О мотивации, оптимизации и частых ошибках в работе над стартапом

Некоторое время назад мы говорили с Владимиром Беком о том, что такое быть предпринимателем, как строить свои проекты и как вести их к успеху. Сегодня мы сосредоточимся на типичных ошибках, которые совершают молодые предприниматели, работая над своим стартапом. Кстати, это интервью будет полезно почитать не только тем, кто запускает свой проект, но и тем, кто работает со стартапами.

motivation-optimization-and-common-startups-errors-stoletnyНаш сегодняшний собеседник – Алексей Столетний, Managing Director в Sigma Software Inc. (США). Более 10 лет Алексей работает со стартапами в Америке и Европе, он не понаслышке знает, на какие «грабли» чаще всего наступают стартаперы.

К команде Sigma Software Алексей присоединился, учась на первом куре ХНУРЭ. В течение всех этих лет он занимался разными задачами, сначала был программистом, затем менеджером проектов, в 2010 году стал главой департамента мобильных решений и провел на этой позиции шесть лет. За это время департамент вырос с 15 человек до 65. В 2015 году, с открытием первого офиса Sigma Software в Америке, Алексей переехал в США и занимается развитием американских офисов. Сейчас их уже четыре: в Лос-Анжелесе, Нью Йорке, Сиэтле и Сан Хосе. Почти все заказчики, с которыми он работает сегодня – стартапы.

Алексей, из твоего опыта, на чем чаще всего «обжигаются» стартаперы?

Довольно часто, когда мы начинаем работать с новым стартапом, я задаю вопрос: что, по-вашему, важно для проекта в первые недели и месяцы? И слышу очень разные ответы: получить клиента, придумать крутые фичи, провести анализ рынка, завести знакомства, и еще много чего. Но на самом деле, ваша главная задача в самом начале – проверить свою бизнес идею, понять работает она или нет.

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

А что же нужно делать?

Proof of concept с минимальным набором фич, потратив при этом минимальную часть средств. Нужно постоянно проводить краш-тесты для проекта, чтобы на начальной стадии обнаружить проблемы, с которыми продукт не сможет дальше жить. Если вернуться к вопросу об окнах, то вместо того, чтобы тратить время и деньги на подбор цветов, ручек и других «примочек», выбрав материал вам нужно протестировать как он ведет себя в различных условиях. Если он идет трещинами, значит нужен другой. Попробовали другой, но он выходит слишком дорогим? Значит пробуйте третий. И так пока не найдется идеальный вариант, с которым уже можно работать дальше.

Ваша бизнес модель должна работать на практике, а не в вашей голове. Чтобы это понять, не нужно сразу нагружать продукт всевозможным функционалом. Выберите минимальный. Но при выборе будьте аккуратны. Распространенная ошибка стартапов – выбор ненужных или не тех фич для первого этапа. Ваш функционал, даже минимальный, уже на начальном этапе должен обеспечивать полный цикл. Если вы сделали окна, но не учли, что в них должны стоять стекла – вы не проверите работает ли ваша бизнес модель. Она не будет работать просто потому, что в ней не хватает жизненно важных вещей.

Лучше всего эта идея отображена на диаграмме Minimum Viable Product – создавайте срез всех слоев, вместо того чтобы делать полностью лишь один из них.

Еще одно распространенное заблуждение – «контракты имеет смысл заключать, когда продукт полностью готов». Это не так. Искать клиентов и продавать им продукт нужно сразу. Да, пусть на первых порах его цена будет куда меньше той, которую вы планировали – просто потому, что ваше решение еще не полностью готово. Зато у вас будет возможность на практике проверить как работает ваша идея в реальных условиях, получить фидбек от заказчика и, наконец, получить деньги, которые можно инвестировать в доработку продукта.

Кстати, с монетизацией затягивать тоже не стоит. Нередко приходится слышать: «Запустим сейчас приложение бесплатно, наберем аудиторию, а потом сделаем его платным». Это ошибка. Поверьте, ваша аудитория, привыкнув пользоваться продуктом бесплатно, после не захочет за него платить. А часть пользователей установило приложение только потому, что оно было бесплатным. Важно монетизировать сразу, пусть поначалу и за меньшую стоимость.

И не нужно увлекаться улучшениями и оптимизацией – это совет и для тех, кто владеет стартапом, и для тех, кто со стартапами работает.

Разве оптимизация не пойдет на пользу продукту, не сделает разработку быстрее и дешевле?

Сделает, если подходить к ней взвешенно. Но такой подход видишь не часто.

Если ваша команда мотивирована и чувствует ответственность за продукт, который делает, понятно, что каждому хочется что-то улучшить – в процессах, подходах, в коде и т.д. Но никто не отслеживает и не анализирует: а действительно ли будет лучше, или как в той поговорке: «хотели, как лучше, а получилось, «как всегда». Действительно ли рефакторинг, который предложил разработчик, принесет пользу или от него будет только задержка?

Как это контролировать? Во-первых, провести исследование, определить какие показатели будут важны для бизнеса, какие улучшения на самом деле помогут продукту быстрее развиваться, а какие нет, составить метрики и определить KPIs. Последние должны иметь ценность для продукта и бизнеса. Улучшение в духе: «у нас было 100 строчек кода, а стало 90» — ничего не даст. Ваши действия должны сокращать затраты, время, помогать продавать продукт – тогда на них стоит тратить время, деньги и энергию.

Ты сказал: «если ваша команда мотивирована». А что делать если нет, и почему такое случается? Ведь считается, что наиболее интересные проекты – это как раз стартапы.

Мотивация команды зависит не от проекта, а от того, как выстроена работа. Довольно часто приходится видеть ситуации, когда команда не знает концепцию и не понимает, как будет работать будущий продукт, для кого он и какие проблемы решает. Чтобы восполнить этот пробел, каждый член команды выстраивает свои предположения, которые могут быть далеки от истины. Такие проблемы порождает недостаток общения бизнеса и команды. Иногда приходится наблюдать как разработчиков искусственно «экранируют» от заказчика, оставляя им возможность общаться только с менеджером проекта. При такой работе часть информации обязательно будет теряться, у команды не будет ощущения, что они что-то решают в судьбе продукта, не будет понимания почему принимаются те или иные решения. Команда не будет чувствовать гордость за выполненную работу, и как результат – команда демотивируется.

Будь вы основателем стартапа, Product Owner, проектным менеджером или разработчиком – вы должны быть заинтересованы в том, чтобы наладить эффективное и постоянное общение друг с другом 🙂

Последние новости

Исповедь интервьюера: 5 ошибок, которые отталкивают кандидатов

Собеседование — это двусторонний процесс, успех которого зависит от всех участников: кандидата и интервьюера. Сергей Лысак, Project Manager в Sigma….

Презентовали программу Международный IT менеджмент для студентов ХНЕУ

Представители Sigma Software University выступили с презентацией «Международный IT менеджмент. Возможности с Sigma Software» для студентов Харьковского национального экономического университета….

Захватывающий Python: секрет курса

В прошлом году в Одессе компания Sigma Software подписала договор о партнерстве с Ришельевским лицеем и, как результат, стартовала факультативный….