0b1000 в Т-Банке

Сегодня у меня юбилей в Т-Банке, 8 лет:) Именно столько лет назад я пришел в тогда еще Тинькофф. Я пришел из Банки.ру, где был лидом команды разработки, что отвечала за рейтинги банков, страховых и остальной UGC (user generated content), а также лидогенерящие странички:) В Тинькофф я вышел на позицию engineering manager заниматься проектами привлечения. Планы на старте были наполеоновскими и они действительно драйвили меня. Это был период роста и моя зона ответственности постоянно менялась. Я чувствовал себя не просто engineering менеджером, а скорее менеджером непрерывных изменений с девизом "пересобери себя и свою команду или умри"... Но как только я справлялся с новым вызовом, то получал следующий. Это происходило примерно каждые полтора-два года. Про многие из этих изменений я рассказывал на YaTalks в прошлом году и в расшифровке этого выступления. С тех пор я собрал у себя dream team из руководителей, которые отвечают за отдельные большие подразделения в 200-300 человек
- Клиентские интерфейсы: платформенные команды веба, мобилы и API
- Маркетинговые технологии: внешняя реклама, маркетинговая платформа
- Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры
- Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье

А еще у меня в подразделении есть важный для меня продукт в виде продуктовой аналитика и a/b платформы. Это важно для компании для того, чтобы быть data-driven, а для меня - это возможность закрыть гештальт относительно математики (теорвер, матстатистика), которая мне нравилась всю дорогу от лицея до физтеха и дальше:) Также я отвечаю за архитектуру как функцию в компании. Это мне близко как технарю, для которого важна engineering excellence и design крутых систем.

Напоследок, я хотел сказать спасибо ребятам из моего юнита "Клиентские интерфейсы, маркетинг и вовлечение". Ребята и делают всю работу, которая приносит радость нашим клиентам, деньги компании, а мне позволяет рассказывать об этом. Кстати, с частью ребят я записывал интервью
- Про архитектуру с моим замом, Антоном Костериным. Антон руководит архитектурной группой при мне
- Про про системных аналитиков с Кириллом Крайневым. Кирилл руководит маркетинговыми технологиями, а также драйвит развитие профессии системных аналитиков
- Про Staff+ инженеров, архитектуру и SDLC с Алексеем Тарасовым. Алексей руководит соц-медиа платформой, а также драйвит наши system design interview и помогает развивать направление staff+ для инженеров
- Про систему для продуктовой аналитики (Statist) с Андреем Цыбиным. Андрей руководит продуктовой аналитикой и a/b платформой.

Думаю, что мы не будем останавливаться на этом и будем делать все более крутой продукт, а также рассказывать о том, как мы это делаем:)

P.S.
В общем, 8 лет - это большой срок, который можно и отметить. Особенно с учетом того, что я не уверен в том, что "доживу" до следующего круглого юбилея в двоичной системе:)

#Management #SelfDevelopment #Engineering #Processes #Software

Моя жена, Анастасия, сейчас заканчивает магистратуру "Психоанализ и психоаналитическое бизнес-консультирование" в Вышке. И в рамках дипломной работы она с коллегами проводит исследование, посвященное формированию и развитию новой профессиональной идентичности. Если вы являетесь продакт-менеджером или планируете им стать, то вы можете принять участие в психаналитической группе "Как занять свое место в профессии". Подробности в крутом канале Насти (на который вы можете подписаться)

#SelfDevelopment

#psy
Мы с группой коллег проводим исследование, посвященное
формированию и развитию новой профессиональной идентичности.
Для практической части мы выбрали профессии, связанные с управлением продуктом.
Если вы недавно перешли в такую профессию, находитесь в процессе перехода или планируете его, приглашаю принять участие в нашей психаналитической группе "Как занять свое место в профессии".

Примеры вопросов, которые могут возникать:
- Вокруг все говорят, что ты product manager, а сам ты про себя так не говоришь/не можешь сказать кто ты;
- Хочешь стать product manager, но не дают\не получается (по разным причинам);
- Уже работаешь в управлении продуктом, но не можешь понять, кто ты такой в своей текущей роли на работе

На группе вы сможете в окружении людей со схожим запросом поисследовать свое состояние и внутренние процессы, поделиться своими чувствами, поискать опору для движения вперед.

Состав группы - 12-15 человек
Длительность встречи - 2 часа
Встречи будут онлайн по субботам, 6 встреч, 1 раз в неделю.

Перед стартом группы будет проведена индивидуальная встреча с одним из консультантов (1 час) для знакомства с методом и друг с другом.

Вся информация строго конфиденциальна и будет обезличена в рамках исследования.

Если вам интересно, пишите в лс

Менторинг сессия на канале SouthHub (Рубрика #Management)

Во вторник вечером я проводил менторинг сессию, запись которой доступна на Youtube. Моим менти был Антон Числов, технический директор МТС Авто. Запрос был на меторинг по теме как осуществлять крупные изменения в больших компаниях. Суть в том, что у ребят на носу 2 больших изменения
1) Переход от разработки по компонентам к stream-aligned командам
2) Переезд из MTS Digital в отдельную компанию внутри экосистемы

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

#Management #Leadership #Processes #Software

Законы простоты (The Laws of Simplicity) (Рубрика #Design)

На днях я прочитал книгу Джона Маэды о законах простоты. Сам Джон является выдающимся американским дизайнером, ученым и педагогом, который известный своими работами на стыке бизнеса, дизайна и технологий. Сейчас он работает вице-президентом по дизайну и искусственному интеллекту в Microsoft. Интересно, что это уже вторая книга этого автора, которая мне понравилась, первой была "ReDesisning Leadership" ("Редизайн лидерства"), о которой я уже писал в канале. Если же возвращаться к самой книге о законах простоты, то интересно, что он написал ее почти 20 лет назад, еще до выхода айфонов на рынок. Тогда она стала бестселлером, но дизайнеры с тех пор двигаются скорее в сторону сложности:)

Джон предложил использовать следующий список законов для нахождения баланса между сложностью и простотой в различных аспектах жизни и работы, делая системы более интуитивными и эффективными
1. Сокращение (Reduce) — Самый простой способ достичь простоты — это осознанное сокращение. Убирайте лишнее, но будьте осторожны, чтобы не убрать что-то важное.
2. Организация (Organize) — Организация помогает сделать систему с множеством элементов более понятной и управляемой. Правильная структура делает сложное проще.
3. Время (Time) — Экономия времени создает ощущение простоты. Чем меньше времени требуется на выполнение задачи, тем проще она воспринимается.
4. Обучение (Learn) — Знания упрощают все. Чем больше вы знаете о системе или процессе, тем легче с ними работать.
5. Различия (Differences) — Простота и сложность взаимосвязаны. Чтобы оценить простоту, необходимо иметь возможность сравнивать ее с чем-то более сложным.
6. Контекст (Context) — То, что находится на периферии простоты, не является незначительным. Контекст важен для понимания и восприятия системы.
7. Эмоции (Emotion) — Больше эмоций лучше, чем меньше. Эмоциональная связь с продуктом или системой делает их более привлекательными и понятными.
8. Доверие (Trust) — Простота требует доверия. Пользователи должны доверять системе, чтобы она казалась простой в использовании.
9. Неудача (Failure) — Некоторые вещи невозможно упростить. Не все попытки создать простоту будут успешными, но важно учиться на ошибках.
10. Единое (The One) — Простота заключается в вычитании очевидного и добавлении значимого. Это объединяющий принцип всех предыдущих законов.

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

#Design #Leadership #Management #SelfDevelopment #Processes

Зачем измерять developer productivity в крупной компании? И как это делать правильно? (Рубрика #Management)

Сегодня я выступаю онлайн на конференции D-Day, что оффлайн проводится в Тирасполе. Я уже выступал на этой конференции 5 лет назад, но тогда это было очно:) В этот раз я решил рассказать про тему developer productivity, начать с того, а зачем ее мерить и дальше рассказать как, а напоследок поделиться тем, как это принято делать у нас в компании. По традиции в день доклада я публикую список материалов по теме, которые позволят изучить тему сильно глубже, чем я успею рассказать за 25 минут

1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции
2) Обзор книги канонической книги "Accelerate" в трех частях:
-- Общая информация по книге, формат исследования и DORA метрики
-- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки
-- Менеджерские и лидерские практики
3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным
4) Разбор темы developer productivity в фреймворках SPACE, DevEx
5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов
6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach)
7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach)
8) Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Comic Agile - Team Topologies (Рубрика #Humor)

В эти выходные я смотрел лекцию Manuel Pais, со-автора книги "Team Topologies", на конференции GoTo. В самом начале своего выступления он ссылается на этот комикс "Comic Agile". На этом ресурсе много забавных комиксов, включая тот, что про Team Topologies. В общем, рекомендую, если вам тоже нравится с юмором подходить к менеджменту:)

#Humor #Management #Leadership #Processes #Software

ЦЕХ 4 - Урок #22 "Взаимодействие с обозревателями, критиками и СМИ. Эксперт — Екатерина Северина" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела PR-менеджер, драматург и книжный обозреватель. Из этого урока я вынес следующие моменты

1) Успеху книги может способствовать личный бренд, который можно повышать за счет работы со СМИ. Это помогает и в плане SEO (по вашему имени находится релевантная информация в поисковиках)
2) СМИ тоже выгодно работать с авторами - это помогает им закрыть контентный голод и получить эксклюзивный материал, а также сэкономить силы штатных журналистов
3) Важно понимать какие СМИ интересны вашей аудитории и взаимодействовать с ними. Тут пригодится анализ публикаций СМИ и их целевой аудитории (часто у СМИ есть медиакиты для рекломадателей, где эти вещи базово описаны)
4) Для анализа СМИ можно почитать и их соцсети и комментарии читателей в них
5) СМИ выстроены в пирамиду: массовые СМИ ориентированы на новичков и не погружаются в глубокие темы, тематические СМИ, такие как "Мир фантастики", предлагают материалы для профессионалов, профи и эксперты в тематических СМИ готовы платить за качественный продукт и не совершают поверхностных суждений.
6) Профи и эксперты в тематических СМИ интересуются не только книгами, но и функционированием индустрии.
7) Также можно сотрудничать с книжными обозревателями и блоггерами - это помогает запустить сарафанное радио и литературный нетворкинг.
8) В общем, для того, чтобы эффективно работать со всеми этими людьми нужна база контактов, которая должна быть рабочей, приносить результат, динамичной и актуальной.
9) Основные элементы записи в базе контактов: фамилия, имя, СМИ, адрес, электронная почта, tg-канал.
10) Важно анализировать эффективность коммуникаций через свою базу и адаптировать подходы в зависимости от результатов (в уроке приводилось куча примеров как писать правильные письма и сообщения)
11) Вообще, есть целая пачка книжных материалов, что автор может предложить СМИ/обозревателям/блоггерам
- Обзор: краткое описание новых книг для привлечения читателей.
- Рецензия: критический анализ и оценка произведений.
- Препринт: отрывок из книги до её выхода.
- Тематическая подборка: рекомендации книг по темам.
- Интервью: редко встречаются, требуют весомого литературного капитала.
- Новости: большие материалы о значимых событиях, таких как смерть автора.

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Insights on How Team Topologies Drive Organizational Success - Manuel Pais - GOTO 2024 - Part I (Рубрика #Management)

Интересное выступление Manuel Pais, со-автора книги "Team Topologies", в котором он делится инсайтами из практического применения топологии команд. Для меня это видео супер-интересно, так как я давно сделал краткий обзор этой книги в трех частях
- Teams as means of Delivery
- Team Topologies that work for flow
- Evolving team interactions for innovation and rapid delivery
А потом еще записал и первый эпизод подкаста "Code of Leadership" вместе со Станиславом Халупом.

Это же выступление Manuel Pais содержит следующие интересные моменты
1. Ни один подход не решает все проблемы сразу, это относится и к топологии команд
2. Комикс Comic Agile забавно рассказывает про Team Topologies, но не слишком правильно (по мнению автора):)
3. Team topologies - это социо-технический подход для улучшения flow и hapiness. Быстрый flow требует большей автономии и четкой цели.
4. Крупные организации задаются вопросами: как расти устойчиво, как становится высоко-производительными, как вовлекать сотрудников
5. Автор разбирает проблему медленного delivery из-за высокой связности команд. В качестве case study приводится пример JP Morgan, где автор решали это через business aligned value streams. Для этого пришлось разобраться с природой зависимостей, сделать команды кросс-функциональными и улучшить коммуникации между ними. На выходе у ребят получилось уменьшить на 60% зависимости между командами. Вообще, публичные case studies доступны на сайте teamtopologies.com, но кейса JP Morgan в публичном доступе нет. Отсюда автор выводит
- Принцип: decouple teams by decoupling their streams/products ("decoupling responsibilities")
- Practice: Independent service heuristics (ISH). Суть в том, чтобы выделить independently-viable services. Начать можно с вопроса, а может ли такой кандидат в стримы работать как отдельный SaaS продукт в облаке
6. Автор переходит к отсутствию бизнес гибкости из-за организационных трений (org frictions). Здесь в качестве кейса приводится история Telenet (его тоже не на сайте). В этом кейсе для любой фичи требовалось участие огромного количества команд. Это замедляло любые изменения до предела. На выходе автор опять приводит
- Принцип: "minimize structural complexity" through grouping closely related streams of value
- Practice: Team (Tribe) interaction modeling. Надо идентифицировать и совместно стратегировать относительно командной структуры, которая сможет эволюционировать в дальнейшем

Продолжение обзора в следующем посте.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes