Про Тинькофф, управление людьми, команды и смыслы

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

Сам он отвечает за то, как компания представлена клиентам: клиентские интерфейсы — мобильное приложение, веб, аутентификация и авторизация; маркетинг внешний и внутренний, с автоматизацией рекламы, программой «приведи друга» и партнёркой для блогеров; вовлечение — медиапроекты вроде журнала «Бизнес секреты» и игровые механики в мобильном банке.

Продуктовые команды кредитных и дебетовых продуктов живут в своих вертикалях; Александр отвечает за платформы с общими правилами. Задача — сохранять контакт с клиентом после выпуска карты. На момент интервью в двух его управлениях порядка 950 человек, целевая структура — три управления.

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

Организационно была функциональная структура: департамент IT с отделами Java-, Scala- и JavaScript-разработчиков и матричное распределение людей по продуктам, где матрица каждый раз выходила разной силы, связь с продуктом была слабой, а работой нередко руководил человек без технической компетенции.

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

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

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

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

Что будет, если новая команда захочет свой стек — «вы любите Java, а я подниму на другом»? MVP сделать можно, отвечает Александр, но с ростом нагрузки понадобятся мощности, и точкой контроля станет запрос ресурсов: придётся объяснить, чем не подошло платформенное решение.

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

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

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

Отсюда принцип оценки: смотреть, что было известно в момент выбора, а не судить только по результату. Журнал архитектурных решений сохраняет этот контекст.

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

Вторая — стремление делать работу лучше и расти. Процесс «Тинькофф рост» переносит инициативу с руководителя на сотрудника: открытые матрицы компетенций показывают ожидания, более сложные задачи дают артефакты для заявки на повышение. Заявку согласуют с руководителем, затем рассматривает сообщество лидов профессии.

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

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

Скорость нужно оценивать вместе с качеством. Сбои будут, вопрос в скорости восстановления и их числе после релиза. Внутри есть инструмент, показывающий движение задач, время от постановки до завершения и время работы над задачей — lead time и cycle time. Отдельные проверки показывают, соблюдают ли сервисы установленные уровни сервиса.

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

Крутую команду он описывает через исследования Google — «Кислород» о руководителях и «Аристотель» о командах. В его пересказе главный фактор — возможность говорить об ошибках и плохих новостях без наказания: так команда учится и улучшает работу.

Среди компаний с интересной инженерной культурой он называет Яндекс, оговаривая различия подразделений, и Авито. О ВКонтакте знает меньше, но выделяет масштаб задач и технической команды.