[Из песочницы] Стоит ли бизнес кофаундеру IT-стартапа учиться программировать?
Далеким летом 2014 года мой ответ на этот вопрос был утвердительным. Это точно изменило мою жизнь. А вот в какую сторону — вопрос открытый. В любом случае я с радостью (и болью) делюсь выстраданными и вычитанными мыслями и личным опытом.Если вы бизнес-кофаундер IT-стартапа ранней стадии или технический ко-фаундер, который думает о том, чем бы занять команду окружающих его бездельников, пока сам он пилит продукт, эта статья для вас.
Конечно, если бизнес-кофаундер научился программировать лет в 14–16 и его опыт в разработке немногим меньше, чем у его технического партнера, это почти идеальный вариант. Почти, потому что у такого расклада сил тоже есть свои минусы (можно сразу удариться в разработку продукта безо всякого изучения рынка), но по крайней мере вопрос, учиться программировать или нет, в таком случае вообще не стоит.
Но что делать, если в вашей команде программист один и вам кажется, что до запуска продукта других значимых задач, кроме разработки, нет, потому что продавать вроде бы еще нечего и пользователей привлекать некуда? Спойлер: это вам только так кажется.
Моя история
В 2014 году наша команда из 4 человек (4 кофаундера, из которых только один был разработчиком) работала над сайтом для подготовки к ЕГЭ bitclass.ru. Все шло относительно хорошо, но к концу учебного года нам показалось неинтересным делать сайт, на котором, пусть и в интерактивной форме и с геймификацией, мы просто публикуем задачи. Мы затеяли довольно радикальный пивот. Эта история еще не закончилась, и о том, что получилось в результате, я еще напишу (получилась lampa.io — социальная образовательная платформа, где публиковать учебные материалы может не только наша редакция, но и все желающие). Так вот, во время этого пивота у меня сложилось (ошибочное) впечатление, что единственный ценный на данный момент вклад, который можно сделать в общее дело, — это программирование. Я испытывала жгучую зависть к нашему единственному разработчику, глядя на множество цветных букв на его черном экране. Он один был занят настоящим делом.
После двух или даже трех месяцев непозволительно расслабленной для wannabe стартапера жизни и одного онлайн-курса по основам программирования я случайно зашла на сайт одной очной школы разработчиков, прочитала описание концепции и подумала, что по-настоящему научиться программировать — хорошая идея. Потом я выбрала самый интенсивный и хардкорный курс по JavaScript + Node.js, который смогла найти, и с головой погрузилась в программирование на 3–3.5 месяца. Это было замечательное время, и программировать почти без выходных (официально 6 дней в неделю по 11 часов в день + еще часов 3–5 после занятий), с перерывами только на сон и еду, в компании людей, которые проходят через тот же опыт, было очень здорово. С одной стороны, мы много работали. С другой стороны, после года работы над собственно стартапом, в котором основной трудностью была постоянная неопределенность, такая структурированная жизнь воспринималось как отпуск. 80–90% моих соучеников стали работать программистами, причем даже не junior«ами.
В результате программировать я научилась, а вот развитие нашего стартапа это сильно замедлило.
С тех пор прошло достаточно много времени, чтобы осмыслить свой опыт и сформулировать плюсы и минусы того, чтобы нетехнический бизнес-кофаундер учился программированию.
Плюсы и минусы
Начнем с плюсов:
- Ваш стартап станет непотопляемым — в самом крайнем и худшем случае ваш burn rate (сумма денег, которую стартап тратит за определенный период времени) может стать равным тратам на жизнь одного человека (в этом, впрочем, есть и минус — можно заниматься бесперспективным проектом годами и потратить на это лучшее время жизни); даже если ваша команда почему-то развалится, стартап сможет это пережить.
- На старте вы можете двигаться быстрее, если в команде появляется еще один программист; хотя с учетом вашей неопытности за полноценную боевую единицу вас поначалу считать будет нельзя; на более поздних стадиях это не имеет большого значения, потому что вы сможете найти еще одного или нескольких программистов на зарплату.
- Не будет мучительного периода, когда продукт еще не готов, а остальным членам команды вроде бы нечего делать. Что приводит к сомнениям, брожению умов и депрессивным настроениям. Главное — помните: то, что вам нечего делать, — полнейшая иллюзия и оправдание своей лени или неуверенности.
- Это, пожалуй, самый главный плюс: даже как бизнес-кофаундер, выполняя вполне себе бизнес-функции, вы становитесь намного более эффективными. Есть тысяча мелочей, для быстрого выполнения которых нужны технические навыки: быстрая публикация нового контента на сайте, добавление JavaScript целей в Яндекс-Метрике, выгрузка данных из базы, тестирование нового value proposition на лендинге. Каждое из этих действий — это даже не программирование, иногда это пара строчек кода, но без технических навыков самостоятельно с ними не справиться. Надо хотя бы знать, куда залезть, чтобы эту пару строчек кода написать. А значит, без технических навыков вы будете двигаться медленнее, чем могли бы.
- Вы сможете оценить, сколько времени занимает какая работа, а значит, сможете лучше планировать и приоритизировать разные задачи. До своего погружения в программирование иногда я даже не высказывала какие-то предложения, заранее предполагая, что делать это долго и сложно, хотя на самом деле их внедрение заняло бы от силы час.
- Когда заканчиваются аргументы, можно быстро что-то сделать самому. Да, в команде должен быть консенсус, но если вы очень верите в какую-то фичу, а кофаундера убедить никак не можете, в крайнем случае можно быстро ее внедрить и проверить результат. А если не пойдет — без проблем убрать.
Но минусы перевешивают:
- Начнем с очевидного. За то время, которое нужно, чтобы по-настоящему научиться программировать, можно сделать много всего полезного. Об этом ниже. В самом крайнем случае можно заработать денег, которые пойдут на зарплату недостающего программиста.
- Желание научиться программировать, то есть все делать самому, может быть признаком неумения или нежелания делегировать и мотивировать или неуверенности в идее.
- У вас появляется дополнительный стимул к тому, чтобы работать много, вместо того, чтобы работать с умом (привычнее в формулировке work hard, not smart). Если считать, что мать изобретений — необходимость, то у ваших потенциальных изобретений будет меньше шансов родиться. У вас больше не будет необходимости придумывать быстрые эксперименты. Зачем делать что-то быстрое и сырое, если можно сразу сделать красиво и правильно? Кстати, такая же ловушка подстерегает и те команды, где все фаундеры изначально программисты.
- Если программировать вам понравится (а это кажется необходимым условием для того, чтобы это вообще получалось), то вам захочется программировать все время; все остальные направления деятельности стартапа, например customer development или маркетинг, будут от этого сильно страдать; программировать очень приятно психологически: вы создаете продукт, в конце дня появляется осязаемый результат и при этом никто вам не говорит, что-то, что вы сделали, абсолютно никому не нужно. Если же вы общаетесь с потенциальными пользователями или даже просто исследуете рынок, то с большой вероятностью постоянно получаете плохие новости.
- Понимание технической стороны вопроса ограничивает полет вашей фантазии. Если вы знаете, что какую-то фичу предстоит внедрять вам, то вы с большой вероятностью придумаете какой-то ее вариант, который проще в разработке, а не лучше для пользователей. И это не всегда эффективно: да, вы потратите на разработку на день меньше, но потеря, например, конверсии за счет неоптимального для пользователей решения может перекрыть всю экономию времени.
Чем себя занять
Так что же делать нетехническим фаундерам в смутное время, когда MVP не готов? Вариантов множество, а некоторые дела и просто лежат на вашем «критическом пути».
- Совершенно очевидно, что можно работать над разными параллельными разработке задачами. В нашем проекте как раз с этим все было просто. Так как продукт состоит из технологии и контента, логично было заниматься созданием контента.
- Во многих случаях customer development можно начинать до появления MVP. Можно проводить интервью с целевой аудиторией не для того, чтобы дать им попробовать ваш продукт, а чтобы понять, чем живут ваши пользователи, как этот рынок работает сейчас без вас и какие у пользователей проблемы (почти точно в этом месте я цитирую чей-то чужой пересказ книги Lean Startup). Интервью должно быть много. И их результаты должны определять, что же, собственно, вы разрабатываете, или хотя бы влиять на это.
- Можно сделать прототип основных интерфейсов (в идеале «живой» — с активными зонами) и заниматься его тестированием c потенциальными пользователями. Плюсы от этого шага кажутся очевидными, но почему-то на своих проектах мы упорно этого не делаем. Подозреваю, что такую же ошибку допускают и другие команды, в которых нет дизайнера. Важно создать и протестировать прототип не столько потому, что так вы сразу улучшаете usability, сколько ради того, чтобы лучше продумать весь продукт от начала до конца, а также лишний раз пообщаться с пользователями и оценить их реакцию на то, что вы делаете.
- Можно проверять, насколько ваша идея интересна целевой аудитории, рассказывая о ней в тематических пабликах в социальных сетях. Можно начинать вести свой блог. Так вы можете нарастить аудиторию еще до запуска продукта. А если вас никто не читает, встает вопрос о том, нужно ли кому-то то, что вы делаете.
Резюме
Вывод здесь такой: если вы бизнес-кофаундер стартапа и думаете о том, чтобы пойти учиться программировать, то, скорее всего, вам не стоит этого делать.
