Когда подчинение менеджеру это зло

Спойлер: всегда. Шучу.
На самом деле, какое-то подчинение в команде помогает, например, разделить ответственность - разработчик пишет код по ТЗ и не парится по поводу бизнес-целей фичи. Он просто доверяет менеджеру и делает то, о чём его просят. Все делают своё дело и все в выигрыше. Однако бывает и так, когда подчинение всё портит.

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

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

Так, а что делать то?
Если команда подходит под критерии о необходимости "креативности" и "свободы принятия решений", то у менеджера продукта не должно быть прямых подчиненных в команде. Разработчики должны быть подчинены руководителю разработчиков и так далее с каждой ролью. Менеджер должен управлять ими только в рамках функции команды и не принимать решений, влияющих на зарплаты и премии. В такой конфигурации в команде допускается продуктивный конфликт, когда никто не боится высказать своё мнение, даже если оно противоречит мнению менеджера. Менеджер не может просто "задавить" сотрудника своим словом, придётся более конструктивно и продуманно доказывать что делать и почему именно так. Зачастую, именно в таких конфликтах и рождается наиболее элегантное решение вопроса.
Конечно, это требует больше энергии со стороны менеджера, но что поделать - таков путь.

Когда попадешь в новый канал, хочется сразу понять, что тут есть интересного и стоит ли оставаться.

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

Оглавление

Как я первый раз уволил человека
Когда продолбать задачи не так уж плохо
Про продажу задач
Базовая проверка аналитика
Когда не надо здороваться в чате
Про мета-вопросы
Про первую статью на Хабр
Почему технари ничего не могут без менеджера
Про неприятную обязанность менеджера
Менеджерское одиночество
Твой код никому не нужен
Про связь технических задач и бизнеса
Когда подчинение менеджеру это зло
Про то, как уходить из команды
Про медовый месяц менеджера
Про догфудинг
Про аэропорты
Про важность сегментации
Про переработки у инженеров
Про AI тулы в работе
Про мотивацию выступить
Про выбор темы для выступления
Часть 1. Что делать, если я не знаю о чем рассказать
Часть 2. Что делать, если я не знаю о чем рассказать
Про книгу Хорошая стратегия плохая стратегия
Про сбой CrowdStrike и Windows
Про MongoDB и удержание пользователей
Technical Product Manager'ы не нужны
Про Meeting notes
Про признание среди инженеров
Про эмоциональный аттач к продукту
Про темную сторону data-driven подхода
Про важные мелочи при запуске продукта в соло
Про ограниченную ответственность продакта
Про конфликт команд продаж и продукта
Про книгу OpenTelemetry
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry?
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry? часть 2
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (1/2)
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (2/2)
Про мои собесы в Яндекс 1
Про мои собесы в Яндекс 2
Когда TPM все таки нужен (а когда нет)
Про книгу "Искусство войны"
Про фокус на результатах

Про то, как уходить из команды

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

Думая об этом, я выделил 4 признака менеджера-чудака:

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

2. Оставляет неприятную атмосферу. Менеджер-негодяй не заботится об эмоциональном фоне команды, когда уходит - ему пофиг, что он грубо сообщил об этом или что половины команды не было, когда он говорил об этом - who cares, узнают от других как-нибудь.

3. Ломает рабочие процессы. Горе-менеджер не заботится о том, чтобы в его отсутствии процессы продолжали работать слаженно - он не ищет себе замену в этих процессах, не поддерживает их до последнего рабочего дня. Процесс нарушился, а это теперь не его дело!

4. Оставляет много неопределенности. Кто будет вместо тебя? Что нам делать, пока нет замены? Когда именно ты уходишь? И ещё куча подобных вопросов ожидаемы и легко прогнозируемы, но наш воображаемый менеджер не хочет потрудиться, чтобы ответить на них ради своей команды.

А, ну и не забудьте сделать всё наоборот, конечно, если вдруг.

Про медовый месяц менеджера

Когда менеджер приходит в новую компанию или в новую команду, у него возникает совершенно замечательный период - так называемый, медовый месяц менеджера. Почему медовый? Потому что это время имеет два особенных свойства:
1. Минимальные ожидания (если он не кризис-менеджер, конечно).
Обычно в компаниях дают неделю-две-месяц на то, чтобы заонбордиться, прочитать важные документы, познакомиться с командой и всё такое. В этот период от нового человека не ждут свершений или прорыва в проектах - достаточно будет, если он вникнет в базовые дела и начнёт выполнять начальные задачи для этой роли. С ходом времени эти ожидания будут расти и через месяц они будут существенно отличаться от начального состояния.
2. Высокая толерантность к неосведомленности.
Другими словами можно задавать любые тупые вопросы без риска показаться глуповатым. "Почему решили перейти на Postgres вместо MySQL? Почему на ретро вы не делаете icebreaker? Почему поставлены именно такие цели на этот квартал?" - новичку прощаются любые вопросы. И этим надо пользоваться, чтобы глубже понять контекст работы. Конечно, в будущем лучше тоже задавать вопросы, даже если они кажутся глупыми, ведь легче задавать глупые вопросы, чем исправлять глупые ошибки. Но, согласитесь, некоторые вопросы выглядят менее уместными через месяц-другой работы в команде.

Кроме учёта этих свойств, есть ещё пару особенных действий, которые важно сделать в этот период:
1. Познакомиться с ключевыми людьми. Руководителем, лидами команд, клиентами и другими стейкхолдерами. Важно понять их ожидания (if any), разобраться с зонами ответственности (с какими вопросами к ним приходить), да и просто по-человечески познакомиться (вживую, если есть возможность). На своём опыте ни раз замечал, что после личного знакомства совместная работа идёт более гладко.
2. Договориться о целях в своей роли. Нужно в явном виде и как можно более однозначно определить, что ожидает руководитель (в идеале, ещё и его руководитель, но эту мысль пока придержим🤐) и как он будет оценивать выполненную работу. В противном случае можно начать делать не то, что нужно и, в лучшем случае, узнать об этом по ходу выполнения, а в худшем - в конце испытательного срока. Поэтому правила игры лучше зафиксировать на старте.

Как считаете, что ещё важно сделать во время медового месяца менеджера?

Про догфудинг
Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".

А причём тут технический менеджмент, спросите вы?

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

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

Честно говоря, однозначного ответа я не нашёл. Я вижу в этом границы использования этой практики - если продукт неактуален для меня, как для клиента, то насколько глубокую обратную связь по его использованию я смогу дать? Это как просить водителя автобуса пользоваться штурвалом от самолета.

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

Про аэропорты

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

В прошлом году мне довелось полетать более 20 раз (не все по работе, конечно). Для кого-то это обычное дело, но для меня такое количество перелетов было в новинку. Соответственно, я много времени провел в аэропортах. И вот пока я еду в такси в очередную поездку, решил поделиться своими хаками, которые выработал для себя, чтобы время в аэропорту и полете прошло более комфортно. Сразу скажу: я не претендую на новизну, просто буду рад, если кто-то отметит что-то полезным для себя.

1. Электронный посадочный вместо бумажного. Если есть возможность, я не печатаю посадочный, а использую электронную версию. Во-первых, это намного быстрее, чем искать терминал печати или отстоять очередь на регистрацию. Во-вторых, бумажку легко потерять, а это осложнит последующую отчётность по командировке.
2. Без багажа. Купил себе мини-чемодан, который проходит в ручную кладь, или гоняю с рюкзаком. Экономится время на ожидание багажа после посадки и деньги на его оплату.
3. Заранее готовлюсь к досмотрам. Ещё на пути в аэропорт выкладываю все металлические предметы из карманов в рюкзак, туда же идут часы, наушники и телефон. И пока другие спешно выкладывают ключи и телефоны, я уже прохожу первый досмотр. Затем достаю паспорт и телефон с посадочным, на втором досмотре телефон и паспорт кладу обратно в рюкзак, чтобы не выкладывать в ящик. После всех досмотров можно уже вернуть часы и прочую технику на нужные места.
4. Вызываю такси при выходе из самолёта. Поскольку багаж я не жду, то, скорее всего, я быстро выйду из аэропорта. А значит время ожидания можно сократить, если вызвать такси сразу.

А есть ли какие-то хаки у вас? Поделитесь!

Сегодня выступил на конференции Mergeconf в университете Иннополиса с темой "Словесный No Code или как ускорять разработку силой слова". В докладе я поделился своими мыслями о важности эффективной коммуникации в командах и советами из собственного опыта на эту тему. Судя по фидбеку аудитории и вопросам в конце - доклад таки нанёс определенную пользу:)

P.S. Для читателей канала чуть позже сделаю пару постов с выжимкой самой сути доклада.

Про важность сегментации

Представьте, что вы менеджер продукта (например, приложения для заказа еды) и вы анализируете тикеты из поддержки в поисках новых задач для беклога. Вы выделили 3 основных тематики обращений (цифры условные):
1. Тормоза в приложении (10 обращений)
2. Плохо работает фильтр каталога (22 обращения)
3. У части ресторанов нет фото блюд (15 обращений)

Над какими проблемами вы будете работать в первую очередь?
Ну, правда, остановитесь на секунду и подумайте.

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

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

Один из прикольных методов такой сегментации - ABCDX-сегментация. Суть ABCDX-разделить своих клиентов на 4 сегмента по степени ценности, которую ваш продукт им наносит:
- А сегмент—продукт супер нужен, покупают много и с удовольствием
- B сегмент—продукт нужен, появляются возражения, чего-то не хватает. Платят плюс-минус регулярно.
- С Сегмент—потребность в решение есть, но не вашем, ваш продукт им особо не помогает.
- D Сегмент—выносят мозг и не покупают
- X Сегмент—потенциально ваш А сегмент, но ваш продукт в текущем виде им не подходит, требует изменений.
Говорят, что 80% выручки приносят именно А и В сегменты при том, что С и D больше привлекают к себе внимание и вынуждают работать над своими проблемами.

Пользуясь этим подходом вы могли бы обнаружить такой расклад по обращениям:
1. Тормоза в приложении (10 обращений: А 8, B 2)!!!
2. Плохо работает фильтр каталога (22 обращения: B 2, C 10, D 10)
3. У части ресторанов нет фото блюд (15 обращений: C 5, D 10)

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

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

P.S. Услышал этот пример про сегментацию на курсе Вани Замесина и очень уж он мне понравился, поэтому и делюсь с вами:)

Про доклад на Mergeconf 2024

Пару постов назад обещал поделиться выжимкой своего доклада с конференции Mergeconf 2024, которая проходила в Иннополисе в конце апреля. Обещание надо выполнять, поэтому погнали:)

Сразу скажу, что я впервые выступал по НЕтехнической теме и, честно говоря, не могу сказать, что мне очень уж понравилось:)
Доклад назывался "Словесный No Code или как ускорять разработку силой слова" и был посвящен теме коммуникаций внутри команд. В самом начале доклада я рассказал о паре исследований, которые показали исключительную важность софт-скиллов для инженеров:
1. Исследование LinkedIn, в котором они на основе своих данных заключили, что те, кто развивают софт скиллы И хард-скиллы получают повышение на 8% быстрее, чем те, кто качает только хард-скиллы.
2. Исследование 1918 года о качестве инженерного образования в США, в котором авторы проводят последовательные опросы инженеров (сначала выборочные интервью, потом опросами по 1,5к и 7к инженеров), в результате которых обнаруживается, что качества характера и коммуникативные навыки это САМАЯ ВАЖНАЯ категория навыков для инженера. У более, чем 50% респондентов важность техники оказалась на последнем месте. Авторы немного недоумевают, почему инженеры с рынка труда говорят о такой важности софт-скиллов при том, что в технических университетах студентов максимально накачивают именно техническими знаниями. Оффтоп: результаты этого исследования потом повлияют на реформы в системе образования США в 20 веке. Само исследование вот тут (стр. 106-107).
Вывод из исследований таков, что софт-скиллы ДЕЙСТВИТЕЛЬНО очень важны, и если хочется достигнуть чего-то значимого, то лучше их развивать.

Немного порассуждав о том, что такое коммуникация (я сформулировал её как "целенаправленное общение") и можно ли измерить её эффективность, мы перешли к советикам по тому, как сделать её эффективнее. Советы разделились на 2 группы:
1. По форме коммуникации.
2. По сути.

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

Чтобы не раздувать один пост, опубликую эти советы отдельными постами завтра и послезавтра.

Первая группа "советиков" касается внешней формы коммуникаций, она больше про внешнее восприятие т.е. про то, как общение с нами воспринимают другие люди.

1. Не пишите "привет". Короткий пункт про то, что в чатах лучше писать приветствие и свой вопрос СРАЗУ в одном сообщении. Не надо писать "привет" и ждать реакции, чтобы продолжить общение. Ровно об этом когда-то у меня был отдельный пост, когда наболело в очередной раз.

2. "Чего ты хочешь от меня?" или про то, что надо четко и однозначно формулировать свой запрос в коммуникациях, если вам что-то нужно от собеседника. Когда менеджер просит команду "по возможности, посмотреть документ Х в ближайшее время" он создаёт не иллюзорную возможность, что разные члены команды поймут эту просьбу по разному. Один посмотрит сегодня, второй оставит комменты по орфографии, а третий забудет после прочтения. "Прошу всех участников проекта перейти на страницу с описанием, прочитать её и оставить свои комментарии до 13 часов пятницы" - тут простор для разночтения уже меньше. Следовательно, вероятность выполнения нужной работы возрастает.

3. Предугадайте вопросы. Когда мы обращаемся с просьбой или задачей к другому человеку, то, вероятно, мы можем предугадать некоторые вопросы и заранее дать на них ответы. Условно, если вы просите финансиста купить лицензии на WinRAR (внезапно!), то есть отличная от нуля вероятность, что он спросит про кол-во лицензий, их стоимость и источник бюджета. И вы можете сэкономить время на всю эту процедуру, если сразу же дадите ему нужную информацию. В докладе я оговорился, что хоть это и экономит время, но додумывать за других их вопросы - дело неблагодарное. Поэтому лично для себя я решил закрывать с самого начала только такие вопросы, в которых я ПРЯМ ТОЧНО уверен, что они будут.

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

5. Подстраивайтесь под ценности собеседника. Если вы знаете, как ВАША задача (в смысле, от вас) может быть полезна собеседнику, как она доставляет ценность ЕМУ, то на этом стоит акцентировать внимание, чтобы повысить мотивацию сделать именно вашу задачу в первую очередь. Например, вам нужно, чтобы ребята из контакт-центра собрали нужные данные для вашей задачи. В обычном режиме они сделают это в Q5 "согласно приоритетам" (с), но если вы подсветите им как ВАША задача сократит время выдачи доступа ИХ новым сотрудникам (это всегда головная боль в контакт-центрах из-за текучки), то может они возьмут её в более короткие сроки. В докладе я оговорился, что эту идею можно использовать не только на благо, но и на зло. Например, для манипуляции - скрытно мотивировать собеседника делать то, что нужно ВАМ в ущерб его интересам. Так не надо, такое я осуждаю.

6. Фиксируйте договоренности. Вроде договорились обо всём, но в момент Х оказывается, что "ой, это не лучшая идея, давай ещё подумаем" или "извини, не помню, что бы мы такое обсуждали, закинь встречу обсудим". Знакомая ситуация? И ведь часто это происходит без злого умысла. И чтобы такого было поменьше, после каждой встречи, на которой родились значимые договоренности, рекомендую отправлять участникам встречи meeting notes, протокол встречи - в разных компаниях называют по-своему. В них должно быть четко и однозначно описано: кто, что и когда договорился сделать. "Привет, вы уже настроили для нас Clickhouse" - "Какой Clickhouse? Мы не планировали вам его давать" - "Глянь в почте, две недели назад вы обещали его подготовить для нас" - "Ой, точно, сейчас что-нибудь придумаем..."

Это были советики по форме. В следующем посте будут советики по сути коммуникации.

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

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

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

9. Будьте проактивными. В реактивном подходе на решения человека сильно влияют внешние раздражители. Что-то происходит вовне и именно это определяет то, что будет делать человек. На проактивных людей действуют те же самые силы, но они не управляют действиями человека - он способен как бы переломить ход и делать то, что нужно для достижения нужного ему результата. Для пояснения я привёл историю с аналитиком, которому сообщили, что заказчик забраковал его ТЗ, а коллега успел записать только пару замечаний.
- Реактивный: okay, не звали на встречу по обсуждению ТЗ - нечего и проситься. Записали только 2 замечания, ну ладно, исправлю их.
- Проактивный: ты че, пёс. Написать самому и попросить полный список замечаний. Напроситься в след. раз самому презентовать своё ТЗ заказчику, чтобы сразу отвечать на замечания.

10. Сдерживайте обещания. Казалось бы - капитанство, но чтобы его чуть раскрыть я предложил 4 подсовета о том, как это делать.
- Не обещайте сразу. Иногда мы склонны пообещать что-то под влиянием эмоций. Тут я предлагаю брать паузы, чтобы лучше обдумать обещание.
- Уточните просьбу. Важно убедиться, что вы правильно поняли, что от вас хотят. Намного лучше переспросить лишний раз, чем сделать не то.
- Обещайте в рамках возможностей. Вроде очевидно, но особенность в том, что если обещание не по силам, сейчас хорошая возможность обозначить риски. Вполне возможно, что обещание можно скорректировать с их учётом.
- Своевременно говорите, если обещания под угрозой. Нет ничего хуже в день Х ВНЕЗАПНО узнать, что нужная работа не сделана (конечно, есть вещи несравнимо хуже). Поэтому о срыве обещания лучше сказать ASAP. (1) Это просто честно. (2) Вероятно, обещание можно скорректировать по срокам/объему.

Вот такой у меня был доклад:)

Моя прошлогодняя статья на Хабре (и единственная, к слову) ВНЕЗАПНО попала в шорт лист конкурса лучших статей - Технотекст 2023🦄
Статья написана про особенности SRE и Observability в мобильных приложениях, так что если какие-то из этих тем вам интересны - you're welcome
https://habr.com/ru/companies/tinkoff/articles/762058

Про переработки в инженерных командах

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

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

При обоих формах переработок (вынужденных или добровольных) нам, как менеджерам, важно особенно следить за двумя моментами:
1. Инженеры могут сами не заметить приближающееся выгорание.
Там посидел на выходных, тут задержался на пару часов вечером - и вот уже работа вызывает больше отвращения, чем интереса. Уже нет никакой инициативы, все задачи одинаково безразличны, а любые трудности в команде бесят максимально. "Так, а может бросить все это и уйти куда-нибудь?!" - такие мысли посещают подгорающего все чаще. У разных людей разный уровень осознанности, но от менеджера у меня более высокие ожидания. Поэтому считаю важным менеджеру быть особенно чутким к команде, когда появляются переработки. По возможности, стоит вообще защитить команду от них (сменить приоритеты или подвинуть сроки). А если кто-то начинает проявлять первые признаки выгорания - такому человеку нужно уделить особое внимание. Конечно, менеджер не психотерапевт, но с т.з. достижения результатов, кажется, проще включиться на этом этапе, чем потом искать нового человека на освободившуюся вакансию.
2. Переработки не должны проходить бесследно.
Наличие переработки - индикатор, что где-то ошиблись с планированием. Если это единичные случаи, то ок. Но если это становится системой - надо разбираться. Хитрость - если люди перерабатывают добровольно, то их переработки могут оказаться незаметными для руководства. Они задерживаются вечерам, сидят на выходных и вообще из кожи вон лезут - а руководство не видит этих усилий. Руководство видит сделанные в срок задачи с приемлемым качеством. И когда к ним потом приходят и просят еще людей в команду, возникает ожидаемый вопрос - а зачем, вы же и так норм справляетесь? И тут прямая задача менеджера правильно подать руководству тему с переработками. Отдельное искусство в таком случае - так позвоkить факапить задачи без переработок, чтобы нужда в расширении команды стала очевидной и в то же время это не нанести особого ущерба бизнесу. Но это совсем другая история...

P.S. Все переработки, которые инициирует компания, должны быть оплачены!

Про AI в работе менеджера

Признаюсь честно, когда начался AI-бум, то я отнесся к нему с большой долей скепсиса. Сразу вспомнил, как раньше все носились с блокчейном, Web 2.0, Big Data и т.д. А когда про AI не начал писать только ленивый, то стала возникать натуральная тошнота от упоминания этой аббревиатуры.
Однако я сам не заметил как в некоторых менеджерских задачах подсел на использование AI-тулов и стал кайфовать от них. И в этом посте я хочу поделиться парой таких штук с вами.

1. Role-playing
Суть подхода в том, чтобы попросить модель отвечать на вопрос из определенной роли. В эту роль я вкладываю описание человека, его должность и опыт, с которым я бы хотел обсудить мой вопрос. "Отвечай как технический менеджер продукта, развивающий observability-платформу..." или "Отвечай как тимлид команды SRE, jотвечающий за высоконагруженную систему...". И что самое классное - ChatGPT (и подобные модели) действительно подстраиваются под эту роль и учитывают ее как доп. контекст для ответа. Таким образом, одну и ту же тему можно "обстучать" об разные роли - концепт идеи обсуждаю с менеджером продукта, метрики - с продуктовым аналитиком, реализацию - с тимлидом. Конечно, все это НЕ заменит обсуждения с реальными людьми, но точно дает шире взглянуть на задачу. У меня МНОГО РАЗ случалось такое, что на этом этапе я видел вопросы, которые изначально я не учитывал.

2. Написание говно-кода
Сейчас мне не нужно писать код, но иногда с помощью кода задачу можно решить более эффективно. Если использовать прошлый пункт и попросить модель "Отвечай как опытный разработчик на bash. Напиши мне скрипт, который...", то можно за очень короткое время получить код, который, возможно, неэлегантно, но все таки выполняет поставленную задачу. Аналогичным подходом полгода назад мне удалось НАМНОГО БЫСТРЕЕ углубиться в данные, которые лежат в Clickhouse, не являясь гуру либы pandas на питоне и SQL-диалекта, на котором работает клик. Таким образом, с помощью LLM можно значительно ускоряться в задачах написания несложного кода (опыта написания production-ready с LLM у меня нет).

3. Поиск через Perplexity
Когда в мою жизнь вошел Perplexity, то я стал, наверно, раза в 2-3 меньше пользоваться поисковиками. Это потому, что с помощью Perplexity я значительно быстрее получаю нужные мне ответы, чем с Гуглом или Яндексом. Фишка этого сервиса в том, что он комбинирует поиск в Интернете и ответ LLM чат-бота. На выходе запроса вы получаете не набор ссылок, а краткое резюме того, что есть в топе Интернета по этой теме. Каждое утверждение этого саммари подкрепляется ссылкой на источник, благодаря чему снижается риск, что LLM напридумывает того, чего нет. Важная фишка этого инструмента - он держит контекст вашего поискового запроса, благодаря чему можно доуточнять что-то на основе полученной информации. Еще в Perplexity есть Pro-запросы. С помощью таких запросов модель как будто глубже пытается понять задачу и дополнительно может сама задать вам вопросы для прояснения недостающих данных. Полученные ответы потом используются для обогащения контекста. Крч, лучше просто попробуйте сами!

А какими AI-штуками пользуетесь вы?
Поделитесь, интересно ж!

27.06 буду выступать в Москве на конференции Сбера - GigaConf 2024. В своем докладе я поделюсь рефлексией одного крупного сбоя в мобильном банке, расскажу, какие выводы мы сделали (не все были приятными) и как мы на корню лечили первопричины. Попутно поделюсь набором советников для DevOps'ов и SRE о том, как они могут (да, могут!) сильно повлиять на надёжность мобильного приложения в компании.
Конференция бесплатная, будет трансляция - welcome!

https://gigaconf.ru

Про мотивацию выступать

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

Начнём с шага №0. Как мне кажется, нулевым и фундаментальным шагом будет не идея для темы доклада и даже не выбор мемов для презентации, а именно прояснение своей мотивации к выступлению. Почему я хочу выступить? Зачем мне это?
Стоит посидеть и крепко подумать об этом. Ведь путь от идеи до фактического выступления бывает непрост и хорошее понимание собственной мотивации может сильно помочь. Одно дело готовиться "по фану", "новый опыт" или "другие выступают, а я че хуже?" - как мне кажется, такая мотивация легко улетучивается при первых сложностях из-за своей поверхностности. И совсем другое дело, если вы твердо решили прокачивать экспертный бренд, чтобы получить новые карьерные возможности или вы хотите выступить, чтобы послужить продвижению своего классного продукта. Такая мотивация более основательная и она не даст вам просто соскочить.

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

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

Шаг 1. Выбор темы

Когда определились с собственной мотивацией к выступлению, самое время подумать о теме и ключевых идеях доклада. О чем вы вы хотите рассказать людям? Какие идеи хотите донести? На этом этапе НЕ нужно бросаться сразу в детальную проработку структуры - еще успеете. Лучше набросайте N вариантов тем, которые видятся вам актуальными и о которых вы можете рассказать - этого будет достаточно для текущего этапа.

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

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

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

Так, это все понятно, но что делать, если я не знаю о чем рассказать? Я просто работаю работу и не делаю ничего невероятного.

Об этом расскажу в следующем посте.

Шаг 1.1 Что делать, если я не знаю о чем рассказать

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

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

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

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

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

В следующем посте накину еще пару идей про темы для докладов.

Шаг 1.2 Что делать, если я не знаю о чем рассказать часть 2

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

Расскажите о свежих релизах
Например, что нового в последней Java (какая там сейчас? 21 уже?). Или какие нововведения в Android SDK 35. Основная идея в том, что бы взять что-то прям свежее-свежее, что только вышло, пропустить через себя и рассказать. Далеко не все следят за самыми последними релизами и за счет этого ваш доклад может быть актуальным. При выборе этого варианта прикольно, что основной контент уже подготовлен до вас тем, кто готовил статью или пресс-релиз о новой фиче. Вам лишь остается переработать это и нормально рассказать.

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

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

Штош. Надеюсь, эти мысли помогут нагнать идеи для докладов:)