Техлиды и архитекторы

Осенью 2020 года на ArchDays я рассказывал как мы в Тинькофф принимаем архитектурные решения. С тех пор прошло много времени и теперь точно можно сказать, что мы действительно пишем архитектурные документы для крупных решений и обсуждаем их заранее. А результаты обсуждения обычно фиксируются в некотором логе архитектурных решений. У каждого крупного подразделения есть собственный процесс ведения такой документации, который похож в общем, но может отличатьтся деталями. Обычно самыми активными на ниве создания, проработки и ревью такой архитектурной документации являются инженеры высоких грейдов. У таких инженеров есть несколько ярко выраженных архетипов, среди которых я хотел сегодня поговорить про техлидов и архитекторов. Эти архетипы неплохо расписаны в книге "Staff Engineer" Вила Ларсона (вот тут мое краткое саммари книги). Но если говорить про эти архетипы своими словами, то
- Техлиды обычно работают в рамках одного домена с одним менеджером и одной-двумя командами. В Тинькофф такие ребята помогают улучшать инженерные метрики сервисов, за которые отвечает команда (MTTR, уровень автоматизации тестирования и деплоев, показатели SLA сервисов и так далее).
- Архитекторы обычно работают вне рамок одной команды и помогают драйвить архитектурные процессы и сложные кросс-командные проекты. В Тинькофф это может быть создание нового продукта, сложная миграция, перепроектирование старого продукта с учетом требований регуляторов и compliance.

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

Кстати, в ветку архитекторов есть тропинка и через ветку системных аналитиков, но этот путь пока экспериментальный и содержит следующие шаги
- Подготовка заявки с архитектурными артефактами, которые были выполнены в рамках рабочих обязанностей (примерно как я рассказывал в этом докладе в части про процесс Т-Роста)
- Прохождение двух интервью: system design interview и интервью про архитектуру и процессы разработки, где мы обсуждаем как выглядят современные процессы разработки, как выстраивать архитектурные процессы в подразделении, а также как вести крупные проекты в роли архитектора

#Engineering #Management #Software #SoftwareArchitecture #Architecture #Architect

А вот и иллюстрация для предыдущего сообщения про архитекторов и техлидов

Тимлиды и как они появляются в компании

У нас в Тинькофф роль тимлида превратилась в формализованную профессию, где тимлид - это руководитель небольшой кросс-функциональной команды, которая может самостоятельно обеспечивать delivery определенной бизнес-ценности для клиента. Тимлид у нас отвечает за все, что происходит с командой: за ее delivery, за процессы разработки внутри команды, за используемые инженерные практики, за people management и так далее. Мы научились набирать таких руководителей рынка (я рассказывал про это в отдельной статье), а также мы умеем их растить внутри. И в этих подходах есть небольшое отличие:
- Мы нанимаем с рынка мы только людей с инженерным бэкграундом, которые умеют в разработку. Мы проверяем это при помощи трех интервью: языкового интервью, system design интервью и it team management интервью. На выходе мы понимаем что человек умеет писать код, умеет проектировать и умеет менеджерить
- А вот рост внутри пока до конца не стандартизован и иногда тимлидами команды становятся не только разработчики в прошлом, но и системные аналитики или qa-инженеры. В таких случаях часто продакт менеджер бывает доволен уровнем взаимодействия с тимлидом, но у этого часто бывает оборотная строна - в таких командах часто западают инженерные практики и/или архитектурные процессы. Проблема в том, что сложно удерживать баланс между бизнесовыми и техническими задачами, если бизнесовые задачи тимлид понимает хорошо, а вот в технике он плавает. В итоге, неявно технические задачи отходят на второй план и делаются по остаточному принципу. А это приводит к накоплению техдолга и замедлению команды. Правда, иногда это нарастание энтропии можно остановить, если в такой команде у тимлида не из разработки есть напарник в виде техлида, про которого я писал в прошлом посте. Но даже в этом случае accountable за инженерку в команде остается тимлид:)

#Management #Leadership #SoftwareDevelopment #Software #Engineering

Мой опыт в качестве тимлида

В продолжение прошлого поста расскажу немного про свой опыт тимлидства:
- В первый раз я стал тимлидом лет десять назад, когда работал над сайтом Woman.ru. Там была интересная конфигурация с принятием проекта от подрядчика, а дальше созданием команды inhouse для дальнейшей разработки и кастомизации сайта этого издания. В прыжке команда была порядка 10 человек, но сильно схлопнулась на рубеже 2014-2015 годов из-за финансовых потрясений
- Дальше я перешел в Банки.ру на похожую позицию, где был тимлидом команды, что отвечала за банковские, страховые, телекоммуникационные рейтинги и прочий UGC. Это был интересный опыт системной работы над техдолгом:) Но через полтора года я подустал с ним бороться, а обещанный на старте крупный продукт так и не стартовал
- Из Банки.ру я ушел в небольшой стартап про рекламу, партнерский маркетинг (CPA) про установки мобильных приложений. В этом стартапе я был аля deputy CTO, хотя по-факту это была такая же позиция тимлида, просто отвечающего за все IT в компании, включая инфраструктуру, процессы разработки, найм и обучение и так далее. За 4 месяца в стартапе я устал так, как за год в обычной компании (я понял, что хаос стартапов - это не для меня). В итоге, я покинул стартап, оставив оклад за последний месяц одному из сооснователей, который объяснил этот вычет фразой "а мы на тебя расчитывали":)

Дальше я пришел в Тинькофф, но здесь я тимлидом не был - я сразу пришел на позицию технического руководителя нескольких команд. И я ни разу не пожалел о своем приходе в компанию - мне кажется, что это самое продуктивное время за мою карьеру, как с точки зрения менеджмента, так и технического развития:)

Кстати, я достаточно часто выступал на тему тимлидов и прочих менеджеров. Вот мои выступления в хронологическом порядке
- Рост команды на порядок, или Как не сойти с ума, будучи frontend-тимлидом в привлечении Tinkoff.ru — выступление на Teamlead Conf 2018 (пример того, как я выстраивал процессы и сетапил роль тимлидов лет 6 назад в своем подразделении)
- Культура разработки глазами тимлида: переход от монопродукта к экосистеме - выступление на Codefest 2019 (здесь я рассказывал как тимлид может улучшать все внутри своей команды)
- SOLID'ный тимлид, или Основы менеджмента для технарей - выступление на Teamlead Conf 2021 (здесь я говорил про основы менеджмента с примерами из инженерных практик)
- Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - мое выступление на Highload++ про роль технического директора
- Как нанимать технических руководителей — выступление на Teamlead Conf 2023 (здесь я рассказывал как мы нанимаем тимлидов и менеджеров повыше)

#Management #Leadership #SoftwareDevelopment #Software #Engineering

Проектируем надежные системы - стоит ли игра свеч

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

Если внезапно окажитесь в Ульяновске в это время, то заходите послушать этот доклад:)

#Architect #Architecture #Software #SoftwareDevelopment #SoftwareArchitecture #Conference

The Art of Software Development • Sander Mak • GOTO 2023

Интересное обзорное выступление от Sander Mak насчет того, а насколько software engineering реально про инженрную состоавляющую, а в какой части это больше про искусство.
В выступлении примерно такая структура:
- А инженеры ли мы? Или мы ученые из сферы computer science? - Нет мы все художники (artists)
- Потому что software development - это про создание абстракций из реального мира в нашем софте
- Дальше автор обсуждает написание кода и говорит про общие принципы и подходы, а потом про вкручивание правил в линтеры, чтобы "художники" не обсуждали вопросы уровня пролемы vs табы. В общем, цель в том, чтобы не увлекаться инструментами и незначимыми деталями, а писать код, который обеспечивает работу выбранных абстракций
- Следующим идет тестирование, причем конкретно unit testing и о чем надо говориться перед написание тестов - тема раскрыта не полностью, но смысл примерно тот же - договоритесь о правилах и дальше сделайте их проверку частью инженерной культуры:)
- Потом приходит очередь дизайна и архитектуры - эта тема мне тоже показалась очень скомканной - автор говорит, что эта часть работы важна и экономит много времени за счет того, что мы сначала думаем, а помто кодим. В итоге, он дает отсылку к выступлению Саймона Брауна The lost art of software design by Simon Brown at Devoxx Belgium 2022, про которое я уже рассказывал раньше
- Предпоследняя часть посвящена процессам - тут автор по верхам задевает скрам и waterfall, но рекомендует вспомнить, что работаем мы с людьми, поэтому читайте "Peopleware: Productive Projects and Teams" от Tom DeMarco и Tim Lister, да будет вам счастье
- Ну и последняя тема посвящена тому, а как мы учимся тому, как писать код - ответ автора в том, что мы учимся на практике, а не из книг, поэтому идите и пишите код, а если вы считаете, что уже умеете, то вам стоит стать ментором для новичков

В общем, получилось интересное по структуре выступление, с интереными мыслями, но многие из которых раскрыты слишком поверхностно как мне показалось.

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems #Management #Leadership #Engineering

Remote Working Approaches That Worked (And Some That Didn’t) • Charles Humble • GOTO 2023

Интересное выступление про удаленную работу, апологетом которой является Charles Humble.
Он выступал за удаленную работу еще до ковида, на котором мы все принудительно оказались в удаленном режиме и смогли попробовать как это. Но Чарльз говорит, что этот опыт мог понравиться не всем, так как это было вынужденной и форс-мажорной мерой. Сейчас многие компании возвращают сотрудников в офис, аргументируя потребностью в повышении эффективности и/или коллаборации. Но так ли все просто...
Если подбивать итог высутпления, то основные мысли Чарльза сводятся к следующему
- Удаленная работа требует отдельного осмысленного проектирования как от компании, так и от сотрудника. Без этого она работает плохо (условно как было в ковид, когда всех отправили по домам)
- Надо отделять работу от дома, даже (особенно) если вы работаете удаленно. Например, при помощи физических границ: работая из кафе, гаража или просто символически выходить на прогулку из дома, имитируя поход на работу, а потом возвращаясь домой (но как бы на работу)
- Серьезно воспринимать свое ментальное здоровье и заниматься спортом, участвовать в социальной жизни
- Компания и менеджеры внутри нее должны позаботиться о прозрачности правил и процессов внутри организации, а также работать над flow информации, чтобы удаленные сотрудники оставались в общем контексте.

Автор вспоминает по ходу рассказа книги:
- Remote Team Interactions Workbook- книга от авторов Team Topologies, где они говорят про удаленную работу и про которую я уже рассказывал
- The Manager's Path - тут автор упоминает часть про one2one и хвалит книгу как отличный гайд для тех, кто переходит из разработчиков в менеджеры. Про эту книгу я тоже уже рассказывал в 4 частях: pre-manager, manager, engineering directors и senior leaders.

#Software #Management #Leadership #Engineering #SoftwareDevelopment

Вакансии в наши команды DBaaS (Database as a Service)

Я очень люблю распределенные системы, архитектуру, дизайн систем. А самое интересное в этом та часть, где хранится state или по простому базы данных. Причем базы данных бывают разные и сейчас у нас в компании активно разрабатывается продукты Database as a Service (пока Postgres и Cassandra). И если вы любите базы как я и еще умеете писать код на Python или Go, то вы можете присоединится к этой команды.

Вот как они сами описывают свой продукт
- Наша команда делает продукт для массового управления кластерами БД.
Но не просто систему получения кластера БД - мы глубоко интегрируемся с платформой разработки, платформой мониторинга и алертинга, платформой доставки данных, и т.д.
Это позволяет предоставить бесшовный опыт для большого количества пользовательских сценариев буквально по клику мышки и вызову одной команды.

А вот какие планы по развитию этих продуктов
Сейчас мы предлагаем пользователям кластера PostgreSQL и Cassandra, однако планируем расширять список поддерживаемых БД. Запускаемые нагрузки активно растут, сейчас это сотни команд и тысячи кластеров, однако ожидаем десять+ тысяч кластеров. Одним словом - огромное количество возможностей для развития и прокачки скиллов в условиях решения нетривиальных задач, с которыми сталкиваются только крупнейшие компании. Сейчас большинство БД работает на виртуальных машинах в приватном облаке, однако в ближайшее время мы планируем запускать наши БД на Baremetal K8s для улучшения производительности.

Вот стек и конкретные задачи, которыми можно будет заняться прямо сейчас
Пишем на Python и Golang, c упором на надежность кода и полное покрытие тестами. Сейчас есть много продуктовых и технических целей как в части подключения Change Data Capturing в PostgreSQL, реализации Disaster Recovery Plan, так и в части управления конфигурациями, инфраструктуры, K8s и разработки Control Plane. Наша команда самостоятельно проектирует, декомпозирует, прототипирует и реализует такие задачи.

Немного про условия
Трудоустройство возможно как в РФ, так и в странах СНГ с Центрами Разработки Тинькофф.

Если вам хочется заниматься такими задачами, то напишите мне в личку (@apolomodov) и дальше я пообщаюсь с вами и познакомлю с коллегами.

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

Материалы из Code of Architecture про базы данных и распределенные системы

В продолжении поста хочу поделиться материалами из клуба Code of Architecture
- Design Data-Intensive Applications (вот плейлист)
- Database Internals - (вот статьи с краткими саммари каждого выпуска: 1, 2, 3 и 4)
- Distributed Systems, 4th Edition (вот статья с ссылками на все выпуски и кратким саммари)
- Обсуждение white paper "Amazon Aurora" (статья с саммари)

Ради интереса я попросил модель Сбера "Кандинский 2.2" нарисовать картинку к посту по описанию "База данных как сервис с логотипами postgres и cassandra" в стиле kandinsky и получилось забавно:)

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

Подкаст "Письма Лиды Таймовой". Выпуск №1: Оценивать или не оценивать

Интересный выпуск подкаста от ребят из Тинькофф про экзистенциальный вопрос про оценку задач:) Трое в лодке обсуждают варианты оценки в часах, сторипойнтих или варинат "no estimate". В выпуске участвуют ведущие: Виктор Шитов и Александр Вазюков, а также гость - Павел Ахметчанов. Все трое работают в Тинькофф и имеют прямое отношение к тюнингу процессов разработки, на основе данных:) Я спойлерить не буду, но отмечу, что как бы вы ни (не) оценивали задачи, вам полезно понимать границы применимости каждого из вариантов, а ребята в подкасте общаются именно про это.

#Software #Engineering #Processes #Project #Management

Улучшение процессов разработки программного обеспечения (Рубрика #Management)

Сегодня в 18.00 по Москве я закрываю трек по "Архитектуре, надежности и качеству" на IT пикнике в Москве с вышеуказанным докладом.
Расшифровку доклада можно уже почитать в статье, а ниже приведены материалы для более глубокого изучения.

4 основные книги, из которых родилась идея доклада
- The Phoenix Project (2013 год) - книга написана в жанре производственного романа и похожа на книгу "Цель" ("Goal") или "Критическая цепь" ("Critical Chain") Голдратта.
- The DevOps Handbook (2016 год) - книга с популяризацией devops подхода
- Accelerate (2018 год) - книга, где приводятся крутые выводы о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент.
- The Unicorn Project (2019 год) - эта книга написана Gene Kim как продолжение предыдущей книги Проект Феникс

Связанные книги
- Team Topologies - книга про Team-First подход при проектировании архитектуры программных систем, так и организации.
- Learning Domain Driven Design - эта книга содержит много рекомендаций о том, как бороться со сложностью при проектировании софта.
- A philosophy of sotfware design - книга посвященная борьбе со сложностью и тому, как практиковать стратегический подход к разработке.
- Making Work Visible - простая книга про улучшение процессов разработки с использованием kanban подходов
- SRE Book - крутая книга целиком посвященная тому, как делать надежные системы и строить процессы вокруг них
- "Lean Software Development" - книга про lean практики в разработке

Исследования и whitepapers на тему доклада
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)
- The SPACE of Developer Productivity - интересный фреймворк для оценивания продуктивности разработчиков (состоит из 5 составляющих: saatisfaction & well being, performance, activity, communication & collaboration, efficiency and flow)
- DevEx: What Actually Drives Productivity - продолжение предыдущего исследования, но теперь про опыт разработчика (feedback loops, cognitive load, flow state), который можно мерить по поведению системы и процессам, а также по восприятию разработчиков

Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
- Эволюция подходов к развитию мобильного банка Тинькофф
- Эволюция web Tinkoff на ArchDays

#Processes #Management #Architecture #Conference #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SoftwareArchitecture

Как развиваться, если ты уже Senior System Analyst

Завтра рассказываю этот доклад в 13:15 в онлайне на конференции Flow для системных аналитиков.
Рассказа будет посвящен карьерным трекам системных аналитиков. Ведь когда-то и они дорастают до ведущих и оказываются перед развилкой. Рассмотрим все варианты роста - от типовых до эзотерических:
-Становление лидером профессии аналитиков;
- Рост в тимлида в кросс-функциональной команде;
-Переход в технический продакт-менеджеры;
- Переход в архитектуру.

Завтра я опубликую расшифровку доклада, а потом через некоторое время появится и его запись:)

P.S.
Изначально я планировал выступить на оффлайн части конференции, но потом планы поменялись, так как в даты конференции я буду не в Москве.
Поэтому выступление перенеслось на 10 дней пораньше и сместилось в онлайн.

#Management #Career #Analyst #Software #SoftwareDevelopment