Стартап это гонка за проверкой гипотез. Деньги ограничены, время ограничено, рынок неизвестен, и каждая неделя, потраченная не на проверку главного вопроса «нужно ли это людям», приближает компанию к концу взлётной полосы. В такой обстановке слово «архитектор» звучит почти как ругательство. Зачем нам человек, который будет рисовать схемы и рассуждать о масштабировании, когда у нас нет ни одного платящего клиента?
Я понимаю этот скепсис и частично его разделяю. Я видел стартапы, которые погибли от архитектуры: полгода строили идеальную систему на микросервисах, а когда вышли на рынок, оказалось, что продукт никому не нужен в таком виде. Но я видел и обратное: стартапы, которые нашли свой рынок, начали расти, а потом застряли на год, потому что систему, слепленную на скорую руку, невозможно было развивать. Так нужен ли архитектор? Да. Но его роль в стартапе совсем другая.
Не звездолёт, а взлётная полоса
Есть соблазн, которому поддаются многие технические основатели: строить звездолёт. Систему, рассчитанную на миллионы пользователей, с идеальной архитектурой, на модных технологиях. Это приятно, это интеллектуально интересно, и это почти всегда убийственно для стартапа. Звездолёт долго строится и дорого стоит, а лететь пока некуда.
Задача архитектора в стартапе не строить звездолёт, а обеспечить взлётную полосу. Сделать так, чтобы маленький лёгкий самолёт (MVP) взлетел как можно быстрее, а если полёт пойдёт удачно, его можно было бы дорабатывать, не разбирая до винтика. Это совершенно другое мышление: не «как сделать идеально», а «как сделать достаточно хорошо, чтобы не закрыть себе дорогу в будущее».
Адаптивность: готовность к развороту
Почти каждый успешный стартап хотя бы раз резко менял направление. Продукт, задуманный для одних клиентов, оказывался нужен другим. Функция, которую считали второстепенной, становилась главной. В английском для этого есть слово pivot, разворот.
Хорошая архитектура стартапа строится так, чтобы разворот бизнеса не требовал переписывания девяноста процентов кода. Это не значит предусмотреть все варианты, это невозможно. Это значит держать систему простой, модульной и с чётко отделённым ядром. Если логика работы с клиентами, оплатами и данными отделена от конкретного интерфейса и конкретного сценария, то при развороте меняется надстройка, а фундамент остаётся.
Я сравниваю это с палаткой и домом. Палатку можно быстро поставить и быстро перенести на другое место, если стоянка оказалась неудачной. Дом надёжнее, но перенести его нельзя. На ранней стадии стартапу нужна хорошая палатка: лёгкая, но не протекающая при первом дожде. Задача архитектора отличить палатку от шалаша, который рухнет от ветра.
Технологическая гигиена
Вторая важная задача архитектора на старте почти незаметна, но её цена проявляется через год. Это выбор инструментов. Язык программирования, фреймворк, база данных, хостинг.
Правило простое: выбирайте скучные, распространённые технологии. Те, на которых пишут тысячи программистов, у которых большое сообщество, хорошая документация и понятные решения типовых проблем. Экзотический язык может быть элегантнее, но когда через полгода Вам понадобится срочно нанять трёх разработчиков, Вы найдёте их за неделю на популярной технологии и за три месяца на экзотической. А три месяца для стартапа это вечность.
Сюда же относятся вещи, которые кажутся мелочами: система контроля версий, автоматическое развёртывание, резервные копии базы, хотя бы минимальные тесты на критичные сценарии вроде оплаты. Это как мыть руки: занимает минуту и спасает от болезней, которые потом лечить очень дорого.
Архитектор как переводчик
Есть ещё одна роль архитектора в стартапе, о которой редко говорят. Он переводчик между бизнесом и технологиями. Основатель приходит с идеей, а архитектор помогает понять, какая часть этой идеи технически дешёвая, а какая дорогая. Часто оказывается, что восемьдесят процентов ценности можно получить за двадцать процентов усилий, если немного изменить формулировку.
Клиент однажды попросил нас сделать в MVP сложную систему рекомендаций с машинным обучением. Мы спросили, какую гипотезу он хочет проверить. Оказалось, что вопрос в том, будут ли люди вообще пользоваться рекомендациями. Для этого хватило ручного списка «популярное на этой неделе», который менеджер обновлял раз в день. Гипотеза проверилась за пару недель вместо нескольких месяцев. Рекомендации, кстати, людям понравились, и машинное обучение появилось уже во второй версии, на реальных данных.
Когда архитектор не нужен
Если Вы проверяете спрос лендингом, ручными продажами или прототипом на конструкторе, отдельный архитектор не нужен. Он понадобится, когда Вы начнёте писать код, который планируете развивать дальше, а не выбросить. На этом этапе даже несколько часов консультации опытного архитектора могут сэкономить месяцы.
В небольшом стартапе роль архитектора часто выполняет технический сооснователь или CTO. Это нормально, если у него есть опыт и он умеет сдерживать себя от строительства звездолётов.
Что делаем мы
Мы в Ingello Systems часто работаем со стартапами именно на этом этапе. Наш подход: быстро описать модель предметной области, сгенерировать на Fractal работающий прототип с нормальной структурой данных, и уже на нём проверять гипотезы. Получается та самая взлётная полоса: прототип появляется за дни, а не месяцы, но под ним правильный фундамент, на котором можно строить дальше, если полёт удался.
Если Вы основатель стартапа, задайте себе вопрос: что произойдёт с Вашей системой, если завтра Вы решите поменять целевого клиента? Если ответ «придётся всё переписывать», Вам нужен архитектор. Не для звездолёта, а для полосы.
