🎙 Метрики, или как не начать измерять фигню

Слушал вчера подкаст Бреслава и Ложечкина про метрики инженерного процесса — и прям захотелось немножко побомбить. Потому что, кажется, эта тема волнует всех, кто когда-либо пытался сделать что-то не только руками, но и головой.

Во-первых, сами ведущие в этот раз встретились впервые вживую, в Лондоне, так что выпуск получился необычный. А во-вторых — он очень жизненный. Потому что с метриками всё, как обычно: все их ненавидят, но без них никуда. И пока команда маленькая — можно как-то «на глаз», поговорить, почувствовать. А потом вдруг становится 50 человек, 100 — и всё, без линейки ни шагу. Только вот линейка-то не всегда про то.

Вот лично я тоже не раз видел, как всё идёт по кривой дорожке. Метрика, которая вроде бы «для наблюдения» — превращается в KPI. И всё. Дальше магия: люди перестают работать для результата и начинают работать на цифру. Потому что премия, потому что оклад, потому что «управление по целям» (ха-ха).

А потом вдруг оказывается, что:
— трекаем часы на задачу в продуктовой разработке (ну серьёзно?);
— velocity в Story Points стал чуть ли не KPI команды (а потом удивляемся, почему оно не работает);
— количество строк кода или коммитов обсуждается как метрика продуктивности.

И ты уже не бизнес решаешь, а выживаешь в отчётности. Причём выживаешь вопреки, а не благодаря.

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

Один из классных пойнтов — метрики можно собирать, но не говорить, что именно ты меряешь. А потом аккуратно смотришь: где у тебя зеленое, где красное. Но не говоришь, пока сам не поймешь, что с этим делать. Иначе — всё, начинается царь горы.

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

Мой итог? Метрики — это хорошо. Но только если ты помнишь, что метрика — это не цель. А способ понять, как ты по дороге ползёшь. Иначе, как говорят ребята: «лучше вообще не мерить, чем делать вид, что ты что-то правильно измеряешь».

Конспект тут

Полезняшка от Андрея Буракова про репликацию и партиционирование

Репликация и партиционирование

Лайтовое введение в репликацию и партиционирование данных в БД для тех, кому лень читать кабанчика. Полезно вдумчиво изучить с точки зрения проектирования распределенных систем в целом, даже если вы ВНЕЗАПНО сами не разрабатываете хранилища.

Репликация
• Часть 1 - синк/асинк репликации, лидер-фоловер
• Часть 2 - проблемы чтения и консистентности, разрешение конфликтов, мультилидеры
• Часть 3 - схемы без лидеров

Партиционирование - проблемы, использование ключей, ребалансировка

#архитектура

Ребята, у меня очередная полезняшка.
Мой хороший знакомый ищет себе в команду толкового технического СА. В Европе!!!
Как видите, я посрамлен, и в Европе нужны СА, так что не пропустите, владелец конторы реально очень адекватный и толковый, можно много чему научиться у него и команды. Дальше текст от него:

Middle+/Senior системный аналитик на проект микрокредитования (мобильный фронт, миддл, бэк)

Прямо сейчас ищем аналитика в команду, которая уже год делает живой проект - мобильное приложение для микрозаймов. Продолжительность - долгосрочная, команда сильная, клиент активный, процессы выстроены. Работаем напрямую, без посредников.

Технологии и стек, с которыми точно столкнётесь:

* микросервисная архитектура, REST, SOAP
* Kafka, RabbitMQ
* HTTP, JSON, XML
* PostgreSQL
* Keycloak
* системы логирования (Java-бэкенд)
* JIRA, Confluence

Будет плюсом:

* понимание UML (sequence, component)
* базовое понимание Java, JS, HTML
* уверенное владение SQL для верификации и редактирования данных

Формат:

* B2B-контракт (обязателен счёт и налоговое резидентство за пределами РФ: Беларусь, Грузия и др.)
* Полная удалёнка
* Обязательное окно доступности: с 14 до 22 по CET
* В команде есть project manager, автотесты на фронте и бэке, адекватный менеджмент, без микроменеджмента

Что делаем:

* расширяем и документируем функциональность
* проектируем микросервисы
* формируем требования
* общаемся с заказчиком (на русском)
* проект живой, в проде, первые релизы уже работают

Пишите в личку @selftomate или передайте знакомым.

Ну что ж, народ проголосовал — начнем с продуктового менеджмента.

Давайте начнем с постановки вопроса. Если вы когда-нибудь искали курсы или статьи по теме продакт-менеджмента, то в 90% случаев это будет история про B2C: как делать простенькие приложения, как валидировать гипотезы, считать объем рынка, проводить глубинные интервью и прочее в том же духе.

И всё вроде бы хорошо — до тех пор, пока ты не оказываешься в большой организации.
Там внезапно выясняется, что у тебя не маленький продукт, а огромный ландшафт. Несколько команд, куча зависимостей, внутренняя платформа, десятки или даже сотни людей. Пример — мобильное приложение банка. Нет, его не делает одна команда. Там каждая фича — это отдельная команда. А сами приложения часто делятся на разные сегменты и рынки.

И вот про такой продуктовый менеджмент — внутренний, платформенный, корпоративный — почти никто не пишет. Ни в статьях, ни в курсах. А жаль.

Очень часто вижу, как B2C-подходы натягивают на B2B-продукты внутри компании. Но ведь у внутренних платформ нет "объема рынка". Глубинные интервью — это разговоры с соседними командами. И вроде бы всё это должно скатиться в бизнес-анализ… но нет. Это всё равно продуктовая работа: бюджетирование, приоритизация, roadmaps, рост и масштабирование.

У меня здесь всегда было много вопросов:
— А какие метрики у платформенного продукта?
— Насколько продакт должен быть технарём?
— Где грань между аналитиком, архитектором и продактом?
— Что отличает technical product manager от “обычного”?

Вот об этом — о платформенных продуктах и техническом продакт-менеджменте — и будет серия моих следующих постов.

Если вы работаете в такой роли (или хотите туда попасть) — давайте обсудим.
Пишите в комментарии: что работает, что не работает, какие проблемы и инсайты вы видите в этих ролях. Очень интересно сравнить опыт.

👋 Всем доброго дня!

Иногда я читаю небольшие каналы — потому что их авторы не связаны требованиями "заходит/не заходит", и могут говорить честно и по делу. И вот один из таких подписчиков недавно написал пост про совмещение — мол, работает сразу в нескольких компаниях.

Захотелось тоже поделиться своими мыслями и опытом.

🧠 Я тоже совмещал.
Больше 4 лет я параллельно с основной работой преподавал и вел курс в OTUS. Причём не просто преподавал, а руководил направлением — что иногда съедало по 10–20 часов в неделю.
Плюс, конечно, этот канал, постоянное чтение, анализ и производство контента — это тоже труд и нагрузка, хоть и другого типа.

💬 Что я думаю о совмещении?
Если у тебя есть желание, энергия и возможность — никто не вправе тебе запрещать совмещать.
Да, это ответственность. Да, надо следить, чтобы не страдала основная работа. Но давайте честно:
Никто не работает 8 часов в день "у станка", без перерывов, прокрастинации, мыслей в сторону. У всех бывают окошки, когда можно сделать что-то ещё.

🎯 Главное — чтобы совмещение не било по двум вещам:

По качеству основной работы

По твоему здоровью и ресурсу

Если эти условия соблюдаются — я абсолютно "за".

🧱 Знаю, например, одного молодого специалиста, который на ИП совмещал сразу несколько проектов и к 23 годам заработал себе на квартиру в Москве. Без помощи родителей.
Вот это результат.
У меня в этом смысле скромнее, и энергии уже не та 😄 Но если она у вас есть — не вижу причин отказываться.

Так что если вам удается находить баланс и при этом вы не выгораете — совмещать можно. И иногда — даже нужно.

А вы как относитесь к совмещению? Был у вас такой опыт?

🎯 О доверии, менеджменте и людях

Мы вроде как собирались качать тему технического и платформенного продакт-менеджмента (и да, к ней я вернусь), но сегодня хочу немного в сторону. В сторону доверия. В сторону людей.

На днях читал книгу «Дело не в кофе» — это Говард Бехар, бывший президент Starbucks, человек, который много говорит про культуру, доверие и лидерство. И я понял, что хочу поговорить про это с вами.

🧠 Про осознанность и цели
Если убрать корпоративную шелуху, одна из главных задач менеджера — понимать, куда идём, и помогать другим идти туда же. Без этого всё остальное рассыпается. Если цели не ясны — то и результат будет туманным.
И если "шляпа съехала" (цели размылись, мотивация упала) — значит, надо останавливаться, переосмысливать, чинить.

👣 Про самостоятельность
Менеджмент не должен превращаться в микроконтроль. Если уборщик знает, что нужно убрать зал — он и сам решит, как это сделать. Не надо указывать ему марку тряпки и траекторию движения.
И с аналитиком, и с продактом, и с дизайнером — так же. Если вы наняли профессионала, дайте ему пространство.

🫂 Про эмпатию и правду
Умение чувствовать людей, видеть, когда у кого что болит — это тоже часть работы.
Как и готовность слушать правду, даже неприятную. И уметь её сказать.
Откровенность и эмпатия идут рука об руку. Без одной не получится нормального доверия. А без доверия — не получится нормальной команды.

💬 Про авторитет
Он не в тайтле, не в голосе на митинге, не в должности. Он в том, как ты ведёшь себя каждый день.
Настоящий авторитет — это когда за тобой хотят пойти. Потому что доверяют. Потому что верят, что ты не предашь.

🔁 Про перевёрнутую оргструктуру
В книге приводится прекрасный образ:
На вершине не директор, а клиент.
Под ним — сотрудники.
А менеджеры и руководители — снизу, потому что их задача — поддерживать. Не командовать, а помогать.

Этот образ мне близок. Я верю, что сильная организация строится на доверии. И на том, что руководитель — это не над, а рядом. Не "контролёр", а партнёр.

Хочу попробовать чуть глубже покопать в тему доверия — особенно в контексте IT, продактов, аналитиков, платформенных команд.
Если это тоже вам откликается — давайте поговорим. Комменты, личка, мысли, примеры — welcome.

Ребята, привет!

Иногда кажется, что весь IT можно описать тремя словами: бардак, выгорание, метрики из ада 😅
Проект плывёт, никто не понимает, кто за что отвечает, новые фичи выходят через боль, а собеседования — это отдельный вид спорта.

Я сам не раз был по обе стороны баррикад — и как аналитик, и как продакт, и как человек, который собирает команду, когда сроки «вчера». Поэтому когда мне попалась вот эта подборка телеграм-каналов, я не просто обрадовался — я туда вошёл. Да-да, я дорос до того, что меня теперь зовут в папки 😎

Собрали реально годноту:
— про процессы и системность (без фанатизма);
— про найм и команду, без HR-болтовни;
— про ИИ, но так, чтобы не взрывался мозг.

В общем, если вы хотите чуть меньше страдать в IT — загляните.
📂 Вот ссылка на папку
Полезное чтиво и люди с мозгом. Подписывайтесь — не пожалеете. Я там тоже есть 👋

🔥 Лето, которое мы заслужили
В Лиссабоне уже который день подряд стабильно под 40 градусов. Мозг плавится.
Все благие намерения написать пост, поработать с материалами, подумать про курс — разбиваются об одно простое желание: пойти в душ.
И вот ты сходил. И у тебя есть… минут 15. Иногда 20. Пока мозг снова не закипел.

Работать в таком режиме, скажем честно, мягко говоря, не вдохновляет.
Особенно когда и на пляж не вырваться — ребенок приболел, так что океан пока под запретом.
Кондиционеры — единственное спасение. Ну и, может, стакан воды с льдом и мятой. Или без мяты. Или просто лед.
В общем, Лиссабон сейчас больше похож на тостер, чем на европейскую столицу.

А у вас как лето началось? Есть свои погодные испытания или другие первые летние боли?
Рассказывайте. Мне хотя бы почитать будет не так жарко 😅

Всем привет! Дружеская интеграция. Как вы знаете, я сейчас в активных поисках работы (про это как-нибудь сделаю отдельный пост) и все больше убеждаюсь, что: Проходить собеседования — это навык. Навык, который надо качать, который устаревает и атрофируется, который дает буст при трудоустройстве.
Если в 2025-м вы хотите
— меньше волноваться на собесах,
— эффективнее отвечать на вопросы и грамотно задавать их,

читайте канал про собеседования в IT, где собран опыт кандидата.
——————
🔹Булат ходит на собесы из азарта и интереса и пишет, какие были этапы, какие задавали вопросы.

Раз — собес в известный темно-розовый бренд, задачка в комментариях
Два — собес, про который долго не хотел писать
Три — собес, после которого был отказ

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

https://t.iss.one/tryoutonadancefloor

🛠 Продолжаю давно обещанную тему про технический продуктовый менеджмент.

Этот пост — больше подготовка. Давайте сначала разберемся: а откуда вообще люди попадают в продуктовку?

🎓 Спойлер: крайне редко кто-то становится продуктом "с нуля". Обычно за плечами уже есть какой-то опыт — и чаще всего он идет из одной из трёх сторон:

1️⃣ Из бизнеса — человек работал в операциях, продажах, поддержке, хорошо понимает, как всё устроено, и начинает делать продукты, которые закрывают реальные боли.

2️⃣ Из маркетинга — с пониманием пользователей, воронок, поведения, каналов. Отсюда часто приходят в роль product marketing manager’ов, а потом и дальше в продукт.

3️⃣ Из технологий — разработчики, аналитики, архитекторы, дата-инженеры. Те, кто понимает, как работают "кишки", и знают, что такое API, фреймворки, DevOps, и как идет выкатка в прод.

В Finom у нас, например, было довольно много ребят из первых двух направлений. И, как ни странно, даже у тех, кто пришёл из разработки, могут быть гэпы — не в коде, а в техническом "ландшафте": как работает деплой, как связаны команды, почему релиз занимает не 2 дня, а 2 недели.

🎯 Вот тут и появляется роль технического продакт-менеджера — человека, который понимает не только продукт и его ценность, но и то, как этот продукт вообще живёт, дышит, выкатывается и мониторится.

Такой TPM может:
-глубже говорить с разработкой (и быть услышанным),
-понимать, где реальный bottleneck,
-управлять совместными релизами,
-разруливать стыки между командами,
-и при этом — точно так же работать с метриками, гипотезами и пользователями.

⚖️ При этом он, может быть, чуть меньше вовлечён в маркетинг, но сильно лучше понимает инфраструктуру, совместимость, архитектуру, CI\CD и всё вот это.

В следующем посте поговорим: а как туда попасть? Особенно если ты сейчас аналитик или архитектор.

Stay tuned.

Всем привет! Моя бывшая коллега Марина опубликовала гайд по работе с LinkedIn.
Посмотрел, несмотря на то, что старался вылизать свой LinkedIn в процессе поиска работы - тоже забрал себе несколько пунктов.
Ну и в целом - Марина очень сильный продакт, я реально горжусь, что был ее бадди, когда она пришла в Finom и помог влиться в работу.
Она пишет много про продуктовые темы и около них, так что велком к ней на канал.

В основе любого сильного проекта стоит сильный специалист.

В IT-мире сложно представить востребованного специалиста, который не разбирается в том, как работают: архитектура, API, базы данных, алгоритмы.

Без этого никуда.

И не страшно, если вы пока плохо разбираетесь в каких-то современных системах. Хуже, если продолжаете игнорировать свои пробелы в hard skills.

Начните с бесплатных уроков по архитектуре и интеграциям:

▪️мощный инструмент — SOAP UI
▪️подробное описание процесса загрузки сайта
▪️модель TCP/IP и устройства
▪️XML — это вам не ХSD

Присоединяйтесь в чат-боте по ссылке:
👇
@studyit_help_bot

🚀 Скидка на полный курс от канала — 1 000 ₽ на Stepik по промокоду SPHERI до конца июля.

🔧 Чем на самом деле занимается TPM?

Окей, разобрались, как люди становятся TPM. А теперь — вопрос не менее интересный: чем вообще занимается Technical Product Manager в реальной жизни?

Если коротко — всем, чем не заняты другие, но что всё равно нужно для того, чтобы продукт заработал.

Но если чуть подробнее — вот мой взгляд:

🧩 TPM — это связка между продуктом, техникой и здравым смыслом.
Он понимает, как всё устроено внутри. Может объяснить, почему «просто подключить нового провайдера» — это 3 месяца работы и миграция схемы данных. И при этом не скатывается в «ну, это невозможно», а помогает найти реалистичный путь.

📦 TPM занимается "внутренней стороной" продукта.
Платформенные штуки, интеграции, API, data pipeline, внутренние сервисы, инфраструктура, процессы доставки фич — всё, что не видно конечному пользователю, но без чего ничего не поедет.

🧠 TPM — это продуктовый инженер.
Он не пишет код, но отлично понимает, что там происходит. Он не продакт-маркетинг менеджер, но знает, как работает onboarding, авторизация, документация, SDK. Он может читать backlog и видеть, где начинается боль.

🧮 TPM разбирается в приоритетах и трейд-оффах.
Вот тут начинается настоящая магия: у тебя есть ограничения на людей, время и систему. Надо выбрать, что сделать, в какой последовательности, с какими долгами, чтобы это не взорвалось. TPM — тот, кто принимает эти решения или помогает принять их техкоманде и бизнесу вместе.

🎯 TPM — это glue role.
Он говорит на нескольких языках: с разработкой — на языке latency, SLA и циклов деплоя, с бизнесом — про «как это поможет клиенту». И умеет переводить с одного на другой.

📉 И да, TPM часто берёт на себя "скучные" куски.
Согласование требований, управление документацией, объяснение архитектуры другим командам, таблицы совместимости, миграционные планы. Всё то, что помогает команде работать без хаоса.

⚠️ Что TPM не делает (в идеале):
— не превращается в project-менеджера по задачкам;
— не пишет код сам (хотя может помочь разобраться);
— не теряет пользовательскую перспективу, даже если фича касается внутренней шины сообщений.

В следующем посте — поговорим, как роль TPM отличается в разных странах и типах компаний.

А вы видели у себя в компании хороших TPM? Или, может, сами такой? Расскажите, чем занимаетесь — сравним опыты.

🌍 TPM в США, Европе, России: где ты работаешь, там ты и TPM

Продолжаем наш сериал про Technical Product Manager’ов. Сегодня поговорим про то, как TPM-роль устроена в разных странах и типах компаний.

Спойлер: везде по-разному. И это ок.

🗽 В Штатах TPM — это инженер с фокусом на продукт.
Сильно завязано на технический бэкграунд. Часто бывшие разработчики. Часто в FAANG-подобных компаниях: Meta, Google, Amazon и прочих. Там TPM — это glue role между продактом и инженерами. Он отвечает за архитектуру решений, roadmap фичей, stakeholder-менеджмент — но руками не кодит.

📈 В Европе TPM — это чуть ближе к платформенным продактам.
В большинстве европейских компаний TPM скорее про инфраструктурные решения, архитектурные вызовы и согласование кросс-командной работы. Может быть продактом внутренних платформ, API, data layer, IAM и прочих внутренних штук. Очень часто совмещает роли системного аналитика, платформенного продакта и деливери менеджера в одном лице.

🌍 В России (и странах постсовка) TPM — это почти всегда либо:
— продакт, у которого просто технарский бэкграунд (и его за это очень уважают);
— системный аналитик, который тащит на себе ещё и продуктовые куски, потому что “ну а кто ещё?”.
А иногда — разработчик, который стал писать задачи в джиру и стал продактом.

📊 В стартапах TPM — это "всё и сразу".
Отвечает за то, чтобы фича заработала и попала в релиз. Пишет требования, проверяет архитектуру, договаривается с соседними командами, деплоит с командой ночью, а потом ещё пишет документацию. И если повезёт — поговорит с пользователями.

🏢 В корпорациях TPM — это менеджер зависимостей.
Если твоя команда делает кусок, который зависит от 8 других команд, и ты не хочешь превратиться в хаос — вот тут нужен TPM. Он следит за API, схемами, контрактами, SLA, и отвечает, чтобы всё приехало вовремя и не взорвалось.

💡 Общая идея — TPM закрывает дырку между продуктом и инженерией.
Где она будет — зависит от зрелости компании, состава команды, и просто от культуры. Где-то TPM будет про архитектуру, где-то — про delivery, где-то — про приоритезацию внутреннего техдолга, где-то — про API как продукт.

В следующем посте — разберём, какие скиллы нужны TPM и как их качать.

А у вас TPM чем занимается? Или, может, ваша команда сама решает без TPM? Поделитесь опытом — интересно, насколько у всех по-разному.

🧠 Навыки TPM: чему учиться и как прокачиваться

Если ты оказался в роли TPM — технического продуктового менеджера — или хочешь туда попасть, главный вопрос, который обычно возникает: а какие вообще навыки нужны?

Ответ, как это часто бывает: это зависит. От компании, индустрии, контекста, людей вокруг. Но если попытаться обобщить, то картина примерно такая.

Во-первых, TPM — это всегда человек на стыке. Он не обязательно пишет код, но должен понимать, как всё работает. Он не менеджер команды в классическом понимании, но всё равно организует совместную работу. Он не архитектор, но знает, какие технические решения возможны, а какие опасны.

Поэтому ключевые скиллы TPM — это:

Техническая эрудиция. Не обязательно глубокие знания по каждому направлению, но хорошее понимание базовых технологий, архитектурных подходов, API, CI/CD, безопасности и ограничений систем.

Продуктовое мышление. Умение сформулировать проблему, вычленить из хаоса реальные потребности, сформулировать гипотезу, найти метрику, по которой будем проверять, и обернуть всё это в фичу, которая решает нужную задачу.

Коммуникация и фасилитация. TPM часто становится переводчиком между бизнесом и инженерами, держит контекст и помогает договариваться, когда кажется, что договориться невозможно.

Системное мышление. Умение видеть не только фичу, но и весь поток изменений, влияние на другие компоненты, процессы доставки и эксплуатации, возможные деградации и сбои.

И самое главное — гибкость и здравый смысл. В реальности всегда будет неидеально: нет времени, нет ресурсов, нет документации. И в этой неопределённости TPM должен находить рабочий путь.

💡 И, пожалуй, тут важно сказать, почему я вообще начал так подробно копать в эту тему. Потому что со стороны системного анализа (а я сам прошёл этот путь) — роль TPM выглядит как очень органичное продолжение. Особенно если ты уже умеешь разбираться в архитектуре, разбираешь процессы, понимаешь, как работает команда — и хочешь не просто описывать, что должно быть сделано, а принимать участие в решении, почему и как это делать.

Дальше — больше. В следующем посте поговорим про типовые ошибки TPM на старте. Особенно если человек приходит из чисто продуктовой или, наоборот, чисто инженерной среды.

🧩 Ошибки начинающих TPM — и как их избежать
(из личных наблюдений и немного боли)

TPM — вроде бы «идеальная» позиция: ты понимаешь бизнес, шаришь в технике, умеешь говорить с командой и стейкхолдерами. Что может пойти не так?

Спойлер: многое.

За последние годы я видел (и сам проходил через) довольно типичные антипаттерны. Вот самые частые:

🔧 «Я пришёл из разработки — теперь буду всё контролировать»
И начинается: ревью каждой строки, диктовка архитектурных решений, участие во всех daily. В итоге ты превращаешься в микроменеджера, команда тебя боится, а никто не понимает, зачем вообще тут ещё и продакт.

📄 «Я пришёл из аналитики — сейчас всё опишу!»
50 страниц спецификаций, три версии диаграммы, обсуждения по каждой кнопке — и ноль понимания, когда и как это пойдёт в прод. TPM — это не архивариус, TPM — это драйвер. Надо не только понимать требования, но и доводить их до результата.

🧠 «Я слишком технический — про пользователей пусть продакт думает»
Так не работает. Ты всё ещё должен понимать, зачем мы вообще это делаем, для кого и какую боль решаем. Без этого ты не TPM, а просто техлид с расписанием встреч.

🚫 «Я больше не технический, я теперь про процессы»
Ошибка в другую сторону. TPM не обязан писать код, но и «не лезть в технику» — путь в никуда. Ты обязан понимать последствия решений, видеть узкие места и уметь перевести боль команды в действия.

💬 «Я веду 1000 обсуждений — но ни одно не довожу до конца»
Плохой TPM — это хаос. Хороший TPM — это glue, который сшивает всех и всё. Ты не просто созываешь митинг — ты обеспечиваешь, чтобы после него стало понятнее. Чтобы договорились. Чтобы пошли делать.

TPM — это не роль между. Это не медиатор. Это связующее и движущее. Glue & driver.
Если хочешь быть полезным — не прячься за бэкграунд. Используй его. Но иди дальше.
Так что если чувствуете, что роль СА вас ограничивает - велком в ТРМ!

Если было полезно — с радостью услышу в комментах и ваши грабли.
Уверен, их у всех было достаточно.

Всем привет! Сегодня буду общаться про лидерство и организацию работы команд. Приходите послушать и позадавать вопросы