Менеджерское одиночество
Одной из интересных особенностей менеджерской роли является определенная степень одиночества в команде. Инженеры, аналитики, дизайнеры могут делиться друг с другом своими переживаниями, позитивными и негативными, однако менеджер зачастую лишён такой возможности.
А почему? Я вижу, по крайней мере, 2 причины:
1. Конфиденциальность. Ты раньше всех узнаешь, кто планирует увольняться или переходить в другую команду. У кого с кем конфликты. Какое направление руководство думает свернуть. И всё такое. И всё это секретики, которые надо хранить, но которые, однако, могут сильно влиять на настрой менеджера и на принимаемые им решения. А к кому идти за поддержкой, когда ты переживаешь из-за чего-то такого секретного?
2. Ожидания лидерства. Мы все знаем, что хороший менеджер это лидер, который вдохновляет других. Но что, если он сам потерял вдохновение и позитивный настрой? К людям из команды с таким не пойдешь, ведь, если попадется недостаточно зрелый человек, то вид подавленного лидера может демотивировать его самого. Да и как поддержать приунывшего лидера? Это тоже вопрос.
Но не все так грустно. Я думаю, что подавленный лидер может обратиться к таким источникам "исцеления":
1. Друзья и семья. Иногда просто выговориться и услышать взгляд со стороны - сильно продвигает в решении проблемы.
2. Коучинг. Специально обученный человек может сильно ускорить собственную рефлексию и помочь удержаться в конструктивном русле.
3. Коллеги менеджеры. Наверняка они тоже сталкивались с чем-то подобным, и если у вас достаточно доверительный контакт, то они могут поделиться своим опытом.
4. Руководитель. Если с ним сложился хороший контакт, он открыт и опытен - его взгляд на ситуацию может быть очень полезен и открыть новые грани.
Одной из интересных особенностей менеджерской роли является определенная степень одиночества в команде. Инженеры, аналитики, дизайнеры могут делиться друг с другом своими переживаниями, позитивными и негативными, однако менеджер зачастую лишён такой возможности.
А почему? Я вижу, по крайней мере, 2 причины:
1. Конфиденциальность. Ты раньше всех узнаешь, кто планирует увольняться или переходить в другую команду. У кого с кем конфликты. Какое направление руководство думает свернуть. И всё такое. И всё это секретики, которые надо хранить, но которые, однако, могут сильно влиять на настрой менеджера и на принимаемые им решения. А к кому идти за поддержкой, когда ты переживаешь из-за чего-то такого секретного?
2. Ожидания лидерства. Мы все знаем, что хороший менеджер это лидер, который вдохновляет других. Но что, если он сам потерял вдохновение и позитивный настрой? К людям из команды с таким не пойдешь, ведь, если попадется недостаточно зрелый человек, то вид подавленного лидера может демотивировать его самого. Да и как поддержать приунывшего лидера? Это тоже вопрос.
Но не все так грустно. Я думаю, что подавленный лидер может обратиться к таким источникам "исцеления":
1. Друзья и семья. Иногда просто выговориться и услышать взгляд со стороны - сильно продвигает в решении проблемы.
2. Коучинг. Специально обученный человек может сильно ускорить собственную рефлексию и помочь удержаться в конструктивном русле.
3. Коллеги менеджеры. Наверняка они тоже сталкивались с чем-то подобным, и если у вас достаточно доверительный контакт, то они могут поделиться своим опытом.
4. Руководитель. Если с ним сложился хороший контакт, он открыт и опытен - его взгляд на ситуацию может быть очень полезен и открыть новые грани.
❤7
Появилась публичная запись с моего последнего доклада c конференции мобильных разработчиков Mobius «А у нас сейчас всё норм работает?» или Что такое observability мобильного приложения.
Поделюсь анонсом с сайта конференции (не зря же его писал!):
Если эта тема вам интересна - welcome на ютуб😊
https://youtu.be/EkT-EvUYww8
Поделюсь анонсом с сайта конференции (не зря же его писал!):
В мире бэкенда, API и баз данных хороший мониторинг давно является чем-то само собой разумеющимся. Вопрос мониторинга серверных приложений давно оброс большим количеством практик, подходов и идей, которые зарекомендовали себя «в бою». Однако в случае с мобильными приложениями и по сей день можно встретить истории, когда во время сбоя единственный способ понять, «а норм ли работает наше приложение», — это запустить его и потыкать своими руками.
Даниэль расскажет, чем плох подход «запустить и потыкать руками» и поделится тем, как в Тинькофф подходят к observability (наблюдаемости) мобильного банка – основного приложения компании с ежедневной аудиторией свыше 10 млн. клиентов. Спикер также расскажет о том, как и за какими метриками следят и какие практики показали свою эффективность в этой теме.
Если эта тема вам интересна - welcome на ютуб😊
https://youtu.be/EkT-EvUYww8
YouTube
Что такое observability мобильного приложения — Даниэль Халиулин, Тинькофф
Делимся докладами с осеннего Mobius 🍁
Кстати, весенний Mobius на подходе! Мы уже думаем над темами новых докладов. Если вам тоже есть, что рассказать — присоединяйтесь к нам и отправляйте заявки: https://mobiusconf.com/callforpapers/?utm_source=social&u…
Кстати, весенний Mobius на подходе! Мы уже думаем над темами новых докладов. Если вам тоже есть, что рассказать — присоединяйтесь к нам и отправляйте заявки: https://mobiusconf.com/callforpapers/?utm_source=social&u…
🔥5
Твой код никому не нужен
Равно как и тест-кейсы. Или эти дейли-митинги, планирования и ретро. Они тоже не нужны вместе с грамотно описанным ТЗ. Оптимизации производительности, метрики и мониторинг туда же. А тем более все эти задачи в Jira и прочих трекерах. Все это никому не нужно...
...если не несёт пользы для бизнеса, если не помогает зарабатывать больше или тратить меньше.
Техническим менеджерам в этой теме выпала нелёгкая доля. Если в "бизнесовых" задачах типа "нарасти конверсию в действие Х" понятна денежная ценность (выше конверсия -> больше целевых действий -> больше выручка), то в технических задачах она далеко не так очевидна. Как, например, посчитать денежный профит от ускорения ответа от веб-сервиса? Как оценить влияние на метрики бизнеса от миграции с одной СУБД на другую? И это далеко не самые сложные примеры.
И что
А вот что - одно из отличий классного технического менеджера от середнячка в том, что первый умеет строить в головах команды и стейкхолдеров ту самую связь от технической "лабуды" до понятной бизнесу ценности. Он умеет показать, как рефакторинг кода поможет тратить меньше или как оптимизация вот этого микро сервиса положительно повлияет на опыт клиента. Такое умение приводит к двум прикольным следствиям:
1. Помогает вдохновить команду. Конечно, все люди разные и кого-то совсем не вдохновляет рост бизнеса или улучшение клиентского опыта. Но есть люди, для которых такая обратная связь очень важна и именно она наполняет их работу особым смыслом. Так вот, для таких людей понимание их влияния становится вдохновением, которое помогает им перформить и получать больше удовлетворения от работы.
2. Помогает отбрасывать шелуху. Когда ты хорошо понимаешь, что действительно ценно для бизнеса, а что нет - намного легче говорить "нет" задачам, которые хоть и выглядят полезными, но на самом деле несут меньшую пользу. В условия ограниченного ресурса, такое отсеивание помогает сохранить фокус на действительно важном и дает смелость отбрасывать лишнее. Такое умение само по себе начинает экономить бизнесу деньги, ведь, не будь его, команда, вероятно, занималась бы какой-то сомнительной технической задачей, занимая время, которое можно было потратить на реально полезное дело.
А как
А как именно строить такую связь от техники к бизнесу? Об этом напишу в одном из следующих постов.
Равно как и тест-кейсы. Или эти дейли-митинги, планирования и ретро. Они тоже не нужны вместе с грамотно описанным ТЗ. Оптимизации производительности, метрики и мониторинг туда же. А тем более все эти задачи в Jira и прочих трекерах. Все это никому не нужно...
...если не несёт пользы для бизнеса, если не помогает зарабатывать больше или тратить меньше.
Техническим менеджерам в этой теме выпала нелёгкая доля. Если в "бизнесовых" задачах типа "нарасти конверсию в действие Х" понятна денежная ценность (выше конверсия -> больше целевых действий -> больше выручка), то в технических задачах она далеко не так очевидна. Как, например, посчитать денежный профит от ускорения ответа от веб-сервиса? Как оценить влияние на метрики бизнеса от миграции с одной СУБД на другую? И это далеко не самые сложные примеры.
И что
А вот что - одно из отличий классного технического менеджера от середнячка в том, что первый умеет строить в головах команды и стейкхолдеров ту самую связь от технической "лабуды" до понятной бизнесу ценности. Он умеет показать, как рефакторинг кода поможет тратить меньше или как оптимизация вот этого микро сервиса положительно повлияет на опыт клиента. Такое умение приводит к двум прикольным следствиям:
1. Помогает вдохновить команду. Конечно, все люди разные и кого-то совсем не вдохновляет рост бизнеса или улучшение клиентского опыта. Но есть люди, для которых такая обратная связь очень важна и именно она наполняет их работу особым смыслом. Так вот, для таких людей понимание их влияния становится вдохновением, которое помогает им перформить и получать больше удовлетворения от работы.
2. Помогает отбрасывать шелуху. Когда ты хорошо понимаешь, что действительно ценно для бизнеса, а что нет - намного легче говорить "нет" задачам, которые хоть и выглядят полезными, но на самом деле несут меньшую пользу. В условия ограниченного ресурса, такое отсеивание помогает сохранить фокус на действительно важном и дает смелость отбрасывать лишнее. Такое умение само по себе начинает экономить бизнесу деньги, ведь, не будь его, команда, вероятно, занималась бы какой-то сомнительной технической задачей, занимая время, которое можно было потратить на реально полезное дело.
А как
А как именно строить такую связь от техники к бизнесу? Об этом напишу в одном из следующих постов.
🔥6
Про связь технических задач и бизнеса
В прошлом посте я писал про то, как полезно менеджеру строить связь между техническими задачами и бизнес-метриками. Такая связь нужна, как минимум, для:
1. Прозрачности пользы, которую приносит продукт/команда
2. Вдохновения команды - люди лучше понимают свой вклад
3. Приоритезации в условиях ограниченных ресурсов - проще сфокусироваться на наиболее полезных задачах.
В этом посте поговорим про то, как именно строить такую связь.
Условно "идеальным" мерилом важности задачи являются деньги. Чем больше задача позволяет зарабатывать или экономить в конечном итоге, тем она важнее и срочнее. Однако в большинстве технических задач влияние на деньги неочевидно, мягко говоря. Нельзя просто взять и оценить сколько рублей нам принесёт, например, переделка фреймворка для автотестов или ускорение ответа от веб-сервиса на 300 мс. Да и оценивать все задачи в деньгах довольно утомительно, если это делать хотя бы с какой-то точностью.
Однако отсутствие денежной оценки не делает задачу бесполезной т.к. понятно, что она приносит пользу другим способом. И у этой пользы с большой вероятностью есть какая-то метрика, которая позволяет более объективно заценить пользу.
Для примера давайте возьмём пример с переделкой фреймворка автотестов для какой-то системы.
Какая польза от этой задачи? На кой её вообще делать? Если сказать по-простому, то, например:
1. Чтоб тесты быстрее проходили
2. Чтобы код был более понятным
3. Чтобы проще был расширять функционал.
Неплохо, цели благие. Но какие метрики могут быть у этих целей? Другими словами, на какие метрики непосредственно влияет выполнение этих целей?
1. Чтоб тесты быстрее проходили -> Сокращается время прогона тестов
2. Чтобы код был более понятным -> Сокращается время онбординга новых QA в проект + сокращается кол-во багов в тестах
3. Чтобы проще был расширять функционал -> Сокращается время время написания новых автотестов.
Так. Становится понятнее? Теперь мы знаем, какие метрики объективно покажут пользу от этой задачи (или бесполезность ). Но где тут бизнес-метрики? Где тут денежки?
И вот тут основной переход: вам не обязательно строить связь этих метрик прямо до каких-то рублей. Достаточно достроить связь с какой-то понятной бизнесу метрики и вся дальнейшая цепока будет основываться именно на ней.
Это как оценивать вклад мощности строительнго миксера при постройке дома. Сложно оценить напрямую экономию от мощного миксера, но вы можете прикинуть пользу через экономию на времени рабочего и, вуаля, вы уже примерно понимаете сколько денег вам сэкономит миксер. Понятно, что пример утрированный, но, надеюсь, суть понятна.
Так вот, возвращаясь к нашему примеру с фреймворком автотестов. Как видно, все они влияют на время, которое входит в общее время цикла разработки. Т.е. с этими автотестами разработка должна ускориться. И в этом главная ценность этой задачи!
Для измерения времени разработки давно существует метрика Lead Time и её старшая сестра TTM (Time to Market, но она больше про общее время выпуска фичи, не только про разработку).
Таким образом, переделка фреймворка тестирования сделает разработку быстрее, и это будет видно на метриках Lead Time и TTM. С этими метриками бизнесу работать уже намного проще т.к. стоимость времени разработки, как правило, понятна и её сокращение можно посчитать. Через эти метрики можно обсуждать приоритет с "бизнесменами".
Естественно, приведенный пример не идеален, как и разбор всей этой цепочки, но я надеюсь, что у меня получилось показать принцип построения связи технических- и бизнес-метрик. В моем примере задача помогает экономить на времени разработки.
В прошлом посте я писал про то, как полезно менеджеру строить связь между техническими задачами и бизнес-метриками. Такая связь нужна, как минимум, для:
1. Прозрачности пользы, которую приносит продукт/команда
2. Вдохновения команды - люди лучше понимают свой вклад
3. Приоритезации в условиях ограниченных ресурсов - проще сфокусироваться на наиболее полезных задачах.
В этом посте поговорим про то, как именно строить такую связь.
Условно "идеальным" мерилом важности задачи являются деньги. Чем больше задача позволяет зарабатывать или экономить в конечном итоге, тем она важнее и срочнее. Однако в большинстве технических задач влияние на деньги неочевидно, мягко говоря. Нельзя просто взять и оценить сколько рублей нам принесёт, например, переделка фреймворка для автотестов или ускорение ответа от веб-сервиса на 300 мс. Да и оценивать все задачи в деньгах довольно утомительно, если это делать хотя бы с какой-то точностью.
Однако отсутствие денежной оценки не делает задачу бесполезной т.к. понятно, что она приносит пользу другим способом. И у этой пользы с большой вероятностью есть какая-то метрика, которая позволяет более объективно заценить пользу.
Для примера давайте возьмём пример с переделкой фреймворка автотестов для какой-то системы.
Какая польза от этой задачи? На кой её вообще делать? Если сказать по-простому, то, например:
1. Чтоб тесты быстрее проходили
2. Чтобы код был более понятным
3. Чтобы проще был расширять функционал.
Неплохо, цели благие. Но какие метрики могут быть у этих целей? Другими словами, на какие метрики непосредственно влияет выполнение этих целей?
1. Чтоб тесты быстрее проходили -> Сокращается время прогона тестов
2. Чтобы код был более понятным -> Сокращается время онбординга новых QA в проект + сокращается кол-во багов в тестах
3. Чтобы проще был расширять функционал -> Сокращается время время написания новых автотестов.
Так. Становится понятнее? Теперь мы знаем, какие метрики объективно покажут пользу от этой задачи (
И вот тут основной переход: вам не обязательно строить связь этих метрик прямо до каких-то рублей. Достаточно достроить связь с какой-то понятной бизнесу метрики и вся дальнейшая цепока будет основываться именно на ней.
Это как оценивать вклад мощности строительнго миксера при постройке дома. Сложно оценить напрямую экономию от мощного миксера, но вы можете прикинуть пользу через экономию на времени рабочего и, вуаля, вы уже примерно понимаете сколько денег вам сэкономит миксер. Понятно, что пример утрированный, но, надеюсь, суть понятна.
Так вот, возвращаясь к нашему примеру с фреймворком автотестов. Как видно, все они влияют на время, которое входит в общее время цикла разработки. Т.е. с этими автотестами разработка должна ускориться. И в этом главная ценность этой задачи!
Для измерения времени разработки давно существует метрика Lead Time и её старшая сестра TTM (Time to Market, но она больше про общее время выпуска фичи, не только про разработку).
Таким образом, переделка фреймворка тестирования сделает разработку быстрее, и это будет видно на метриках Lead Time и TTM. С этими метриками бизнесу работать уже намного проще т.к. стоимость времени разработки, как правило, понятна и её сокращение можно посчитать. Через эти метрики можно обсуждать приоритет с "бизнесменами".
Естественно, приведенный пример не идеален, как и разбор всей этой цепочки, но я надеюсь, что у меня получилось показать принцип построения связи технических- и бизнес-метрик. В моем примере задача помогает экономить на времени разработки.
🔥3
Когда подчинение менеджеру это зло
Спойлер: всегда. Шучу.
На самом деле, какое-то подчинение в команде помогает, например, разделить ответственность - разработчик пишет код по ТЗ и не парится по поводу бизнес-целей фичи. Он просто доверяет менеджеру и делает то, о чём его просят. Все делают своё дело и все в выигрыше. Однако бывает и так, когда подчинение всё портит.
А портит всё оно тогда, когда от команды ожидается креативность и даётся большая степень свободы в принятии решений. Мол, вот вы команда, у вас есть всё, что нужно, мы не будем говорить вам ЧТО ИМЕННО делать, скажем только ЦЕЛИ, а дальше решайте сами. Пока-пока, ждём результатов! Такая модель хорошо зарекомендовала себя в т.н. "продуктовых" командах, которые имеют сами в себе всех нужных людей, чтобы добавить какую-то ценность в продукт. Например, новую фичу. Такой подход показал свою эффективность во многих компаниях в мире.
Так вот, про подчинение. Подчинение в таких командах может напрочь убивать те самые "креативность" и "свободу принятия решений". Там, где раньше менеджеру на очередную "супер идею" разработчики сказали бы, что это полная фигня - вырастает фильтр "а выгодно ли мне говорить что-то против?". Там, где QA мог тормознуть задачу сомнительного качества - он лишний раз подумает, не скажется ли это на его премии. Таким образом, подчинение может ухудшать итоговый результат. Структура команды вроде четкая, а вот конечная ценность пользователю наносится меньше из-за того, что создаётся почва для всяких компромиссов.
Так, а что делать то?
Если команда подходит под критерии о необходимости "креативности" и "свободы принятия решений", то у менеджера продукта не должно быть прямых подчиненных в команде. Разработчики должны быть подчинены руководителю разработчиков и так далее с каждой ролью. Менеджер должен управлять ими только в рамках функции команды и не принимать решений, влияющих на зарплаты и премии. В такой конфигурации в команде допускается продуктивный конфликт, когда никто не боится высказать своё мнение, даже если оно противоречит мнению менеджера. Менеджер не может просто "задавить" сотрудника своим словом, придётся более конструктивно и продуманно доказывать что делать и почему именно так. Зачастую, именно в таких конфликтах и рождается наиболее элегантное решение вопроса.
Конечно, это требует больше энергии со стороны менеджера, но что поделать - таков путь.
На самом деле, какое-то подчинение в команде помогает, например, разделить ответственность - разработчик пишет код по ТЗ и не парится по поводу бизнес-целей фичи. Он просто доверяет менеджеру и делает то, о чём его просят. Все делают своё дело и все в выигрыше. Однако бывает и так, когда подчинение всё портит.
А портит всё оно тогда, когда от команды ожидается креативность и даётся большая степень свободы в принятии решений. Мол, вот вы команда, у вас есть всё, что нужно, мы не будем говорить вам ЧТО ИМЕННО делать, скажем только ЦЕЛИ, а дальше решайте сами. Пока-пока, ждём результатов! Такая модель хорошо зарекомендовала себя в т.н. "продуктовых" командах, которые имеют сами в себе всех нужных людей, чтобы добавить какую-то ценность в продукт. Например, новую фичу. Такой подход показал свою эффективность во многих компаниях в мире.
Так вот, про подчинение. Подчинение в таких командах может напрочь убивать те самые "креативность" и "свободу принятия решений". Там, где раньше менеджеру на очередную "супер идею" разработчики сказали бы, что это полная фигня - вырастает фильтр "а выгодно ли мне говорить что-то против?". Там, где QA мог тормознуть задачу сомнительного качества - он лишний раз подумает, не скажется ли это на его премии. Таким образом, подчинение может ухудшать итоговый результат. Структура команды вроде четкая, а вот конечная ценность пользователю наносится меньше из-за того, что создаётся почва для всяких компромиссов.
Так, а что делать то?
Если команда подходит под критерии о необходимости "креативности" и "свободы принятия решений", то у менеджера продукта не должно быть прямых подчиненных в команде. Разработчики должны быть подчинены руководителю разработчиков и так далее с каждой ролью. Менеджер должен управлять ими только в рамках функции команды и не принимать решений, влияющих на зарплаты и премии. В такой конфигурации в команде допускается продуктивный конфликт, когда никто не боится высказать своё мнение, даже если оно противоречит мнению менеджера. Менеджер не может просто "задавить" сотрудника своим словом, придётся более конструктивно и продуманно доказывать что делать и почему именно так. Зачастую, именно в таких конфликтах и рождается наиболее элегантное решение вопроса.
Конечно, это требует больше энергии со стороны менеджера, но что поделать - таков путь.
👍3
Когда попадешь в новый канал, хочется сразу понять, что тут есть интересного и стоит ли оставаться.
Для упрощения этой задачи решил сделать оглавление по постам, чтобы их можно было быстро прощелкать и сложить какое-то базовое впечатление.
Ну и чтобы старые посты было удобнее перечитывать!(я ведь не один их перечитываю иногда...не один ведь?!)
Для упрощения этой задачи решил сделать оглавление по постам, чтобы их можно было быстро прощелкать и сложить какое-то базовое впечатление.
Ну и чтобы старые посты было удобнее перечитывать!
Оглавление
Как я первый раз уволил человека
Когда продолбать задачи не так уж плохо
Про продажу задач
Базовая проверка аналитика
Когда не надо здороваться в чате
Про мета-вопросы
Про первую статью на Хабр
Почему технари ничего не могут без менеджера
Про неприятную обязанность менеджера
Менеджерское одиночество
Твой код никому не нужен
Про связь технических задач и бизнеса
Когда подчинение менеджеру это зло
Про то, как уходить из команды
Про медовый месяц менеджера
Про догфудинг
Про аэропорты
Про важность сегментации
Про переработки у инженеров
Про AI тулы в работе
Про мотивацию выступить
Про выбор темы для выступления
Часть 1. Что делать, если я не знаю о чем рассказать
Часть 2. Что делать, если я не знаю о чем рассказать
Про книгу Хорошая стратегия плохая стратегия
Про сбой CrowdStrike и Windows
Про MongoDB и удержание пользователей
Technical Product Manager'ы не нужны
Про Meeting notes
Про признание среди инженеров
Про эмоциональный аттач к продукту
Про темную сторону data-driven подхода
Про важные мелочи при запуске продукта в соло
Про ограниченную ответственность продакта
Про конфликт команд продаж и продукта
Про книгу OpenTelemetry
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry?
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry? часть 2
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (1/2)
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (2/2)
Про мои собесы в Яндекс 1
Про мои собесы в Яндекс 2
Когда TPM все таки нужен (а когда нет)
Про книгу "Искусство войны"
Про фокус на результатах
Как я первый раз уволил человека
Когда продолбать задачи не так уж плохо
Про продажу задач
Базовая проверка аналитика
Когда не надо здороваться в чате
Про мета-вопросы
Про первую статью на Хабр
Почему технари ничего не могут без менеджера
Про неприятную обязанность менеджера
Менеджерское одиночество
Твой код никому не нужен
Про связь технических задач и бизнеса
Когда подчинение менеджеру это зло
Про то, как уходить из команды
Про медовый месяц менеджера
Про догфудинг
Про аэропорты
Про важность сегментации
Про переработки у инженеров
Про AI тулы в работе
Про мотивацию выступить
Про выбор темы для выступления
Часть 1. Что делать, если я не знаю о чем рассказать
Часть 2. Что делать, если я не знаю о чем рассказать
Про книгу Хорошая стратегия плохая стратегия
Про сбой CrowdStrike и Windows
Про MongoDB и удержание пользователей
Technical Product Manager'ы не нужны
Про Meeting notes
Про признание среди инженеров
Про эмоциональный аттач к продукту
Про темную сторону data-driven подхода
Про важные мелочи при запуске продукта в соло
Про ограниченную ответственность продакта
Про конфликт команд продаж и продукта
Про книгу OpenTelemetry
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry?
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry? часть 2
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (1/2)
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (2/2)
Про мои собесы в Яндекс 1
Про мои собесы в Яндекс 2
Когда TPM все таки нужен (а когда нет)
Про книгу "Искусство войны"
Про фокус на результатах
👍3
Сказки технического менеджера pinned «Оглавление Как я первый раз уволил человека Когда продолбать задачи не так уж плохо Про продажу задач Базовая проверка аналитика Когда не надо здороваться в чате Про мета-вопросы Про первую статью на Хабр Почему технари ничего не могут без менеджера Про неприятную…»
Про то, как уходить из команды
Наверно, в жизни каждого менеджера наступает момент, когда ему надо оставить свою команду - его повышают и теперь его ждут новые задачи или он увольняется и уходит в другую компанию - ситуации бывают разные. Вопрос в том, как уйти по-джентельменски, а не как чудак?
Думая об этом, я выделил 4 признака менеджера-чудака:
1. Уходит и не передаёт важные дела. Он забывает передать кому надо договоренности о повышении сотрудников или о ходе проектов. Он не передаёт информацию о планах, а оставляет команду и приемника (если он вообще есть) самих додумываться. Он не оповещает стейкхолдеров о своем уходе. Ну вы поняли, короче - он уходит, а они там сами как-нибудь.
2. Оставляет неприятную атмосферу. Менеджер-негодяй не заботится об эмоциональном фоне команды, когда уходит - ему пофиг, что он грубо сообщил об этом или что половины команды не было, когда он говорил об этом - who cares, узнают от других как-нибудь.
3. Ломает рабочие процессы. Горе-менеджер не заботится о том, чтобы в его отсутствии процессы продолжали работать слаженно - он не ищет себе замену в этих процессах, не поддерживает их до последнего рабочего дня. Процесс нарушился, а это теперь не его дело!
4. Оставляет много неопределенности. Кто будет вместо тебя? Что нам делать, пока нет замены? Когда именно ты уходишь? И ещё куча подобных вопросов ожидаемы и легко прогнозируемы, но наш воображаемый менеджер не хочет потрудиться, чтобы ответить на них ради своей команды.
А, ну и не забудьте сделать всё наоборот, конечно, если вдруг.
Наверно, в жизни каждого менеджера наступает момент, когда ему надо оставить свою команду - его повышают и теперь его ждут новые задачи или он увольняется и уходит в другую компанию - ситуации бывают разные. Вопрос в том, как уйти по-джентельменски, а не как чудак?
Думая об этом, я выделил 4 признака менеджера-чудака:
1. Уходит и не передаёт важные дела. Он забывает передать кому надо договоренности о повышении сотрудников или о ходе проектов. Он не передаёт информацию о планах, а оставляет команду и приемника (если он вообще есть) самих додумываться. Он не оповещает стейкхолдеров о своем уходе. Ну вы поняли, короче - он уходит, а они там сами как-нибудь.
2. Оставляет неприятную атмосферу. Менеджер-негодяй не заботится об эмоциональном фоне команды, когда уходит - ему пофиг, что он грубо сообщил об этом или что половины команды не было, когда он говорил об этом - who cares, узнают от других как-нибудь.
3. Ломает рабочие процессы. Горе-менеджер не заботится о том, чтобы в его отсутствии процессы продолжали работать слаженно - он не ищет себе замену в этих процессах, не поддерживает их до последнего рабочего дня. Процесс нарушился, а это теперь не его дело!
4. Оставляет много неопределенности. Кто будет вместо тебя? Что нам делать, пока нет замены? Когда именно ты уходишь? И ещё куча подобных вопросов ожидаемы и легко прогнозируемы, но наш воображаемый менеджер не хочет потрудиться, чтобы ответить на них ради своей команды.
А, ну и не забудьте сделать всё наоборот, конечно, если вдруг.
❤6👍1
Про медовый месяц менеджера
Когда менеджер приходит в новую компанию или в новую команду, у него возникает совершенно замечательный период - так называемый, медовый месяц менеджера. Почему медовый? Потому что это время имеет два особенных свойства:
1. Минимальные ожидания (если он не кризис-менеджер, конечно).
Обычно в компаниях дают неделю-две-месяц на то, чтобы заонбордиться, прочитать важные документы, познакомиться с командой и всё такое. В этот период от нового человека не ждут свершений или прорыва в проектах - достаточно будет, если он вникнет в базовые дела и начнёт выполнять начальные задачи для этой роли. С ходом времени эти ожидания будут расти и через месяц они будут существенно отличаться от начального состояния.
2. Высокая толерантность к неосведомленности.
Другими словами можно задавать любые тупые вопросы без риска показаться глуповатым. "Почему решили перейти на Postgres вместо MySQL? Почему на ретро вы не делаете icebreaker? Почему поставлены именно такие цели на этот квартал?" - новичку прощаются любые вопросы. И этим надо пользоваться, чтобы глубже понять контекст работы. Конечно, в будущем лучше тоже задавать вопросы, даже если они кажутся глупыми, ведь легче задавать глупые вопросы, чем исправлять глупые ошибки. Но, согласитесь, некоторые вопросы выглядят менее уместными через месяц-другой работы в команде.
Кроме учёта этих свойств, есть ещё пару особенных действий, которые важно сделать в этот период:
1. Познакомиться с ключевыми людьми. Руководителем, лидами команд, клиентами и другими стейкхолдерами. Важно понять их ожидания (if any), разобраться с зонами ответственности (с какими вопросами к ним приходить), да и просто по-человечески познакомиться (вживую, если есть возможность). На своём опыте ни раз замечал, что после личного знакомства совместная работа идёт более гладко.
2. Договориться о целях в своей роли. Нужно в явном виде и как можно более однозначно определить, что ожидает руководитель (в идеале, ещё и его руководитель, но эту мысль пока придержим🤐) и как он будет оценивать выполненную работу. В противном случае можно начать делать не то, что нужно и, в лучшем случае, узнать об этом по ходу выполнения, а в худшем - в конце испытательного срока. Поэтому правила игры лучше зафиксировать на старте.
Как считаете, что ещё важно сделать во время медового месяца менеджера?
Когда менеджер приходит в новую компанию или в новую команду, у него возникает совершенно замечательный период - так называемый, медовый месяц менеджера. Почему медовый? Потому что это время имеет два особенных свойства:
1. Минимальные ожидания (если он не кризис-менеджер, конечно).
Обычно в компаниях дают неделю-две-месяц на то, чтобы заонбордиться, прочитать важные документы, познакомиться с командой и всё такое. В этот период от нового человека не ждут свершений или прорыва в проектах - достаточно будет, если он вникнет в базовые дела и начнёт выполнять начальные задачи для этой роли. С ходом времени эти ожидания будут расти и через месяц они будут существенно отличаться от начального состояния.
2. Высокая толерантность к неосведомленности.
Другими словами можно задавать любые тупые вопросы без риска показаться глуповатым. "Почему решили перейти на Postgres вместо MySQL? Почему на ретро вы не делаете icebreaker? Почему поставлены именно такие цели на этот квартал?" - новичку прощаются любые вопросы. И этим надо пользоваться, чтобы глубже понять контекст работы. Конечно, в будущем лучше тоже задавать вопросы, даже если они кажутся глупыми, ведь легче задавать глупые вопросы, чем исправлять глупые ошибки. Но, согласитесь, некоторые вопросы выглядят менее уместными через месяц-другой работы в команде.
Кроме учёта этих свойств, есть ещё пару особенных действий, которые важно сделать в этот период:
1. Познакомиться с ключевыми людьми. Руководителем, лидами команд, клиентами и другими стейкхолдерами. Важно понять их ожидания (if any), разобраться с зонами ответственности (с какими вопросами к ним приходить), да и просто по-человечески познакомиться (вживую, если есть возможность). На своём опыте ни раз замечал, что после личного знакомства совместная работа идёт более гладко.
2. Договориться о целях в своей роли. Нужно в явном виде и как можно более однозначно определить, что ожидает руководитель (в идеале, ещё и его руководитель, но эту мысль пока придержим🤐) и как он будет оценивать выполненную работу. В противном случае можно начать делать не то, что нужно и, в лучшем случае, узнать об этом по ходу выполнения, а в худшем - в конце испытательного срока. Поэтому правила игры лучше зафиксировать на старте.
Как считаете, что ещё важно сделать во время медового месяца менеджера?
❤7
Про догфудинг
Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".
А причём тут технический менеджмент, спросите вы?
А вот причём. Я искренне убежден, что если технический менеджер не использует свой продукт регулярно как обычный пользователь, то он теряет 80% возможностей для его улучшения. Цифру я, конечно, придумал, но сути это не меняет.
Не используешь свой продукт:
- не видишь очевидных провалов в сценарии использования (кто-то же другой их должен заметить, да?)
- не замечаешь раздражающих багов (которые уже давно есть в беклоге, просто "не горят")
- не примечаешь напрашивающихся улучшений.
Конечно, всё это актуально для продуктов, в которых сам менеджер является целевой аудиторией, для которой делается система. Но что делать, если вы разрабатываете какую-то специфичную историю, например, b2b сервис по автоматизации расчётов коммунальных услуг для складов? Как тут догфудить?
Честно говоря, однозначного ответа я не нашёл. Я вижу в этом границы использования этой практики - если продукт неактуален для меня, как для клиента, то насколько глубокую обратную связь по его использованию я смогу дать? Это как просить водителя автобуса пользоваться штурвалом от самолета.
Однако уверенное базовое понимание ценности системы для пользователей, способность осмысленно пройти основные сценарии использования - всё это минимум, который я бы ожидал от любого технического менеджера.
Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".
А причём тут технический менеджмент, спросите вы?
А вот причём. Я искренне убежден, что если технический менеджер не использует свой продукт регулярно как обычный пользователь, то он теряет 80% возможностей для его улучшения. Цифру я, конечно, придумал, но сути это не меняет.
Не используешь свой продукт:
- не видишь очевидных провалов в сценарии использования (кто-то же другой их должен заметить, да?)
- не замечаешь раздражающих багов (которые уже давно есть в беклоге, просто "не горят")
- не примечаешь напрашивающихся улучшений.
Конечно, всё это актуально для продуктов, в которых сам менеджер является целевой аудиторией, для которой делается система. Но что делать, если вы разрабатываете какую-то специфичную историю, например, b2b сервис по автоматизации расчётов коммунальных услуг для складов? Как тут догфудить?
Честно говоря, однозначного ответа я не нашёл. Я вижу в этом границы использования этой практики - если продукт неактуален для меня, как для клиента, то насколько глубокую обратную связь по его использованию я смогу дать? Это как просить водителя автобуса пользоваться штурвалом от самолета.
Однако уверенное базовое понимание ценности системы для пользователей, способность осмысленно пройти основные сценарии использования - всё это минимум, который я бы ожидал от любого технического менеджера.
❤2👍1
Про аэропорты
Стратссессии, планирования, встречи с клиентами - когда ты менеджер в распределенной команде, то частенько возникает потребность поехать в командировку. Ведь как бы ни был крут Зум - часто именно личное общение решает.
В прошлом году мне довелось полетать более 20 раз (не все по работе, конечно). Для кого-то это обычное дело, но для меня такое количество перелетов было в новинку. Соответственно, я много времени провел в аэропортах. И вот пока я еду в такси в очередную поездку, решил поделиться своими хаками, которые выработал для себя, чтобы время в аэропорту и полете прошло более комфортно. Сразу скажу: я не претендую на новизну, просто буду рад, если кто-то отметит что-то полезным для себя.
1. Электронный посадочный вместо бумажного. Если есть возможность, я не печатаю посадочный, а использую электронную версию. Во-первых, это намного быстрее, чем искать терминал печати или отстоять очередь на регистрацию. Во-вторых, бумажку легко потерять, а это осложнит последующую отчётность по командировке.
2. Без багажа. Купил себе мини-чемодан, который проходит в ручную кладь, или гоняю с рюкзаком. Экономится время на ожидание багажа после посадки и деньги на его оплату.
3. Заранее готовлюсь к досмотрам. Ещё на пути в аэропорт выкладываю все металлические предметы из карманов в рюкзак, туда же идут часы, наушники и телефон. И пока другие спешно выкладывают ключи и телефоны, я уже прохожу первый досмотр. Затем достаю паспорт и телефон с посадочным, на втором досмотре телефон и паспорт кладу обратно в рюкзак, чтобы не выкладывать в ящик. После всех досмотров можно уже вернуть часы и прочую технику на нужные места.
4. Вызываю такси при выходе из самолёта. Поскольку багаж я не жду, то, скорее всего, я быстро выйду из аэропорта. А значит время ожидания можно сократить, если вызвать такси сразу.
А есть ли какие-то хаки у вас? Поделитесь!
Стратссессии, планирования, встречи с клиентами - когда ты менеджер в распределенной команде, то частенько возникает потребность поехать в командировку. Ведь как бы ни был крут Зум - часто именно личное общение решает.
В прошлом году мне довелось полетать более 20 раз (не все по работе, конечно). Для кого-то это обычное дело, но для меня такое количество перелетов было в новинку. Соответственно, я много времени провел в аэропортах. И вот пока я еду в такси в очередную поездку, решил поделиться своими хаками, которые выработал для себя, чтобы время в аэропорту и полете прошло более комфортно. Сразу скажу: я не претендую на новизну, просто буду рад, если кто-то отметит что-то полезным для себя.
1. Электронный посадочный вместо бумажного. Если есть возможность, я не печатаю посадочный, а использую электронную версию. Во-первых, это намного быстрее, чем искать терминал печати или отстоять очередь на регистрацию. Во-вторых, бумажку легко потерять, а это осложнит последующую отчётность по командировке.
2. Без багажа. Купил себе мини-чемодан, который проходит в ручную кладь, или гоняю с рюкзаком. Экономится время на ожидание багажа после посадки и деньги на его оплату.
3. Заранее готовлюсь к досмотрам. Ещё на пути в аэропорт выкладываю все металлические предметы из карманов в рюкзак, туда же идут часы, наушники и телефон. И пока другие спешно выкладывают ключи и телефоны, я уже прохожу первый досмотр. Затем достаю паспорт и телефон с посадочным, на втором досмотре телефон и паспорт кладу обратно в рюкзак, чтобы не выкладывать в ящик. После всех досмотров можно уже вернуть часы и прочую технику на нужные места.
4. Вызываю такси при выходе из самолёта. Поскольку багаж я не жду, то, скорее всего, я быстро выйду из аэропорта. А значит время ожидания можно сократить, если вызвать такси сразу.
А есть ли какие-то хаки у вас? Поделитесь!
🔥6👍1
Сегодня выступил на конференции Mergeconf в университете Иннополиса с темой "Словесный No Code или как ускорять разработку силой слова". В докладе я поделился своими мыслями о важности эффективной коммуникации в командах и советами из собственного опыта на эту тему. Судя по фидбеку аудитории и вопросам в конце - доклад таки нанёс определенную пользу:)
P.S. Для читателей канала чуть позже сделаю пару постов с выжимкой самой сути доклада.
P.S. Для читателей канала чуть позже сделаю пару постов с выжимкой самой сути доклада.
🔥19
Про важность сегментации
Представьте, что вы менеджер продукта (например, приложения для заказа еды) и вы анализируете тикеты из поддержки в поисках новых задач для беклога. Вы выделили 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. Услышал этот пример про сегментацию на курсе Вани Замесина и очень уж он мне понравился, поэтому и делюсь с вами:)
Представьте, что вы менеджер продукта (например, приложения для заказа еды) и вы анализируете тикеты из поддержки в поисках новых задач для беклога. Вы выделили 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. Услышал этот пример про сегментацию на курсе Вани Замесина и очень уж он мне понравился, поэтому и делюсь с вами:)
🔥8
Про доклад на Mergeconf 2024
Пару постов назад обещал поделиться выжимкой своего доклада с конференции Mergeconf 2024, которая проходила в Иннополисе в конце апреля. Обещание надо выполнять, поэтому погнали:)
Сразу скажу, что я впервые выступал по НЕтехнической теме и, честно говоря, не могу сказать, что мне очень уж понравилось:)
Доклад назывался "Словесный No Code или как ускорять разработку силой слова" и был посвящен теме коммуникаций внутри команд. В самом начале доклада я рассказал о паре исследований, которые показали исключительную важность софт-скиллов для инженеров:
1. Исследование LinkedIn, в котором они на основе своих данных заключили, что те, кто развивают софт скиллы И хард-скиллы получают повышение на 8% быстрее, чем те, кто качает только хард-скиллы.
2. Исследование 1918 года о качестве инженерного образования в США, в котором авторы проводят последовательные опросы инженеров (сначала выборочные интервью, потом опросами по 1,5к и 7к инженеров), в результате которых обнаруживается, что качества характера и коммуникативные навыки это САМАЯ ВАЖНАЯ категория навыков для инженера. У более, чем 50% респондентов важность техники оказалась на последнем месте. Авторы немного недоумевают, почему инженеры с рынка труда говорят о такой важности софт-скиллов при том, что в технических университетах студентов максимально накачивают именно техническими знаниями. Оффтоп: результаты этого исследования потом повлияют на реформы в системе образования США в 20 веке. Само исследование вот тут (стр. 106-107).
Вывод из исследований таков, что софт-скиллы ДЕЙСТВИТЕЛЬНО очень важны, и если хочется достигнуть чего-то значимого, то лучше их развивать.
Немного порассуждав о том, что такое коммуникация (я сформулировал её как "целенаправленное общение") и можно ли измерить её эффективность, мы перешли к советикам по тому, как сделать её эффективнее. Советы разделились на 2 группы:
1. По форме коммуникации.
2. По сути.
В первую группу у меня попали советы, которые затрагивают больше техники общения. Во второй группе я попытался опуститься чуть глубже и поговорить про внутреннее состояние в процессе взаимодействия.
Чтобы не раздувать один пост, опубликую эти советы отдельными постами завтра и послезавтра.
Пару постов назад обещал поделиться выжимкой своего доклада с конференции Mergeconf 2024, которая проходила в Иннополисе в конце апреля. Обещание надо выполнять, поэтому погнали:)
Сразу скажу, что я впервые выступал по НЕтехнической теме и, честно говоря, не могу сказать, что мне очень уж понравилось:)
Доклад назывался "Словесный No Code или как ускорять разработку силой слова" и был посвящен теме коммуникаций внутри команд. В самом начале доклада я рассказал о паре исследований, которые показали исключительную важность софт-скиллов для инженеров:
1. Исследование LinkedIn, в котором они на основе своих данных заключили, что те, кто развивают софт скиллы И хард-скиллы получают повышение на 8% быстрее, чем те, кто качает только хард-скиллы.
2. Исследование 1918 года о качестве инженерного образования в США, в котором авторы проводят последовательные опросы инженеров (сначала выборочные интервью, потом опросами по 1,5к и 7к инженеров), в результате которых обнаруживается, что качества характера и коммуникативные навыки это САМАЯ ВАЖНАЯ категория навыков для инженера. У более, чем 50% респондентов важность техники оказалась на последнем месте. Авторы немного недоумевают, почему инженеры с рынка труда говорят о такой важности софт-скиллов при том, что в технических университетах студентов максимально накачивают именно техническими знаниями. Оффтоп: результаты этого исследования потом повлияют на реформы в системе образования США в 20 веке. Само исследование вот тут (стр. 106-107).
Вывод из исследований таков, что софт-скиллы ДЕЙСТВИТЕЛЬНО очень важны, и если хочется достигнуть чего-то значимого, то лучше их развивать.
Немного порассуждав о том, что такое коммуникация (я сформулировал её как "целенаправленное общение") и можно ли измерить её эффективность, мы перешли к советикам по тому, как сделать её эффективнее. Советы разделились на 2 группы:
1. По форме коммуникации.
2. По сути.
В первую группу у меня попали советы, которые затрагивают больше техники общения. Во второй группе я попытался опуститься чуть глубже и поговорить про внутреннее состояние в процессе взаимодействия.
Чтобы не раздувать один пост, опубликую эти советы отдельными постами завтра и послезавтра.
❤4
Первая группа "советиков" касается внешней формы коммуникаций, она больше про внешнее восприятие т.е. про то, как общение с нами воспринимают другие люди.
1. Не пишите "привет". Короткий пункт про то, что в чатах лучше писать приветствие и свой вопрос СРАЗУ в одном сообщении. Не надо писать "привет" и ждать реакции, чтобы продолжить общение. Ровно об этом когда-то у меня был отдельный пост, когда наболело в очередной раз.
2. "Чего ты хочешь от меня?" или про то, что надо четко и однозначно формулировать свой запрос в коммуникациях, если вам что-то нужно от собеседника. Когда менеджер просит команду "по возможности, посмотреть документ Х в ближайшее время" он создаёт не иллюзорную возможность, что разные члены команды поймут эту просьбу по разному. Один посмотрит сегодня, второй оставит комменты по орфографии, а третий забудет после прочтения. "Прошу всех участников проекта перейти на страницу с описанием, прочитать её и оставить свои комментарии до 13 часов пятницы" - тут простор для разночтения уже меньше. Следовательно, вероятность выполнения нужной работы возрастает.
3. Предугадайте вопросы. Когда мы обращаемся с просьбой или задачей к другому человеку, то, вероятно, мы можем предугадать некоторые вопросы и заранее дать на них ответы. Условно, если вы просите финансиста купить лицензии на WinRAR (внезапно!), то есть отличная от нуля вероятность, что он спросит про кол-во лицензий, их стоимость и источник бюджета. И вы можете сэкономить время на всю эту процедуру, если сразу же дадите ему нужную информацию. В докладе я оговорился, что хоть это и экономит время, но додумывать за других их вопросы - дело неблагодарное. Поэтому лично для себя я решил закрывать с самого начала только такие вопросы, в которых я ПРЯМ ТОЧНО уверен, что они будут.
4. Не упарывайтесь в детали. Порой при обсуждении верхнеуровневых вопросов, люди углубляются в детали, обсуждение которых может вообще не пригодиться. Например, когда вы обсуждаете то, как ускорить запуск вашего приложения, совершенно не важно как вы будете именовать партиции в Postgre, которые потенциально могут ускорить выполнение запросов. Может вы и не будете делать эти партиции, и есть ещё N более важных векторов оптимизаций. В итоге тратится время, верхнеуровневые вопросы не решены, назначаем ещё один созвон...
5. Подстраивайтесь под ценности собеседника. Если вы знаете, как ВАША задача (в смысле, от вас) может быть полезна собеседнику, как она доставляет ценность ЕМУ, то на этом стоит акцентировать внимание, чтобы повысить мотивацию сделать именно вашу задачу в первую очередь. Например, вам нужно, чтобы ребята из контакт-центра собрали нужные данные для вашей задачи. В обычном режиме они сделают это в Q5 "согласно приоритетам" (с), но если вы подсветите им как ВАША задача сократит время выдачи доступа ИХ новым сотрудникам (это всегда головная боль в контакт-центрах из-за текучки), то может они возьмут её в более короткие сроки. В докладе я оговорился, что эту идею можно использовать не только на благо, но и на зло. Например, для манипуляции - скрытно мотивировать собеседника делать то, что нужно ВАМ в ущерб его интересам. Так не надо, такое я осуждаю.
6. Фиксируйте договоренности. Вроде договорились обо всём, но в момент Х оказывается, что "ой, это не лучшая идея, давай ещё подумаем" или "извини, не помню, что бы мы такое обсуждали, закинь встречу обсудим". Знакомая ситуация? И ведь часто это происходит без злого умысла. И чтобы такого было поменьше, после каждой встречи, на которой родились значимые договоренности, рекомендую отправлять участникам встречи meeting notes, протокол встречи - в разных компаниях называют по-своему. В них должно быть четко и однозначно описано: кто, что и когда договорился сделать. "Привет, вы уже настроили для нас Clickhouse" - "Какой Clickhouse? Мы не планировали вам его давать" - "Глянь в почте, две недели назад вы обещали его подготовить для нас" - "Ой, точно, сейчас что-нибудь придумаем..."
Это были советики по форме. В следующем посте будут советики по сути коммуникации.
1. Не пишите "привет". Короткий пункт про то, что в чатах лучше писать приветствие и свой вопрос СРАЗУ в одном сообщении. Не надо писать "привет" и ждать реакции, чтобы продолжить общение. Ровно об этом когда-то у меня был отдельный пост, когда наболело в очередной раз.
2. "Чего ты хочешь от меня?" или про то, что надо четко и однозначно формулировать свой запрос в коммуникациях, если вам что-то нужно от собеседника. Когда менеджер просит команду "по возможности, посмотреть документ Х в ближайшее время" он создаёт не иллюзорную возможность, что разные члены команды поймут эту просьбу по разному. Один посмотрит сегодня, второй оставит комменты по орфографии, а третий забудет после прочтения. "Прошу всех участников проекта перейти на страницу с описанием, прочитать её и оставить свои комментарии до 13 часов пятницы" - тут простор для разночтения уже меньше. Следовательно, вероятность выполнения нужной работы возрастает.
3. Предугадайте вопросы. Когда мы обращаемся с просьбой или задачей к другому человеку, то, вероятно, мы можем предугадать некоторые вопросы и заранее дать на них ответы. Условно, если вы просите финансиста купить лицензии на WinRAR (внезапно!), то есть отличная от нуля вероятность, что он спросит про кол-во лицензий, их стоимость и источник бюджета. И вы можете сэкономить время на всю эту процедуру, если сразу же дадите ему нужную информацию. В докладе я оговорился, что хоть это и экономит время, но додумывать за других их вопросы - дело неблагодарное. Поэтому лично для себя я решил закрывать с самого начала только такие вопросы, в которых я ПРЯМ ТОЧНО уверен, что они будут.
4. Не упарывайтесь в детали. Порой при обсуждении верхнеуровневых вопросов, люди углубляются в детали, обсуждение которых может вообще не пригодиться. Например, когда вы обсуждаете то, как ускорить запуск вашего приложения, совершенно не важно как вы будете именовать партиции в Postgre, которые потенциально могут ускорить выполнение запросов. Может вы и не будете делать эти партиции, и есть ещё N более важных векторов оптимизаций. В итоге тратится время, верхнеуровневые вопросы не решены, назначаем ещё один созвон...
5. Подстраивайтесь под ценности собеседника. Если вы знаете, как ВАША задача (в смысле, от вас) может быть полезна собеседнику, как она доставляет ценность ЕМУ, то на этом стоит акцентировать внимание, чтобы повысить мотивацию сделать именно вашу задачу в первую очередь. Например, вам нужно, чтобы ребята из контакт-центра собрали нужные данные для вашей задачи. В обычном режиме они сделают это в Q5 "согласно приоритетам" (с), но если вы подсветите им как ВАША задача сократит время выдачи доступа ИХ новым сотрудникам (это всегда головная боль в контакт-центрах из-за текучки), то может они возьмут её в более короткие сроки. В докладе я оговорился, что эту идею можно использовать не только на благо, но и на зло. Например, для манипуляции - скрытно мотивировать собеседника делать то, что нужно ВАМ в ущерб его интересам. Так не надо, такое я осуждаю.
6. Фиксируйте договоренности. Вроде договорились обо всём, но в момент Х оказывается, что "ой, это не лучшая идея, давай ещё подумаем" или "извини, не помню, что бы мы такое обсуждали, закинь встречу обсудим". Знакомая ситуация? И ведь часто это происходит без злого умысла. И чтобы такого было поменьше, после каждой встречи, на которой родились значимые договоренности, рекомендую отправлять участникам встречи meeting notes, протокол встречи - в разных компаниях называют по-своему. В них должно быть четко и однозначно описано: кто, что и когда договорился сделать. "Привет, вы уже настроили для нас Clickhouse" - "Какой Clickhouse? Мы не планировали вам его давать" - "Глянь в почте, две недели назад вы обещали его подготовить для нас" - "Ой, точно, сейчас что-нибудь придумаем..."
Это были советики по форме. В следующем посте будут советики по сути коммуникации.
🔥5
Вторая группа "советиков" касается больше внутренней сути коммуникации и находится на чуть более глубоком уровне, чем какие-то техники общения. В самом начале этого раздела я оговорился, что для применения следующих пунктов нужно на личном уровне быть искренне заинтересованным в собеседнике. Если этого не будет, то собеседник почувствует фальшь и это осложнит коммуникацию. Люди всегда чувствую эту фальшь, когда над ними пытаются провернуть какие-то "техники общения", в то время как на деле вам наплевать на них. Итак, к советикам.
7. Думайте в формате win-win. Этот формат подразумевает, что вы позаботитесь не только о своей выгоде, но и о выгоде собеседника. Если вы прогнете собеседника под себя, то вы может и выиграйте в краткосроке, но на долгосроке хорошо работает только win-win взаимодействие. При этом, конечно, эти самые "win" могут быть ОЧЕНЬ разными в разных ситуациях.
8. Пытайтесь понять собеседника. В этом пункте я рассказал о том, что оч полезно для себя формулировать позицию собеседника без упрощения и карикатуры - я сам после такого упражнения не раз и не два по-другому начинал видеть другую сторону в переговорах. Рассказал о примере, как мне однажды довелось участвовать в конфликте двух команд, когда одна сомнительно (но окэй) переделала архитектуру важного участка кода, сломав тесты другой команде. Первая встреча была довольно негативная, поэтому на вторую встречу лиды команд получили задание без эмоций текстом сформулировать свою позицию И позицию другой стороны. Интересно, что вторая встреча нам не понадобилась - по ходу упражнения ребята прониклись мотивацией другой стороны и смогли дружелюбно 1 на 1 договориться.
9. Будьте проактивными. В реактивном подходе на решения человека сильно влияют внешние раздражители. Что-то происходит вовне и именно это определяет то, что будет делать человек. На проактивных людей действуют те же самые силы, но они не управляют действиями человека - он способен как бы переломить ход и делать то, что нужно для достижения нужного ему результата. Для пояснения я привёл историю с аналитиком, которому сообщили, что заказчик забраковал его ТЗ, а коллега успел записать только пару замечаний.
- Реактивный: okay, не звали на встречу по обсуждению ТЗ - нечего и проситься. Записали только 2 замечания, ну ладно, исправлю их.
- Проактивный:ты че, пёс. Написать самому и попросить полный список замечаний. Напроситься в след. раз самому презентовать своё ТЗ заказчику, чтобы сразу отвечать на замечания.
10. Сдерживайте обещания. Казалось бы - капитанство, но чтобы его чуть раскрыть я предложил 4 подсовета о том, как это делать.
- Не обещайте сразу. Иногда мы склонны пообещать что-то под влиянием эмоций. Тут я предлагаю брать паузы, чтобы лучше обдумать обещание.
- Уточните просьбу. Важно убедиться, что вы правильно поняли, что от вас хотят. Намного лучше переспросить лишний раз, чем сделать не то.
- Обещайте в рамках возможностей. Вроде очевидно, но особенность в том, что если обещание не по силам, сейчас хорошая возможность обозначить риски. Вполне возможно, что обещание можно скорректировать с их учётом.
- Своевременно говорите, если обещания под угрозой. Нет ничего хуже в день Х ВНЕЗАПНО узнать, что нужная работа не сделана (конечно, есть вещи несравнимо хуже). Поэтому о срыве обещания лучше сказать ASAP. (1) Это просто честно. (2) Вероятно, обещание можно скорректировать по срокам/объему.
Вот такой у меня был доклад:)
7. Думайте в формате win-win. Этот формат подразумевает, что вы позаботитесь не только о своей выгоде, но и о выгоде собеседника. Если вы прогнете собеседника под себя, то вы может и выиграйте в краткосроке, но на долгосроке хорошо работает только win-win взаимодействие. При этом, конечно, эти самые "win" могут быть ОЧЕНЬ разными в разных ситуациях.
8. Пытайтесь понять собеседника. В этом пункте я рассказал о том, что оч полезно для себя формулировать позицию собеседника без упрощения и карикатуры - я сам после такого упражнения не раз и не два по-другому начинал видеть другую сторону в переговорах. Рассказал о примере, как мне однажды довелось участвовать в конфликте двух команд, когда одна сомнительно (но окэй) переделала архитектуру важного участка кода, сломав тесты другой команде. Первая встреча была довольно негативная, поэтому на вторую встречу лиды команд получили задание без эмоций текстом сформулировать свою позицию И позицию другой стороны. Интересно, что вторая встреча нам не понадобилась - по ходу упражнения ребята прониклись мотивацией другой стороны и смогли дружелюбно 1 на 1 договориться.
9. Будьте проактивными. В реактивном подходе на решения человека сильно влияют внешние раздражители. Что-то происходит вовне и именно это определяет то, что будет делать человек. На проактивных людей действуют те же самые силы, но они не управляют действиями человека - он способен как бы переломить ход и делать то, что нужно для достижения нужного ему результата. Для пояснения я привёл историю с аналитиком, которому сообщили, что заказчик забраковал его ТЗ, а коллега успел записать только пару замечаний.
- Реактивный: okay, не звали на встречу по обсуждению ТЗ - нечего и проситься. Записали только 2 замечания, ну ладно, исправлю их.
- Проактивный:
10. Сдерживайте обещания. Казалось бы - капитанство, но чтобы его чуть раскрыть я предложил 4 подсовета о том, как это делать.
- Не обещайте сразу. Иногда мы склонны пообещать что-то под влиянием эмоций. Тут я предлагаю брать паузы, чтобы лучше обдумать обещание.
- Уточните просьбу. Важно убедиться, что вы правильно поняли, что от вас хотят. Намного лучше переспросить лишний раз, чем сделать не то.
- Обещайте в рамках возможностей. Вроде очевидно, но особенность в том, что если обещание не по силам, сейчас хорошая возможность обозначить риски. Вполне возможно, что обещание можно скорректировать с их учётом.
- Своевременно говорите, если обещания под угрозой. Нет ничего хуже в день Х ВНЕЗАПНО узнать, что нужная работа не сделана (конечно, есть вещи несравнимо хуже). Поэтому о срыве обещания лучше сказать ASAP. (1) Это просто честно. (2) Вероятно, обещание можно скорректировать по срокам/объему.
Вот такой у меня был доклад:)
❤5
Моя прошлогодняя статья на Хабре (и единственная, к слову) ВНЕЗАПНО попала в шорт лист конкурса лучших статей - Технотекст 2023🦄
Статья написана про особенности SRE и Observability в мобильных приложениях, так что если какие-то из этих тем вам интересны - you're welcome
https://habr.com/ru/companies/tinkoff/articles/762058
Статья написана про особенности SRE и Observability в мобильных приложениях, так что если какие-то из этих тем вам интересны - you're welcome
https://habr.com/ru/companies/tinkoff/articles/762058
🔥13
Про переработки в инженерных командах
Когда дедлайны по-настоящему приближаются и заканчиваются все "буферы времени", которые были заложены в оценку сроков работ, в дело вступают старые знакомые - переработки! Инженеры начинают засиживаться по вечерам, а иногда и вовсе на выходных, героически спасая проект и собственное лицо. Про лицо - это не про физическое лицо (в ИТ вроде не принято так решать вопросы:)), а в том смысле, что зачастую они же сами и дают оценки сроков, которые не в силах потом выполнить в силу разных уважительных причин (без сарказма!) и за это бывает стыдно перед коллегами.
В отдельную категорию я бы отнес инженеров, которые перерабатывают добровольно. Сидят вечерами и на выходных, но не потому что их попросили, а потому что ИНТЕРЕСНО. Выпала действительно захватывающая, необычная задача и хочется добить ее как хочется дочитать классную книгу, где вот-вот будет развязка. По моему наблюдению, это чаще встречается у инженеров, которые только набираются опыта - сеньоры-помидоры обычно уже повидали всякое и их сложно чем-то удивить.
При обоих формах переработок (вынужденных или добровольных) нам, как менеджерам, важно особенно следить за двумя моментами:
1. Инженеры могут сами не заметить приближающееся выгорание.
Там посидел на выходных, тут задержался на пару часов вечером - и вот уже работа вызывает больше отвращения, чем интереса. Уже нет никакой инициативы, все задачи одинаково безразличны, а любые трудности в команде бесят максимально. "Так, а может бросить все это и уйти куда-нибудь?!" - такие мысли посещают подгорающего все чаще. У разных людей разный уровень осознанности, но от менеджера у меня более высокие ожидания. Поэтому считаю важным менеджеру быть особенно чутким к команде, когда появляются переработки. По возможности, стоит вообще защитить команду от них (сменить приоритеты или подвинуть сроки). А если кто-то начинает проявлять первые признаки выгорания - такому человеку нужно уделить особое внимание. Конечно, менеджер не психотерапевт, но с т.з. достижения результатов, кажется, проще включиться на этом этапе, чем потом искать нового человека на освободившуюся вакансию.
2. Переработки не должны проходить бесследно.
Наличие переработки - индикатор, что где-то ошиблись с планированием. Если это единичные случаи, то ок. Но если это становится системой - надо разбираться. Хитрость - если люди перерабатывают добровольно, то их переработки могут оказаться незаметными для руководства. Они задерживаются вечерам, сидят на выходных и вообще из кожи вон лезут - а руководство не видит этих усилий. Руководство видит сделанные в срок задачи с приемлемым качеством. И когда к ним потом приходят и просят еще людей в команду, возникает ожидаемый вопрос - а зачем, вы же и так норм справляетесь? И тут прямая задача менеджера правильно подать руководству тему с переработками. Отдельное искусство в таком случае - так позвоkить факапить задачи без переработок, чтобы нужда в расширении команды стала очевидной и в то же время это не нанести особого ущерба бизнесу. Но это совсем другая история...
P.S. Все переработки, которые инициирует компания, должны быть оплачены!
Когда дедлайны по-настоящему приближаются и заканчиваются все "буферы времени", которые были заложены в оценку сроков работ, в дело вступают старые знакомые - переработки! Инженеры начинают засиживаться по вечерам, а иногда и вовсе на выходных, героически спасая проект и собственное лицо. Про лицо - это не про физическое лицо (в ИТ вроде не принято так решать вопросы:)), а в том смысле, что зачастую они же сами и дают оценки сроков, которые не в силах потом выполнить в силу разных уважительных причин (без сарказма!) и за это бывает стыдно перед коллегами.
В отдельную категорию я бы отнес инженеров, которые перерабатывают добровольно. Сидят вечерами и на выходных, но не потому что их попросили, а потому что ИНТЕРЕСНО. Выпала действительно захватывающая, необычная задача и хочется добить ее как хочется дочитать классную книгу, где вот-вот будет развязка. По моему наблюдению, это чаще встречается у инженеров, которые только набираются опыта - сеньоры-помидоры обычно уже повидали всякое и их сложно чем-то удивить.
При обоих формах переработок (вынужденных или добровольных) нам, как менеджерам, важно особенно следить за двумя моментами:
1. Инженеры могут сами не заметить приближающееся выгорание.
Там посидел на выходных, тут задержался на пару часов вечером - и вот уже работа вызывает больше отвращения, чем интереса. Уже нет никакой инициативы, все задачи одинаково безразличны, а любые трудности в команде бесят максимально. "Так, а может бросить все это и уйти куда-нибудь?!" - такие мысли посещают подгорающего все чаще. У разных людей разный уровень осознанности, но от менеджера у меня более высокие ожидания. Поэтому считаю важным менеджеру быть особенно чутким к команде, когда появляются переработки. По возможности, стоит вообще защитить команду от них (сменить приоритеты или подвинуть сроки). А если кто-то начинает проявлять первые признаки выгорания - такому человеку нужно уделить особое внимание. Конечно, менеджер не психотерапевт, но с т.з. достижения результатов, кажется, проще включиться на этом этапе, чем потом искать нового человека на освободившуюся вакансию.
2. Переработки не должны проходить бесследно.
Наличие переработки - индикатор, что где-то ошиблись с планированием. Если это единичные случаи, то ок. Но если это становится системой - надо разбираться. Хитрость - если люди перерабатывают добровольно, то их переработки могут оказаться незаметными для руководства. Они задерживаются вечерам, сидят на выходных и вообще из кожи вон лезут - а руководство не видит этих усилий. Руководство видит сделанные в срок задачи с приемлемым качеством. И когда к ним потом приходят и просят еще людей в команду, возникает ожидаемый вопрос - а зачем, вы же и так норм справляетесь? И тут прямая задача менеджера правильно подать руководству тему с переработками. Отдельное искусство в таком случае - так позвоkить факапить задачи без переработок, чтобы нужда в расширении команды стала очевидной и в то же время это не нанести особого ущерба бизнесу. Но это совсем другая история...
P.S. Все переработки, которые инициирует компания, должны быть оплачены!
👍2🔥2
Про 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-штуками пользуетесь вы?
Поделитесь, интересно ж!
Признаюсь честно, когда начался 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-штуками пользуетесь вы?
Поделитесь, интересно ж!
👍6
27.06 буду выступать в Москве на конференции Сбера - GigaConf 2024. В своем докладе я поделюсь рефлексией одного крупного сбоя в мобильном банке, расскажу, какие выводы мы сделали (не все были приятными) и как мы на корню лечили первопричины. Попутно поделюсь набором советников для DevOps'ов и SRE о том, как они могут (да, могут!) сильно повлиять на надёжность мобильного приложения в компании.
Конференция бесплатная, будет трансляция - welcome!
https://gigaconf.ru
Конференция бесплатная, будет трансляция - welcome!
https://gigaconf.ru
gigaconf.ru
GigaConf 2025 // Москва, 25 июня
GigaConf 2025 — Узнай, как GenAI меняет разработку. Большая конференция Сбера про генеративный ИИ
❤3🔥2