Культура разработки Tinkoff.ru: переход от монопродукта к экосистеме

Александр начинает с биографии: один из ведущих технических вузов страны, работа в крупных интернет-компаниях, запуск woman.ru вместе с командой, народные рейтинги в banki.ru, небольшой рекламный стартап — и в конце 2016 года переход в Tinkoff.ru, в привлечение. В зону управления входят неавторизованная часть сайта с главной страницей, админка, через которую конфигурируются веб и другие системы, автоматизация всех каналов привлечения и система персонализации с проверкой гипотез тестами: потенциальному клиенту надо показать релевантный продукт. Дальше — про компанию целиком: с 2013 года продуктов появилось очень много, и на каждый тоже нужно привлекать клиентов, а в 2016-м привлечение решили автоматизировать серьёзнее прежнего. Метафора Александра: изнутри компания похожа на мегаполис, где бизнес-вертикали — небоскрёбы, стоящие на общей платформе с приватным облаком и частью публичных; вместе это и складывается в экосистему. Смысл роста в том, чтобы любое направление запускалось относительно безболезненно, а для повторяемости нужна не только платформа, но и процессы.

Привлечение повторяет структуру компании в миниатюре, и свой подход Александр раскладывает на три грани: что мы делаем, как делаем и какой командой. На стратегию и продуктово-процессный подход тимлид, по его словам, влияет лишь косвенно, но понимать их обязан. Себя он предлагает проверить четырьмя вопросами: объясните ли вы стратегию компании на пальцах; сумеете ли оценить здоровье бизнеса — у публичных компаний по стоимости акций, у непубличных по доле рынка; есть ли у топ-менеджеров видение, которое транслируется сотрудникам и рынку; остаётся ли у вас время думать о стратегии или всё съедает текучка. За подробностями он отправляет к книге Managing Humans, где есть отдельная глава про здоровье компании и команды. Продуктовый подход означает, что любой продукт, внешний или внутренний, ведут как продукт — с целями и требованиями. В иерархической структуре это сложно, мешают грани между отделами, а идей всегда больше, чем команд, поэтому важно понимать, как выбирают те, что пойдут в работу.

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

Какой именно процесс разработки выбран — waterfall, Scrum, Kanban, XP — Александр считает менее важным, чем типовые провалы: процесс никто не выстраивал и он «получился какой-то»; внутри команды нет видимости, и в момент проблемы не понять, дело в людях или в процессе; нет ни процессных, ни результатных метрик, поэтому не с чем сравнить прошлые периоды; удачные практики соседей не переиспользуются, хотя у них, например, оценка в стори-поинтах вместо часов работает отлично. За этим обычно стоит отсутствие персонального ответственного за процессы. Архитектуру он называет одним из ключевых пунктов: стадии проектирования часто просто нет, прототип внезапно становится production-решением, и жить с ним приходится дальше. Самая проблемная унаследованная система — не замороженная, а та, в которую бизнес хочет активно добавлять фичи, не планируя технического развития. Архитектор не прилетит на вертолёте с готовой архитектурой: тимлиду самому приходится проводить аудит систем и составлять технический roadmap — в привлечении этим занимается лично Александр.

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

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