Я часто общаюсь с техническими специалистами, которые уже основали стартап или только собираются это сделать. Считается, что такой сценарий идеален для программиста. На самом деле ожидания не всегда совпадают с реальностью.
Я расскажу, как выглядит работа СТО и co-founder’а изнутри. Надеюсь, кому-то из молодых технических директоров мой опыт поможет не совершить старых ошибок — ведь грабли, на которые наступают люди с техническим складом ума, обычно весьма похожи.
Личное дело: нужен ли программисту стартап
Итак, прежде чем запускать собственный стартап, в первую очередь, стоит вспомнить о систематической ошибке выжившего — survivorship bias. Суть survivorship bias заключается в том, что мы получаем много информации о группе «выживших» и почти никакой информации — о «погибших». В
Все истории успеха стартапов, которые мы слышим, — это капля в море историй с совершенно иной концовкой. Есть сотни тысяч тех, кто не выжили. Если забыть о них, можно неправильно рассчитать свои силы и почти гарантированно оказаться за бортом.
Когда мы в 2015 году попали в акселератор TechStars Berlin, нам на первой же презентации привели статистику по проблемам, о которых не пишут специализированные СМИ. Стартап может столкнуться с депрессией или семейными проблемами фаундеров, тюремным заключением, алкоголизмом и кучей других сложностей. Все ситуации — реальные случаи, и это только малая часть.
Запуск стартапа — сложная и рискованная затея. Нужно с самого начала разобраться, зачем вам все это. Быстро заработать денег? Тогда вам не сюда, вам в аутсорс или эмиграцию. В стартапе первые несколько лет денег точно не будет. Нам порой на зарплаты не хватало, так что нужна другая мотивация.
Хочется побыть крутым начальником? Тоже не сюда, потому что на первых порах СТО может самостоятельно заниматься переустановкой ОС, настройкой корпоративной почты или sip call-центра. Рутинные задачи придется выполнять всем.
Но если осознавать все риски и брать на себя ответственность, то результат того стоит. Стартап — это значительный уровень свободы творчества, это гордость за результат. Вера в проект и радость от создания собственного полезного продукта — вот те вещи, которые помогают держаться в сложных ситуациях и отказываться от джоб-офферов, зарплата в которых на порядок выше нынешней.
Начало работы: как принять правильные решения на старте
Начальные этапы работы и первые принимаемые решения — одни из самых важных для СТО в стартапе. Первые шаги — это выбор фреймворка, языка программирования и технологического стека, на котором будет создаваться проект.
На этом этапе часто возникает вопрос или даже дискуссия: писать ли проект на том, что уже знаешь, или взяться за новую технологию? Конечно, первый вариант быстрее, зато второй — интереснее с точки зрения профессионального роста. Мне приходилось работать в обоих вариантах (в свое время осваивал Groovy в таких условиях).
Но «интересно» — не тот параметр, который решает все. Чтобы построить успешный бизнес, логичнее спросить себя:
- Смогу ли я на той технологии, которой уже владею, построить архитектуру для масштабируемого проекта?
- Смогу ли я на этапе роста стартапа, нагрузок и команды оптимизировать, переписать или эффективно поддерживать проект на этой технологии?
Если ответ положительный, мой совет таков: пишите на том, что уже знаете. Удовлетворить потребность в профессиональном росте еще успеете, например — за счет полиглотной микросервисной архитектуры.
В нашем случае основной проект на Python дополнялся функционалом на Java, JS. Коммуникации с основным проектом осуществлялись через RabbitMQ. К слову, рекомендую книгу Сэма Ньюмана о построении микросервисов, можно бесплатно получить по ссылке.
С самого начала важно взять хороший фреймворк под свой язык программирования, ибо при написании проекта с нуля набор задач в целом похож, и большую часть из них уже решили. Scaffolding, сообщество разработчиков, хороший набор библиотек (желательно с большим количеством звезд на GitHub) — вот те вещи, на которые стоит обращать самое пристальное внимание.
Быстродействие фреймворка и самого языка программирования уже не слишком значимы, хотя несколько лет назад это было крайне важно. Исключение — проекты, где быстродействие лежит в основе успеха.
Релиз MVP и выбор фич проекта
На начальном этапе главная задача — релиз MVP. Советую быстро писать хороший код и при этом не забывать о коммуникации с коллегами, отвечающими за бизнес-составляющую проекта. Очень важно, чтобы бизнес-часть команды занималась «продажами» еще до релиза.
Если этого не происходит, если «бизнес» ждет неделями или месяцами, пока СТО с девелоперами напишут код, то это «красный флаг», что в команде есть проблема. В нашем случае было так: мы писали MVP, имея только простейший лендинг, на который приходили заявки. И Кирилл Бигай, наш СЕО, садился и вручную обзванивал потенциальных клиентов, продавал продукт.
Второй важный момент — определение фич проекта. Бизнес-части всегда нужно будет больше фич на каком-то временном отрезке, чем их вообще возможно зарелизить. Приходится выбирать. Поскольку денег и времени у стартапа мало, а заказчики и исполнители — это одни и те же люди, нужно понять, какие конкретно метрики нужны проекту и какие фичи могут помочь в достижении целей по этим метрикам.
Для технологических компаний, нацеленных на exit через приобретение, важно писать фичи, которые вписываются в данную стратегию. Если это компания, которая не монетизируется, важен user base, проектам на локальном рынке важен заработок с первого дня.
Выбранные фичи нужно правильно оценить. Недооценка времени на реализацию — сознательная или несознательная — типичная ошибка.
По опыту могу сказать, что затягивание сроков — негативный сценарий. Если не получается уложиться, лучше, как говорится, флексить скуп фичи — изменить объем функционала так, чтобы не выбиваться из графика. Все, что не успеется до дедлайна, переносится в следующую итерацию разработки.
При этом от накопления «технического долга» все равно никуда не денешься. Но нужно следить, чтобы на начальных этапах не было критических ошибок в архитектуре. Рекомендую общаться с хорошо подкованным ментором или поддерживать связь с СТО других проектов, которые уже прошли данный этап и могут дать совет.
Мне помогли регулярные встречи с другими СТО, митапы, хакатоны и другие ивенты. Напомню, что нельзя забывать о принципе give first: необходимо поддерживать коллег с меньшим опытом, когда у них возникают вопросы — так выстраивается сообщество.
Сообщество поможет и в том, что касается баз данных. На ранних этапах стоит регулярно разговаривать на эту тему с коллегами, которые писали похожие продукты. Плохо подобранная схема данных — это необходимость миграции данных и схем в будущем, что сложно назвать приятным моментом.
У нас, к примеру, неправильно подобранный способ сохранения сумм в разных валютах «аукнулся» дополнительными задачами в процессе масштабирования на другие рынки. У коллег из дружественного проекта до сих пор дают о себе знать проблемы с данными, которые содержатся в MongoDB, потому как NoSql — не панацея от проблем со схемой, если продукт получает определенную степень связности.
Этап роста: что нужно и чего не нужно делать разработчикам
Как только вашим продуктом начнет пользоваться постоянно растущая аудитория, обязательно возникнет вопрос о том, способен ли проект выдерживать растущие нагрузки. Вспомним слова Дональда Кнута: «Premature optimization is the root of all evil». Нужно дважды подумать, существует ли для вас подобная проблема.
Общее правило сводится к тому, что коды переписываются заново при росте нагрузок на порядок. При линейном росте часто оказывается эффективнее решать вопрос за счет вертикального масштабирования и баз данных.
На этом этапе, если вы хотите действительно развиваться профессионально, рекомендую перенаправить на других людей все процессы, которые могут отвлечь команду разработчиков и не относятся непосредственно к разработке.
Вот примеры задач, которыми не должны заниматься девелоперы:
- Локализация продукта. Стартапы из СНГ в большинстве случаев «обречены» выходить на глобальный рынок, потому что делать продукты исключительно для локального рынка экономически нецелесообразно. И я часто замечал, что коллеги из других проектов регулярно просят изменить какой-то текст, потому что нашлась ошибка локализации или были загружены новые тексты на сайт. Базовая имплементация continuous localization — вот что нужно, чтобы больше никогда не тратить время программистов на рутинные задачи по обновлению переводов.
- Поддержка пользователей. Да, на первых порах приходится заниматься этим самостоятельно, но когда количество обращений все растет и растет, приходит время набирать команду в саппорт. В нашем случае именно специалист отдела поддержки был первым человеком, который присоединился к команде, и это оказалось одним из наиболее верных кадровых решений. Хочу уточнить, что поддержкой все равно придется заниматься, за все баги будете отвечать вы, но можно будет забыть хотя бы о рутинных задачах — вроде выяснения версии браузера или предложения почистить cookies.
- Маркетинг. Вынесите редактирование целевых страниц в административную часть сайта и настройте инструменты, которые позволят снять маркетинговую работу с программистов: например, Google Tag Manager.
- Статистика. В стартапах часто пытаются писать внутреннюю систему статистики. Мы тоже этим переболели. Это крайне неэффективное использование ресурсов, потому как предугадать все метрики и срезы невозможно. Лучше делать выгрузку всех серых данных в программы бизнес-аналитики.
- Админка. Настройте права на редактирование нужных моделей для остальной части команды. Особенно хорошо, если ваш фреймворк поддерживает scaffolding.
Целесообразность административных задач
Нужно принимать решение, хотите ли вы развивать в себе компетенции DevOps. Часто можно отказаться от части технического администрирования проекта, воспользовавшись какой-либо системой PaaS или привлекая в команду соответствующих специалистов. Но иногда, в силу технических особенностей, нужно иметь более глубокий опыт в инфраструктуре.
В нашем случае важен контроль на каждом этапе, поэтому пришлось в процессе научиться настраивать Nginx и VPN, разворачивать Docker на серверах и заниматься другими, совсем не программерскими вопросами. Это хорошая возможность повысить конкретные компетенции и лучше понять современные технологии, но такие задачи требуют времени.
Опять-таки, общайтесь со специалистами, которые делали то же самое до вас, просите совета. Добавлю, что почти все IaaS-платформы имеют специальные программы для стартапов — с живой поддержкой и консультацией по использованию продуктов. Например, мы по приглашению Amazon ходили на конференцию в Берлине, где был трек для стартапов. Практически за день мы прошли экспресс-курс по эффективному использованию их сервисов.
Писать ли тесты и когда это делать
Проверяйте чек-лист Джоэла Спольски, закрывайте вещи, которые еще не имплементированы. Дискуссия допускается в тех пунктах, которые касаются тестов и документации. Стартапы — это скорость, и написание тестов может значительно замедлить разработку продукта.
Иногда эти затраты окупаются, иногда — нет. В некоторых случаях лучше отказаться от идеи покрыть продукт хрупкими тестами на 100%, но потом при каждой итерации вносить необходимые правки. А вот действительно критические части продукта нужно покрыть стойкими тестами и компромиссно закрывать те вещи, которые не будут переписываться.
Мы довольно-таки регулярно что-то дописываем и переписываем, и я не фанат TDD. Моя логика не в том, что нужно 100% покрытие, а в том, что тесты нужно писать в определенный момент времени, когда на это есть ресурсы.
Особенно важно начать писать больше тестов в тот момент, когда к команде присоединяются новые люди. В процессе знакомства с продуктом они вполне могут писать код, который что-то ломает. Тесты — эффективный инструмент на уровне с код ревью, который помогает локализовать подобные проблемы.
От стартапа к бизнесу: ответы на нетехнические вопросы
Знакомые регулярно спрашивают: «Сколько вы еще будете оставаться стартапом? Вам уже три/четыре/пять лет, а вы до сих пор пиаритесь». Все просто: пока гипотетический уход одного из фаундеров несет в себе риск закрытия проекта, мы стартап.
Но в какой-то момент необходимо превращать стартап в бизнес. На практике это означает прикрыть все основные системные риски, связанные с людьми.
Бизнес должен работать независимо от того, кто занимается операционной деятельностью. Все процессы в команде должны быть автоматизированы и задокументированы так, чтобы основной ценностью проекта стали процессы и активы, а не только команда основателей. СТО должен собрать в своей команде людей, которым интересно работать над проектом с технической точки зрения.
Роль СТО на этом этапе заключается в том, чтобы отстроить команду, организовать в ней правильные процессы и постоянно профессионально развивать. На код на этом этапе остается мало времени, к сожалению. Ключевой функцией становится работа с людьми.
Как мотивировать команду разработчиков
Я думаю, основная мотивация хорошей команды программистов — сложные и интересные задачи. Мотивация должна иметь поддержку в виде адекватной зарплаты, но цифры могут быть и ниже медианы по рынку.
В такой ситуации отсекаются люди, которые приходят работать ради денег, а не ради продукта. В западной практике часто команде программистов выделяется часть компании через option pool — право выкупа акций по минимальной стоимости в момент, когда стартап становится успешным. У нас, к сожалению, этот инструмент пока не пользуется особой популярностью, потому что у нас не так-то много знаковых историй успеха.
Для сравнения возьмем «PayPal-мафию». Сообщество бывших работников PayPal, в числе которых не только фаундеры, на свои акции option pool создали немало успешных бизнесов и стали миллионерами.
Есть и другие «мафии», менее известные. Например, в Берлине мы познакомились с бывшими сотрудниками ZenDesk и DeliveryHero, которые тоже инвестируют и запускают собственные проекты за счет акций option pool. Еще один пример, географически более близкий — польский сервис niania.pl, который предназначен для поиска нянь. Выходцы из этого проекта пару лет назад развернули активную инвестиционную деятельность в Восточной Европе, основав несколько успешных бизнесов.
СТО должен рассказывать своей команде такие истории, объяснять этот инструмент. Ощущение владения продуктом, а тем более — юридически закрепленное, это идеальная мотивация для команды. Нужно его вводить, и чем больше будет историй успеха, тем популярнее станет такой подход.
Автоматизация и безопасность на этапе перехода
Кроме сложных и интересных задач, у программистов всегда будет рутина. На этапе перехода от стартапа к зрелому бизнесу нужно максимально автоматизировать все задачи по разработке.
Важно сделать хорошую внутреннюю базу знаний, так новые люди смогут легко войти в курс дела. Процессы разработки нужно лучше документировать, тестирование продукта становится важным и неизбежным процессом.
Если раньше one-click-deployment уже было хорошо, то теперь необходимо больше смотреть в сторону практик immutable deployment. Аварийные состояния могут быть не особо критичны для стартапа, а вот для «взрослого» бизнеса они более болезненны.
Еще один ключевой процесс на этапе перехода — обеспечение безопасности проекта, начиная от администрирования прав команды, защиты от DDoS-атак, заканчивая уязвимостью кода. Стойкий фундамент, построенный на предыдущих этапах, поможет легче решать подобные проблемы. Как вариант, можно привлекать внешний аудит безопасности.
Вместо итога — резюме в четырех пунктах
- Работа в роли СТО в стартапе — невероятно интересный опыт, позволяющий пройти весь путь разработки продукта и превратить свое умение программировать в бизнес. Более того, вы будете свободны в выборе технологий и путей решения проблем. Но это требует и ответственности за выбор. Профессиональный рост происходит очень быстро, но и нагрузки соответствующие.
- Собственный стартап — это не про деньги. Процитирую нашего инвестора Семена Дукача: «Стартап — не лучший метод, чтобы заработать денег, лучше научитесь программировать и идите работать в аутсорсинговую компанию, там вас ждет материальный успех». Он говорил об украинских стартапах, но то же справедливо в какой-то степени для любой другой страны, а для СНГ — так точно.
- Задача СТО — писать не идеальный код, а тот, что поможет реализовать бизнес-идею. В процессе работы придется не только программировать. Но хорошие инженерные практики и развитие команды будут сильным конкурентным преимуществом — и это то, на что СТО имеет существенное влияние.
- Важно быть в курсе современных технологий и по возможности внедрять их в проект. Но нужно в первую очередь делать минимальный анализ cost/benefit с точки зрения бизнеса. Мы в свое время рассматривали возможность миграции с Backbone на Angular, но временные затраты были несравнимо больше тех «плюшек», которые можно было получить. С другой стороны, мы анализировали переезд с self-hosted PostGreSQL на Amazon RDB, и это требовало значительных затрат времени, но выигрыш от новой технологии при масштабировании был существенно выше.
Подводя черту под всем сказанным, скажу одно: позиция CTO в стартапе — невероятный опыт. Работать было интересно и до того, как Preply наконец «выстрелил», а путь этот занял не один год. Думаю, именно поэтому у нас получилось: мы делали то, во что верили, а не просто стремились заработать. Только у тех, кто горит заявленной идеей, есть шансы добиться собственных целей.
