4 убийцы стартапов: взгляд программиста
Перевели статью программиста Немиля Далала про заблуждения, мифы и иллюзии стартаперов, которые мешают им сделать хороший продукт.
В 2016 году я познакомился с начинающим предпринимателем, который планировал запуск проекта по доставке фермерских продуктов. Мне кажется, он все делал не так. Он был уверен, что «инженеры знают лучше», поэтому полностью положился на разработчика. Тот выбрал среду исходя исключительно из собственных вкусов, без оглядки на то, было это выгодно компании или нет. Большая часть технических работ на раннем этапе велась на аутсорсе. Дорожная карта продукта выглядела оптимистично (веб и мобильное приложение планировалось запустить одновременно) несмотря на то, что большая часть бизнес-процессов еще не была обкатана. Так выглядит рецепт краха.
Разработка в области стартапов отличается от большинства других типов разработки программного обеспечения. Продуктивность в данном случае стоит оценивать в краткосрочной и среднесрочной перспективе. Наиболее ценны люди, которые могут быстро переписывать код и хорошо работать с сырым кодом. Тут нужно выбирать решения прагматично – нельзя просто взять и выбрать самую раскрученную или привычную технологию.
Если ваш стартап еще не нашел подходящей технологической базы, вот четыре ловушки, которых вам следует избегать в ходе поисков.
Непродуманное масштабирование
Самая распространенная ошибка проектирования стартапа – преждевременное масштабирование: имеется в виду планирование крупномасштабной разработки на первом этапе, когда проект еще совсем мал. В таком случае вы ставите слишком далекие цели, выгоды от которых, возможно, никогда не будет.
Проблемы с переоценкой собственного масштаба типичны для стартапов. В начале 2010-х годов стартаперы частично перестали использовать реляционные базы данных из-за предполагаемой бесконечной масштабируемости баз данных NoSQL (таких как MongoDB и Cassandra). В итоге стартапы потеряли свои преимущества перед крупными корпорациями из-за ажиотажа вокруг микросервисов. В течение многих лет Rails называли непригодным лишь потому, что он медленнее, чем другие фреймворки.
Преждевременное масштабирование разрушительно для стартапов, у которых мало денег и мало инженеров, но огромные требования к функционалу и постоянная потребность в корректировании кода.
Почему преждевременное масштабирование происходит так часто, если это ли убийца стартапов номер один?
Во-первых, это весело. Первоначальная версия Twitter представляла собой простое монолитное CRUD-приложение, которое теперь может создать любой сетевой инженер. Всего за несколько лет в сервис обзавелся множеством интересных задач: большие объемы данных для запроса, огромные затраты времени простоя, всплески использования, огромная база пользователей. Добавление масштабируемых технологий для удовлетворения этих потребностей сделало работу разработчиков интереснее и привлекательнее. Ажиотаж сделал раннее масштабирование легкой ловушкой для инженерных команд.
Во-вторых, создание эффективных систем всегда кажется рациональным решением. Некоторые инженеры не любят работать с сырым кодом, это вызывает у них стресс. Отвращение к потенциально неэлегантным решениям особенно актуально для начинающих разработчиков, которые работали в крупных технологических компаниях, где все должно быть сделано «по-крупному». «Делать вещи, которые не масштабируются», – лозунг бизнес-инкубатора Y Combinator, который отлично подходит и для разработки, и для бизнеса.
Отсутствие масштабирования убивает меньше стартапов, чем может показаться: если вы добьетесь успеха, скорее всего, у вас появятся деньги, чтобы исправить все ошибки.
В-третьих, дорожные карты и инструменты придумываются исходя из гипероптимистичных представлений о будущем. Стартап-лидеры представляют идеальные картинки, иначе они не создавали бы компании. Даже тот факт, что продукт встраивается в рынок, не значит, что можно не пересматривать инженерные решения. Опасность состоит в том, что вы можете переоценить уровень масштаба, который вам нужен.
Попытка предвидеть будущие потребности до того, как они возникнут, отнимает ценные ресурсы от вашей непосредственной цели – создания продукта, который нужен людям.
Непроверенные технологии
Стартапы вредят себе, когда слишком сильно полагаются на «блестящие новинки». Новинки привлекают легкостью работы, особенно если ее нужно сделать в короткие сроки. Но полагаться на новейшие технологии непродуктивно в среднесрочной перспективе.
Например, хранилище данных DSL и JSON MongoDB, подобное Javascript, упростило написание кода для разработчиков Javascript по сравнению с использованием реляционных баз данных SQL. То есть простота использования не должна быть основным показателем при выборе базы данных.
Однажды во время собеседования некий инженер-программист сказал мне, что он никогда не будет работать в компании, которая не использует CoffeeScript (сегодня это может быть Elixir). Такая позиция может стать проблемой для компании.
У новых технологий свои проблемы. Уровни отказа новых инструментов плохо изучены, поэтому трудно спрогнозировать, что может пойти не так. Новые языки и фреймворки не имеют библиотек или большого количества специалистов, способных писать на них. Из-за нехватки ресурсов нужно больше усилий для развития, это усложняет подбор персонала. Вы не сможете в полной мере сосредоточиться на создании функций, которые понравятся вашим пользователям.
Частично проблема заключается в том, что инженеры, особенно если они не фаундеры, хотят внедрять технологии, которые делают их востребованными на рынке труда. В таких областях, как интерфейсная разработка, подобная погоня за новинками может означать переписывание кода каждые 6–12 месяцев.
Особенно «блестящие новинки» любят начинающие разработчики. Они еще не видели негативных последствий при выборе новейших инструментов.
Хуже того, разработчики часто не понимают, что раскрученная технология еще не делает ее подходящей средой для запуска. Обычно стартаперы берут технологический стек хорошо известного стартапа или крупной компании и пересаживаются на него, не оценивая целесообразность выбора. Когда команда проекта невелика, у разработчиков нет опытных наставников, они не могут противостоять медиа и манящей рекламе.
Разработчики стартапов часто цитируют известную статью Пола Грэма «Парадокс Python», в которой Python повышает производительность запуска по сравнению с Java. Пост Грэма часто используется для оправдания использования нового языка или фреймворка. Тем не менее, реальная точка зрения Грэма заключалась в том, что разработчики программного обеспечения должны выбирать инструменты, которые максимизируют производительность при запуске, а не рефлекторно отдавать предпочтение новейшей технологии. На самом деле, когда Грэма (на Y Combinator в 2013 году) спросили об идеальных языках, он отметил: «У нас были стартапы, которые писали свой код на PHP – и это меня немного беспокоит. Но не так сильно, как меня беспокоит противоположное».
Инженер рискует, когда присоединяется к стартапу, но он не должен привносить дополнительные риски, связанные с ненужными технологиями.
Найм не того разработчика
Множество проблем у стартапов возникает из-за найма не тех инженеров. Стартапы часто ищут «рок-звезд» или «ниндзя». Им нужны безупречное образование и знания, которые можно получить, работая в успешных компаниях. В Силиконовой долине уже в описаниях вакансий фильтруют кандидатов, использующих новейшие технологии, и упускают прагматичных инженеров, способных быстро освоить необходимые инструменты.
Работе над стартапами мало где учат. Огромное количество программистов работает в первую очередь на крупные компании, т.е. не обладает нужными навыками и умениями. А стартапы в свою очередь вынуждены полагаться на профессионалов, не идеально подходящих для их проектов.
Разные типы разработчиков несут с собой и разные риски:
- Инженеры с опытом работы в крупных компаниях часто сталкиваются с масштабным кодом, но им не комфортно работать с сырым кодом. К тому же они редко напрямую взаимодействуют с пользователями;
- Элита не готова к работе с технологиями в стиле «сантехника», когда нужно решать простые типизированные задачи на ранних этапах запуска, они слишком квалифицированы;
- Джуниор-программисты, которых часто привлекают стартапы, могут внедрить слишком много новейших технологий, что плохо сказывается на архитектуре всей системы;
- Development shops часто предпочитают технологии, которые позволяют им быть продуктивными для многих клиентов, у них нет стимула изучать новые инструменты для конкретного клиента, как нет и долгосрочного интереса к проекту.
Напротив, идеальные начинающие разработчики-стартаперы увлечены миссией компании, это гарантирует, что они останутся на борту, даже когда компания столкнется с трудностями при выводе продукта на рынок.
У них есть минимальная ориентация на продукт и им нравится постоянно менять код. Лучшие стартап-разработчики часто имеют опыт работы в простых проектах с открытым исходным кодом в течение несколько лет и научились за это время обслуживать и поддерживать производительность системы, а не просто создавать ее.
Вместо того, чтобы рассматривать определенные технологии как своего рода «серебряные пули», они предпочитают производительные инструменты, которые отвечают среднесрочным потребностям организации. Лучшие начинающие разработчики видят в технологиях средство решения проблем. Они думают о проблемном пространстве (потребностях пользователей) и о том, как и какое программное обеспечение можно использовать для решения проблемы вместо того, чтобы искать проблему, которую может решить новая технология.
Их отношение к работе можно описать словами «умею-применяю». Они сталкиваются с серьезными вызовами, сдерживая, но не отрицая оптимизм владельцев продукта. Этим инженерам нужна эмпатия и интуиция их пользователей, чтобы учесть их потребности в процессе переписывания кода.
Еще одно предупреждение. Опыт, полученный стартап-разработчиками в разных компаниях, может радикально отличаться. Разработчик, который был успешным в команде из пяти человек, может оказаться провальным в команде из двадцати пяти человек, это тоже нужно учитывать, нанимая человека, который был частью успешного стартапа. Стартапы должны выходить за рамки брендов и нанимать инженеров в зависимости от пригодности для текущего проекта.
Проблемы с продуктом и менеджментом
Еще больше ошибок при запуске связано с самим продуктом и с менеджментом, а не с разработкой.
Основатели стартапов крайне оптимистичные люди. Их представления о продукте обычно превосходят возможности их небольших команд. Этот оптимизм ведет к чрезмерному найму, слишком большому сбору средств и в конечном итоге к выгоранию. Со стороны менеджера ситуация выглядит как «программисты на работают», но фактически это означает, что менеджмент не установил им нужные рамки.
Самоуверенность основателей стартапов передается инженерной команде, которая начинает думать, что точно знает, как должна быть выстроена система, хотя сама бизнес-модель стартапа еще неопределенна. Правильнее будет поддерживать оптимистичных инженеров и пессимистичных бизнес-лидеров, при этом стороны должны сотрудничать, чтобы найти продукт, подходящий рынку.
Другая проблема заключается в том, что руководство часто находит технических консультантов, а именно инженеров в других успешных стартапах. Импорт предполагаемых «экспертов» из потенциально не связанных между собой компаний или сфер приносит лишь дополнительные проблемы.
Наконец, руководство должно понять и признать, что инженеры являются критически важным компонентом любого важного решения относительно продукта. Часто разработчики воспринимаются как сервисная организация, которую можно контролировать, когда возникают важные бизнес-решения. Обеспечение здоровых отношений между разработчиками и продуктовыми менеджерами – еще одна причина, по которой важно найти подходящих сотрудников.