Книжный куб

Материалы к докладу на конференции Flow "Как развиваться, если ты уже Senior System Analyst" Расшифровка доклада уже доступна в моем блоге. Но так как у меня очень обширный доклад и я упоминаю много моментов, про которые рассказывал отдельные доклады, то я прикладываю ссылки на эти материалы - Доклад "'Канал. Продукт. Платформа' или эволюция подходов к развитию мобильного банка Тинькофф"  - Краткий обзор "Team topologies" в трех частях   - - Teams as means of Delivery - - Team Topologies that work for flow - - Evolving team interactions for innovation and rapid delivery - Статья "Про performance review в командах разработки" - Обзор white paper "DevEx: What Actually Drives Productivity"  - Доклад "Современные подходы к разработке программного обеспечения"  - Доклад "SOLID'ный тимлид, или основы менеджмента для технарей"  - Доклад "Как нанимать технических руководителей"  - Доклад "Как и куда развиваться, если ты уже Senior Software Engineer"  - Доклад "Варианты роста инженера, если он уже Senior"  - Доклады про system design interview  - - в общем про system design в Тинькофф  - - больше про то, как мы оцениваем прохождение собеседования  - - как подготовиться к собеседованию  - -пример на C++ Russia 2022 про проектирование ленты в сервисе видео - - пример на ArchDays 2022 про проектирование букинга номеров в отелях  - - пример на C++ Russia 2023 про проектирование умных парковок #Career #SystemDesign #Software #SoftwareArchitecture #Architecture #Engineering

Публичное интервью по troubleshooting для SRE-инженеров на Devoops Сегодня у меня целых два выступления на разных конференциях. Вечером будет публичное интервью по troubleshooting на Devoops, а днем я расскажу про пути развития senior аналитиков на Flow. Изначально я не планировал такой нагрузки, но выступление на Flow пришлось тоже подвинуть в онлайн:) Если же возвращаться к интервью на Devoops, то оно посвящено тому как выглядит одно из интервью для SRE инженеров. А выглядит оно как работа в рамках инцидента, где сценарий приблизительно таков: 1. По легенде кандидат и интервьюер работают совместно в SRE-команде. Кандидат исполняет роль Lead, а интервьюер — Junior. 2. Собственно, по той же легенде Lead уезжает на конференцию, а Junior остается дежурить. 3. Дальше происходит инцидент, который они вместе распутывают, так как junior сразу использует "звонок другу" и дальше под руководством лида пытается со всем справиться:) На публичном интервью я буду выступать в качестве интервьюера, а выступить в качестве собеседуемого согласился Салих Фахрутдинов - Senior SRE в Tinkoff Origination Platform. Спасибо Салиху и надеюсь, что у нас получится интересно:) #Engineering #SRE #Career #Interview #Processes #Postmortem #Management

Using Semantic Metadata to Create an Automated Microservice Data Mesh • Marty Pitt • YOW! 2022 Странное выступление от Marty Pitt, создателя Orbital, автоматизированной платформы для интеграции, а также языка taxi для описания семантики данных. Сначала автор рассказывал про то, что такое data mesh и для чего он нужен. Потом перешел к семантическим метаданным с использованием языка taxi и я сразу вспомнил семантический веб, RDF триплеты и язык SPARQL. А дальше разметив так данные автор пишет запросы аля graphql и дальше данные вытягиваются автоматически при помощи платформы Vyne. В общем и целом, концепция показалась мне приветом из прошлого, но под другим соусом. И все бы ничего, но я не уловил как эта магия будет масштабироваться и управляться за границами демо-примеров. P.S. Приложил слайды из презентации, которые демонстрируют идеи автора. #Data #Software #SoftwareArchitecture #Architecture #Engineering

Как развиваться, если ты уже Senior System Analyst Завтра рассказываю этот доклад в 13:15 в онлайне на конференции Flow для системных аналитиков. Рассказа будет посвящен карьерным трекам системных аналитиков. Ведь когда-то и они дорастают до ведущих и оказываются перед развилкой. Рассмотрим все варианты роста - от типовых до эзотерических: -Становление лидером профессии аналитиков; - Рост в тимлида в кросс-функциональной команде; -Переход в технический продакт-менеджеры; - Переход в архитектуру. Завтра я опубликую расшифровку доклада, а потом через некоторое время появится и его запись:) P.S. Изначально я планировал выступить на оффлайн части конференции, но потом планы поменялись, так как в даты конференции я буду не в Москве. Поэтому выступление перенеслось на 10 дней пораньше и сместилось в онлайн. #Management #Career #Analyst #Software #SoftwareDevelopment

Обзор white paper "DevEx: What Actually Drives Productivity" Меня достаточно сильно интересуют вопросы продуктивности процессов разработки программного обеспечения. Я читаю много статей на эту тему и сегодня я немного расскажу о white paper "DevEx: What Actually Drives Productivity", написанной в 2023 году в продолжении "The SPACE of Developer Productivity" 2021 года, о которой я рассказывал чуть ранее и если упрощать, то там они предложили отдельный фреймворк SPACE, который расширяет метрики DORA. В новой же статье пойдет речь про фреймворк DevEx, который поможет вам измерить опыт разработчиков, который напрямую влияет на эффективность их работы:) Подробнее в моем блоге. P.S. Для затравки приложил основную инфографику, что я нарисовал для обобщения мыслей из white paper. #Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

Улучшение процессов разработки программного обеспечения Сегодня в 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

Руководство фасилитатора (Facilitator’s Guide to Participatory Decision-Making) Я прочитал эту книга Сэма Кейнера 7 лет назад, когда слово фасилитация еще не стало таким популярным:) Начать описание книги стоит с того, чтобы рассказать кто же собственно такой фасилитатор, который упоминается в названии книги. Это человек, который своими действиями помогает группе поддерживать конструктивный диалог и прийти к решениям проблем, затрагивающих группу. Фактически, фасилитатор - это катализатор группового общения. Теперь собственно о книге. Она довольно хороша как практическое пособие для начинающего/продолжающего фасилитатора. Выполнена в форме справочника групповых упражнений и готова к применению на практике. Но вот читать эту книгу последовательно слишком скучно. Видимо для вдумчивого диалога с книгой тоже требуется помощь фасилитатора:) Сеемь лет назад я решил, что книга больше расчитана на фасилитаторов фасилитирующих фасилитируемые форумы фасилитаторов:) Но теперь я думаю, что многие вещи оттуда полезно знать для более эффективного проведения встреч:) #Management #PublicSpeaking #Leadership #SelfDevelopment

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

Обзор книги "Лидеры продукта" ("Product Leadership") Прочитал эту книгу про product leadership в надежде лучше понять специфику работы product manager. Это сделать получилось, но ощущения от книги оказались смешанными: + авторы сделали хорошую структуру разделов в книге (про это поже) + опросили кучу людей, что исполняют похожую роль  - засунули кусочки из этих 100 интервью в каждую главу так, что есть ощущение, что жуешь ассорти, в котором нет общей структуры, а есть как яркие мысли, так и проходной порожняк от младшего помощника старшего менеджера по UX-дизайну продукта микроскопической компании  - последняя часть посвящена работе с аутсорс-компаниями, которую пропагандируют авторы, которые работают в аутсорс-компаниях. И их не смущает конфликт интересов:) Подробнее прочитать про книгу можно в моей статье #ProductManagement #Management #Leadership #Software

Материалы из Code of Architecture про базы данных и распределенные системы В продолжении поста хочу поделиться материалами из клуба Code of Architecture - Design Data-Intensive Applications (вот плейлист) - Database Internals - (вот статьи с краткими саммари каждого выпуска: 1, 2, 3 и 4) - Distributed Systems, 4th Edition (вотDab статья с ссылками на все выпуски и кратким саммари) Ради интереса я попросил модель Сбера "Кандинский 2.2" нарисовать картинку к посту по описанию "База данных как сервис с логотипами postgres и cassandra" в стиле kandinsky и получилось забавно:) #Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

Вакансии в наши команды 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

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

Вдохновленные (Inspired) Я прочитал эту книгу Марти Кагана пару лет назад, когда хотел чуток больше узнать про product management, так как эта книга целиком посвященную продуктовой культуре в общем и продакт-менеджменту в частности. Книга мне понравилась, но она больше напоминает ряд отдельных эссе, которые автор постфактум скомпоновал по темам: - Уроки лучших компаний - Правильные люди - Правильный продукт - Правильный процесс - Культура (странно, что без прилагательного "правильная") На самом деле книга так и собралась из кучи статей автора из его блога, поэтому на 350 страниц получилось 5 частей и 67 глав:) Из интересного мне зашла история про проблемы с дорожными картами - я их сам часто использую и интересно было почитать что с ними бывает не так. Суть в том, что если фиксировать в roadmaps конкретные эпики или задачи, то так сужается гибкость в работе команд. Лучше указывать какие результаты ожидаются по результатам этих активностей и насколько должны поменяться целевые метрики. Интересно, что мои технические roadmaps часто были про изменение инженерных практик команды, изменения архитектуры приложений или масштабного рефакторинга, а не просто какой-то набор эпиков, что неплохо укладывается в рекомендации автора. Также интересно было почитать про важность наличия в команде delivery manager, который был переведен как операционный менеджер с техническими навыками, правда, в самой главе переводчики сделали ремарку, что в России это называется проджект менеджером, что явно не так:) Интересно было почитать про роль директора по технологиям или CTO:) Чисто в силу того, что сейчас я выполняю эту роль. Неплохо было расписано про дизайн-спринт или как автор его назвал спринт на этапе исследования продукта, так как по мнению автора в этом спринте решаются не только вопросы дизайна. А вообще в книге очень много крутой информации, поэтому я рекомендую с ней ознакомиться не только продакт-менеджерам, но и всем участникам продуктовых команд разработки. #ProductManagement #Management #Leadership #Software

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 #DistirbutedSystems #Management #Leadership #Engineering

Проектируем надежные системы - стоит ли игра свечь Выступаю в середине сентября на конференции "Стачка" с докладом про проектирование надежных систем, в котором попробую задать и ответить на следующие вопросы - надо ли нам думать о надежности нашей системы и от чего это зависит - как оценить надежность существующей системы - почему надежность сложно добавить в существующую систему - какие существуют принципы для проектирования надежных систем - как выстроить процессы для ее достижения Если внезапно окажитесь в Ульяновске в это время, то заходите послушать этот доклад:) #Architect #Architecture #Software #SoftwareDevelopment #SoftwareArchitecture #Conference

Мой опыт в качестве тимлида В продолжение прошлого поста расскажу немного про свой опыт тимлидства: - В первый раз я стал тимлидом лет десять назад, когда работал над сайтом 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

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

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

Техлиды и архитекторы Осенью 2020 года на ArchDays я рассказывал как мы в Тинькофф принимаем архитектурные решения. С тех пор прошло много времени и теперь точно можно сказать, что мы действительно пишем архитектурные документы для крупных решений и обсуждаем их заранее. А результаты обсуждения обычно фиксируются в некотором логе архитектурных решений. У каждого крупного подразделения есть собственный процесс ведения такой документации, который похож в общем, но может отличатьтся деталями. Обычно самыми активными на ниве создания, проработки и ревью такой архитектурной документации являются инженеры высоких грейдов. У таких инженеров есть несколько ярко выраженных архетипов, среди которых я хотел сегодня поговорить про техлидов и архитекторов. Эти архетипы неплохо расписаны в книге "Staff Engineer" Вила Ларсона (вот тут мое краткое саммари книги). Но если говорить про эти архетипы своими словами, то - Техлиды обычно работают в рамках одного домена с одним менеджером и одной-двумя командами. В Тинькофф такие ребята помогают улучшать инженерные метрики сервисов, за которые отвечает команда (MTTR, уровень автоматизации тестирования и деплоев, показатели SLA сервисов и так далее). - Архитекторы обычно работают вне рамок одной команды и помогают драйвить архитектурные процессы и сложные кросс-командные проекты. В Тинькофф это может быть создание нового продукта, сложная миграция, перепроектирование старого продукта с учетом требований регуляторов и compliance. Обычно в оба эти архетипа вырастают инженеры, которые прошли огонь, воду и медные трубы и доросли в итоге до Senior уровня. А дальше в какой-то момент они поняли, что им хочется больше сложности и больше влияния на результат и ради этого они готовы брать на себя больше ответственности. В этот момент у них обычно есть возможность попробовать себя в одной из этих двух ролей, а дальше после пары лет успешной работы можно номинироваться на следующий уровень в виде Staff Engineer, который в Тинькофф тоже есть:) Кстати, в ветку архитекторов есть тропинка и через ветку системных аналитиков, но этот путь пока экспериментальный и пока содержит следующие шаги - Подготовка заявки с архитектурными артефактами, которые были выполнены в рамках рабочих обязанностей (примерно как я рассказывал в этом докладе в части про процесс Т-Роста) - Прохождение двух интервью: system design interview и интервью про архитектуру и процессы разработки, где мы обсуждаем как выглядят современные процессы разработки, как выстраивать архитектурные процессы в подразделении, а также как вести крупные проекты в роли архитектора #Engineering #Management #Software #SoftwareArchitecture #Architecture #Architect

Кто такие Technical Product Manager, зачем они компаниям и как им взаимодействовать со стейкхолдерами? Интересная статья про технических менеджеров продуктов, которые есть в некоторых компаниях (в Тинькофф они тоже есть). По-факту, такие технические продакт-менеджеры делают внутренний платформенный продукт, у которого пользователями являются инженеры внутри, которые не всегда любят делиться своими проблемами, используя мантру "я могу решить любую проблему". В итоге, такой продакт менеджер должен уметь классно общаться с технарями, чтобы понять как сделать продукт, который им действительно поможет. В этой статье приводятся метрики таких платформенных продуктов: - как они влияют на time to market продуктовых команд (платформы должны помогать сократить ttm) - dimension cost или ограничение по стоимости продукта (если строить платформу слишком дорого, то это не ок) - net promoter score (насколько инженеры довольны своей работой на платформе, по этому показателю можно оценить developer experience) Дальше рассматривается вопрос о том, как на этой роли взаимодействовать со стейкхолдерами и доносить пользу от своих продуктов - часто признание находит только продуктовые команды, а создатели внутренних платформ часто оказываются крайними в случае проблем и невидимками в случае успехов:) В итоге, надо уметь разжевывать технические детали нетехническим стейкхолдерам и вклад своих команд в общий результат. #Management #Leadership #ProductManagement