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

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

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, проектным менеджером или разработчиком – вы должны быть заинтересованы в том, чтобы наладить эффективное и постоянное общение друг с другом 🙂

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

Підтримка дуального навчання та співпраця із ХНЕУ ім. С. Кузнеця

Компанія Sigma Software та ХНЕУ ім. С. Кузнеця укладуть угоду про підготовку магістрів за напрямком «Міжнародний ІТ менеджмент». Про це….

Интервью с выпускником курса Sigma Software University

Сегодня, когда стать ИТ специалистом мечтают многие, когда индустрия растет, открывая новые перспективы, рынок предлагает множество различных курсов и тренингов….

Яркие идеи хакатона Smart City & IoT

Sigma Software University выступил генеральным партнером хакатона «Smart City & IoT 2018», который прошел 16-18 ноября в ХНУ им. В. Н. Каразина. В соревновании приняло участие более….