яйца

на завтрак теперь моя любимая еда. Не десяток, конечно, трёх пока хватает ?

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

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

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

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

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

В общем, доброе утро, друзья!

дайджест самых самых

Пишу регулярно последние два месяца и на канале уже двести ценных человек! Хочу поделиться подборкой постов, которые, возможно, кто-то ещё не видел:

?Как построить антихрупкую команду.

?Про взаимоопыление компаний в условиях одной дислокации.

?Инцидент-менеджмент в айти и урбанистике, принципы которого могут спасти жизни.

?Плохие отзывы - это благо! Как правильно на них среагировать.

?"Ешь сам свою собачью еду!" Польза догфудинга для любых компаний.

?Моя подготовка к пенсии с 35 лет ?

?Что мне помогает писать посты регулярно. Простой рецепт.

Техдолг
ч.2

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

Альтернативный подход в работе с техдолгом – когда всё оценивается в деньгах. Хотя это часто бывает нетривиально.

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

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

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

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

Например, 20% времени разработчиков мы посвящаем техдолгу. Это нормальный рабочий вариант, но тут важно, во-первых, придерживаться рамок процентовки. Во-вторых, нужно регулярно пересматривать квоту в соответствии с развитием продукта/сервиса.

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

Хочется узнать, если у вас есть какой-то опыт или мнение по этому поводу? Как по-вашему здесь правильно и хорошо делать?

Техдолг
ч.1

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

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

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

⚪️Другая крайность - когда лид разработки упирается, встаёт в позу и говорит: "нет, пока мы всё не отрефакторим, никаких новых фичей не будет!"

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

✔️ Правильный подход – это когда бизнес и разработка дружат, договариваются, находят баланс и правильно оценивают совместные приоритеты.

Но как именно оценивать эти приоритеты? Мне нравится один из инструментов, о котором рассказывается в книжке про site reliability engineering от Google про error budget. Вводится метрика с количеством ошибок, инцидентов и так далее, а также некая норма. Если у нас ошибок меньше нормы и всё стабильно, значит мы спокойно делаем новую функциональность. А если вдруг прогрессия ошибок растёт, тогда отодвигаем бизнес-задачи на второй план, и первыми делаем всё, что связано с починкой и надёжностью.

Но есть и альтернативный подход ?
продолжение следует...

Каждый раз расстраиваюсь, когда увольняется кто-то из сотрудников ?

Успокаиваю себя тем, что это совершенно нормально и естественно.

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

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

Мир IT маленький, и с людьми, которые уходят, в будущем велика вероятность где-то встретиться, или человек вернётся к вам обратно ?
А как вы переносите ситуацию, когда из вашей команды кто-то решает уйти?

✏️ Послание себе и коллегам,
у которых начинается ревью.

Каждые полгода для меня это довольно стрессовый период, но кое-что помогает с этим справиться:

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

2️⃣Ревью - это отличная возможность остановиться и окинуть взглядом прошлые полгода, сделать для себя ретроспективу крайних 6 месяцев. Также возможность выразить коллегам обратную связь (благодарности и пожелания для развития).

3️⃣Не надо делать как я - заполнять этап самооценки за 3 часа до дедлайна. Писать с нуля всегда сложно. Лучше как можно раньше написать какой-то черновик, пусть там будет криво-косо, но уже что-то заполнено, а потом редактировать его по чуть-чуть и в конце просто причесать.

4️⃣Постарайся написать факты. Какие результаты были? Что изменилось? Какую ценность это принесло?
Здорово, если будут цифры, например, уменьшилось время отклика на хх секунд, запустили продукт на хх дней раньше и им воспользовалось хх пользователей.

5️⃣Если ты руководитель, то неважно, как много ты сам сделал. Важно, что сделала твоя команда. Благодаря тому, как ты выстроил процессы, кого нанял, как обучил и помог в работе.

6️⃣Добавь больше людей в запрос обратной связи. Дай возможность коллегам выразить свои впечатления по взаимодействию с тобой в работе. Это даст более развернутую картину для твоего руководителя, чтобы выставлять оценку.

7️⃣Когда будешь заполнять обратную связь на коллег, не надо просто писать всем хорошие слова, это плохая стратегия. Если я знаю, что человек всем пишет примерно одинаковые хвалебные отзывы, то это пустой сигнал для меня как руководителя. В итоге я не учитываю его отзывы. Постарайся указать какие-то факты, в чем именно человек тебе помог, что сделал хорошо. Написать зоны роста, что у человека сейчас получается плохо, это тоже полезно для него же, ведь ты даёшь ему возможность стать лучше и получить в будущем высокую оценку. При этом необязательно заполнять обратную связь вообще на всех. Если тебе нечего сказать, нет смысла выжимать из себя хоть что-то.

8️⃣Не всё зависит от тебя. Если много работали над проектом, но бизнес решил его свернуть, вовсе не значит, что ты плохо работал. И твоя работа не была бесполезной. Это нормальный процесс, бизнес тестирует гипотезы и не все взлетают. Обязательно укажи этот проект и что удалось в нём достичь, постарайся сформулировать свой вклад.

9️⃣Будет здорово, если ты напишешь не только текущие результаты и что получилось хорошо, но и что НЕ получилось. А также почему, и какие действия планируешь в этом направлении. Напиши свой план с зонами роста и стратегией на следующее полугодие. Грамотный руководитель зачтёт это в плюс, что поможет лучше запланировать следующий период.

1️⃣0️⃣Заведи отдельный файлик/блокнот/место, куда ты будешь фиксировать записи для следующего ревью - кому что указать в обратной связи, что вписать в свои результаты/достижения и т.д.

1️⃣1️⃣Самая полезная для тебя часть - оглашение результатов. Не оценка, а обратная связь, которая поможет трезво оценивать свою работу и вектор развития. Обсуди с руководителем подробнее и договоритесь о целях на следующие полгода. Если внесёшь их в голсы, то это уже план, по которому можно двигаться. А потом будет очень удобно перенести из голсов в результаты и не ломать голову.

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

инцидент-менеджмент
в айти и на дорогах ?

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

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

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

*?Представьте ситуацию - стажёр подключился к базе данных в продакшн среде, ошибся там в запросе и случайно удалил все данные (кто не ронял прод? :)). И вот на разборе инцидентов говорят: "надо учить стажёров внимательнее писать запросы, а еще при подключении к базе надо выводить объявление "не удаляй все данные". Бред же?* Любой инженер скажет, что надо не только людей учить, но и обеспечивать инфраструктуру так, чтобы такого в принципе не могло случиться. Должны быть ограничения прав доступа, получать данные только через отдельный интерфейс, изменения в базе должны проходить контроли и так далее.

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

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