Про книгу OpenTelemetry
Дочитал наконец-таки книгу Теда Янга и Остина Паркера "Изучаем OpenTelemetry: современный мониторинг систем". Эта книга описывает новый и все более популярный стандарт по сбору телеметрии для целей мониторинга - OpenTelemetry (OTEL). Книга получилась не мануалом по использованию, не декларацией подхода, а чем-то средним с перевесом во вторую сторону. Авторы рассказали про предпосылки появления стандарта, про него в целом, про его внутреннее устройство и надавали советов по внедрению в своей компании. В своей работе я часто сталкиваюсь с OTEL, поэтому мне хотелось изучить тему "с основ".
Какие идеи заинтересовали больше всего:
1. Прикольный подход с разделением API и SDK.
Хоть это и не что-то новое, ребята из OTEL заложили такой подход, при котором на этапе разработки с помощью OTEL API разработчик может описать логику сбора телеметрии, не заботясь о том, куда она в итоге будет отправляться. Для того, чтобы данные телеметрии начали реально отправляться, нужно подключить OTEL SDK, который и будет отвечать за отправку в настроенную локацию. Без подключенного SDK телеметрия, которую описывали в API, не будет генерироваться. Этот маневр выглядит избыточным, если пишешь приложение с нуля самостоятельно. Но такой подход начинает сиять, когда в твоем проекте используется много разных сторонних библиотек - благодаря тому, что многие популярные либы переходят на использование OTEL API, подключая OTEL SDK к своему проекту разработчик получается всю телеметрию всех используемых библиотек. Благодаря этому любую проблему с приложением найти будет гораздо проще, даже если она кроется в коде сторонней либы. С другой стороны, конечно, это создает дополнительную работу по первоначальной настройке фильтров того, какая телеметрия вам интересна, а какая не оч.
2. Интересный подход с трейсингом в виде стержня телеметрии
Я привык, что есть 3 столпа телеметрии - логи, метрик и трейсы. И, как правило, все они независимы друг от друга. Это создает проблему, которую авторы описали как "три вкладки в бразуере": для каждого вида телеметрии есть отдельный UI, по которому человек должен сам искать корреляции - по id сессии, по времени или еще как-то. В противовес этому OTEL предлагает использовать трейсы как основную сущность телеметрии - логи предлагают аттачить к спанам (спан это выполнение одной операции, а трейс это вся цепочка таких операций), метрики считать на основе спанов и добавлять к ним иногда трейсы. В итоге получится, что вся телеметрия строится вокруг трейсинга, и просматривая его, инженер будет видеть сразу все - трейсы, логи и метрики через exemplars (это когда иногда к показаниям метрик можно добавить traceId, чтобы получить пример операции, которая выполнялась во время таких-то показаний метрик)
3. OTEL предлагает использовать собственный коллектор для сбора телеметрии
В индустрии наблюдаемости уже есть разного рода коллекторы (сборщик данных), которые себя хорошо показали "в бою". Но ребята разработали новый, который ориентирован сразу на все типы телеметрии и умеет работать в разных режимах (типа как сборщик данных или как промежуточный агрегатор). Надо признать, что на текущий момент их коллектор вполне неплох и по функциям и стабильности показывает себя не хуже конкурентов.
В общем, книга мне показалась интересной, хоть и многое оттуда было уже известно из-за того, что я сам работаю в этом домене. По ходу чтения мне не хватило "кишков" реализации, но за этим авторы предлагают идтив документацию.
P.S. Кстати, это одна из первых технических книг, когда меня напрягал перевод на русский - местами было прям сложновато читать, приходилось прикидывать как это можно сказать на англ. и становилось чуть понятнее.
Дочитал наконец-таки книгу Теда Янга и Остина Паркера "Изучаем OpenTelemetry: современный мониторинг систем". Эта книга описывает новый и все более популярный стандарт по сбору телеметрии для целей мониторинга - OpenTelemetry (OTEL). Книга получилась не мануалом по использованию, не декларацией подхода, а чем-то средним с перевесом во вторую сторону. Авторы рассказали про предпосылки появления стандарта, про него в целом, про его внутреннее устройство и надавали советов по внедрению в своей компании. В своей работе я часто сталкиваюсь с OTEL, поэтому мне хотелось изучить тему "с основ".
Какие идеи заинтересовали больше всего:
1. Прикольный подход с разделением API и SDK.
Хоть это и не что-то новое, ребята из OTEL заложили такой подход, при котором на этапе разработки с помощью OTEL API разработчик может описать логику сбора телеметрии, не заботясь о том, куда она в итоге будет отправляться. Для того, чтобы данные телеметрии начали реально отправляться, нужно подключить OTEL SDK, который и будет отвечать за отправку в настроенную локацию. Без подключенного SDK телеметрия, которую описывали в API, не будет генерироваться. Этот маневр выглядит избыточным, если пишешь приложение с нуля самостоятельно. Но такой подход начинает сиять, когда в твоем проекте используется много разных сторонних библиотек - благодаря тому, что многие популярные либы переходят на использование OTEL API, подключая OTEL SDK к своему проекту разработчик получается всю телеметрию всех используемых библиотек. Благодаря этому любую проблему с приложением найти будет гораздо проще, даже если она кроется в коде сторонней либы. С другой стороны, конечно, это создает дополнительную работу по первоначальной настройке фильтров того, какая телеметрия вам интересна, а какая не оч.
2. Интересный подход с трейсингом в виде стержня телеметрии
Я привык, что есть 3 столпа телеметрии - логи, метрик и трейсы. И, как правило, все они независимы друг от друга. Это создает проблему, которую авторы описали как "три вкладки в бразуере": для каждого вида телеметрии есть отдельный UI, по которому человек должен сам искать корреляции - по id сессии, по времени или еще как-то. В противовес этому OTEL предлагает использовать трейсы как основную сущность телеметрии - логи предлагают аттачить к спанам (спан это выполнение одной операции, а трейс это вся цепочка таких операций), метрики считать на основе спанов и добавлять к ним иногда трейсы. В итоге получится, что вся телеметрия строится вокруг трейсинга, и просматривая его, инженер будет видеть сразу все - трейсы, логи и метрики через exemplars (это когда иногда к показаниям метрик можно добавить traceId, чтобы получить пример операции, которая выполнялась во время таких-то показаний метрик)
3. OTEL предлагает использовать собственный коллектор для сбора телеметрии
В индустрии наблюдаемости уже есть разного рода коллекторы (сборщик данных), которые себя хорошо показали "в бою". Но ребята разработали новый, который ориентирован сразу на все типы телеметрии и умеет работать в разных режимах (типа как сборщик данных или как промежуточный агрегатор). Надо признать, что на текущий момент их коллектор вполне неплох и по функциям и стабильности показывает себя не хуже конкурентов.
В общем, книга мне показалась интересной, хоть и многое оттуда было уже известно из-за того, что я сам работаю в этом домене. По ходу чтения мне не хватило "кишков" реализации, но за этим авторы предлагают идти
P.S. Кстати, это одна из первых технических книг, когда меня напрягал перевод на русский - местами было прям сложновато читать, приходилось прикидывать как это можно сказать на англ. и становилось чуть понятнее.
www.piter.com
Изучаем OpenTelemetry: современный мониторинг систем
Практическое руководство по OpenTelemetry от основателей проекта.
🔥9👍3❤1
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry?
Пока читал книгу по OpenTelemetry (писал об этом в прошлом посте), задавался вопросом, а зачем большим известным богатым вендорам систем мониторинга типа DataDog или NewRelic вообще поддерживать общий стандарт телеметрии OpenTelemetry (OTEL)?
Сходу вижу несколько причин для них НЕ поддерживать его, а напротив, задавить:
1. OTEL упрощает переход к другому вендору
Стандарт регламентирует форматы логов, метрик и трейсов и даже дает collector, который позволяет их собирать и отправлять в хранилище. А это значит, что задача по заливке своей телеметрии значительно упрощается для всех без регистрации и смс. Разберитесь как настраивается сбор и отправка данных в OTEL, и переключение между разными вендорами систем мониторинга превращается в переделку ограниченного числа конфигов. Конечно, обязательно есть нюансы, но в любом случае такой проект обойдется значительно дешевле бизнесу и проще технарям, чем гига-проект, в котором надо перелопатить половину инфраструктуры, чтобы мигрировать на новую проприетарную систему мониторинга. А значит сменить вендора теперь стало проще.
2. OTEL создает конкуренцию для проприетарных сборщиков телеметрии
Не для того DataDog-alike вендоры разрабатывали своих агентов (агент это такой тип приложения, который "подсаживается" к другой системе и в runtime по тихой собирает ее телеметрию), чтобы клиенты брали open source collector от OTEL. Конечно, кто-то так и будет использовать проприетарные решения от вендора, ну а кто-то таки перейдет на OTEL collector. Разве кому-то хочется терять пользователей?
3. OTEL увеличивает конкурентность использования open source стека для observability
Раньше консистентный сбор и отправка телеметрии были проблемами, которые крупные вендоры за деньги с успехом решали для своих клиентов за счет своих разработок. А теперь эти проблемы значительно упростились благодаря распространению OTEL, и платить за их решение уже не так ценно. А если решение от вендора дает меньше ценность, то может вовсе рассмотреть open source типа ELK, SigNoz или HyperDX? Зачем платить вендору?
В общем, у больших вендоров вполне есть причины не поддерживать OTEL, а, напротив, саботировать его, ведь это создает угрозу их бизнесу, казалось бы... Но не все так просто - об этом напишу в следующем посте прям на днях.
Пока читал книгу по OpenTelemetry (писал об этом в прошлом посте), задавался вопросом, а зачем большим известным богатым вендорам систем мониторинга типа DataDog или NewRelic вообще поддерживать общий стандарт телеметрии OpenTelemetry (OTEL)?
Сходу вижу несколько причин для них НЕ поддерживать его, а напротив, задавить:
1. OTEL упрощает переход к другому вендору
Стандарт регламентирует форматы логов, метрик и трейсов и даже дает collector, который позволяет их собирать и отправлять в хранилище. А это значит, что задача по заливке своей телеметрии значительно упрощается для всех без регистрации и смс. Разберитесь как настраивается сбор и отправка данных в OTEL, и переключение между разными вендорами систем мониторинга превращается в переделку ограниченного числа конфигов. Конечно, обязательно есть нюансы, но в любом случае такой проект обойдется значительно дешевле бизнесу и проще технарям, чем гига-проект, в котором надо перелопатить половину инфраструктуры, чтобы мигрировать на новую проприетарную систему мониторинга. А значит сменить вендора теперь стало проще.
2. OTEL создает конкуренцию для проприетарных сборщиков телеметрии
Не для того DataDog-alike вендоры разрабатывали своих агентов (агент это такой тип приложения, который "подсаживается" к другой системе и в runtime по тихой собирает ее телеметрию), чтобы клиенты брали open source collector от OTEL. Конечно, кто-то так и будет использовать проприетарные решения от вендора, ну а кто-то таки перейдет на OTEL collector. Разве кому-то хочется терять пользователей?
3. OTEL увеличивает конкурентность использования open source стека для observability
Раньше консистентный сбор и отправка телеметрии были проблемами, которые крупные вендоры за деньги с успехом решали для своих клиентов за счет своих разработок. А теперь эти проблемы значительно упростились благодаря распространению OTEL, и платить за их решение уже не так ценно. А если решение от вендора дает меньше ценность, то может вовсе рассмотреть open source типа ELK, SigNoz или HyperDX? Зачем платить вендору?
В общем, у больших вендоров вполне есть причины не поддерживать OTEL, а, напротив, саботировать его, ведь это создает угрозу их бизнесу, казалось бы... Но не все так просто - об этом напишу в следующем посте прям на днях.
Telegram
Сказки технического менеджера
Про книгу OpenTelemetry
Дочитал наконец-таки книгу Теда Янга и Остина Паркера "Изучаем OpenTelemetry: современный мониторинг систем". Эта книга описывает новый и все более популярный стандарт по сбору телеметрии для целей мониторинга - OpenTelemetry (OTEL).…
Дочитал наконец-таки книгу Теда Янга и Остина Паркера "Изучаем OpenTelemetry: современный мониторинг систем". Эта книга описывает новый и все более популярный стандарт по сбору телеметрии для целей мониторинга - OpenTelemetry (OTEL).…
👍6
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry? часть 2
Первая часть тут
Какие причины поддержать OTEL все таки есть у крупных вендоров и как они используют OTEL в свою пользу
Вижу, по крайней мере, несколько причин:
1. Поддержать OTEL стоило, чтобы быть в тренде своих клиентов
OTEL хайпанул, и у существующих клиентов успело сложиться ожидание о том, что их вендор поддержит этот тренд. Не поддержать его означало бы потерять очки лояльности какого-то числа клиентов, а то и вовсе потерять их как клиентов.
2. Поддержать OTEL стоило, чтобы сделать органичную PR-кампанию
Когда OTEL стал распространяться, то написать о нем в своем корп. блоге или в документации означало привлечь дополнительный трафик, который с какой-то конверсией наверняка в итоге конвертировался в платных клиентов. Сказать о том, что вы поддерживаете OTEL - это создать инфоповод, о котором напишут техно-СМИ - все это трафик, бренд и то, из чего бизнес извлекает выгоду в разных аспектах.
3. Поддержать OTEL стоило, чтобы не бороться с стандартом, а возглавить его и учесть в нем свои интересы
У OTEL есть определенная структура комитетов, которые принимают решения разного уровня относительно стандарта. Так вот, ради интереса загляните в то, какие люди входят в ключевые комитеты OTEL. Там вы увидите немало людей из таких компаний как Splunk, DataDog, New Relic, Dynatrace, Honeycomb. Находясь на самом "острие" стандарта, они могут оказывать существенное влияние на его формирования. Стоит полагать, что не без учета интересов их бизнеса.
4. Поддержать OTEL стоило, чтобы привлечь новых клиентов
Одна из фишек OTEL в том, что он призван избавить компании от vendor-lock (жесткой привязки к одному поставщику ПО). Это весомое преимущество, которое рассматривают компании при выборе новой системы мониторинга. Так вот, для многих компаний сейчас совместимость с OTEL это одно из базовых требований к системе. Если бы вендоры сделали ставку на гибель OTEL и НЕ поддержали бы стандарт, то в таких условиях они бы перестали попадать в шорт-лист компаний, которых выбирают. Конечно, им такого не нужно, они не хотят терять сегмент платящих OTEL-frendly клиентов.
При этом, надо оговориться, что зачастую речь идет не о полной и "честной" поддержке OTEL, а скорее о необходимом минимуме, чтобы их не привлекли за обман:) С одной стороны говорят "мы поддерживаем OTEL!!1", а с другой делают НАМНОГО более тесную интеграции при использовании своих проприетарных инструментов. Об этом классно написали ребята из SigNoz.
А от меня еще пару примеров по DataDog:
1. Зацените как они описывают интеграцию OTEL с самим собой. Типа есть две опции - одна хорошая с OTEL, а вторая с кучей доп. фичей и 850+ интеграций из коробки, но с нашим проприетарным агентом. Чувствуете, к чему они клонят?
2. А вот тут таблица сравнения паритета по фичам при разных сетапах - с OTEL и их проприетарными инструментами. Не знаю как вам, а мне прям бросается в глаза насколько меньше фичей они дают при сетапе "Full OTel".
Кто бы сомневался, что большие вендоры не просто так большие - они очень умело используют техно-тренды на пользу своему бизнесу. При этом, конечно, стоит порадоваться, что они вообще поддержали OTEL и дали пространство для развития отрасли в этом направлении. Кажется, в этом намного больше плюсов для всех.
Первая часть тут
Какие причины поддержать OTEL все таки есть у крупных вендоров и как они используют OTEL в свою пользу
Вижу, по крайней мере, несколько причин:
1. Поддержать OTEL стоило, чтобы быть в тренде своих клиентов
OTEL хайпанул, и у существующих клиентов успело сложиться ожидание о том, что их вендор поддержит этот тренд. Не поддержать его означало бы потерять очки лояльности какого-то числа клиентов, а то и вовсе потерять их как клиентов.
2. Поддержать OTEL стоило, чтобы сделать органичную PR-кампанию
Когда OTEL стал распространяться, то написать о нем в своем корп. блоге или в документации означало привлечь дополнительный трафик, который с какой-то конверсией наверняка в итоге конвертировался в платных клиентов. Сказать о том, что вы поддерживаете OTEL - это создать инфоповод, о котором напишут техно-СМИ - все это трафик, бренд и то, из чего бизнес извлекает выгоду в разных аспектах.
3. Поддержать OTEL стоило, чтобы не бороться с стандартом, а возглавить его и учесть в нем свои интересы
У OTEL есть определенная структура комитетов, которые принимают решения разного уровня относительно стандарта. Так вот, ради интереса загляните в то, какие люди входят в ключевые комитеты OTEL. Там вы увидите немало людей из таких компаний как Splunk, DataDog, New Relic, Dynatrace, Honeycomb. Находясь на самом "острие" стандарта, они могут оказывать существенное влияние на его формирования. Стоит полагать, что не без учета интересов их бизнеса.
4. Поддержать OTEL стоило, чтобы привлечь новых клиентов
Одна из фишек OTEL в том, что он призван избавить компании от vendor-lock (жесткой привязки к одному поставщику ПО). Это весомое преимущество, которое рассматривают компании при выборе новой системы мониторинга. Так вот, для многих компаний сейчас совместимость с OTEL это одно из базовых требований к системе. Если бы вендоры сделали ставку на гибель OTEL и НЕ поддержали бы стандарт, то в таких условиях они бы перестали попадать в шорт-лист компаний, которых выбирают. Конечно, им такого не нужно, они не хотят терять сегмент платящих OTEL-frendly клиентов.
При этом, надо оговориться, что зачастую речь идет не о полной и "честной" поддержке OTEL, а скорее о необходимом минимуме, чтобы их не привлекли за обман:) С одной стороны говорят "мы поддерживаем OTEL!!1", а с другой делают НАМНОГО более тесную интеграции при использовании своих проприетарных инструментов. Об этом классно написали ребята из SigNoz.
А от меня еще пару примеров по DataDog:
1. Зацените как они описывают интеграцию OTEL с самим собой. Типа есть две опции - одна хорошая с OTEL, а вторая с кучей доп. фичей и 850+ интеграций из коробки, но с нашим проприетарным агентом. Чувствуете, к чему они клонят?
2. А вот тут таблица сравнения паритета по фичам при разных сетапах - с OTEL и их проприетарными инструментами. Не знаю как вам, а мне прям бросается в глаза насколько меньше фичей они дают при сетапе "Full OTel".
Кто бы сомневался, что большие вендоры не просто так большие - они очень умело используют техно-тренды на пользу своему бизнесу. При этом, конечно, стоит порадоваться, что они вообще поддержали OTEL и дали пространство для развития отрасли в этом направлении. Кажется, в этом намного больше плюсов для всех.
GitHub
community/community-members.md at main · open-telemetry/community
OpenTelemetry community content. Contribute to open-telemetry/community development by creating an account on GitHub.
🔥3👍2
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (1/2)
Ладно-ладно, я специально немного утрировал. "За спиной", "за глаза", "в крысу🐀" - для этого формата есть разные определения, но суть одна: порой менеджеру необходимо обсуждать одних людей с другими людьми, причем частенько без ведома первых. В самом начале своего менеджерского пути я стеснялся этого - как это можно обсуждать сотрудника в его отсутствие? Но со временем я осознал важную мысль: некоторые разговоры не только необходимы, но и полезны для команды и самих людей. И если я, как менеджер, игнорирую эту часть работы или делаю ее плохо, то я обкрадываю команду относительно той пользы, которую мог бы им нанести. Важно лишь правильно проводить эти обсуждения.
Когда обсуждать за спиной все таки нужно?
1. Когда руководитель сотрудника просит фидбек о нем
Иногда руководители других сотрудников могут приходить с вопросами "Ну как он/она? Норм работает?". Кол-во таких запросов тем больше, чем ближе годовое ревью. Эта информация нужна им для составления плана развития сотрудника, сверки относительно фидбека от других людей. Ну и иногда она может оказать какое-то влияние на его годовую оценку (ну или как там у вас премии распределяют?). Этот же пункт работал, когда мне нужен был фидбек о работе своих сотрудников.
2. Когда фидбек не просили, но ты видишь плохой сигнал
Бывает такое, что по ходу работы над задачей человек может повести себя неконструктивно, например, разраба попросили проверить собственный фикс, а он сказал, что это не его работа, пусть QA проверяют. Все мы люди и порой можем где-то косячить, это норм. Но иногда бывает полезно сообщить такой сигнал руководителю сотрудника, чтобы он учел это при работе с ним, а может и превентивно принял какие-то меры, если сотрудник уже выгорает, например. Лично я этим вариантом пользовался ТОЛЬКО когда у меня был налаженный контакт с руководителем сотрудника и я был АБСОЛЮТНО уверен в адекватности восприятия руководителем такого фидбека.
3. Когда надо решить, кому лучше поручить задачу
Не всегда тимлид может в одиночку безошибочно определить лучшего исполнителя для той или иной задачи (по версии продакта, конечно). Например, на этой неделе есть свободный инженер, которому можно поручить задачу рефакторинга пары важных джоб на CI, однако его личные особенности таковы, что он ненавидит работать с CI. И тут возникает пространство для того, что бы обсудить, кому вместо него лучше эту задачу дать или пофиг на личные предпочтения...И вот мы снова обсуждаем людей и их особенности.
4. Когда нужно решить конфликт
Выслушать одну сторону конфликта, уточнить все важные детали, скорректировать неадекватные ожидания/поведение, а то может и вторую сторону послушать, побыть медиатором. Крч, в конфликтных историях обсуждение другого сотрудника это чуть не стержень беседы.
И это не исчерпывающий список ситуаций. Как видите, всех их объединяет вектор на более продуктивную работы команды, а не просто стремление посплетничать.
Ладно-ладно, я специально немного утрировал. "За спиной", "за глаза", "в крысу🐀" - для этого формата есть разные определения, но суть одна: порой менеджеру необходимо обсуждать одних людей с другими людьми, причем частенько без ведома первых. В самом начале своего менеджерского пути я стеснялся этого - как это можно обсуждать сотрудника в его отсутствие? Но со временем я осознал важную мысль: некоторые разговоры не только необходимы, но и полезны для команды и самих людей. И если я, как менеджер, игнорирую эту часть работы или делаю ее плохо, то я обкрадываю команду относительно той пользы, которую мог бы им нанести. Важно лишь правильно проводить эти обсуждения.
Когда обсуждать за спиной все таки нужно?
1. Когда руководитель сотрудника просит фидбек о нем
Иногда руководители других сотрудников могут приходить с вопросами "Ну как он/она? Норм работает?". Кол-во таких запросов тем больше, чем ближе годовое ревью. Эта информация нужна им для составления плана развития сотрудника, сверки относительно фидбека от других людей. Ну и иногда она может оказать какое-то влияние на его годовую оценку (ну или как там у вас премии распределяют?). Этот же пункт работал, когда мне нужен был фидбек о работе своих сотрудников.
2. Когда фидбек не просили, но ты видишь плохой сигнал
Бывает такое, что по ходу работы над задачей человек может повести себя неконструктивно, например, разраба попросили проверить собственный фикс, а он сказал, что это не его работа, пусть QA проверяют. Все мы люди и порой можем где-то косячить, это норм. Но иногда бывает полезно сообщить такой сигнал руководителю сотрудника, чтобы он учел это при работе с ним, а может и превентивно принял какие-то меры, если сотрудник уже выгорает, например. Лично я этим вариантом пользовался ТОЛЬКО когда у меня был налаженный контакт с руководителем сотрудника и я был АБСОЛЮТНО уверен в адекватности восприятия руководителем такого фидбека.
3. Когда надо решить, кому лучше поручить задачу
Не всегда тимлид может в одиночку безошибочно определить лучшего исполнителя для той или иной задачи (по версии продакта, конечно). Например, на этой неделе есть свободный инженер, которому можно поручить задачу рефакторинга пары важных джоб на CI, однако его личные особенности таковы, что он ненавидит работать с CI. И тут возникает пространство для того, что бы обсудить, кому вместо него лучше эту задачу дать или пофиг на личные предпочтения...И вот мы снова обсуждаем людей и их особенности.
4. Когда нужно решить конфликт
Выслушать одну сторону конфликта, уточнить все важные детали, скорректировать неадекватные ожидания/поведение, а то может и вторую сторону послушать, побыть медиатором. Крч, в конфликтных историях обсуждение другого сотрудника это чуть не стержень беседы.
И это не исчерпывающий список ситуаций. Как видите, всех их объединяет вектор на более продуктивную работы команды, а не просто стремление посплетничать.
👍10
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (2/2)
А как правильно обсуждать других?
Для себя я выработал несколько простых принципов, вот такие я вспомнил:
1. Этичность превыше всего
В данном контексте в "этичность" я вкладываю корректность и конфиденциальность. В любом обсуждении сотрудника есть определенные границы, за которые нельзя заходить: его семья, какое-то его прошлое, соцсети - это такие темы, которые не касаются рабочих моментов и они слишком личные. Считаю, что корректно будет избежать таких тем и отказаться от их обсуждения в любой форме. Конфиденциальность - это сделать так, что бы сказанное мне "по секрету" осталось только у меня и никуда дальше не утекло. Если сотрудник рассказал мне о каких-то личных вещах, я должен сохранить их личными.
2. Приводить факты и конкретные примеры
Любой фидбек о сотруднике (особенно негативный) должен сопровождаться конкретными примерами поведения. Причем прежде всего не моими оценками поведения, а именно фактами. Не "демотивирует коллег", а "на дейликах 3.04 и 7.04 при всех ругал код Ивана, называя егонеподдерживаемым говном ". Такой фидбек требует больше времени, но куда деваться - это часть работы менеджера.
3. "А смогу ли я сказать это в лицо этому человеку?"
Пожалуй, это мой основной принцип - при обсуждении человека, я пытаюсь представлять, смогу ли я тот же самый месседж (но может другими словами) сказать человеку открыто лицом к лицу? Если да - говорить спокойно, иначе НЕ говорить о нем и крепко задуматься, почему мне стремно сказать такое человеку лично. А вот как такие непростые вещи говорить людям лицом к лицу, это совсем другая история...
А как правильно обсуждать других?
Для себя я выработал несколько простых принципов, вот такие я вспомнил:
1. Этичность превыше всего
В данном контексте в "этичность" я вкладываю корректность и конфиденциальность. В любом обсуждении сотрудника есть определенные границы, за которые нельзя заходить: его семья, какое-то его прошлое, соцсети - это такие темы, которые не касаются рабочих моментов и они слишком личные. Считаю, что корректно будет избежать таких тем и отказаться от их обсуждения в любой форме. Конфиденциальность - это сделать так, что бы сказанное мне "по секрету" осталось только у меня и никуда дальше не утекло. Если сотрудник рассказал мне о каких-то личных вещах, я должен сохранить их личными.
2. Приводить факты и конкретные примеры
Любой фидбек о сотруднике (особенно негативный) должен сопровождаться конкретными примерами поведения. Причем прежде всего не моими оценками поведения, а именно фактами. Не "демотивирует коллег", а "на дейликах 3.04 и 7.04 при всех ругал код Ивана, называя его
3. "А смогу ли я сказать это в лицо этому человеку?"
Пожалуй, это мой основной принцип - при обсуждении человека, я пытаюсь представлять, смогу ли я тот же самый месседж (но может другими словами) сказать человеку открыто лицом к лицу? Если да - говорить спокойно, иначе НЕ говорить о нем и крепко задуматься, почему мне стремно сказать такое человеку лично. А вот как такие непростые вещи говорить людям лицом к лицу, это совсем другая история...
👍10❤3
Всем привет!
И, да, я перешёл в Яндекс🤘. Тут я в роли технического менеджера (продакт + проджект) буду развивать основную платформу наблюдаемости внутренних и внешних продуктов, и ту ее часть, которая предоставляется клиентам в Облаке. Испытываю по этому поводу приятное чувство предвкушения. Осталось не завалить испытательный срок🙈
Чуть позже бахну пост про процесс найма в Яндекс - в моем случае он получился аж из 7 (семь) этапов собеседований, есть что рассказать.
И, да, я перешёл в Яндекс🤘. Тут я в роли технического менеджера (продакт + проджект) буду развивать основную платформу наблюдаемости внутренних и внешних продуктов, и ту ее часть, которая предоставляется клиентам в Облаке. Испытываю по этому поводу приятное чувство предвкушения. Осталось не завалить испытательный срок🙈
Чуть позже бахну пост про процесс найма в Яндекс - в моем случае он получился аж из 7 (семь) этапов собеседований, есть что рассказать.
🔥32👍3❤2
Про мой процесс найма в Яндекс (1/2)
Так вот, я обещал написать о том, как выглядел процесс найма в Яндекс в моем случае. Кстати, я вас случайно обманул, этапов было не 7, а 8🫠
Сразу оговорюсь, что в других случаях процесс может выглядеть по-другому, а также, что он отличается в зависимости от профиля позиции - для инженеров один флоу, для менеджеров другой. Я собеседовался на позицию технического менеджера. Как я понял, в понимании Яндекса технический менеджер это продакт менеджер + проджект менеджер + все это в техническом сложном домене (у меня вот домен наблюдаемости и мониторинга). Итак, here we go
1. Первичный чек с рекрутером
На этом этапе рекрутер рассказала о вакансии, продукте и требованиях. Также она расспросила о моем опыте и ответила на вопросы. Кажется, это самый понятный этап, на котором рекрутер проводит первичную фильтрацию кандидатов. По ходу общения мы оба пришли к заключению, что на первый взгляд я подозрительно хорошо подхожу под эту вакансию. Кто знает, тот знает, что Яндекс славится многоступенчатыми собеседованиями и требовательным отбором кандидатов. Так вот, рекрутер предложила мне ДО начала всех этих этапов сразу пообщаться с потенциальным будущим руководителем, чтобы провести "вайб чек". Будет мэтч - супер, пойду по этапам собеседований, не будет - ну может и нет смысла?
2. ВНЕЗАПНО: первый фит с руководителем
Мы познакомились, непринуждённо пообщались по темам менеджмента людей и продуктов, про observability и вокруг этой темы, обсудили особенности и порядки их команды и обо всем таком. Встреча была короткая и ненапряжная - вайб-чек был взаимно пройден, а это значит, что можно двигаться дальше по этапам.
3. Управление проектами
На этом этапе меня ждало часовое собеседование на тему управления проектам, где меня сначала спрашивали в формате викторины типа "что такое критический путь?" или "что такое хорошая цель проекта?", а затем накидывали разные кейсы из жизни проектного менеджера, где предполагалось больше рассуждения вслух. Каждый такой кейс мы раскручивали, и если я предлагал какое-то решение, то мы углублялись в его особенности, границы применимости и примеры из реальной жизни. Не могу назвать это собеседование легкой прогулкой, но и совсем уж сложным оно не было - самая жесть была впереди.
4. Управление продуктами
На этом собеседовании меня ждал один продуктовый кейс про запуск нового технического продукта. Мы взяли некий продукт и обсудили все его этапы от голой идеи до запуска в продакшон и последующей поддержки. На каждом значимом этапе мы тормозили и шли немного вглубь. Например, вопросы про этап идеи - "Какие вопросы ты задашь, когда к тебе пришли с этой идеей?" или "как ты решишь, что над этой темой стоит работать, если у тебя и так есть несколько других инициатив?". Пример вопросов с этапа MVP - "Как будешь искать первых клиентов (early adopters)?" или "Как поймешь, что шаг MVP пройден?". Честно говоря, я даже не заметил как прошел час этого собеседования - общаться было интересно и полезно т.к. в какие-то моменты интервьюер делился и своим взглядом на вопрос.
Следующие этапы во втором посте
Так вот, я обещал написать о том, как выглядел процесс найма в Яндекс в моем случае. Кстати, я вас случайно обманул, этапов было не 7, а 8🫠
Сразу оговорюсь, что в других случаях процесс может выглядеть по-другому, а также, что он отличается в зависимости от профиля позиции - для инженеров один флоу, для менеджеров другой. Я собеседовался на позицию технического менеджера. Как я понял, в понимании Яндекса технический менеджер это продакт менеджер + проджект менеджер + все это в техническом сложном домене (у меня вот домен наблюдаемости и мониторинга). Итак, here we go
1. Первичный чек с рекрутером
На этом этапе рекрутер рассказала о вакансии, продукте и требованиях. Также она расспросила о моем опыте и ответила на вопросы. Кажется, это самый понятный этап, на котором рекрутер проводит первичную фильтрацию кандидатов. По ходу общения мы оба пришли к заключению, что на первый взгляд я подозрительно хорошо подхожу под эту вакансию. Кто знает, тот знает, что Яндекс славится многоступенчатыми собеседованиями и требовательным отбором кандидатов. Так вот, рекрутер предложила мне ДО начала всех этих этапов сразу пообщаться с потенциальным будущим руководителем, чтобы провести "вайб чек". Будет мэтч - супер, пойду по этапам собеседований, не будет - ну может и нет смысла?
2. ВНЕЗАПНО: первый фит с руководителем
Мы познакомились, непринуждённо пообщались по темам менеджмента людей и продуктов, про observability и вокруг этой темы, обсудили особенности и порядки их команды и обо всем таком. Встреча была короткая и ненапряжная - вайб-чек был взаимно пройден, а это значит, что можно двигаться дальше по этапам.
3. Управление проектами
На этом этапе меня ждало часовое собеседование на тему управления проектам, где меня сначала спрашивали в формате викторины типа "что такое критический путь?" или "что такое хорошая цель проекта?", а затем накидывали разные кейсы из жизни проектного менеджера, где предполагалось больше рассуждения вслух. Каждый такой кейс мы раскручивали, и если я предлагал какое-то решение, то мы углублялись в его особенности, границы применимости и примеры из реальной жизни. Не могу назвать это собеседование легкой прогулкой, но и совсем уж сложным оно не было - самая жесть была впереди.
4. Управление продуктами
На этом собеседовании меня ждал один продуктовый кейс про запуск нового технического продукта. Мы взяли некий продукт и обсудили все его этапы от голой идеи до запуска в продакшон и последующей поддержки. На каждом значимом этапе мы тормозили и шли немного вглубь. Например, вопросы про этап идеи - "Какие вопросы ты задашь, когда к тебе пришли с этой идеей?" или "как ты решишь, что над этой темой стоит работать, если у тебя и так есть несколько других инициатив?". Пример вопросов с этапа MVP - "Как будешь искать первых клиентов (early adopters)?" или "Как поймешь, что шаг MVP пройден?". Честно говоря, я даже не заметил как прошел час этого собеседования - общаться было интересно и полезно т.к. в какие-то моменты интервьюер делился и своим взглядом на вопрос.
Следующие этапы во втором посте
❤9🔥5🤔3
Про мой процесс найма в Яндекс (2/2)
5. Управление людьми
Это собеседование целиком и полностью состояло из набора кейсов из жизни руководителя - "тебе надо, чтобы смежники сделали задачу Х, а они оч заняты, что будешь делать?" или "в команде есть продуктивный, но токсичный чел, от которого стонет команда, как разрулишь?" и вот в таком духе. Кейсы усложнялись на ходу, динамически добавлялись новые вводные и мы рассуждали о том, как изменяется решение. Попутно обсуждали организацию процессов разработки и поддержки. Собес был динамичным и интересным, но все же более энергозатратным, чем предыдущий этап.
6. Архитектура
На этом этапе я готовился к классическому system design интервью (прям правда готовился), когда есть вводня задача и нужно спроектировать систему, которая ее решает. Однако с самого начала встреча пошла не так, как я ожидал - мы начали с формата викторины, где меня спрашивали вопросы типа "что происходит, когда мы вводим адрес с браузере?" или "Какие уровни OSI знаешь?". На часть вопросов я ответил норм, на часть не смог ответить, но при этом старался рассуждать вслух. В какой-то момент интервьюер предложил перейти к проектированию системы и мы погнали. Обычно первым этапом system design интервью является уточнение требований - тут мне предложили самому придумать адекватные требования. Штош, это интересный хак, если ты не подготовился к собеседованию как интервьюер, подумал я (хотя сомнений в качестве его подготовки у меня не было). Далее все шло более-менее стандартно, разве что только на тему отказоустойчивости мы поговорили дольше всего - как резервировать балансеры, graceful degradation при отвале части инфры и вот это все. В целом собес прошел неплохо, но физически я очень устал.
7. Комбо
После прошлого этапа рекрутер рассказала, что меня ждет еще один Особый этап, о котором мы не говорили заранее. Этот этап проводят не всем, а только тем, как я понял, кто получил достаточно хорошие отзывы на каждом из этапов интервью. Собеседование идет полтора часа и охватает сразу 3 темы - проекты, продукты и техника. Цель - еще раз оценить тебя и сверить фидбек с тем, который давали интервьюеры на предыдущих этапах. Штош, погнали.
На самом собеседовании мы действительно быстро бежали по всем этим темам - часть вопросов была в формате викторины, но больше было решения кейсов. Интервьюер предупредил меня, что он будет перебивать, если поймет, что я хорошо отвечаю на вопрос - все ради того, чтобы покрыть больше вопросов по этим трем темам. И, действительно, в какие-то моменты я чувствовал себя на шоу "Самый умный", как только я давал норм ответ, он сразу же накидывал следующий вопрос, не давая перевести дух. В таком формате мы провели полтора часа интенсивного обсуждения нон-стопом. Прикольный опыт, очень крутой интервьюер, но это супер энергозатратный формат.
8. Фит-интервью с командой
Это последний этап, на котором мы еще раз встретились с руководителем, только на этот раз с ним была менеджер из будущей команды. На этом этапе не было сложных вопросов, мы познакомились, ребята ответили на мои вопросы о работе и я ответил на пару вопросов о себе.
Второй вайб-чек был пройден, и дальше все следующие встречи были про оффер и его условия, но это совсем другая история...
5. Управление людьми
Это собеседование целиком и полностью состояло из набора кейсов из жизни руководителя - "тебе надо, чтобы смежники сделали задачу Х, а они оч заняты, что будешь делать?" или "в команде есть продуктивный, но токсичный чел, от которого стонет команда, как разрулишь?" и вот в таком духе. Кейсы усложнялись на ходу, динамически добавлялись новые вводные и мы рассуждали о том, как изменяется решение. Попутно обсуждали организацию процессов разработки и поддержки. Собес был динамичным и интересным, но все же более энергозатратным, чем предыдущий этап.
6. Архитектура
На этом этапе я готовился к классическому system design интервью (прям правда готовился), когда есть вводня задача и нужно спроектировать систему, которая ее решает. Однако с самого начала встреча пошла не так, как я ожидал - мы начали с формата викторины, где меня спрашивали вопросы типа "что происходит, когда мы вводим адрес с браузере?" или "Какие уровни OSI знаешь?". На часть вопросов я ответил норм, на часть не смог ответить, но при этом старался рассуждать вслух. В какой-то момент интервьюер предложил перейти к проектированию системы и мы погнали. Обычно первым этапом system design интервью является уточнение требований - тут мне предложили самому придумать адекватные требования. Штош, это интересный хак, если ты не подготовился к собеседованию как интервьюер, подумал я (хотя сомнений в качестве его подготовки у меня не было). Далее все шло более-менее стандартно, разве что только на тему отказоустойчивости мы поговорили дольше всего - как резервировать балансеры, graceful degradation при отвале части инфры и вот это все. В целом собес прошел неплохо, но физически я очень устал.
7. Комбо
После прошлого этапа рекрутер рассказала, что меня ждет еще один Особый этап, о котором мы не говорили заранее. Этот этап проводят не всем, а только тем, как я понял, кто получил достаточно хорошие отзывы на каждом из этапов интервью. Собеседование идет полтора часа и охватает сразу 3 темы - проекты, продукты и техника. Цель - еще раз оценить тебя и сверить фидбек с тем, который давали интервьюеры на предыдущих этапах. Штош, погнали.
На самом собеседовании мы действительно быстро бежали по всем этим темам - часть вопросов была в формате викторины, но больше было решения кейсов. Интервьюер предупредил меня, что он будет перебивать, если поймет, что я хорошо отвечаю на вопрос - все ради того, чтобы покрыть больше вопросов по этим трем темам. И, действительно, в какие-то моменты я чувствовал себя на шоу "Самый умный", как только я давал норм ответ, он сразу же накидывал следующий вопрос, не давая перевести дух. В таком формате мы провели полтора часа интенсивного обсуждения нон-стопом. Прикольный опыт, очень крутой интервьюер, но это супер энергозатратный формат.
8. Фит-интервью с командой
Это последний этап, на котором мы еще раз встретились с руководителем, только на этот раз с ним была менеджер из будущей команды. На этом этапе не было сложных вопросов, мы познакомились, ребята ответили на мои вопросы о работе и я ответил на пару вопросов о себе.
Второй вайб-чек был пройден, и дальше все следующие встречи были про оффер и его условия, но это совсем другая история...
❤13🔥9🤔7
Про infra.conf 2025 от Яндекса
На больших техно-конференциях мне особенно интересно послушать доклады на темы, в которых я сам разбирался или с которыми были связаны реальные проекты - всегда остается интрига:
- А вдруг ребята сделали круче, чем мы?
- А вдруг они нашли какую-то хитрость, которую мы прощелкали?
- А как они решили нюансы Х и Y?
- И т.д.
Так происходит и с конференцией Infra.Conf 2025 от Яндекса - infra.conf 2025, которая пройдет 5 июня в Москве. Это конференция от Яндекс Инфраструктуры, на которой будут доклады про платформенную разработку, применение LLM, обеспечение безопасности, инфраструктуру для ML и мобильной разработки.
Лично меня больше всего заинтересовали такие доклады, на которые я забукал себе время в календаре:
1. Превозмогая опенсорс: опыт внедрения OpenTelemetry, Qryn и Coroot в ecom.tech
В этом докладе спикер расскажет как они выстраивали систему наблюдаемости в крупном e-commerce (Самокат), используя опенсорс-решения OpenTelemetry, Qryn и Coroot. В анонсе он обещает рассказать почему они отказались от Elastic APM, и почему Grafana Tempo не справился с нагрузкой. Как MinIO не выдержал объёма данных, переход на S3 привёл к потере трейсов, а Qryn с ClickHouse помог решить проблему хранения. Как они научились превращать трейсы в метрики с помощью VictoriaMetrics, и как Coroot помог анализировать аномалии и быстрее разбираться с инцидентами. Звучит все очень интригующе.
2. Tetragon: лучшие практики и нюансы разработки Tracing Policy от Positive Technologies
Что такое Tetragon, Cilium и Tracing Policy я не знаю, но меня подкупает, что спикер будет говорить о eBPF и о его применении в теме ИБ. Поскольку я не гуру eBPF, вижу для себя полезным посмотреть на практический кейс использования этой технологии, которая активно используется и в теме observability.
3. Облачные технологии по приземлённым ценам: как мы оптимизировали затраты без ущерба для производительности от Magnit Tech
В докладе спикер обещает рассказать об их подходе к выявлению неэффективно используемых ресурсов в Облаке и способах оптимизации затрат без ущерба производительности. Помимо праздного любопытства, мне интересен этот кейс и с практической стороны - вдруг я пойму, как могу оптимизировать инфру у себя?
Конференция будет проходить очно в Москве, но есть возможность посмотреть и онлайн, в любом случае обязательно зарегаться.
На больших техно-конференциях мне особенно интересно послушать доклады на темы, в которых я сам разбирался или с которыми были связаны реальные проекты - всегда остается интрига:
- А вдруг ребята сделали круче, чем мы?
- А вдруг они нашли какую-то хитрость, которую мы прощелкали?
- А как они решили нюансы Х и Y?
- И т.д.
Так происходит и с конференцией Infra.Conf 2025 от Яндекса - infra.conf 2025, которая пройдет 5 июня в Москве. Это конференция от Яндекс Инфраструктуры, на которой будут доклады про платформенную разработку, применение LLM, обеспечение безопасности, инфраструктуру для ML и мобильной разработки.
Лично меня больше всего заинтересовали такие доклады, на которые я забукал себе время в календаре:
1. Превозмогая опенсорс: опыт внедрения OpenTelemetry, Qryn и Coroot в ecom.tech
В этом докладе спикер расскажет как они выстраивали систему наблюдаемости в крупном e-commerce (Самокат), используя опенсорс-решения OpenTelemetry, Qryn и Coroot. В анонсе он обещает рассказать почему они отказались от Elastic APM, и почему Grafana Tempo не справился с нагрузкой. Как MinIO не выдержал объёма данных, переход на S3 привёл к потере трейсов, а Qryn с ClickHouse помог решить проблему хранения. Как они научились превращать трейсы в метрики с помощью VictoriaMetrics, и как Coroot помог анализировать аномалии и быстрее разбираться с инцидентами. Звучит все очень интригующе.
2. Tetragon: лучшие практики и нюансы разработки Tracing Policy от Positive Technologies
Что такое Tetragon, Cilium и Tracing Policy я не знаю, но меня подкупает, что спикер будет говорить о eBPF и о его применении в теме ИБ. Поскольку я не гуру eBPF, вижу для себя полезным посмотреть на практический кейс использования этой технологии, которая активно используется и в теме observability.
3. Облачные технологии по приземлённым ценам: как мы оптимизировали затраты без ущерба для производительности от Magnit Tech
В докладе спикер обещает рассказать об их подходе к выявлению неэффективно используемых ресурсов в Облаке и способах оптимизации затрат без ущерба производительности. Помимо праздного любопытства, мне интересен этот кейс и с практической стороны - вдруг я пойму, как могу оптимизировать инфру у себя?
Конференция будет проходить очно в Москве, но есть возможность посмотреть и онлайн, в любом случае обязательно зарегаться.
Мероприятия | Yandex Infrastructure
infra.conf 2025. Конференция Yandex Infrastructure.
Всё про создание инфраструктуры и эксплуатацию высоконагруженных систем.
👍5❤4
Когда TPM все таки нужен (а когда нет)
Пишу сейчас статью на Хабр про роль TPM (Technical Product Manager) - кто это, зачем нужен, как в нее попадают люди и все такое. И довольно продолжительное время пытался осмыслить какой-то ключевой фактор, который сильнее всего определяет, нужна такая роль в команде или нет.
Начал я с тезиса о том, что TPM нужен ТОЛЬКО тогда, когда пользователями продукта являются инженеры. Типа любой продакт должен знать своих клиентов, а тут вот клиенты технари, значит и продакт должен быть соответствующим. На что мои дорогие ревьюеры справедливо накинули мне пример продукта T-ID (Tinkoff ID) и его аналогов - система для упрощенной авторизации на сайте/приложении: заключаешь договор, подключаешь SDK в свой код и твои пользователи получают возможность залогиниться в два клика. Пользователями являются обычные люди, но продукт имеет явную техническую составляющую, которая сильно влияет на его развитие (инфра, SDK, комплаенс и т.д.). Соответственно, развивать такой продукт без технической насмотренности нельзя.
Продолжая анализ, я пришел к новому тезису - чем сильнее стратегия развития продукта зависит от технических факторов, тем сильнее команде нужен TPM. Если продукт можно развивать, не углубляясь в технических аспекты, а руководствоваться только пользовательскими потребностями, то TPM тут не нужен (это 99% случаев). Если без понимания архитектуры и технологий и/или процессов разработки сделать продукт хорошо не получится - вот тут-то и нужен TPM. Пока у меня есть уверенность в этом тезисе.
P.S. Кто готов поучаствовать в ревью статьи на Хабр - пишите в личку, я буду благодарен за помощь!😊
Пишу сейчас статью на Хабр про роль TPM (Technical Product Manager) - кто это, зачем нужен, как в нее попадают люди и все такое. И довольно продолжительное время пытался осмыслить какой-то ключевой фактор, который сильнее всего определяет, нужна такая роль в команде или нет.
Начал я с тезиса о том, что TPM нужен ТОЛЬКО тогда, когда пользователями продукта являются инженеры. Типа любой продакт должен знать своих клиентов, а тут вот клиенты технари, значит и продакт должен быть соответствующим. На что мои дорогие ревьюеры справедливо накинули мне пример продукта T-ID (Tinkoff ID) и его аналогов - система для упрощенной авторизации на сайте/приложении: заключаешь договор, подключаешь SDK в свой код и твои пользователи получают возможность залогиниться в два клика. Пользователями являются обычные люди, но продукт имеет явную техническую составляющую, которая сильно влияет на его развитие (инфра, SDK, комплаенс и т.д.). Соответственно, развивать такой продукт без технической насмотренности нельзя.
Продолжая анализ, я пришел к новому тезису - чем сильнее стратегия развития продукта зависит от технических факторов, тем сильнее команде нужен TPM. Если продукт можно развивать, не углубляясь в технических аспекты, а руководствоваться только пользовательскими потребностями, то TPM тут не нужен (это 99% случаев). Если без понимания архитектуры и технологий и/или процессов разработки сделать продукт хорошо не получится - вот тут-то и нужен TPM. Пока у меня есть уверенность в этом тезисе.
P.S. Кто готов поучаствовать в ревью статьи на Хабр - пишите в личку, я буду благодарен за помощь!😊
👍5🤔1
Про статью на Хабр о TPM
С момента моего перехода в технический менеджмент, особенно с погружением в продуктовую его часть, я немного мечтал написать статью на Хабр о TPM. В российских интернетах не много информации об этой роли и мне хотелось восполнить этот недостаток своим опытом. В статье я хотел рассказать, как вижу роль Technical Product Manager, нафига они вообще нужны - это очередной Scrum Master Pro Max или в этой роли действительно есть хоть какой-то смысл.
И наконец-то я сделал это - статья уже на Хабре!
В ней делюсь опытом работы в этой роли:
- Когда TPM действительно нужен команде, а когда это пустая трата денег
- Почему техническая экспертиза становится критичной для некоторых продуктов
- 17 навыков, которые реально требуются на практике
- Как люди переходят в TPM из разработки, аналитики и продактов.
Интересного чтения:)
С момента моего перехода в технический менеджмент, особенно с погружением в продуктовую его часть, я немного мечтал написать статью на Хабр о TPM. В российских интернетах не много информации об этой роли и мне хотелось восполнить этот недостаток своим опытом. В статье я хотел рассказать, как вижу роль Technical Product Manager, нафига они вообще нужны - это очередной Scrum Master Pro Max или в этой роли действительно есть хоть какой-то смысл.
И наконец-то я сделал это - статья уже на Хабре!
В ней делюсь опытом работы в этой роли:
- Когда TPM действительно нужен команде, а когда это пустая трата денег
- Почему техническая экспертиза становится критичной для некоторых продуктов
- 17 навыков, которые реально требуются на практике
- Как люди переходят в TPM из разработки, аналитики и продактов.
Интересного чтения:)
Хабр
Technical Product Manager — кто это, а главное, зачем?
Привет, Хабр! Меня зовут Даниэль Халиулин и должен признаться, что я Technical Product Manager (TPM) или технический менеджер продукта, если по-русски. Последние годы провел в этой должности на разных...
🔥16👍5🤔2
Когда продолбать задачи не так уж плохо
Зацепила одна мысль из книги "Путь джедая" Макса Дорофеева. В разделе 6.4.3 он говорит о том, что на пути к большим важным и полезным задачам нас встречает много второстепенных задач, которые тоже претендуют на наше внимание. И если уделять внимание всем таким задачам, то просто не останется сил на то, что бы заниматься действительно важными и полезными вещами. Поэтому в какой-то момент надо научиться не бояться продалбывать такие второстепенные задачи, выработать, своего рода, иммунитет к таким локальным провалам ради того, чтобы оставались силы на важное.
Он приводит близкую мне аналогию бойцовского поединка - если во время боя ты будешь думать только о том, как не пропустить удар, то победить скорее всего не получится. Если противник твоего уровня, то он обязательно достанет тебя. Поэтому чтобы победить нужно быть готовым пропустить какие-то удары ради того, чтобы нанести более сокрушительные. В конечном итоге, хоть ты и будешь с синяками, но всё таки выиграешь бой (но это не точно).
Эта идея звучит для меня как таблетка от FOMO (fear of missing out, боязнь пропустить интересное). Вместо того, чтобы переживать о том, что я что-то упускаю, лучше сфокусироваться на поставленных целях и задачах и принять как норму, что в чём-то второстепенном я точно продолбаюсь. Но если раньше я бы переключался и тратил энергию на то, чтобы не допустить этот провал во второстепенном вопросе, то сейчас я могу со спокойной душой забить. Ведь я сфокусирован на более весомых задачах.
Естественно, это всё очень гибко. Иногда в силу разных причин то, что было второстепенным, становится более важным. Как Макс пишет в книге "в этом мире не всё всегда и везде, а кое-что иногда и местами".
---
Пост-повтор от поста 2023 года.
Зацепила одна мысль из книги "Путь джедая" Макса Дорофеева. В разделе 6.4.3 он говорит о том, что на пути к большим важным и полезным задачам нас встречает много второстепенных задач, которые тоже претендуют на наше внимание. И если уделять внимание всем таким задачам, то просто не останется сил на то, что бы заниматься действительно важными и полезными вещами. Поэтому в какой-то момент надо научиться не бояться продалбывать такие второстепенные задачи, выработать, своего рода, иммунитет к таким локальным провалам ради того, чтобы оставались силы на важное.
Он приводит близкую мне аналогию бойцовского поединка - если во время боя ты будешь думать только о том, как не пропустить удар, то победить скорее всего не получится. Если противник твоего уровня, то он обязательно достанет тебя. Поэтому чтобы победить нужно быть готовым пропустить какие-то удары ради того, чтобы нанести более сокрушительные. В конечном итоге, хоть ты и будешь с синяками, но всё таки выиграешь бой (но это не точно).
Эта идея звучит для меня как таблетка от FOMO (fear of missing out, боязнь пропустить интересное). Вместо того, чтобы переживать о том, что я что-то упускаю, лучше сфокусироваться на поставленных целях и задачах и принять как норму, что в чём-то второстепенном я точно продолбаюсь. Но если раньше я бы переключался и тратил энергию на то, чтобы не допустить этот провал во второстепенном вопросе, то сейчас я могу со спокойной душой забить. Ведь я сфокусирован на более весомых задачах.
Естественно, это всё очень гибко. Иногда в силу разных причин то, что было второстепенным, становится более важным. Как Макс пишет в книге "в этом мире не всё всегда и везде, а кое-что иногда и местами".
---
Пост-повтор от поста 2023 года.
🔥10❤4
Про "Искусство войны"
На днях дочитал книгу Сунь-Цзы "Искусство войны" и вот какие мысли почерпнул для себя и какими хочу поделиться с вами.
- Хоть автор и говорит о войне в буквальном смысле, дальше в посте я буду писать о войне как конкуренции за клиентов, рынок, ресурсы, время и влияние в бизнес-среде.
- Осознал, что часто видел в себе и других подход "выложить все карты на стол и открыто поговорить" - мне это видится более честным и благородным, даже если итогое решение получится не очень. Однако иногда это может быть контрпродуктивно, если другая сторона настроена на "войну" и скрытые манипуляции. И тут нужна какая-то мудрость, чтобы распознать этот настрой и не раскрыть лишней информации.
- Довольно долго я игнорировал эту "темную" часть бизнес-реальности полный уверенности, что мы делаем общее дело и все такое. Но надо признать факт - не все люди настроены дружелюбно, не все думают в формате win-win, есть люди, которые используют других для достижения своих личных целей и готовы делать многое ради своей выгоды. И это надо учитывать.
- Автор уделяет немалую часть книги работе со шпионами и информаторами и это тоже как будто нечестно что-ли! Однако, вспомните сами, зачастую самая свежая и практичная информация может приходить не по "официальным каналам", а от отдельных людей. Слухи, сплетни и вот это все - частенько именно эта информация помогает быстрее подготовиться к каким-нибудь изменением. При этом здесь тоже ловлю себя на мысли, что хочу "быть выше всего этого" и игнорирую такую информацию. Возможно, зря.
- В бизнес-контексте для меня это подчеркнуло важность нетворкинга и связей. В очередной раз напомнил себе, что самые ценные инсайты приходили не из докладов и статей, а из личных бесед в людьми за бокалом чего-нибудь.
- Эта интересная аналогия показывает еще одну грань лидерства - умение ставить команду в такие условия, в которых успех неизбежен или наиболее вероятен. С одной стороны, лидер должен создавать такие условия, а с другой иметь решительность направить команду именно в эту сторону, хотя возможна тысяча других вариантов.
- Для меня эта мысль ценна тем, что иногда я стремлюсь создать скорее комфортные, а не результативные условия для команды. Такой вектор исходит из веры, что если создать профессионалам норм условия, то дальше они сами будут работать на результат - должен признаться, я обжигался тут не один раз.
В целом, книга произвела на меня смешанное впечатление. У меня было от нее много ожиданий, которые в итоге не оправдались. Автор пишет витиевато, не спеша пояснять многие из своих идей. Часть информации и вовсе относится исключительно к старым временам. Многие ценные мысли написаны в формате каких-то афоризмов - коротко и неинформативно. Благо, книга короткая, поэтому ROI относительно потраченного времени нормальный:)
На днях дочитал книгу Сунь-Цзы "Искусство войны" и вот какие мысли почерпнул для себя и какими хочу поделиться с вами.
- Хоть автор и говорит о войне в буквальном смысле, дальше в посте я буду писать о войне как конкуренции за клиентов, рынок, ресурсы, время и влияние в бизнес-среде.
Война — путь обмана. Поэтому, если можешь что-то — показывай противнику, что не можешь; если используешь что-то — показывай, что не используешь
- Осознал, что часто видел в себе и других подход "выложить все карты на стол и открыто поговорить" - мне это видится более честным и благородным, даже если итогое решение получится не очень. Однако иногда это может быть контрпродуктивно, если другая сторона настроена на "войну" и скрытые манипуляции. И тут нужна какая-то мудрость, чтобы распознать этот настрой и не раскрыть лишней информации.
- Довольно долго я игнорировал эту "темную" часть бизнес-реальности полный уверенности, что мы делаем общее дело и все такое. Но надо признать факт - не все люди настроены дружелюбно, не все думают в формате win-win, есть люди, которые используют других для достижения своих личных целей и готовы делать многое ради своей выгоды. И это надо учитывать.
Знание положения противника можно получить только от людей.
- Автор уделяет немалую часть книги работе со шпионами и информаторами и это тоже как будто нечестно что-ли! Однако, вспомните сами, зачастую самая свежая и практичная информация может приходить не по "официальным каналам", а от отдельных людей. Слухи, сплетни и вот это все - частенько именно эта информация помогает быстрее подготовиться к каким-нибудь изменением. При этом здесь тоже ловлю себя на мысли, что хочу "быть выше всего этого" и игнорирую такую информацию. Возможно, зря.
- В бизнес-контексте для меня это подчеркнуло важность нетворкинга и связей. В очередной раз напомнил себе, что самые ценные инсайты приходили не из докладов и статей, а из личных бесед в людьми за бокалом чего-нибудь.
Ведя войско, следует ставить его в такие условия, как если бы, забравшись на высоту, убрали лестницы.
- Эта интересная аналогия показывает еще одну грань лидерства - умение ставить команду в такие условия, в которых успех неизбежен или наиболее вероятен. С одной стороны, лидер должен создавать такие условия, а с другой иметь решительность направить команду именно в эту сторону, хотя возможна тысяча других вариантов.
- Для меня эта мысль ценна тем, что иногда я стремлюсь создать скорее комфортные, а не результативные условия для команды. Такой вектор исходит из веры, что если создать профессионалам норм условия, то дальше они сами будут работать на результат - должен признаться, я обжигался тут не один раз.
В целом, книга произвела на меня смешанное впечатление. У меня было от нее много ожиданий, которые в итоге не оправдались. Автор пишет витиевато, не спеша пояснять многие из своих идей. Часть информации и вовсе относится исключительно к старым временам. Многие ценные мысли написаны в формате каких-то афоризмов - коротко и неинформативно. Благо, книга короткая, поэтому ROI относительно потраченного времени нормальный:)
🔥10🤔2❤1👍1💯1
Продвигать свой телеграм-канал сейчас не так-то просто. Органического роста в Телеграме почти нет. А как только ты что-то делаешь для его продвижения, то с одной стороны сталкиваешься с флером инфоцыганства - "ну вот, сейчас будет впаривать очередные курсы" или "он просто хочет зарабатывать на рекламе". А с другой тебе машет рукой внутренний критик, который говорит "да кому интересно, что ты там пишешь?!" и "вот будешь нормально писать, тогда и продвигай". Но если со вторым я знаком очень давно и знаю, как с ним работать, то вот первое - для меня это что-то новое.
Это я все к чему. Я тут решил поучаствовать в конкурсе авторских телеграм-каналов - https://tg-contest.tilda.ws/. Там опытные авторы собирают авторов менее опытных и дают им площадку, чтобы их увидела широкая аудитория и люди оттуда могли подобрать каналы себе по душе. Так что, если на досуге захочется посмотреть на авторские каналы - полистайте канал, где будет проходить конкурс @tg_contest_main. Вдруг найдете для себя что-то интересное.
Голосовать за себя я НЕ призываю - у меня нет стремления там бороться и побеждать. Рассматриваю это скорее как новый интересный опыт и возможность сделать шаг в сфере развития канала. Every step counts.
Это я все к чему. Я тут решил поучаствовать в конкурсе авторских телеграм-каналов - https://tg-contest.tilda.ws/. Там опытные авторы собирают авторов менее опытных и дают им площадку, чтобы их увидела широкая аудитория и люди оттуда могли подобрать каналы себе по душе. Так что, если на досуге захочется посмотреть на авторские каналы - полистайте канал, где будет проходить конкурс @tg_contest_main. Вдруг найдете для себя что-то интересное.
Голосовать за себя я НЕ призываю - у меня нет стремления там бороться и побеждать. Рассматриваю это скорее как новый интересный опыт и возможность сделать шаг в сфере развития канала. Every step counts.
❤4👍3💯1
Пост про фокус на результатах
- каждый раз хихикаю с этого видео (ютуб, вк), и каждый же раз где-то на заднем плане возникает мысль о важности результатов, а не просто упорной работы. Как пелось у Linkin Park - "I tried so hard and got so far But in the end, it doesn't even matter". Ладно, хватит цитат, тем более, что песня "In the End" была совсем не об этом.
Фокус на конечном результате работы - амбициозном, видимом, классном - это та самая штука, которая заставляет мыслить более остро. Когда ты сфокусирован получить результат в условиях ограниченных ресурсов, ты отбрасываешь менее важное, ты бритвой Оккама отрезаешь лишнее, чтобы осталось самое главное. У этого подхода тоже есть оборотная сторона, но кто будет спорить с тем, что более крут тот менеджер, у которого более значимые результаты?
Не могу сказать, что у меня с этим нет проблем. Именно поэтому недавно крепко задумался о фокусе на результатах и решил поделиться парой мыслей тут.
1/ Лучше показывать, чем рассказывать
Можно рассказывать разные концепции, обсуждать уровни реализации, но если есть что-то, что можно показать - код, дизайн, прототип - это точно ускорит получение обратной связи и сделает ее более релеватной. Кроме того такие штуки лучше запоминаются людям - в момент перфоманс-ревью коллега Вася вспомнит скорее ваш первый прототип системы авторизации и то, как это продвинуло диалог, чем десятое обсуждение процесса резолвинга идентификаторов в человекочитаемые строки. Отчасти это связано с тем, что людям проще сказать, что "не так", чем "как именно надо".
2/ На старте любой движухи подумать, что можно отдать в качестве MVP прям завтра.
Не, ну не прям завтра, а на этой неделе, например. Тут MVP я использую в значении "минимальный значимый результат" - что-то такое, что уже будет ценно для поставленной задачи, хоть и решает ее не полностью. Нужно провести исследование - можно по быстрому отдать первую версию плана. Нужно написать RFC - аппрувнуть структуру и основные тезисы (хотя с обсуждением сырого RFC я бы был осторожен). Думаю, принцип понятен. Эта мысль засияла для меня чуть ярче, когда я пилил свой pet-проект - когда ты своими собственными деньгами отвечаешь за разработку, то находить быстрые решения становится полегче. Например, можно не корпеть над текстами транзакционных писем, а просто сделать хоть какие-то уже транзакционные письма, а текст сделать чуть позже.
3/ "Better done than мать его perfect”
Другими словами лучше сделать НОРМ и заданные сроки, чем полировать до совершенства непойми сколько. Ох, сколько раз я себе говорил это - вот еще одно интервью проведу и все будет совсем понятно, вот еще тут формулировки на слайде дополирую и все будет как надо. И ведь все равно не наступает тот счастливый момент, когда все прям супер-пупер! Все равно всегда находится еще одна мелочь, которую надо поправить. Именно поэтому эта фраза так засела в голове - она немного возвращает перфекциониста с небес на землю.
"Мы довольны своей работой МАКСИМАЛЬНО, но, к сожалению, наша работа не дала результат" (с)
- каждый раз хихикаю с этого видео (ютуб, вк), и каждый же раз где-то на заднем плане возникает мысль о важности результатов, а не просто упорной работы. Как пелось у Linkin Park - "I tried so hard and got so far But in the end, it doesn't even matter". Ладно, хватит цитат, тем более, что песня "In the End" была совсем не об этом.
Фокус на конечном результате работы - амбициозном, видимом, классном - это та самая штука, которая заставляет мыслить более остро. Когда ты сфокусирован получить результат в условиях ограниченных ресурсов, ты отбрасываешь менее важное, ты бритвой Оккама отрезаешь лишнее, чтобы осталось самое главное. У этого подхода тоже есть оборотная сторона, но кто будет спорить с тем, что более крут тот менеджер, у которого более значимые результаты?
Не могу сказать, что у меня с этим нет проблем. Именно поэтому недавно крепко задумался о фокусе на результатах и решил поделиться парой мыслей тут.
1/ Лучше показывать, чем рассказывать
Можно рассказывать разные концепции, обсуждать уровни реализации, но если есть что-то, что можно показать - код, дизайн, прототип - это точно ускорит получение обратной связи и сделает ее более релеватной. Кроме того такие штуки лучше запоминаются людям - в момент перфоманс-ревью коллега Вася вспомнит скорее ваш первый прототип системы авторизации и то, как это продвинуло диалог, чем десятое обсуждение процесса резолвинга идентификаторов в человекочитаемые строки. Отчасти это связано с тем, что людям проще сказать, что "не так", чем "как именно надо".
2/ На старте любой движухи подумать, что можно отдать в качестве MVP прям завтра.
Не, ну не прям завтра, а на этой неделе, например. Тут MVP я использую в значении "минимальный значимый результат" - что-то такое, что уже будет ценно для поставленной задачи, хоть и решает ее не полностью. Нужно провести исследование - можно по быстрому отдать первую версию плана. Нужно написать RFC - аппрувнуть структуру и основные тезисы (хотя с обсуждением сырого RFC я бы был осторожен). Думаю, принцип понятен. Эта мысль засияла для меня чуть ярче, когда я пилил свой pet-проект - когда ты своими собственными деньгами отвечаешь за разработку, то находить быстрые решения становится полегче. Например, можно не корпеть над текстами транзакционных писем, а просто сделать хоть какие-то уже транзакционные письма, а текст сделать чуть позже.
3/ "Better done than мать его perfect”
Другими словами лучше сделать НОРМ и заданные сроки, чем полировать до совершенства непойми сколько. Ох, сколько раз я себе говорил это - вот еще одно интервью проведу и все будет совсем понятно, вот еще тут формулировки на слайде дополирую и все будет как надо. И ведь все равно не наступает тот счастливый момент, когда все прям супер-пупер! Все равно всегда находится еще одна мелочь, которую надо поправить. Именно поэтому эта фраза так засела в голове - она немного возвращает перфекциониста с небес на землю.
💯12
Сказки технического менеджера
Продвигать свой телеграм-канал сейчас не так-то просто. Органического роста в Телеграме почти нет. А как только ты что-то делаешь для его продвижения, то с одной стороны сталкиваешься с флером инфоцыганства - "ну вот, сейчас будет впаривать очередные курсы"…
Крч, побочным эффектом (в хорошем смысле!) участия в этом конкурсе стало знакомство с другими авторами каналов в категории управления продуктами.
Было интересно посмотреть, о чем они пишут, о чем они переживают по ходу конкурса. Погулял по их каналам - кто-то пишет размашисто, кто-то более сухо и по делу. Одни фигачат лонгриды, а другие пишут короткие посты. Но все они примечательны тем, что дают авторский ламповый контент - не по заказу компаний и не маркетинга для.
Если вам интересно такое - загляните в папку этих каналов (мой канал там тоже есть!), прогуляйтесь, вдруг найдете для себя что-то интересное - папка "Продакты тут".
Было интересно посмотреть, о чем они пишут, о чем они переживают по ходу конкурса. Погулял по их каналам - кто-то пишет размашисто, кто-то более сухо и по делу. Одни фигачат лонгриды, а другие пишут короткие посты. Но все они примечательны тем, что дают авторский ламповый контент - не по заказу компаний и не маркетинга для.
Если вам интересно такое - загляните в папку этих каналов (мой канал там тоже есть!), прогуляйтесь, вдруг найдете для себя что-то интересное - папка "Продакты тут".
🔥5👍1
Про отдых и выгорание
Совсем скоро я планирую отправиться в недолгий отпуск. И сколько себя помню - всегда относился к своим отпускам стратегически: рассматривал их не сколько как развлекуху, сколько как инвестицию в свою будущую работоспособность и энергичность, ведь если я норм отдохну, то у меня появятся силы достигать! Этот подход не лишен недостатков - например, слишком серьезное отношение к отдыху создает напряженность, что в свою очередь только вредит его качеству. Однако мне 30+, я сохранил работоспособность и энтузиазм - значит это как-то работает:)
Многие пишут, что качественно отдыхать не менее важно, чем качественно работать, и я полностью согласен с этим. Ведь если плохо отдыхать, то не будет энергии, выгоришь, станешь развалюхой - а они никому не нужны, с такими людьми мало кто хочет иметь дело. Не хочется быть таким человеком.
Переломным моментом в своем взгляде на отдых я считаю момент, когда я прям осознал, что НИКТО В МИРЕ не позаботится всерьез о моем отдыхе, кроме меня самого. Друзья могут посетовать на синяки под глазами и вялость, но они не заставят меня организовать себе отпуск - сильно настаивать в этой сфере не принято. Семья тоже может не видеть в этом проблемы пока ты более-менее делаешь все, что должен. Вот и получается, что никто не придет тебя спасать от выгорания - заботиться об этом нужно самому.
Как одну из небольших мер против заценил для себя практику вечерних прогулок - выхожу гулять и по ходу дела мысленно отвечаю себе на 3 вопроса:
1. Что хорошего было в этом дне?
2. За что я благодарен сегодня?
3. В чем бы я мог быть получше сегодня?
Иногда сам удивляюсь тому, какие цепочки мыслей возникают. Такое внутреннее обсуждение помогает осмыслить и переживать каждый конкретный день со всеми его вопросиками. Попробуйте, вдруг и вам зайдет.
Совсем скоро я планирую отправиться в недолгий отпуск. И сколько себя помню - всегда относился к своим отпускам стратегически: рассматривал их не сколько как развлекуху, сколько как инвестицию в свою будущую работоспособность и энергичность, ведь если я норм отдохну, то у меня появятся силы достигать! Этот подход не лишен недостатков - например, слишком серьезное отношение к отдыху создает напряженность, что в свою очередь только вредит его качеству. Однако мне 30+, я сохранил работоспособность и энтузиазм - значит это как-то работает:)
Многие пишут, что качественно отдыхать не менее важно, чем качественно работать, и я полностью согласен с этим. Ведь если плохо отдыхать, то не будет энергии, выгоришь, станешь развалюхой - а они никому не нужны, с такими людьми мало кто хочет иметь дело. Не хочется быть таким человеком.
Переломным моментом в своем взгляде на отдых я считаю момент, когда я прям осознал, что НИКТО В МИРЕ не позаботится всерьез о моем отдыхе, кроме меня самого. Друзья могут посетовать на синяки под глазами и вялость, но они не заставят меня организовать себе отпуск - сильно настаивать в этой сфере не принято. Семья тоже может не видеть в этом проблемы пока ты более-менее делаешь все, что должен. Вот и получается, что никто не придет тебя спасать от выгорания - заботиться об этом нужно самому.
Как одну из небольших мер против заценил для себя практику вечерних прогулок - выхожу гулять и по ходу дела мысленно отвечаю себе на 3 вопроса:
1. Что хорошего было в этом дне?
2. За что я благодарен сегодня?
3. В чем бы я мог быть получше сегодня?
Иногда сам удивляюсь тому, какие цепочки мыслей возникают. Такое внутреннее обсуждение помогает осмыслить и переживать каждый конкретный день со всеми его вопросиками. Попробуйте, вдруг и вам зайдет.
❤15🔥7
Про перебивания
Любой менеджер продукта, хоть технический, хоть нет, часто участвует в обсуждениях - планов, фичей, проблем, людей и т.д. И, работая в разных компаниях, я наблюдаю как по-разному команды относятся к перебиванию друг друга в этих обсуждениях. В одних компаниях все обязательно пользуются фичами "Поднять руку" на онлайн-встречах и ждут своей очереди, в других "токен" на высказывание получает тот, кто громче и наглее. В одних говорящему всегда дают высказать свою мысль до конца, в других запросто перебивают и вставляют комментарии прямо по ходу повествования другого человека.
И ведь интересно, что при обоих подходах я НЕ наблюдаю, что бы хоть один из них радикально негативно влиял на результативность общего дела. Казалось бы, если перебивать и не давать высказать важную мысль, то это может сыграть в минус дважды:
1. Страдает вовлеченность человека. Он видит, что его мнение не слушают и перестанет вовлекаться в обсуждения.
2. Можно упустить действительно важный комментарий, который окажет негативное влияние на ход событий.
При том, что я терпеть не могу, когда перебивают меня или других людей при мне - я видел, что "перебивающие" команды двигались вперед и достигали достойного результата. Конечно, я тут немного сравниваю черное и белое - в реальности оттенков намного больше. В командах есть разные люди, которые могут вести себя по-разному в разных обстоятельствах.
Для себя я вывел пару принципов поведения в таких ситуациях:
1. Для достижения результата мне нужно уметь подстроиться под собеседников, а не ломать их своим представлением о коммуникации. Если принято перебивать - штош, надо тоже не стесняться (мне это дается сложно) Если принято давать больше пространства - тоже ок.
2. Если меня перебивают в процессе действительно важной мысли (важной по моему мнению, конечно), то явно обозначаю границу в духе "Дай, пожалуйста, я договорю" или "Педро, не перебивай меня, пожалуйста". В большинстве случаев этого достаточно не только для того, что бы договорить текущую мысль, но и на весь разговор.
3. Если на встрече участники часто перебивают, и темы уходят все дальше от той, по которой я хотел что-то сказать, то стараюсь сразу же записать куда-то мысль или вопрос, чтобы при следующей возможности вернуться к интересующей теме, если она действительно важна для меня.
К слову, зачастую бывает так, что намного полезнее не бороться за пространство в разговоре, а остановиться и послушать мета-информацию - кто за что борется, кто чего избегает, кто к чьему мнению (не) прислушивается. Иногда эти наблюдения помогают в дальнейшем не меньше, чем влияние на русло разговора.
Любой менеджер продукта, хоть технический, хоть нет, часто участвует в обсуждениях - планов, фичей, проблем, людей и т.д. И, работая в разных компаниях, я наблюдаю как по-разному команды относятся к перебиванию друг друга в этих обсуждениях. В одних компаниях все обязательно пользуются фичами "Поднять руку" на онлайн-встречах и ждут своей очереди, в других "токен" на высказывание получает тот, кто громче и наглее. В одних говорящему всегда дают высказать свою мысль до конца, в других запросто перебивают и вставляют комментарии прямо по ходу повествования другого человека.
И ведь интересно, что при обоих подходах я НЕ наблюдаю, что бы хоть один из них радикально негативно влиял на результативность общего дела. Казалось бы, если перебивать и не давать высказать важную мысль, то это может сыграть в минус дважды:
1. Страдает вовлеченность человека. Он видит, что его мнение не слушают и перестанет вовлекаться в обсуждения.
2. Можно упустить действительно важный комментарий, который окажет негативное влияние на ход событий.
При том, что я терпеть не могу, когда перебивают меня или других людей при мне - я видел, что "перебивающие" команды двигались вперед и достигали достойного результата. Конечно, я тут немного сравниваю черное и белое - в реальности оттенков намного больше. В командах есть разные люди, которые могут вести себя по-разному в разных обстоятельствах.
Для себя я вывел пару принципов поведения в таких ситуациях:
1. Для достижения результата мне нужно уметь подстроиться под собеседников, а не ломать их своим представлением о коммуникации. Если принято перебивать - штош, надо тоже не стесняться (мне это дается сложно) Если принято давать больше пространства - тоже ок.
2. Если меня перебивают в процессе действительно важной мысли (важной по моему мнению, конечно), то явно обозначаю границу в духе "Дай, пожалуйста, я договорю" или "Педро, не перебивай меня, пожалуйста". В большинстве случаев этого достаточно не только для того, что бы договорить текущую мысль, но и на весь разговор.
3. Если на встрече участники часто перебивают, и темы уходят все дальше от той, по которой я хотел что-то сказать, то стараюсь сразу же записать куда-то мысль или вопрос, чтобы при следующей возможности вернуться к интересующей теме, если она действительно важна для меня.
К слову, зачастую бывает так, что намного полезнее не бороться за пространство в разговоре, а остановиться и послушать мета-информацию - кто за что борется, кто чего избегает, кто к чьему мнению (не) прислушивается. Иногда эти наблюдения помогают в дальнейшем не меньше, чем влияние на русло разговора.
👍17❤7
Про кастомные доработки в платформах
Одним из вызовов при разработке инженерных платформ в больших компаниях является тема кастомных доработок. У вас есть платформа, которой пользуются десятки или сотни команд. И сценарий обычно один и тот же - приходит большой и влиятельный внутренний клиент (команда, департамент, whatever) и просит сделать такую фичу в платформе, которая действительно будет полезна и ценна для него. Однако проблема в том, что зачастую эта функция не нужна НИКОМУ из пользователей платформы, кроме него. Она будет использоваться эксклюзивно этим большим клиентом.
Сделали такую доработку один раз. Потом еще разок. И ведь нельзя сказать, что пользы нет - большой и важный клиент действительно решает свою задачу с помощью этих фич и в итоге больше зарабатывает или меньше тратит на уровне компании. А разве не для этого и существуют платформы в больших компаниях?! И отказать тоже непросто - отказ делать кастомные штуки может спровоцировать политический конфликт. Отношения с влиятельным клиентом могут стать натянутыми. Он может начать задумываться о разработке собственного решения, что ослабит позиции платформы в компании. И что делать менеджеру платформы в такой ситуации?
Универсального ответа тут не существует, но мне кажется, что смысл имеет следующее:
0.Потрогать траву и успокоиться
1. В каком-то виде заручиться поддержкой руководства т.к. возможно будет эскалация - будет круто, если руководство вам доверяет и знает, что вы не сделаете хрень.
2. Проверить расчеты ценности от кастомной доработки, если они вообще есть. Может оказаться так, что на деле они основаны на очень оптимистичных предположениях или не учитывают какие-то факторы. Если тут обнаружатся несостыковки, они пригодятся на следующих этапах. Например, может оказаться, что в основе предположение роста x3 в год, а на деле вы ждете x1,5.
3. Подумать, есть ли такая мера обобщения предложенной фичи, в которой она будет полезна не только этому клиенту? Есть ли возможность сделать из кастомной идеи такой общий функционал, который даст ценность другим пользователям? Например, клиент хочет показывать в UI статус из какой-то кастомной системы, которая есть только у него. Обобщенный функционал мог бы выглядеть как возможность редактировать виджеты на странице, и одним из виджетов был бы виджет для статусов из той самой системы этого клиента. Таким образом ВСЕ пользователи получили бы возможность менять вид страницы под свои задачи с помощью виджетов, и важный клиент в их числе.
4. Достаточно подробно объяснить важному клиенту почему именно вы отказали ему в фиче. Важно, чтобы он понял, что вы не самодур, а действительно его цените (цените же?) и при этом следите за качеством платформы для всех пользователей. Если у вас будут на руках те самые несостыковки и какие-то цифры, которые покажут потенциал последствия от кастома - покажите их, хоть они тут и не главные.
5. Приготовиться к давлению. Если важный клиент настойчив, то он может в каком-то виде начать давить на вас (в корпорациях это могут делать тонко). Кмк, тут важно сохранить фокус на будущем сотрудничестве и не допустить, чтобы этот конфликт стал деструктивным. Это непросто.
А вообще, работа в платформах это довольно специфичная история. Надо будет об этом еще написать что ли...
Одним из вызовов при разработке инженерных платформ в больших компаниях является тема кастомных доработок. У вас есть платформа, которой пользуются десятки или сотни команд. И сценарий обычно один и тот же - приходит большой и влиятельный внутренний клиент (команда, департамент, whatever) и просит сделать такую фичу в платформе, которая действительно будет полезна и ценна для него. Однако проблема в том, что зачастую эта функция не нужна НИКОМУ из пользователей платформы, кроме него. Она будет использоваться эксклюзивно этим большим клиентом.
Сделали такую доработку один раз. Потом еще разок. И ведь нельзя сказать, что пользы нет - большой и важный клиент действительно решает свою задачу с помощью этих фич и в итоге больше зарабатывает или меньше тратит на уровне компании. А разве не для этого и существуют платформы в больших компаниях?! И отказать тоже непросто - отказ делать кастомные штуки может спровоцировать политический конфликт. Отношения с влиятельным клиентом могут стать натянутыми. Он может начать задумываться о разработке собственного решения, что ослабит позиции платформы в компании. И что делать менеджеру платформы в такой ситуации?
Универсального ответа тут не существует, но мне кажется, что смысл имеет следующее:
0.
1. В каком-то виде заручиться поддержкой руководства т.к. возможно будет эскалация - будет круто, если руководство вам доверяет и знает, что вы не сделаете хрень.
2. Проверить расчеты ценности от кастомной доработки, если они вообще есть. Может оказаться так, что на деле они основаны на очень оптимистичных предположениях или не учитывают какие-то факторы. Если тут обнаружатся несостыковки, они пригодятся на следующих этапах. Например, может оказаться, что в основе предположение роста x3 в год, а на деле вы ждете x1,5.
3. Подумать, есть ли такая мера обобщения предложенной фичи, в которой она будет полезна не только этому клиенту? Есть ли возможность сделать из кастомной идеи такой общий функционал, который даст ценность другим пользователям? Например, клиент хочет показывать в UI статус из какой-то кастомной системы, которая есть только у него. Обобщенный функционал мог бы выглядеть как возможность редактировать виджеты на странице, и одним из виджетов был бы виджет для статусов из той самой системы этого клиента. Таким образом ВСЕ пользователи получили бы возможность менять вид страницы под свои задачи с помощью виджетов, и важный клиент в их числе.
4. Достаточно подробно объяснить важному клиенту почему именно вы отказали ему в фиче. Важно, чтобы он понял, что вы не самодур, а действительно его цените (цените же?) и при этом следите за качеством платформы для всех пользователей. Если у вас будут на руках те самые несостыковки и какие-то цифры, которые покажут потенциал последствия от кастома - покажите их, хоть они тут и не главные.
5. Приготовиться к давлению. Если важный клиент настойчив, то он может в каком-то виде начать давить на вас (в корпорациях это могут делать тонко). Кмк, тут важно сохранить фокус на будущем сотрудничестве и не допустить, чтобы этот конфликт стал деструктивным. Это непросто.
А вообще, работа в платформах это довольно специфичная история. Надо будет об этом еще написать что ли...
💯7🔥5❤1
Про сон
Фундаментом здоровой продуктивности (в смысле без веществ) является нормальный сон. Если спишь хорошо - это даёт базу, на которой можно уже строить другие дела. Если спишь плохо - все техники продуктивности мира будут иметь минимальный эффект.
Меня этот факт удивляет своей простотой и действенностью. Каждый раз в нем убеждаюсь, когда плохо посплю пару дней.
Не знаю как у вас, а я периодически не могу быстро заснуть - мысли о проектах и бизнес-идеи, которые сделают меня богачом, сменяют одна другую. В такие моменты использую хак: говорю себе, что я обо в чем этом обязательно подумаю, но попозже; а сейчас я просто уставший человек, которому нужен отдых. И после этого почему-то отпускает.
Ну ладно, я пошел спать, всем спокойной ночи)
Фундаментом здоровой продуктивности (в смысле без веществ) является нормальный сон. Если спишь хорошо - это даёт базу, на которой можно уже строить другие дела. Если спишь плохо - все техники продуктивности мира будут иметь минимальный эффект.
Меня этот факт удивляет своей простотой и действенностью. Каждый раз в нем убеждаюсь, когда плохо посплю пару дней.
Не знаю как у вас, а я периодически не могу быстро заснуть - мысли о проектах и бизнес-идеи, которые сделают меня богачом, сменяют одна другую. В такие моменты использую хак: говорю себе, что я обо в чем этом обязательно подумаю, но попозже; а сейчас я просто уставший человек, которому нужен отдых. И после этого почему-то отпускает.
Ну ладно, я пошел спать, всем спокойной ночи)
❤18👍3
Сказки технического менеджера
Про кастомные доработки в платформах Одним из вызовов при разработке инженерных платформ в больших компаниях является тема кастомных доработок. У вас есть платформа, которой пользуются десятки или сотни команд. И сценарий обычно один и тот же - приходит большой…
Еще немного про платформы
Продолжая тему корпоративных платформ, захотел рассказать, что это такое и чем платформы отличаются от обычных систем и продуктов.
Платформа - это такая ИТ-система, которая решает комплексные задачи, решения которых в свою очередь важны другим системам для предоставления ценности конечному пользователю. По-простому, это такая система, которая дает некий функциональный фундамент, используя который другие системы могут сделать что-то, что даст ценность уже конечному клиенту. А клиент за нее заплатит.
Например, CI-платформа внутри компании никак не приносит денег и ценности клиентам напрямую (они даже не знают, что это такое, а главное зачем), но благодаря ей разработчики могут собирать свои приложения, строить автоматизацию и не ломать себе мозг лишний раз. Это ускоряет их работу, что, в свою очередь, позволяет больше времени уделить разработке продукта для милого клиента. Получается, что CI-платформа предоставляет какой-то кирпичик, который встраивается в технологический фундамент вообще других систем.
Как правило, платформы вырастают из потребности оптимизировать когнитивные, временные и, в конечном итоге, финансовые затраты компании на какие-то общие технические задачи, которые важны широкому кругу корпоративных систем. Чтобы каждый раз при разработке новой системы не решать одни и те же задачи, предлагается делать платформы, которые решат эти задачи за всех разом.
Например, многим системам нужна ролевая модель и управление доступами - го сделаем IAM-платформу (Identity and Access Management), чтобы каждый не изобретал свой велосипед. Или многим системам нужен качественный мониторинг - го сделаем платформу наблюдаемости, чтобы к ней легко подключались и не ломали голову над своими мониторингами каждый раз. Или нам нужно каждый раз поддерживать мультиязычность в UI в наших продуктах - го уже сделаем платформу локализации и будем управлять текстами централизованно. В общем, принцип вы поняли.
Важной чертой платформы является простота и скорость интеграции с ней. Это когда каждый новый продукт может просто и без доработок в платформе интегрироваться с ней, и начать получать ценность. Это становится возможным, когда платформа задает общие стандарты и контракты - вот тебе общий API, вот тебе хорошие гайды, вот тебе лучшие практики. Команда продукта делает все как написано и, вуаля, начинает получать ценность от платформы!
Конечно, я описываю утрированно идеальный случай - на деле в платформе могут быть какие-то неочевидности, гайды могут терять актуальность и т.д. Но для команды, которая делает конечных продукт, преодолеть эти шероховатности в 100 раз проще, чем самим решать изначальную задачу (например, получить норм мониторинг). И вот мера того, как легко и просто интегрироваться (условный time-to-value), это одна из качественных характеристик платформы.
Продолжая тему корпоративных платформ, захотел рассказать, что это такое и чем платформы отличаются от обычных систем и продуктов.
Платформа - это такая ИТ-система, которая решает комплексные задачи, решения которых в свою очередь важны другим системам для предоставления ценности конечному пользователю. По-простому, это такая система, которая дает некий функциональный фундамент, используя который другие системы могут сделать что-то, что даст ценность уже конечному клиенту. А клиент за нее заплатит.
Например, CI-платформа внутри компании никак не приносит денег и ценности клиентам напрямую (они даже не знают, что это такое, а главное зачем), но благодаря ей разработчики могут собирать свои приложения, строить автоматизацию и не ломать себе мозг лишний раз. Это ускоряет их работу, что, в свою очередь, позволяет больше времени уделить разработке продукта для милого клиента. Получается, что CI-платформа предоставляет какой-то кирпичик, который встраивается в технологический фундамент вообще других систем.
Как правило, платформы вырастают из потребности оптимизировать когнитивные, временные и, в конечном итоге, финансовые затраты компании на какие-то общие технические задачи, которые важны широкому кругу корпоративных систем. Чтобы каждый раз при разработке новой системы не решать одни и те же задачи, предлагается делать платформы, которые решат эти задачи за всех разом.
Например, многим системам нужна ролевая модель и управление доступами - го сделаем IAM-платформу (Identity and Access Management), чтобы каждый не изобретал свой велосипед. Или многим системам нужен качественный мониторинг - го сделаем платформу наблюдаемости, чтобы к ней легко подключались и не ломали голову над своими мониторингами каждый раз. Или нам нужно каждый раз поддерживать мультиязычность в UI в наших продуктах - го уже сделаем платформу локализации и будем управлять текстами централизованно. В общем, принцип вы поняли.
Важной чертой платформы является простота и скорость интеграции с ней. Это когда каждый новый продукт может просто и без доработок в платформе интегрироваться с ней, и начать получать ценность. Это становится возможным, когда платформа задает общие стандарты и контракты - вот тебе общий API, вот тебе хорошие гайды, вот тебе лучшие практики. Команда продукта делает все как написано и, вуаля, начинает получать ценность от платформы!
Конечно, я описываю утрированно идеальный случай - на деле в платформе могут быть какие-то неочевидности, гайды могут терять актуальность и т.д. Но для команды, которая делает конечных продукт, преодолеть эти шероховатности в 100 раз проще, чем самим решать изначальную задачу (например, получить норм мониторинг). И вот мера того, как легко и просто интегрироваться (условный time-to-value), это одна из качественных характеристик платформы.
🔥11❤2👍1