Кем мы станем, когда вырастем. Александр Поломодов

Александр начинает с биографии: на момент записи ему 37, он закончил МФТИ и собирался стать учёным, но с третьего курса ушёл в айти, где тогда ещё не так много платили. Начал с техподдержки, через полгода стал программировать — он подхалтуривал в свободное время, и ему сказали: зачем делать это для кого-то другого, иди к нам.

Потом была магистратура IBS по системному анализу и год работы аналитиком: диплом был про реинжиниринг бизнес-процессов, он одновременно переделывал процессы и писал ТЗ под их автоматизацию. В кризис 2008–2009 годов компании стало плохо, и он много собеседовал людей на выход, разбираясь, на кого переложить их ответственность; после этого решил, что разработчиком проще — просто пишешь код.

Дальше был инженерный трек: синьор, тимлид, небольшой стартап и приход в Тинькофф инженерным менеджером на онлайн-привлечение, где было три команды примерно по три человека. Больше шести лет спустя в его управлении около 650–700 человек.

Что цепляет в архитектуре? Александр связывает интерес к ней с желанием решать сложные задачи. В IT его привлекают архитектурные изменения и их связь с оргструктурой: он вспоминает закон Конвея и необходимость менять систему так, чтобы она продолжала работать.

На вопрос о том, что отталкивает в работе, Александр отвечает: ничего. Освоенные задачи можно упрощать и передавать дальше: он вспоминает переход между доменами сложности — из хаоса в complex, затем в complicated и в очевидное. То, что перестало быть вызовом для тебя, может стать точкой роста для другого; в этом смысл делегирования.

А архитекторы, по его мнению, начинаются не с диплома, а со склада мышления: физика в лицее объяснила ему, зачем нужны модели — выделить важное и абстрагироваться от остального.

Андрей Дмитриев предложил разложить разговор по блокам и начать с формализации задачи. Александр объясняет её через фреймворк систем-дизайн-интервью: первая фаза — понять, что за система, зачем она, кто ею пользуется, какие нужны интеграции.

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

Дальше идут функциональные и нефункциональные требования и байка о том, что нефункциональные плохо продаются: бизнес отвечает, что заказывал функции. Поэтому их переименовывают в атрибуты качества или в архитектурные характеристики — ранние решения дорого менять постфактум. Андрей Бураков подхватывает шутку знакомого архитектора: аналитик отличается от архитектора тем, что архитектор думает про НФТ.

В ответ Александр рассказывает про аналитика, которого брали на платформу A/B-тестов, где нужны статистика, работа с данными и поддержка высокой нагрузки. Тот умел задавать вопросы, накидывать идеи по улучшению, документировать проектные решения и фиксировать взаимодействие компонентов: он делил ответственность с руководителем разработки, забирал сложные темы вроде подготовки сегментов и отслеживания коллизий, отдавал их на ревью — и дорос из ведущего аналитика до архитектора, а потом до технического продакта этой системы.

Нужны ли аналитики вообще, зависит от конфигурации: на заказной разработке по фиксированной цене огромна стадия предпроектирования и документации, при итеративной продуктовой разработке не нужно проектировать всё заранее, зато под большие межкомандные изменения пишут RFC — из свежих Александру нравится документ про новую авторизацию для физлиц.

В финале участники возвращаются к необходимости аналитиков. Александр объясняет компромисс: универсального инженера трудно найти, а разделение ролей увеличивает число передач ответственности. В мобильном банке при росте разделили работу «технологов» на системный и бизнес-анализ; другим командам хватает продакта и инженеров. Нужную конфигурацию определяют задачи и компетенции, а не общий запрет на роль аналитика.

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

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

Расти он советует не на абстрактных задачах из интернета, а на своей системе: взять первый сценарий, неважно, записан он юзкейсом, user story или jobs to be done, и разобраться, где входная точка и какие компоненты участвуют; попутно появятся инсайты, а инициативу может заметить работодатель.

Дальше — теория и практика: сети, операционные системы, распределённые системы, классическая книга про паттерны интеграции, Клеппман с «кабанчиком» и Learning Domain-Driven Design Влада Хононова, а сверх книг петпроект. Сам он ради общения с инфраструктурным инженером, который лет пять назад помогал переезжать в Kubernetes, прошёл курсы и лабы и стал сертифицированным администратором.

Виды архитекторов он разбирает по книге Staff Engineer: техлид внутри команды, солвер-пожарный, архитектор кросс-командных решений и правая рука уровня зама CTO — такой человек, признаётся Александр, скоро понадобится и ему самому.

Ярлыки, по его словам, гвоздями не прибиты: отвечая на вопрос про разницу software- и solution-архитектора, он советует выбирать не шильдик, а профиль работы — например, роль связующего звена там, где решение делают пять команд.

А на финальный вопрос, кем он станет, когда вырастет, отвечает: по технической ветке он около максимума, хочет написать книгу и летом прочитать курс на английском в Барселоне.