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

Те продакт-менеджеры, кто как и я работают в больших компаниях, могут не замечать, как много важных вопросов, которые тоже влияют на продукт, НА САМОМ ДЕЛЕ, закрывают другие отделы в компании. Например, мы не переживаем за юридическую сторону работы продукта - если что-то возникает, то мы просто аутсорсим эти вопросы в головы корпоративных юристов и они делают все по красоте. Или мы не паримся о том, что бы нас не задудосили (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 года.

Про "Искусство войны"

На днях дочитал книгу Сунь-Цзы "Искусство войны" и вот какие мысли почерпнул для себя и какими хочу поделиться с вами.
- Хоть автор и говорит о войне в буквальном смысле, дальше в посте я буду писать о войне как конкуренции за клиентов, рынок, ресурсы, время и влияние в бизнес-среде.

Война — путь обмана. Поэтому, если можешь что-то — показывай противнику, что не можешь; если используешь что-то — показывай, что не используешь

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

Знание положения противника можно получить только от людей.

- Автор уделяет немалую часть книги работе со шпионами и информаторами и это тоже как будто нечестно что-ли! Однако, вспомните сами, зачастую самая свежая и практичная информация может приходить не по "официальным каналам", а от отдельных людей. Слухи, сплетни и вот это все - частенько именно эта информация помогает быстрее подготовиться к каким-нибудь изменением. При этом здесь тоже ловлю себя на мысли, что хочу "быть выше всего этого" и игнорирую такую информацию. Возможно, зря.
- В бизнес-контексте для меня это подчеркнуло важность нетворкинга и связей. В очередной раз напомнил себе, что самые ценные инсайты приходили не из докладов и статей, а из личных бесед в людьми за бокалом чего-нибудь.

Ведя войско, следует ставить его в такие условия, как если бы, забравшись на высоту, убрали лестницы.

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

В целом, книга произвела на меня смешанное впечатление. У меня было от нее много ожиданий, которые в итоге не оправдались. Автор пишет витиевато, не спеша пояснять многие из своих идей. Часть информации и вовсе относится исключительно к старым временам. Многие ценные мысли написаны в формате каких-то афоризмов - коротко и неинформативно. Благо, книга короткая, поэтому ROI относительно потраченного времени нормальный:)

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

Это я все к чему. Я тут решил поучаствовать в конкурсе авторских телеграм-каналов - https://tg-contest.tilda.ws/. Там опытные авторы собирают авторов менее опытных и дают им площадку, чтобы их увидела широкая аудитория и люди оттуда могли подобрать каналы себе по душе. Так что, если на досуге захочется посмотреть на авторские каналы - полистайте канал, где будет проходить конкурс @tg_contest_main. Вдруг найдете для себя что-то интересное.

Голосовать за себя я НЕ призываю - у меня нет стремления там бороться и побеждать. Рассматриваю это скорее как новый интересный опыт и возможность сделать шаг в сфере развития канала. Every step counts.

Пост про фокус на результатах

"Мы довольны своей работой МАКСИМАЛЬНО, но, к сожалению, наша работа не дала результат" (с)

- каждый раз хихикаю с этого видео (ютуб, вк), и каждый же раз где-то на заднем плане возникает мысль о важности результатов, а не просто упорной работы. Как пелось у 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”
Другими словами лучше сделать НОРМ и заданные сроки, чем полировать до совершенства непойми сколько. Ох, сколько раз я себе говорил это - вот еще одно интервью проведу и все будет совсем понятно, вот еще тут формулировки на слайде дополирую и все будет как надо. И ведь все равно не наступает тот счастливый момент, когда все прям супер-пупер! Все равно всегда находится еще одна мелочь, которую надо поправить. Именно поэтому эта фраза так засела в голове - она немного возвращает перфекциониста с небес на землю.

Крч, побочным эффектом (в хорошем смысле!) участия в этом конкурсе стало знакомство с другими авторами каналов в категории управления продуктами.

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

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

Про отдых и выгорание

Совсем скоро я планирую отправиться в недолгий отпуск. И сколько себя помню - всегда относился к своим отпускам стратегически: рассматривал их не сколько как развлекуху, сколько как инвестицию в свою будущую работоспособность и энергичность, ведь если я норм отдохну, то у меня появятся силы достигать! Этот подход не лишен недостатков - например, слишком серьезное отношение к отдыху создает напряженность, что в свою очередь только вредит его качеству. Однако мне 30+, я сохранил работоспособность и энтузиазм - значит это как-то работает:)

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

Переломным моментом в своем взгляде на отдых я считаю момент, когда я прям осознал, что НИКТО В МИРЕ не позаботится всерьез о моем отдыхе, кроме меня самого. Друзья могут посетовать на синяки под глазами и вялость, но они не заставят меня организовать себе отпуск - сильно настаивать в этой сфере не принято. Семья тоже может не видеть в этом проблемы пока ты более-менее делаешь все, что должен. Вот и получается, что никто не придет тебя спасать от выгорания - заботиться об этом нужно самому.

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