Про технических руководителей в Тинькофф

Александр начинает с себя: последние семь лет он в компании, сейчас — технический директор направления, отвечающего за клиентские интерфейсы, маркетинг и вовлечение, то есть за жёлтое приложение, сайт, рекламу и проектные истории вроде монополии и пяти букв. Ландшафт технических директоров в Тинькофф он раскладывает на три части: бизнес-вертикали со своим ИТ (инвестиции, страхование, мобильный оператор, банк для физлиц и для бизнеса), платформенные решения (инфраструктура, платформа разработки, дата-платформа) и сервис-линии, которые оказывают сервис другим вертикалям. У каждой части свой технический директор; себя Александр относит скорее к платформенной стороне и отдельно отвечает за подход компании к архитектурным и процессным вопросам. На вопрос ведущих, кого считать CTO, он отвечает: руководителя управления — точно, но дальше начинается семантика. Внутри управления бывают отдельные продукты со своим CPO, и тогда технический руководитель отдела фактически тоже CTO — как в нефинансовых сервисах, куда входят Тинькофф Город и направление Travel, по некоторой статистике второе или третье тревел-агентство в России.

Такой человек автономен в решениях и вне компании назывался бы CTO, но на рынке его ждёт подвох: в Тинькофф часть болей закрывают платформенные решения и корпоративные функции — найм, бюджетирование, сквозные процессы, — а в другой организации их эффективность внезапно становится его зоной ответственности. Саму иерархию Александр разбирает снизу: начинается она с тимлида, для которого есть матрица компетенций. Первый грейд отвечает за всё, что происходит в кросс-функциональной команде: за деливери и предсказуемость поставки, за менеджмент внутри и за инженерные практики — качество сервисов, нефункциональные требования, контролируемый техдолг, надёжность. Важность последней он объясняет экосистемным эффектом: промах в одном продукте люди переносят на весь бренд. Команды не разгоняют больше десяти человек. Над группой команд одного домена стоит «тимлид тимлидов» — точный нейминг после унификации названий Александр честно не помнит, — дальше отдел на сто-полтораста человек, где на бизнес-ревью спрашивают не только P&L, но и деливери-метрики, качество и безопасность, а затем управление из нескольких отделов, которое иногда называют центром.

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

Процессные ребята любят Kanban Maturity Model — плакат висит у Александра прямо на стекле, — но сам он предпочитает превращать модель в практику, а не в религию. Внутренний инструмент вытаскивает данные по задачам из Jira и не только; единого процесса на всех нет, каждая команда выбирает шаблон под себя, поэтому даже настройка дашборда требует понимания теории очередей: cycle time, lead time, где активные фазы. Дашборды команд собираются каскадно поднимать до направлений, отделов и управлений: на операционном ревью руководитель тогда будет смотреть не «как дела и были ли факапы», а динамику команды относительно неё самой — сколько пул-реквестов, как меняется lead time. Верхнеуровневый прототип работает, но команды в него набираются руками, а их под сотню. Инженерные метрики — стабильность сервисов, соблюдение SLA, автотесты — пока сведены отдельно: мешает метамодель, где управленческая структура, продуктовая, репозитории и рантайм-элементы не сходятся один в один.

Ко второй половине разговора ведущие просят рассказать, как стать техническим руководителем в компании; Александр ссылается на свою статью и доклад и разбирает три интервью для тимлида. Первое — по языку, который человек считает основным. Второе — системный дизайн с намеренно невысокой планкой: тимлид не проектирует за всех, но обязан понимать трейд-оффы между слоями и выступать арбитром. Слоёную организацию он показывает диалогом: бэкенд предлагает реализовать логику на фронте, фронт просит отдать ему GraphQL, «а дальше под капотом произойдёт магия», а автор API считает, что RPS — это уже проблема базы. Третье интервью — про управление командой: people management, деливери и инженерные практики вплоть до того, понимает ли человек, чем плохо полагаться на одних ручных тестировщиков. Для уровней выше добавляются выравнивание бизнеса и ИТ, найм и бюджетирование, а менеджерское интервью Александр ведёт по реальным ситуациям кандидата, а не по гипотетическим кейсам; дальше идут фит-интервью с командами.

Свой инсайт формулирует один из ведущих: по нескольким последним записям с разными руководителями видно, что архитектор перестаёт быть фигурой «на башне» — роль размазывается по руководителям, и архитектурного понимания ждут уже от тимлида, чего раньше не было; те же ожидания, по его наблюдению, в Яндексе, Авито и ВТБ. Александр отвечает, что архитекторы есть и у него, но обычно не в команде, а при техническом директоре продукта: смысл в том, чтобы проблему решали там, где хватает контекста, а не эскалировали к перегруженному человеку, который выдаст дженерик-решение. Работает это через архитектурный процесс: команда пишет RFC с проблемой, вариантами и сравнением, а архитектор челленджит документ и подсказывает, у кого в компании была похожая задача. Отсюда же письменная культура и реестр ADR — слишком часто «исторически сложилось» не оставляет следов. В финале он советует расти через рефлексию: на интервью сразу видно, кто разобрал свой опыт, а кто получает инсайт прямо в разговоре.