Первое увольнение

Сегодня я первый раз в жизни уволил человека. Вернее, не совсем прям я, а лид команды. Но я непосредственно участвовал в принятии этого решения, был на финальном разговоре с этим человеком, высказал свою позицию в пользу его увольнения на финальной встрече.
Он был разработчиком в нашей команде, и его производительность и способность прислушиваться к обратной связи не соответствовала тому, что мы ожидали. Перед принятием решения об увольнении мы давали ему шансы, давали т.н. "негативную обратную связь". Мы договорились с ним о наборе конкретных задач, которые ему нужно сделать за 2 недели. Человеку его грейда выделенного времени на такие задачи должно хватить с запасом. Но, к сожалению, прошло 3 недели, но ни одна задача так и не была сделана на 100%. Се ля ви. Благо, всё это обнаружилось и решилось в течении испытательного срока.
Я знал, что у него семья и временное разрешение на проживание в стране из-за работы. С одной стороны, это не моё дело, а с другой по-человечески я ему сочувствую и хочу помочь чем-нибудь. После увольнения у него было бы всего 15 дней, чтобы найти новую работу или чтобы покинуть страну. Звучит довольно жестко. Поэтому мы постарались максимально смягчить этот удар - предложили до конца испытательного срока (почти 3 недели) пойти в отпуск за свой счёт. Таким образом, он сможет искать работу с меньшим давлением, чем если бы он сразу оказался на улице. We did our best.
История, конечно, не из приятных, но я вижу это довольно полезным опытом. Причём полезным с двух сторон:
1. Эта ситуация показывает оборотную сторону "работы". Пока ты в "матрице" и перформишь на достаточном уровне - всё окей, система поощряет тебя. Но нельзя обольщаться. Как только твоя производительность упадёт ниже какой-то планки (не всегда очевидной) - система избавится от тебя очень быстро. Поэтому не стоит слишком сильно "прикипать" к своей работе. Я должен быть нужен работе больше, чем она мне.

2. Эта ситуация заставляет немного по-другому посмотреть на сотрудников в команде. Если раньше в моей системе координат увольнение было чем-то далёким и недостижимым, то сейчас моё "окно Овертона" расширилось. Теперь я, как менеджер, опробовал новый для себя инструмент в работе. И теперь я знаю, что ещё могу сделать, если сотрудник не прислушивается к ОС и показывает слабые результаты.

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

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

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

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

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

Про продажу задач

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

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

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

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

Базовая проверка аналитика

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

Суть: человек принимающий решения (например, менеджер проекта) просит подопытного срочно специфицировать новую фичу, которая "прям точно нужна, делаем ASAP".

Провалом проверки будет ситуация, когда подопытный без лишних вопросов подрывается и пишет ТЗ со слов ЛПР и в меру своей фантазии.
Успехом будет ситуация, когда вы услышите от подопытного подобные вопросы:
- а зачем нам это делать?
- почему это нужно сделать срочно? Что случится, если мы сделаем позже?
- у меня в работе фичи А и Б, мне их приостановить из-за этой срочной фичи?

По этим вопросам станет понятно:
1. Человек не смущается, когда кто-то уверенно говорит ему "дичь". Прежде всего он думает своей головой.
2. Человек думает о качестве конечного результата, а не просто тупо исполняет то, что ему сказали.

Когда не надо здороваться в чате

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

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

Вместо этого лучше писать свой вопрос сразу вместе с приветствием в одном сообщении. Тогда собеседник с первых секунд после прочтения начнёт думать над вашим вопросом (но это не точно) и вы повысите вероятность получения быстрого ответа.

Мне очень понравилось как эту идею доходчиво изложили на сайте https://nohello.net/ru/ (время чтения макс. 2 минуты).

P.S. Про второй вид поведения напишу в следующем посте.

Про мета-вопросы

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

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

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

Вместо мета-вопроса лучше сразу в одном сообщении давать конкретику. "Мне нужно построить дашборд в Jira. Подскажите, пожалуйста, как в фильтре выбрать задачи, входящие в эпик?". Вопрос понятный, кто знает ответ, тот сможет сразу же ответить.

Эту проблему коротко и наглядно расписали на сайте - https://nometa.xyz/ru.html (время чтения макс. 2 минуты).

Сегодня вечером выступаю на конференции DevOops на площадке в Москве с темой "Mobile SRE — когда надежность нужна не только на бэкендах"🤘
В своём докладе я проведу рефлексию одного крупного сбоя в мобильном банке, расскажу про полезные изменения, которые стриггерил этот сбой и предложу советики, которые можно применить прямо сразу после доклада на благо мобильного приложения вашей компании🙂

Когда-нибудь запилю серию постов о том, как отбираются и готовятся доклады на большие конференции) ну и про опыт самого выступления тоже.

Представьте, что у вас 10+ млн. пользователей в сутки. И примерно 0.001% из них может обратиться в поддержку каждый день. Чтобы им помочь, вам нужны подробные логи вашей системы. Писать такие подробные логи всегда и по всем пользователям - слишком дорого. Но без подробных логов им не помочь. Как бы вы решили эту проблему?

Пока я готовлю очередной содержательный и полезный пост (а других постов у меня и нет😜), предлагаю вам почитать мою первую статью на Хабре, где я затрагиваю и эту тему🔥

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

Чуть не забыл саму статью - https://habr.com/ru/companies/tinkoff/articles/762058

Почему технари ничего не могут без менеджера

Ладно-ладно, чего завелись, всё они могут без менеджеров. Просто команды без менеджера (или того, кто сыграет роль менеджера) склонны делать одну и ту же ошибку - делать никому не нужные фичи и делать их долго и нудно для самих себя. Конечно, менеджеры бывают разные и просто его наличие не гарантирует результат, но с другой стороны, а что гарантирует?

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

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

Сегодня выступаю на митапе Big Monitoring Meetup X - https://monhouse.tech/big-monitoring-meetup-x/.
Буду рассказывать свой доклад с DevOops с минимальными доработками, тема "Mobile SRE - когда надёжность нужна не только на бекэндах". В докладе будет рефлексия одного крупного сбоя в мобильном банке, про то как мы системно закрывали причины его возникновения и про выводы, которые могут быть полезны инженерам, которые даже не занимаются фронтами.

Чуть позже сделаю здесь несколько постов с выжимкой самой сути из этого доклада.

Про неприятную обязанность менеджера

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

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

И тут есть определенная развилка:

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

Вариант 2: дать явный фидбек сотруднику, что так делать неприемлемо, договориться об изменении поведения.
Плюсы: сохраняем мораль команды (деструктивное поведение не будет распространяться), развитие сотрудника (для человека может быть открытием то, как его поведение выглядит со стороны).
Минусы: придется напрячься (в таких ситуациях нужно ОЧЕНЬ хорошо подготовиться в общению), риск потери приятельских отношений и появление напряжения в отношении с сотрудником (не все адекватно воспринимают фидбек).

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

Сегодня в обед буду выступать на конференции Mobius 2023 Autumn в Санкт-Петербурге. Тема моего доклада «А у нас сейчас всё норм работает?» или Что такое observability мобильного приложения.

Если почти все последние выступления я знакомил "серверных" инженеров с спецификой мобильных приложений, то в этот раз основная аудитория доклада это сами мобильные разработчики.

Фух, надеюсь, все получится🤘

Менеджерское одиночество

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

А почему? Я вижу, по крайней мере, 2 причины:
1. Конфиденциальность. Ты раньше всех узнаешь, кто планирует увольняться или переходить в другую команду. У кого с кем конфликты. Какое направление руководство думает свернуть. И всё такое. И всё это секретики, которые надо хранить, но которые, однако, могут сильно влиять на настрой менеджера и на принимаемые им решения. А к кому идти за поддержкой, когда ты переживаешь из-за чего-то такого секретного?
2. Ожидания лидерства. Мы все знаем, что хороший менеджер это лидер, который вдохновляет других. Но что, если он сам потерял вдохновение и позитивный настрой? К людям из команды с таким не пойдешь, ведь, если попадется недостаточно зрелый человек, то вид подавленного лидера может демотивировать его самого. Да и как поддержать приунывшего лидера? Это тоже вопрос.

Но не все так грустно. Я думаю, что подавленный лидер может обратиться к таким источникам "исцеления":
1. Друзья и семья. Иногда просто выговориться и услышать взгляд со стороны - сильно продвигает в решении проблемы.
2. Коучинг. Специально обученный человек может сильно ускорить собственную рефлексию и помочь удержаться в конструктивном русле.
3. Коллеги менеджеры. Наверняка они тоже сталкивались с чем-то подобным, и если у вас достаточно доверительный контакт, то они могут поделиться своим опытом.
4. Руководитель. Если с ним сложился хороший контакт, он открыт и опытен - его взгляд на ситуацию может быть очень полезен и открыть новые грани.

Появилась публичная запись с моего последнего доклада c конференции мобильных разработчиков Mobius «А у нас сейчас всё норм работает?» или Что такое observability мобильного приложения.

Поделюсь анонсом с сайта конференции (не зря же его писал!):

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

Даниэль расскажет, чем плох подход «запустить и потыкать руками» и поделится тем, как в Тинькофф подходят к observability (наблюдаемости) мобильного банка – основного приложения компании с ежедневной аудиторией свыше 10 млн. клиентов. Спикер также расскажет о том, как и за какими метриками следят и какие практики показали свою эффективность в этой теме.

Если эта тема вам интересна - welcome на ютуб😊
https://youtu.be/EkT-EvUYww8

Твой код никому не нужен

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

Техническим менеджерам в этой теме выпала нелёгкая доля. Если в "бизнесовых" задачах типа "нарасти конверсию в действие Х" понятна денежная ценность (выше конверсия -> больше целевых действий -> больше выручка), то в технических задачах она далеко не так очевидна. Как, например, посчитать денежный профит от ускорения ответа от веб-сервиса? Как оценить влияние на метрики бизнеса от миграции с одной СУБД на другую? И это далеко не самые сложные примеры.

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

А как
А как именно строить такую связь от техники к бизнесу? Об этом напишу в одном из следующих постов.

Про связь технических задач и бизнеса

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

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

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

Для примера давайте возьмём пример с переделкой фреймворка автотестов для какой-то системы.
Какая польза от этой задачи? На кой её вообще делать? Если сказать по-простому, то, например:
1. Чтоб тесты быстрее проходили
2. Чтобы код был более понятным
3. Чтобы проще был расширять функционал.

Неплохо, цели благие. Но какие метрики могут быть у этих целей? Другими словами, на какие метрики непосредственно влияет выполнение этих целей?
1. Чтоб тесты быстрее проходили -> Сокращается время прогона тестов
2. Чтобы код был более понятным -> Сокращается время онбординга новых QA в проект + сокращается кол-во багов в тестах
3. Чтобы проще был расширять функционал -> Сокращается время время написания новых автотестов.

Так. Становится понятнее? Теперь мы знаем, какие метрики объективно покажут пользу от этой задачи (или бесполезность). Но где тут бизнес-метрики? Где тут денежки?

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

Так вот, возвращаясь к нашему примеру с фреймворком автотестов. Как видно, все они влияют на время, которое входит в общее время цикла разработки. Т.е. с этими автотестами разработка должна ускориться. И в этом главная ценность этой задачи!
Для измерения времени разработки давно существует метрика Lead Time и её старшая сестра TTM (Time to Market, но она больше про общее время выпуска фичи, не только про разработку).

Таким образом, переделка фреймворка тестирования сделает разработку быстрее, и это будет видно на метриках Lead Time и TTM. С этими метриками бизнесу работать уже намного проще т.к. стоимость времени разработки, как правило, понятна и её сокращение можно посчитать. Через эти метрики можно обсуждать приоритет с "бизнесменами".

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