Про Meeting notes

MN (Meeting Notes), протокол встреч, MoM (Minutes of Meeting) - как только не называют заметки по результатам встречи, в которых отражают основные обсуждения и договоренности. Большинство инженеров от природы очень легко относятся к этой штуке - или пишут на скорую руку в формате потока сознания, или вовсе забивают на них. А зачем тратить время на эту бюрократию? Главное, что мы все решили и поняли друг друга на встрече! "По крайней мере, мне так показалось, что поняли... Они даже согласились с тем, что я предложил...". А потом наступает момент, когда договоренности должны быть реализованы и тут оказывается, что поняли "они" не совсем так, как надо. А часть важных моментов как-то вот упустили - "они" искренне сожалеют, "мы" тоже. В итоге результат грустный - работа в срок не сделана.

Можно подумать, что я представляю MN (давайте я их так буду называть) как супер-решение всех проблем с коммуникацией, но это не так.

Так зачем нужны эти самые MN?
1. Чтобы поделиться результатами встречи с теми, кто на не быть не мог. Болезни, отпуска, кошк рожает - все мы люди и иногда можем пропустить встречу по важному нам проекту. В таком случае приятно получить MNку с выжимкой встречи и понять, что мог и не приходить ты остался в контексте.
2. Чтобы убедиться, что все стороны встречи правильно друг друга поняли.
Кто участвовал в сколько-нибудь значимых переговорах, тот знает, насколько обманчивой бывает мысль, что вы друг друга понимаете. Так вот, написанные MN создают площадку для участников встречи, чтобы оценить качество понимания друг друга. Сколько раз у меня было такое, что на встрече вроде ударили по рукам, а после MN приходят комментарии в духе "в п.3 написано, что мы сделаем Х за неделю, но мы договаривались на месяц" или "вы пишете, что Х случилось по причине Y, но так сказать будет неправильно, потому что Z". Тут, конечно, можно было бы сказать, что это именно я переговорщик так себе, поэтому так, но у других я тоже замечал такое много раз.
3. Чтобы освободить голову
Это одна из моих любимых "фич" MNок. Если после каждой значимой встречи писать MNку, то это освобождает голову от необходимости помнить, кто кому и что должен - все это записано и публично. Когда у тебя много проектов/фич/продуктов, то в голове это поместить просто нереально, поэтому я ценю MN за то, что позволяют выгрузить хоть небольшой дамп моей памяти, освободив ее для чего-то более важного (рилсы, например).
4. Чтобы прикрыть жопу.
Решил оставить этот пункт как есть:) MNки бывают очень актуальны, когда через время после встречи кто-то приходит и начинает необоснованно требовать выполнения какой-то работы - слишком рано или больший объем. В таких случаях очень полезно вместе с "просителем" заглянуть в MNку и посмотреть, о чем именно вы тогда договорились. Сколько раз это переводило разговор из русла "Вы обещали сделать нам X и Y!" в "Ой, сорри, мы договаривались только на объем X". А если бы мы не написали MN той встречи? Пришлось бы отвлекаться от других задач и тратить время и энергию на то, чтобы передоговориться с заведомо завышенными ожиданиями". Кстати, это возможно благодаря одному негласному правилу - если что-то написано в MN и ты не написал ничего против, значит ты автоматически согласен с тем, что там написано.

Подведем итог:
1. Прочитали 4 пункта о важности ведения MNок.
2. Решили бахнуть лайк посту и более дисциплинированно относиться к MNкам.

Про признание среди инженеров

Когда технический менеджер попадает в команду инженеров в качестве участника рабочего процесса (например, в роли владельца продукта или просто какого-то стейкхолдера), то для будущего эффективного взаимодействия должна произойти одна интересная штука. Эта штука - признание командой инженеров авторитета этого менеджера.

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

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

Что может помочь техническому менеджеру получить это признание?
На этот счет у меня несколько мыслей:
0. Поработать с кодом проекта своими руками
Написать какую-нибудь полезную мелкую утилиту, до которой не доходили руки у команды; написать какие-нибудь скрипты, которые автоматизируют работу с тем, что напрашивается; вникнуть в архитектуру проекта и поспрашивать ребят о неочевидных моментах - все эти элементы объединяет работа с кодом собственным руками. Да, копание в коде это не то, зачем обычно нанимают технических менеджеров, но когда инженеры увидят, что вы реально шарите на уровне кода - вы получите 10 очков инженерного увожения. "Talk is cheap show me the code" (c) Линус Торвальдс

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

2. Покажи полезный результат в зоне своей ответственности
Копаться в коде и слушать на 1-1 это, конечно, хорошо, но не менее важно показать реальный результат своей работы, на которую тебя, собственно, взяли. Если задачи крутятся вокруг клиентских исследований - покажи, какие гипотезы были, почему они важны и что ты накопал по ним, какие выводы сделал. Если задачи больше вокруг стратегии - покажи как ты над ней работаешь, на какие ключевые вопросы в ней отвечаешь. Если задачи про рост - покажи какие каналы и почему задействуешь, какие планы по росту и зачем он нужен. Крч, идея в том, чтобы для инженеров было очевидно какую ценность команде ты приносишь - без этого все остальное становится просто шелухой.

Как считаете, нужно это признание техническому менеджеру или и без него норм?

Эмоциональный аттач к продукту это полезно или не очень?

Или другими словами эмоциональная привязанность к результату своего труда - будь то продукт, проект или команда, которая выполняет задачи. Я имею ввиду, когда человек не просто нейтрально выполняет поставленные задачи (может быть и амбициозные), а искренне переживает за успех продукта, чувствует внутренний эмоциональный отклик, когда с его продуктом происходит что-то хорошее или что-то плохое. Например, когда кто-то из стейкхолдеров необоснованно ругает продукт. Или когда, напротив, какой-нибудь NPS продутта (Net Promoted Score, индекс лояльности клиентов) побил рекорд в этот раз. Вот такая эмоциональная вовлеченность это хорошо для продакта или не очень?

С одной стороны, на такой вовлеченности можно "сворачивать горы" ради продукта:
- делать больше важных задач
- делать более качественно, замечать даже мельчайшие детали, которые влияют на успех
- вдохновлять других людей

И это все классные штуки. Но с другой стороны из-за такой вовлеченности:
- ты острее воспринимаешь критику и неудачи (не обязательно внешне)
- ты тратишь больше энергии и времени на продукт
- ты можешь не замечать очевидных проблем продукта из-за собственных искажений от такой вовлеченности

Возможно, тут уместно было бы сказать, что нужен баланс. Но обычно эта мысль, что "во всем нужен баланс" ничего толком не объясняет. По собственному опыту, я так и не пришел к однозначному ответу на изначальный вопрос. Когда мне по каким-то причинам нравится продукт, над которым я работаю - я сильно вовлекаюсь в его развитие, но неоднократно было так, что из-за такой вовлеченности я получал неприятные последствия, которые были бы менее чувствительными, будь у меня "больше баланса" или "здоровая степень пофигизма". Например, однажды я с трудом засыпал несколько ночей подряд и сильно измотался из-за того, что переживал, что мою визу в Кувейт не одобрят - я считал, что для успеха проекта мне КРАЙНЕ ВАЖНО лично встретиться с людьми от клиента, и если этого не случится - проект сильно потеряет в заинтересованности от клиентов, а моя роль в нем уменьшится. Вот такие переживания были. Визу, кстати, тогда мне дали.

Что думаете, эмоциональный аттач это полезно или не очень?

Пару недель назад вышел таки подкаст с моим участием у Лёши Гладкова (его канал Mobile Developer один из топовых в СНГ по мобильной разработке). В подкасте подробнее обсудили масштабный летний сбой у CrowdStrike (немного писал о нем) тему надёжности, производительности и наблюдаемости приложений. Правда, подкаст вышел в его закрытом сообществе, но где-то в начале года он должен стать доступным на открытых площадках (напишу об этом!).

Это был мой первой опыт подкастинга. Слушал себя со стороны и думал о том, как важна поставленная речь и четкая логическая цепочка - буду работать над этим в следующем году. Интересно, что этот опыт значительно отличается от выступлений на конференциях - там у меня заготовленный спич, известные места для импровизации и четкий план рассказа. В подкасте совсем не так. Хоть там и была заготовлена базовая структура, разговор идёт сам собой, нужно ловить волну разговора.

Темная сторона data driven подхода

Сейчас модно быть data driven чуваками. Кто забыл - data driven это когда решения принимаются на основе данных. Юзеры часто заходят в этот раздел, значит качаем в первую очередь его, цвет Важной Кнопки не меняем пока не проведем А/Б-тест и не наберём статзначимый объем трафика. Этот подход имеет плюсы и минусы. Среди плюсов хотел бы отметить, что он снижает долю субъективщины, поскольку данные показывают сухие факты - решения на их основе меньше зависят от личного мнения. Оставим пока за скобками то, что данными можно успешно манипулировать:)

А вот о чем я хотел написать, так это о темной стороне всей этой data driven вечеринки - огромный объем совершенно никому не нужных данных. Аналитики покрывают событиями каждый чих пользователя "чтоб было" - а потом забывают про эти события через неделю, потому что есть другие важные задачи. Разработчики подключают сторонние SDK, которые помимо прочего, отливают куча информации производителю бесплатного SDK - масштаб бездумного сбора данных множится.

А ведь сбор любых данных несёт в себе вполне явные накладные расходы:
- на стороне клиента они стоят времени процессора (для сбора), пространства на диске (для буферизации) и интернет-трафика (для отправки), что в конечном итоге негативно влияет на перфоманс клиентской части
- на стороне сервера на порядок больше CPU, памяти и трафика для обработки данных, полученных с клиентов
- на стороне хранилища все тоже самое, только ещё и диски для хранения. Ой, вам еще и репликация нужна? Тогда умножаем объем данных на N.
- это уже не говоря о том, что все это нужно грамотно спроектировать, разработать и поддерживать, на что нужно время недешевых инженеров.
Таким образом, компании сливают кучу времени людей и денег на сбор и хранение бесполезных данных. Сам видел.

Что делать?
1. Проверить свой продукт - а не отливаем мы прямо сейчас кучу аналитики, которая нам нафиг не нужна? Вдруг мы так впустую тратим ресурсы клиента и компании?
2. При разработке новых фич учитывать аналитику минимально необходимого набора действий. Нет, не надо логировать отдельно нажатие на дропдаун и отдельно выбор варианта - достаточно затрекать параметры всей формы.

В общем, желаю всем подходить к аналитике более осознанно.

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

Подкаст опубликован на Ютубе - https://youtu.be/P0yrAzqHjIQ. Смотрите, комментируйте, буду рад обратной связи! Если будут вопросы - welcome в комментарии к посту:)

В этом подкасте мы поговорили о таких темах:
- Что именно случилось у CrowdStrike, когда они положили половину компьютеров в мире летом 2024 (я уже писал об этом пост)
- Почему НА САМОМ ДЕЛЕ важно следить за надежностью и производительностью мобильных приложений
- Как технически и организационно обеспечить наблюдаемость ключевых аспектов приложения
- Как устроена работа с темами производительности и надёжности мобилок в больших продуктах на десятки команд
- Что такое Sage в Т-Банке и зачем разрабатывать СВОЮ систему мониторинга в наше время

Про важные мелочи при запуске продукта в соло

Те продакт-менеджеры, кто как и я работают в больших компаниях, могут не замечать, как много важных вопросов, которые тоже влияют на продукт, НА САМОМ ДЕЛЕ, закрывают другие отделы в компании. Например, мы не переживаем за юридическую сторону работы продукта - если что-то возникает, то мы просто аутсорсим эти вопросы в головы корпоративных юристов и они делают все по красоте. Или мы не паримся о том, что бы нас не задудосили (DDoS) - админы выстаивают эту защиту или компания оплачивает услуги сервиса по фильтрации трафика.

В процессе работы над своим pet-проектом (возможно, позже расскажу о нем) словил проблемы, о которых даже не думал, когда делал что-то подобное по работе в найме. Полторы недели назад я запустил рекламную кампанию в Яндекс Директе и у меня поперли регистрации пользователей. Кампанию настраивал по модели CPA (Cost per Action, оплата за целевое действие) т.е. я плачу за каждую регистрацию, а не просто просмотр сайта. Однако в ходе работы кампании я заметил, что существенная часть пользователей повторно проходили регистрацию в течении нескольких минут после первой, иногда делали 3-4 регистрации. Но...зачем? Скорее всего из-за того, что мое письмо для верификации email попадало в спам. В целом, наверно, это было ожидаемо, ведь я отправлял его с обычного ящика @gmail.com через SMTP. Таким образом у меня крутилась рекламная кампания, была какая-то конверсия из просмотров в клики, из кликов в регистрации, пользователи регались, не видели письма, регались повторно - кто-то в итоге догадывался зайти в Спам и найти письмо, а кто-то просто забивал. А я платил за все это Яндексу🫠

Улучшать репутацию ящика на @gmail.com не оптимально, поэтому мне придется переносить все нотификации на почту на собственном домене. А значит придется платить еще и за хостинг почты, ведь если поднимать собственный SMTP сервер, то он будет вызывать еще больше подозрений у спам-фильтров и письма будут чаще попадать в спам. Оплату хостинга почты надо еще и учесть в юнит-экономике продукта т.к. это регулярные затраты на обслуживание🫠

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

Про ограниченную ответственность продакта

Некоторое время назад я думал о менеджере продукта как о человеке, который аккумулирует на себе всю ответственность за конечную ценность и качество продукта, которые видит клиент. Соответственно, если в этой части что-то идет не так, то ментально ответственность я возлагал именно на продакта:
- Если поддержка тупит, то вопрос к руководителю поддержки. А кто его главный заказчик в компании? Менеджер продукта. Значит именно продакт должен инициировать изменения в поддержке.
- Если в продукте много багов, то вопрос к тимлиду или руководителю разработки. А кто сильнее всего влияет на приоритеты разработки? Менеджер продукта. Значит именно он должен перераспределить приоритеты так, чтобы было достаточно времени на фикс багов.
- Если продукт плохо продается на рынке, то вопрос к отделу продаж. А кто, собственно, формирует продукт, который так плохо продается? Менеджер продукта. Ок, продукт может и супер, но кто тогда должен инициировать изменения в подходе к продажам? Все тот же человек.
- И т.д.

Во всех этих историях по цепочке ответственность я доходил именно до менеджера продукта. Возможно, до продакт-лида, если там несколько продактов.

Однако такой подход совсем не учитывает, что существуют факторы за пределами влияния продакта:
1. На продукт может влиять решение вышестоящего руководства.
Например, может быть принято решение об ограничениях инвестиций - это значит, что качество техподдержки или скорость разработки нельзя улучшить наймом большего кол-ва людей. Конечно, в таких условиях продакту можно поработать над эффективностью, но в какой-то момент придется рассмотреть вариант смириться с текущим уровнем качества при текущих затратах.
2. На результаты могут плохо влиять конкретные люди
Например, если в команде есть выгоревшие инженеры, которые развязывают споры вместо реальной работы, задачи будут затягиваться, качество страдать, в итоге: посредственный результат. В матричной структуре у продакта "здесь нет власти" на увольнения - значит влияние на решение этого вопроса потребует больше времени, на протяжении которого будет страдать качество продукта.

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

Эх, надо пойти перечитать что ли Inspired Мартина Кагана...

Про конфликт команд продукта и продаж

Некоторое время назад для меня было открытием наличие такого конфликта между командами: продажи хотят продавать как можно больше и на максимально жирные чеки, а продукт хочет выдерживать стратегию развития и давать долгосрочную ценность клиентам. Как видите, у обоих команд благие желания и никакую из них нельзя упрекнуть в том, что они желают плохого. Так в чем же тут конфликт?

А конфликт тут заложен сразу на нескольких слоях:
1. У этих отделов разные цели
Продажи обычно ориентированы на краткосрочные результаты: закрытие сделок, выполнение плана по выручке. Их KPI часто связаны с количеством продаж, временем сделок и конверсий между этапами воронки. Чуваки же со стороны продукта фокусируется на стратегических целях: создание конкурентного продукта, который будет приносить ценность клиентам и удерживать их на долгосрок. Их метрики связаны с удовлетворенностью клиентов (всякие NPS, CSI и т.д.), ретеншоном и проникновением ключевых фичей.

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

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

И как решать этот конфликт?
Я точно не знаю, но мне кажется, что плохой путь - это каждому из отделов замыкаться на "своей Зоне Ответственности", пытаясь достигать исключительно своих целей без учета целей друг друга. На деле оба отдела нужны и супер важны для успеха продукта на рынке, а такой подход напоминает басню про лебедя, рака и щуку, где каждый тащит воз в свою сторону.
Хороший подход (но сложный, блин) - это глубоко сотрудничать, погружаться в специфику друг друга и искать точки синергии. Например, продукт может вовлекать продажи на разных этапах планирования фич, а продажи погружать продукт глубже в запросы клиентов на этапе пресейла. Но это совсем другая история...

Про книгу 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 (писал об этом в прошлом посте), задавался вопросом, а зачем большим известным богатым вендорам систем мониторинга типа 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? часть 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 и дали пространство для развития отрасли в этом направлении. Кажется, в этом намного больше плюсов для всех.

Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (1/2)

Ладно-ладно, я специально немного утрировал. "За спиной", "за глаза", "в крысу🐀" - для этого формата есть разные определения, но суть одна: порой менеджеру необходимо обсуждать одних людей с другими людьми, причем частенько без ведома первых. В самом начале своего менеджерского пути я стеснялся этого - как это можно обсуждать сотрудника в его отсутствие? Но со временем я осознал важную мысль: некоторые разговоры не только необходимы, но и полезны для команды и самих людей. И если я, как менеджер, игнорирую эту часть работы или делаю ее плохо, то я обкрадываю команду относительно той пользы, которую мог бы им нанести. Важно лишь правильно проводить эти обсуждения.

Когда обсуждать за спиной все таки нужно?

1. Когда руководитель сотрудника просит фидбек о нем
Иногда руководители других сотрудников могут приходить с вопросами "Ну как он/она? Норм работает?". Кол-во таких запросов тем больше, чем ближе годовое ревью. Эта информация нужна им для составления плана развития сотрудника, сверки относительно фидбека от других людей. Ну и иногда она может оказать какое-то влияние на его годовую оценку (ну или как там у вас премии распределяют?). Этот же пункт работал, когда мне нужен был фидбек о работе своих сотрудников.

2. Когда фидбек не просили, но ты видишь плохой сигнал
Бывает такое, что по ходу работы над задачей человек может повести себя неконструктивно, например, разраба попросили проверить собственный фикс, а он сказал, что это не его работа, пусть QA проверяют. Все мы люди и порой можем где-то косячить, это норм. Но иногда бывает полезно сообщить такой сигнал руководителю сотрудника, чтобы он учел это при работе с ним, а может и превентивно принял какие-то меры, если сотрудник уже выгорает, например. Лично я этим вариантом пользовался ТОЛЬКО когда у меня был налаженный контакт с руководителем сотрудника и я был АБСОЛЮТНО уверен в адекватности восприятия руководителем такого фидбека.

3. Когда надо решить, кому лучше поручить задачу
Не всегда тимлид может в одиночку безошибочно определить лучшего исполнителя для той или иной задачи (по версии продакта, конечно). Например, на этой неделе есть свободный инженер, которому можно поручить задачу рефакторинга пары важных джоб на CI, однако его личные особенности таковы, что он ненавидит работать с CI. И тут возникает пространство для того, что бы обсудить, кому вместо него лучше эту задачу дать или пофиг на личные предпочтения...И вот мы снова обсуждаем людей и их особенности.

4. Когда нужно решить конфликт
Выслушать одну сторону конфликта, уточнить все важные детали, скорректировать неадекватные ожидания/поведение, а то может и вторую сторону послушать, побыть медиатором. Крч, в конфликтных историях обсуждение другого сотрудника это чуть не стержень беседы.

И это не исчерпывающий список ситуаций. Как видите, всех их объединяет вектор на более продуктивную работы команды, а не просто стремление посплетничать.

Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (2/2)

А как правильно обсуждать других?
Для себя я выработал несколько простых принципов, вот такие я вспомнил:
1. Этичность превыше всего
В данном контексте в "этичность" я вкладываю корректность и конфиденциальность. В любом обсуждении сотрудника есть определенные границы, за которые нельзя заходить: его семья, какое-то его прошлое, соцсети - это такие темы, которые не касаются рабочих моментов и они слишком личные. Считаю, что корректно будет избежать таких тем и отказаться от их обсуждения в любой форме. Конфиденциальность - это сделать так, что бы сказанное мне "по секрету" осталось только у меня и никуда дальше не утекло. Если сотрудник рассказал мне о каких-то личных вещах, я должен сохранить их личными.

2. Приводить факты и конкретные примеры
Любой фидбек о сотруднике (особенно негативный) должен сопровождаться конкретными примерами поведения. Причем прежде всего не моими оценками поведения, а именно фактами. Не "демотивирует коллег", а "на дейликах 3.04 и 7.04 при всех ругал код Ивана, называя его неподдерживаемым говном". Такой фидбек требует больше времени, но куда деваться - это часть работы менеджера.

3. "А смогу ли я сказать это в лицо этому человеку?"
Пожалуй, это мой основной принцип - при обсуждении человека, я пытаюсь представлять, смогу ли я тот же самый месседж (но может другими словами) сказать человеку открыто лицом к лицу? Если да - говорить спокойно, иначе НЕ говорить о нем и крепко задуматься, почему мне стремно сказать такое человеку лично. А вот как такие непростые вещи говорить людям лицом к лицу, это совсем другая история...

Всем привет!
И, да, я перешёл в Яндекс🤘. Тут я в роли технического менеджера (продакт + проджект) буду развивать основную платформу наблюдаемости внутренних и внешних продуктов, и ту ее часть, которая предоставляется клиентам в Облаке. Испытываю по этому поводу приятное чувство предвкушения. Осталось не завалить испытательный срок🙈

Чуть позже бахну пост про процесс найма в Яндекс - в моем случае он получился аж из 7 (семь) этапов собеседований, есть что рассказать.

Про мой процесс найма в Яндекс (1/2)

Так вот, я обещал написать о том, как выглядел процесс найма в Яндекс в моем случае. Кстати, я вас случайно обманул, этапов было не 7, а 8🫠

Сразу оговорюсь, что в других случаях процесс может выглядеть по-другому, а также, что он отличается в зависимости от профиля позиции - для инженеров один флоу, для менеджеров другой. Я собеседовался на позицию технического менеджера. Как я понял, в понимании Яндекса технический менеджер это продакт менеджер + проджект менеджер + все это в техническом сложном домене (у меня вот домен наблюдаемости и мониторинга). Итак, here we go

1. Первичный чек с рекрутером
На этом этапе рекрутер рассказала о вакансии, продукте и требованиях. Также она расспросила о моем опыте и ответила на вопросы. Кажется, это самый понятный этап, на котором рекрутер проводит первичную фильтрацию кандидатов. По ходу общения мы оба пришли к заключению, что на первый взгляд я подозрительно хорошо подхожу под эту вакансию. Кто знает, тот знает, что Яндекс славится многоступенчатыми собеседованиями и требовательным отбором кандидатов. Так вот, рекрутер предложила мне ДО начала всех этих этапов сразу пообщаться с потенциальным будущим руководителем, чтобы провести "вайб чек". Будет мэтч - супер, пойду по этапам собеседований, не будет - ну может и нет смысла?

2. ВНЕЗАПНО: первый фит с руководителем
Мы познакомились, непринуждённо пообщались по темам менеджмента людей и продуктов, про observability и вокруг этой темы, обсудили особенности и порядки их команды и обо всем таком. Встреча была короткая и ненапряжная - вайб-чек был взаимно пройден, а это значит, что можно двигаться дальше по этапам.

3. Управление проектами
На этом этапе меня ждало часовое собеседование на тему управления проектам, где меня сначала спрашивали в формате викторины типа "что такое критический путь?" или "что такое хорошая цель проекта?", а затем накидывали разные кейсы из жизни проектного менеджера, где предполагалось больше рассуждения вслух. Каждый такой кейс мы раскручивали, и если я предлагал какое-то решение, то мы углублялись в его особенности, границы применимости и примеры из реальной жизни. Не могу назвать это собеседование легкой прогулкой, но и совсем уж сложным оно не было - самая жесть была впереди.

4. Управление продуктами
На этом собеседовании меня ждал один продуктовый кейс про запуск нового технического продукта. Мы взяли некий продукт и обсудили все его этапы от голой идеи до запуска в продакшон и последующей поддержки. На каждом значимом этапе мы тормозили и шли немного вглубь. Например, вопросы про этап идеи - "Какие вопросы ты задашь, когда к тебе пришли с этой идеей?" или "как ты решишь, что над этой темой стоит работать, если у тебя и так есть несколько других инициатив?". Пример вопросов с этапа MVP - "Как будешь искать первых клиентов (early adopters)?" или "Как поймешь, что шаг MVP пройден?". Честно говоря, я даже не заметил как прошел час этого собеседования - общаться было интересно и полезно т.к. в какие-то моменты интервьюер делился и своим взглядом на вопрос.

Следующие этапы во втором посте

Про мой процесс найма в Яндекс (2/2)

5. Управление людьми
Это собеседование целиком и полностью состояло из набора кейсов из жизни руководителя - "тебе надо, чтобы смежники сделали задачу Х, а они оч заняты, что будешь делать?" или "в команде есть продуктивный, но токсичный чел, от которого стонет команда, как разрулишь?" и вот в таком духе. Кейсы усложнялись на ходу, динамически добавлялись новые вводные и мы рассуждали о том, как изменяется решение. Попутно обсуждали организацию процессов разработки и поддержки. Собес был динамичным и интересным, но все же более энергозатратным, чем предыдущий этап.

6. Архитектура
На этом этапе я готовился к классическому system design интервью (прям правда готовился), когда есть вводня задача и нужно спроектировать систему, которая ее решает. Однако с самого начала встреча пошла не так, как я ожидал - мы начали с формата викторины, где меня спрашивали вопросы типа "что происходит, когда мы вводим адрес с браузере?" или "Какие уровни OSI знаешь?". На часть вопросов я ответил норм, на часть не смог ответить, но при этом старался рассуждать вслух. В какой-то момент интервьюер предложил перейти к проектированию системы и мы погнали. Обычно первым этапом system design интервью является уточнение требований - тут мне предложили самому придумать адекватные требования. Штош, это интересный хак, если ты не подготовился к собеседованию как интервьюер, подумал я (хотя сомнений в качестве его подготовки у меня не было). Далее все шло более-менее стандартно, разве что только на тему отказоустойчивости мы поговорили дольше всего - как резервировать балансеры, graceful degradation при отвале части инфры и вот это все. В целом собес прошел неплохо, но физически я очень устал.

7. Комбо
После прошлого этапа рекрутер рассказала, что меня ждет еще один Особый этап, о котором мы не говорили заранее. Этот этап проводят не всем, а только тем, как я понял, кто получил достаточно хорошие отзывы на каждом из этапов интервью. Собеседование идет полтора часа и охватает сразу 3 темы - проекты, продукты и техника. Цель - еще раз оценить тебя и сверить фидбек с тем, который давали интервьюеры на предыдущих этапах. Штош, погнали.
На самом собеседовании мы действительно быстро бежали по всем этим темам - часть вопросов была в формате викторины, но больше было решения кейсов. Интервьюер предупредил меня, что он будет перебивать, если поймет, что я хорошо отвечаю на вопрос - все ради того, чтобы покрыть больше вопросов по этим трем темам. И, действительно, в какие-то моменты я чувствовал себя на шоу "Самый умный", как только я давал норм ответ, он сразу же накидывал следующий вопрос, не давая перевести дух. В таком формате мы провели полтора часа интенсивного обсуждения нон-стопом. Прикольный опыт, очень крутой интервьюер, но это супер энергозатратный формат.

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

Про 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
В докладе спикер обещает рассказать об их подходе к выявлению неэффективно используемых ресурсов в Облаке и способах оптимизации затрат без ущерба производительности. Помимо праздного любопытства, мне интересен этот кейс и с практической стороны - вдруг я пойму, как могу оптимизировать инфру у себя?

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

Когда TPM все таки нужен (а когда нет)

Пишу сейчас статью на Хабр про роль TPM (Technical Product Manager) - кто это, зачем нужен, как в нее попадают люди и все такое. И довольно продолжительное время пытался осмыслить какой-то ключевой фактор, который сильнее всего определяет, нужна такая роль в команде или нет.

Начал я с тезиса о том, что TPM нужен ТОЛЬКО тогда, когда пользователями продукта являются инженеры. Типа любой продакт должен знать своих клиентов, а тут вот клиенты технари, значит и продакт должен быть соответствующим. На что мои дорогие ревьюеры справедливо накинули мне пример продукта T-ID (Tinkoff ID) и его аналогов - система для упрощенной авторизации на сайте/приложении: заключаешь договор, подключаешь SDK в свой код и твои пользователи получают возможность залогиниться в два клика. Пользователями являются обычные люди, но продукт имеет явную техническую составляющую, которая сильно влияет на его развитие (инфра, SDK, комплаенс и т.д.). Соответственно, развивать такой продукт без технической насмотренности нельзя.

Продолжая анализ, я пришел к новому тезису - чем сильнее стратегия развития продукта зависит от технических факторов, тем сильнее команде нужен TPM. Если продукт можно развивать, не углубляясь в технических аспекты, а руководствоваться только пользовательскими потребностями, то TPM тут не нужен (это 99% случаев). Если без понимания архитектуры и технологий и/или процессов разработки сделать продукт хорошо не получится - вот тут-то и нужен TPM. Пока у меня есть уверенность в этом тезисе.

P.S. Кто готов поучаствовать в ревью статьи на Хабр - пишите в личку, я буду благодарен за помощь!😊

Про статью на Хабр о TPM

С момента моего перехода в технический менеджмент, особенно с погружением в продуктовую его часть, я немного мечтал написать статью на Хабр о TPM. В российских интернетах не много информации об этой роли и мне хотелось восполнить этот недостаток своим опытом. В статье я хотел рассказать, как вижу роль Technical Product Manager, нафига они вообще нужны - это очередной Scrum Master Pro Max или в этой роли действительно есть хоть какой-то смысл.

И наконец-то я сделал это - статья уже на Хабре!

В ней делюсь опытом работы в этой роли:
- Когда TPM действительно нужен команде, а когда это пустая трата денег
- Почему техническая экспертиза становится критичной для некоторых продуктов
- 17 навыков, которые реально требуются на практике
- Как люди переходят в TPM из разработки, аналитики и продактов.

Интересного чтения:)

Когда продолбать задачи не так уж плохо

Зацепила одна мысль из книги "Путь джедая" Макса Дорофеева. В разделе 6.4.3 он говорит о том, что на пути к большим важным и полезным задачам нас встречает много второстепенных задач, которые тоже претендуют на наше внимание. И если уделять внимание всем таким задачам, то просто не останется сил на то, что бы заниматься действительно важными и полезными вещами. Поэтому в какой-то момент надо научиться не бояться продалбывать такие второстепенные задачи, выработать, своего рода, иммунитет к таким локальным провалам ради того, чтобы оставались силы на важное.

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

Эта идея звучит для меня как таблетка от FOMO (fear of missing out, боязнь пропустить интересное). Вместо того, чтобы переживать о том, что я что-то упускаю, лучше сфокусироваться на поставленных целях и задачах и принять как норму, что в чём-то второстепенном я точно продолбаюсь. Но если раньше я бы переключался и тратил энергию на то, чтобы не допустить этот провал во второстепенном вопросе, то сейчас я могу со спокойной душой забить. Ведь я сфокусирован на более весомых задачах.

Естественно, это всё очень гибко. Иногда в силу разных причин то, что было второстепенным, становится более важным. Как Макс пишет в книге "в этом мире не всё всегда и везде, а кое-что иногда и местами".
---
Пост-повтор от поста 2023 года.