Стартап це перегони з перевірки гіпотез. Гроші обмежені, час обмежений, ринок невідомий, і кожен тиждень, витрачений не на перевірку головного питання «чи потрібне це людям», наближає компанію до кінця злітної смуги. У такій обстановці слово «архітектор» звучить майже як лайка. Навіщо нам людина, яка малюватиме схеми й міркуватиме про масштабування, коли в нас немає жодного клієнта, що платить?
Я розумію цей скепсис і частково його поділяю. Я бачив стартапи, які загинули від архітектури: пів року будували ідеальну систему на мікросервісах, а коли вийшли на ринок, виявилося, що продукт у такому вигляді нікому не потрібен. Але бачив і протилежне: стартапи, які знайшли свій ринок, почали рости, а потім застрягли на рік, бо систему, зліплену нашвидкуруч, неможливо було розвивати. То чи потрібен архітектор? Так. Але його роль у стартапі зовсім інша.
Не зореліт, а злітна смуга
Є спокуса, якій піддається багато технічних засновників: будувати зореліт. Систему, розраховану на мільйони користувачів, з ідеальною архітектурою, на модних технологіях. Це приємно, це інтелектуально цікаво, і це майже завжди вбивчо для стартапу. Зореліт довго будується й дорого коштує, а летіти поки нікуди.
Завдання архітектора в стартапі не будувати зореліт, а забезпечити злітну смугу. Зробити так, щоб маленький легкий літак (MVP) злетів якомога швидше, а якщо політ піде вдало, його можна було б доопрацьовувати, не розбираючи до гвинтика. Це зовсім інше мислення: не «як зробити ідеально», а «як зробити досить добре, щоб не закрити собі дорогу в майбутнє».
Адаптивність: готовність до розвороту
Майже кожен успішний стартап хоча б раз різко змінював напрям. Продукт, задуманий для одних клієнтів, виявлявся потрібним іншим. Функція, яку вважали другорядною, ставала головною. В англійській для цього є слово pivot, розворот.
Добра архітектура стартапу будується так, щоб розворот бізнесу не вимагав переписування девʼяноста відсотків коду. Це не означає передбачити всі варіанти, це неможливо. Це означає тримати систему простою, модульною і з чітко відокремленим ядром. Якщо логіка роботи з клієнтами, оплатами й даними відокремлена від конкретного інтерфейсу та конкретного сценарію, то під час розвороту змінюється надбудова, а фундамент лишається.
Я порівнюю це з наметом і будинком. Намет можна швидко поставити й швидко перенести на інше місце, якщо стоянка виявилася невдалою. Будинок надійніший, але перенести його не можна. На ранній стадії стартапу потрібен добрий намет: легкий, але такий, що не протікає за першого дощу. Завдання архітектора відрізнити намет від куреня, який упаде від вітру.
Технологічна гігієна
Друге важливе завдання архітектора на старті майже непомітне, але його ціна проявляється за рік. Це вибір інструментів. Мова програмування, фреймворк, база даних, хостинг.
Правило просте: обирайте нудні, поширені технології. Ті, якими пишуть тисячі програмістів, у яких велика спільнота, добра документація й зрозумілі розвʼязання типових проблем. Екзотична мова може бути елегантнішою, але коли за пів року Вам знадобиться терміново найняти трьох розробників, Ви знайдете їх за тиждень на популярній технології й за три місяці на екзотичній. А три місяці для стартапу це вічність.
Сюди ж належать речі, які здаються дрібницями: система контролю версій, автоматичне розгортання, резервні копії бази, хоча б мінімальні тести на критичні сценарії на кшталт оплати. Це як мити руки: займає хвилину й рятує від хвороб, які потім дуже дорого лікувати.
Архітектор як перекладач
Є ще одна роль архітектора в стартапі, про яку рідко говорять. Він перекладач між бізнесом і технологіями. Засновник приходить з ідеєю, а архітектор допомагає зрозуміти, яка частина цієї ідеї технічно дешева, а яка дорога. Часто виявляється, що вісімдесят відсотків цінності можна отримати за двадцять відсотків зусиль, якщо трохи змінити формулювання.
Клієнт якось попросив нас зробити в MVP складну систему рекомендацій із машинним навчанням. Ми спитали, яку гіпотезу він хоче перевірити. Виявилося, що питання в тому, чи користуватимуться люди рекомендаціями взагалі. Для цього вистачило ручного списку «популярне цього тижня», який менеджер оновлював раз на день. Гіпотеза перевірилася за кілька тижнів замість кількох місяців. Рекомендації, до речі, людям сподобалися, і машинне навчання зʼявилося вже в другій версії, на реальних даних.
Коли архітектор не потрібен
Якщо Ви перевіряєте попит лендингом, ручними продажами чи прототипом на конструкторі, окремий архітектор не потрібен. Він знадобиться, коли Ви почнете писати код, який плануєте розвивати далі, а не викинути. На цьому етапі навіть кілька годин консультації досвідченого архітектора можуть заощадити місяці.
У невеликому стартапі роль архітектора часто виконує технічний співзасновник або CTO. Це нормально, якщо в нього є досвід і він уміє стримувати себе від будівництва зорельотів.
Що робимо ми
Ми в Ingello Systems часто працюємо зі стартапами саме на цьому етапі. Наш підхід: швидко описати модель предметної області, згенерувати на Fractal робочий прототип із нормальною структурою даних і вже на ньому перевіряти гіпотези. Виходить та сама злітна смуга: прототип зʼявляється за дні, а не місяці, але під ним правильний фундамент, на якому можна будувати далі, якщо політ вдався.
Якщо Ви засновник стартапу, поставте собі питання: що станеться з Вашою системою, якщо завтра Ви вирішите змінити цільового клієнта? Якщо відповідь «доведеться все переписувати», Вам потрібен архітектор. Не для зорельота, а для смуги.
