#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

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

Этим постом я заканчивую рассказ про выступление Manuel Pais, со-автора книги "Team Topologies". В прошлом посте я начинал обзор этого рассказа про инсайт из практического применения топологии команд.

7. Автор затрагивает неконсистентный опыт пользователей. В качестве кейса приводится история BBC (ее тоже не на сайте). Здесь суть была в том, что у BBC было много продуктов, каждый из которых имел свой особенный интерфейс и это не очень нравилось пользователям:) В итоге, BBC просто выделили стандартные фронтовые компоненты, но и сделали большой реорг, что они описывали у себя на Medium. В итоге, автор выделяет следующие
- Принцип: optimize for innovation & speed when those are needed, allow "eventual consistency" and standartization to emerge later
- Practice: Collaborate, facilitate, x-as-a-service. Платформенным командам важно правильно выбирать тип взаимодействия
8. Автор переходит к медленному time-to-market. Рассматривается пример SAP, у которого сложности со скоростью из-за соблюдения требований законодательства и обеспечения безопасности (и наверное не только из-за этого). В итоге, ребята занялись внутренней платформой для упрощения работы команд разработчиков. Платформа рассматривалась как продукт, ориентированный на группы команд, страдающих от сложных процессов соответствия требованиям и безопасности.
- Принцип: turn blocking dependencies into unblocking ("dependency inversion" for teams)
- Practice: Product management in platform. Подробнее про это можно прочитать в моем разборе CNCF Platform White Paper: 1, 2 и 3
9. Автор переходит к работе с тезисом "we can't do that in my organization". Это кейс GfK/NIQ. У ребят аля SAFE и все команды заняты продуктовой разработкой. Они придумали, что каждый пятый спринт будут работать над платформенными задачами
- Принцип: "behaviors over structures". don't wait for the ideal org / process / scale
- Practice: Thinnest viable platform. Можно начать с максимально тонкой платформы, что уже приносит пользу организации
10. Топология команд рассматривается как социально-технический подход для увеличения потока и повышения удовлетворенности. Организации могут применять идеи топологии команд в разных сферах бизнеса, адаптируя их под свои нужды. Важно иметь видение и понимать принципы топологии команд. Примеры выше показывают, как можно адаптировать идеи и принципы для текущей ситуации. Сообщество вокруг топологии команд активно и заинтересовано, и есть множество ресурсов для изучения и применения этих идей.

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

Опрос, который изменил опросы (Рубрика #Math)

Интересная научная статья о почтовом опросе 1936 года, проведенного крупной и уважаемой газетой "The Literary Digest" среди своих двух миллионов подписчиков. Данный опрос был проведен перед очередными выборами президента США и подписчики просто должны были выбрать кандидата, которого они будут поддерживать на выборах. Результаты опроса предсказывали уверенную победу республиканского кандидата, а реальность выдала противоположный результат - а именно победу демократа с полуторным преимуществом. Такое расхождение в прогнозе и фактах в итоге привело к закрытию газеты, а причина была всего лишь в том, что журнал не принимал во внимание факт того, что на точность прогноза критически влияет репрезентативность выборки из генеральной совокупности:)) А если по простому, то для получения правдоподобных результатов надо правильно формировать множество тех, кто будет проходить опрос.

P.S.
После таких историй почему-то вспоминается крылатая фраза

Есть три вида лжи: ложь, наглая ложь и статистика.

которую больше 100 лет назад Марк Твен приписал премьер-министру Великобритании Бенджамину Дизраэли.

#Math #Data #Statistics

Code of Leadership #22 - Интервью с Дмитрием Аношиным про data engineering (Рубрика #Data)

В этом выпуске ко мне пришел в гости крутой гость, Дмитрий Аношин. Дима является экспертом в data engineering, ведет канал @rockyourdata, также Дима почти 10 лет работал западных Bigtech компаниях. Кстати, выпуск доступен в виде подкаста и в Яндекс Музыке.

Мы обсудили следующие темы:
- Как Дима входил в IT порядка 15 лет назад
- Как он развивал свои навыки как дата инженер
- Как он уехал в Канаду и адаптировался там
- Как развивалась карьера Димы в Amazon, Microsoft и что он вынес из этого опыта
- Как Дима стал создателем обучающих проектов datalearn, surfalytics, а также как ему удалось написать целую гору книг
- Как находить мотивацию для роста и развития

Если говорить подробнее про Дмитрия, то он уже больше 15 лет занимается аналитикой и инжинирингом данных, а 10 последних лет проработал в Северной Америке. Из них 5 лет в Амазоне, где работал в нескольких командах, включая Alexa AI (в Бостоне) и Customer Behaviour Analytics (в Сиэтле). Поучаствовал в действительно инновационных проектах, где драйвером являются данные. Видел и Big Data и Machine Learning в действии в масштабе крупнейшей компании мира. После Амазона работал 4 года в Microsoft Xbox и Microsoft Azure Data&AI. Активно принимал участие в развитии Microsoft продуктов для аналитики - Synapse, Fabric, Azure Databricks.

Теперь, Дмитрий помогает создавать инновационные аналитические решения, дата команды и модернизировать устаревшие решения через свою компанию rockyourdata.cloud и глобально готовит инженеров и аналитиков через свое сообщество Surfalytics.com (на английском), до этого несколько лет развивал проект Datalearn.ru, на котором делился фундаментальными знаниями и помогал бесплатно всем желающим войти в ИТ, знания там все еще актуальны.

Дмитрий написал несколько книг по аналитике и преподает несколько лет Облачные Вычисления (Cloud Computing) в партнерстве с Microsoft в Университете Виктории.

Еще из интересных проектов:
- Создал онлайн выставку писем CEO про увольнения в крупных компаниях - https://www.layoffmemos.com/
- Совместно с Московским Зоопарком и Вконтакте организовал группу по наблюдению за популяцией пеликанов и экомониторинга с использованием AI - https://www.scifly.ai/

Из последнего, Дмитрий создает главный Российский портал Дата Инженеръ посвященный карьере дата инженера, куда он планирует добавить road map для вакансий Инженера Данных, Аналитика и BI разработчика и ссылки на лучшие бесплатные ресурсы: книги, тренинги, курсы, видео, телеграмм каналы, и многое друго, что поможет понять, кто такой иженер данных и как таким стать, преимущественно на русском языке.

#Database #Architecure #Software #Data #SystemDesign #Management