CTO as a Service

Цена пробела в техническом руководстве состоит не в плохом коде. Плохой код обходится дорого, но он обратим; настоящая цена лежит в решениях, которые никто в тот момент не счёл решениями и которые потом уже не отменить. В какой стране лежат данные. На чьё имя открыт облачный аккаунт. Первый API-контракт, отданный наружу. Ни одно из них не попадает в повестку под заголовком «решение», большинство проходит внутри спринта незаметно, а через два года именно они определяют, что компания вообще способна сделать. Работа в этой услуге состоит не в написании кода, а в том, чтобы оказаться впереди таких решений: отделить необратимые, записать их вместе с обоснованием и оставить запись у вас.

Определение роли и критерии соответствия

Речь идёт о принятии, обосновании и письменной фиксации технических решений без найма штатного технического руководителя. Границы роли очерчиваются сразу: мы не становимся должностным лицом с правом подписи и не становимся юридическим начальником инженеров в вашем штате. Есть и порог, за которым правильным ответом оказывается именно штатный CTO: когда поток решений делается непрерывным, то есть когда каждую неделю появляется новый вопрос, затрагивающий архитектуру, внешняя роль перестаёт успевать. Эта услуга построена для компаний, где решения приходят пачками, а между ними идут периоды внедрения и измерения. Одно наблюдение из самой работы: в проектах Tegoly, Finteo и Terazzi консультирование ни разу не шло в одиночку. В каждом из них делалась и работа по реализации, от новых экранов и модулей до бэкенда и производительности. Консультация здесь не представляет собой слой, оторванный от исполнения.

Что входит в работу

Шесть заголовков ниже охватывают всё, что происходит внутри соглашения по CTO as a Service. Первые два составляют основание: установление того, где система стоит сегодня на самом деле, и фиксация решений вместе с их обоснованием. Следующие два касаются выбора: с какой технологией и с каким подрядчиком работать и кого брать в команду. Пятый посвящён инвентаризации накопленного долга. Шестой посвящён переводу той же информации на язык, понятный инвестору и совету директоров.

Технический due diligence и оценка текущего состояния

Оценка начинается не с документа, а с работающей системы: сначала проверяется, поднимается ли проект с нуля на чистой машине, ведь установка, которая живёт только на нескольких ноутбуках, по сути остаётся недоказанной. Дальше смотрят, на чьё имя открыты аккаунты репозитория, облака, домена, DNS, магазина приложений и платёжного провайдера, а также как код попадает в продакшен, кто способен его выкатить и записан ли где-нибудь шаг отката. Вопроса о том, делаются ли резервные копии, недостаточно: пробовали ли хоть раз восстановление, ведь непроверенная копия остаётся недоказанной. Проверяется и то, лежат ли секреты в репозитории, какая среда выполнения потеряла поддержку и к какой части системы способен прикоснуться только один человек. На выходе получается не записка, а письменный список, упорядоченный по стоимости и влиянию.

Журнал архитектурных решений и обоснование

Каждое решение умещается на одной странице: вопрос, на который оно отвечает, рассмотренные варианты, выбранный путь, обоснование и условие, при котором вопрос стоит открыть заново. Последний пункт пропускают чаще всего, а без записанного условия возврата решение со временем затвердевает в привычку, которую уже никто не оспаривает. Настоящая проверка записи приходится не на день, когда её сделали, а на день год спустя, когда кто-нибудь спрашивает, было ли то или иное поведение системы намеренным. Именно это и есть долг намерения, который мы разбирали в статье о долге знаний: причина решения так и осталась незаписанной. Код может быть чистым, а тесты могут проходить, и всё же команда не отличит выбранное поведение от случайного. Код, порождённый ИИ, ускоряет этот долг, потому что инструмент, выдавший предложение, не записывает своё обоснование за вас.

Выбор технологии и оценка подрядчика

Вопрос при выборе состоит не в том, какая технология лучше, а в том, чего будет стоить ошибка. Решают три критерия: кто станет сопровождать это после передачи, находятся ли на вашем рынке инженеры под эту технологию и может ли хостинг остаться в ваших собственных аккаунтах. На системе, которая уже работает, ответом по умолчанию служит «не менять», потому что обоснование рисковать тем, что и так работает, ради альтернативы, которая выглядит лучше лишь на бумаге, обычно оказывается слабым. Ни в одном из проектов Tegoly, Finteo и Terazzi работающая технология не заменялась: в проекте Tegoly работа шла на уже стоявших MSSQL и Azure, а в Finteo и Terazzi она шла на платформах, которые у этих компаний уже были. Со стороны подрядчика мерой служит не список референсов, а форма передачи и владение аккаунтами.

Формирование команды и оценка инженеров

Первые инженеры не только пишут код: на практике именно они задают выбор технологий компании и планку последующих собеседований. Поэтому ранний наём делается не под организационную схему, воображаемую через три года, а под решения ближайших двенадцати месяцев. Центр тяжести самой оценки тоже сместился. Вывод нашей статьи о том, каково быть junior-разработчиком в эпоху ИИ, состоит в следующем: чтобы получать от ИИ пользу, надо сперва знать, что именно спрашивать, а затем обладать технической базой, позволяющей оценить, верен ли полученный ответ. Поэтому вопрос на собеседовании перестаёт звучать как «напишите эту функцию» и становится «вот сгенерированное изменение, что в нём не так и почему». Мы участвуем в технической части собеседования и пишем критерии оценки; решение о найме принимаете вы.

Инвентаризация технического долга и приоритеты

Инвентаризация разделяет три долга, потому что каждый закрывается своей работой. Технический долг живёт в кодовой базе и закрывается изменением кода. Долг знаний представляет собой разрыв в понимании между кодовой базой и людьми, которые за неё отвечают, и закрывается только передачей знаний; переписывание кода чаще всего его увеличивает. Долг намерения состоит в том, что обоснование решения осталось незаписанным, и закрывается письмом. После разделения каждый пункт попадает в одну из трёх коробок: то, что обязано измениться до роста, то, что способно долго жить как есть, и то, чего не коснутся никогда, потому что стоявшее за ним предположение отпало. Для каждого пункта отдельно пишется цена оставить и цена исправить, чтобы очерёдность задавала коммерческая сторона, а не техническая.

Общение с инвесторами и советом директоров

Совет директоров никогда не спрашивает, какой фреймворк используется. Он спрашивает, в чём риск, сколько он стоит и когда наступит срок платежа. Мы пишем сводку, переводящую техническое состояние в эти три колонки. В инвестиционном раунде техническая проверка со стороны покупателя всё равно требует тот же список: владение аккаунтами и доменом, совместимость используемых лицензий открытого кода с вашим продуктом, страна размещения данных и положение дел с GDPR и региональными требованиями к резидентности данных, прошлые инциденты безопасности, области знания, оставшиеся на одном человеке. Эти пункты не собираются в момент открытия раунда, они готовы заранее. Цифру, которую мы не в состоянии проверить, мы за вас не пишем, и такую проверку в качестве должностного лица компании не подписываем.

Какие решения необратимы

Сортировка решений по их обратимости представляет собой самый практичный инструмент в этой работе. Длинные совещания уходят обычно на обратимые: библиотека интерфейса, инструмент CI, стиль кода, большинство библиотек, хостинг-провайдер. Они бьют по нервам, но из них всегда можно вернуться, тогда как решения, которые не отменить, обычно проходят в тишине, и таких выделяется пять. Первое: заложены ли идентичность пользователя и разделение данных между клиентами в модель данных или в код приложения. Второе: где лежат данные, ведь перенос представляет собой не только техническую работу, он заново открывает договоры с клиентами. Третье: владение аккаунтами, поскольку если облако, домен и репозиторий открыты на имя подрядчика, возврат превращается в юридический процесс, а не в технический. Четвёртое: то, каким образом платёжный провайдер и логика возвратов, подписок и счетов вшиты в данные. Пятое: первый API-контракт, отданный наружу, ведь каждый интегрировавшийся клиент закрепляет его на месте. Для этих пяти письменное обоснование до принятия решения обязательно. Для остальных нет, иначе процедура сама превращается в нагрузку.

Критерии оценки агентства или подрядчика

Этот раздел мы пишем, сами будучи агентством, поэтому тот же список обязан быть применим и к нам, и для этого достаточно шести вопросов. Лежит ли репозиторий со всей историей в вашем аккаунте или передача приходит архивной папкой? Передача без истории делает нечитаемым, кто и что менял и когда. На чьё имя открыты аккаунты облака, домена, DNS и магазина приложений, и если вы разойдётесь сегодня, какого пароля у вас не окажется? Поднимается ли проект с нуля где-то, кроме машины подрядчика? Записано ли обоснование решений или оно живёт в памяти нескольких человек? Построил ли подрядчик собственный закрытый слой, который не унести с собой? В каких единицах оценивается запрос на изменение и как двигается счёт, когда объём растёт? Работа, не дающая ясного ответа на все шесть вопросов, привязывает вас к этому подрядчику независимо от качества сделанного.

Выход: вы становитесь самостоятельными

Мерой успеха здесь служит не продление соглашения, а то, что оно становится ненужным. Выход происходит одним из трёх способов: вы нанимаете собственного технического руководителя, роль забирает старший инженер, уже работающий в команде, или поток решений замедляется и постоянная роль перестаёт быть нужной. Во всех трёх случаях готовится один и тот же передаточный пакет: полный журнал решений, оценка текущего состояния, инвентаризация технического долга по трём коробкам, список аккаунтов и доступов с указанием владельцев, заметки по оценке подрядчиков. Чего мы избегаем, так это превращения в единственную точку знания: решения лежат там, где ваша команда способна их открыть и прочитать, а не в наших головах и не в переписке. Ваши аккаунты мы не держим на своё имя и закрытого слоя, который нельзя унести, после себя не оставляем. Без этих двух правил выход перестаёт быть передачей и становится проектом переезда.

Разделение полномочий в принятии решений

Работа начинается с оценки текущего состояния: она оценивается отдельной строкой, а её результатом становится письменный список, который вы вправе забрать и отдать своей команде. Дальше всё идёт по открытому списку решений: у каждого пункта есть владелец, дата открытия и статус, а закрытые переходят в журнал решений. Нам принадлежит техническая рекомендация, и рекомендация всегда пишется с названной альтернативой, причём цена обеих сторон излагается вместе. Вам принадлежат бюджет, наём, выбор подрядчика, момент выхода в продакшен и юридическая ответственность. Мы говорим и о том, когда услуга не нужна: если есть один продукт, одна команда и устоявшаяся система с уже принятыми решениями, требуется не консультирование, а сопровождение. Когда проблема состоит в нагрузке, а не в решениях, работа уходит в масштабирование бэкенда, а когда речь о ещё не проверенной продуктовой идее, она уходит в разработку MVP.

Как это сработало в трёх кейсах

Три работы ниже представляют собой проекты, в которых эта работа была сделана. У каждой есть своя страница в разделе историй успеха, и каждую можно проверить извне.

• Tegoly: Платформа электронной подписи и деловых процессов, нацеленная на глобальный рынок. На уже работающей системе сделаны новые пользовательские экраны и модули, интеграции электронной подписи и управления документами, кеширование, конфигурация серверов на Azure, слои безопасности MSSQL и Azure, а также технический SEO.
• Finteo: Финтех-платформа цифровых платежей. Главное изменение произошло на фронтенде: весь интерфейс перепроектирован, добавлены доработки клиентской панели, формы и новые экраны, применены контентные стратегии и технический SEO.
• Terazzi: Веб-платформа бренда в области строительства и отделки. Устранены проблемы дизайна, выпущены доработки клиентской панели и новые экраны, проведена оптимизация бэкенда и производительности, применены контентные стратегии ради видимости в поиске.