Ситуация до боли знакома. Кто-то предлагает новый чек-лист для контроля задач, и тут же уважаемые “эксперты” начинают дебаты:

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

Скепсис понятен. Чек-листы и правда легко превращаются в пыльные файлы, забытые на гугл-диске. Но когда команда говорит: "Мы реально спотыкаемся тут каждый день" — это уже повод задуматься.

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

🔧 Чек-лист, который работает:

1. Простой. Понятные пункты, которые легко проверять.
2. Приносит пользу здесь и сейчас. Если чек-лист экономит время, нервы или спасает от ошибок, его начнут использовать.
3. Имеет связь с задачей. Это не просто "чтобы было", а чтобы сделать проект лучше.

Автоматизация — это здорово, это гораздо лучше чек-листов и инструкций. Но давайте признаем: не всё можно сразу закодить в линтеры (и тем более не всегда на это есть время и силы). И да, иногда проще заклеить дыру скотчем, пока не нашли сварочный аппарат. Главное, чтобы этот скотч держал, а не просто создавал видимость исправления.

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

"и кнуты у вас вялые и пряники черствые"

#цитата_дня #цитата_дна

SLA и снижение потерь от инцидентов

Рассказываю про то, как построить SLA для платформенных продуктов, в чём тут отличие от обычных, "продуктовых" продуктов, как с этим связаны SLI, SRE и другие страшные трёхбуквенные слова.
Пройдёмся по инфраструктуре, по управлению ожиданиями и заветным девяточкам.
Бонусом — пачка лулзов из реальной жизни.

https://youtu.be/hIvWnxdBtR8

👑

Работал я как-то с человеком, который решил, что я "неправильный", и взялся меня лечить. Никто его об этом не просил. Но, кажется, он был уверен: если сумеет меня "вылечить", то станет ещё умнее и успешнее.

Сегодняшний пост — о локальных царьках.

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

Как распознать царька:
- Красивые сказки, которые увлекают, но не сходятся с реальностью.
- Имидж «великого» и единственно правого, который он старательно лепит вокруг себя.
- Настойчивое желание переубедить всех и каждого, что правда только за ним.
- Общение с ним часто вызывает ощущение: "Что вообще происходит?".
- Авторитет "царя" нельзя оспаривать, иначе вы — враг.
- Отказ признавать свои ошибки, даже очевидные.
- Разрыв между словами и делами, скрытый под маской харизмы.
- Деление мира на "равных" (себе) и всех остальных.

Звучит знакомо?

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

Как выживать?
1. Держитесь своих интересов. Помните: никто не знает, что вам нужно, лучше вас самих.
2. Опирайтесь на факты, а не на их красивые истории.
3. Слушайте свои ощущения — если что-то не так, это повод задуматься.
4. Не бойтесь своей самостоятельности. Уход от такого "царя" — это не слабость, а победа.

Токсичные лидеры встречаются везде, и избежать их сложно. Но ваша задача — защитить себя, свои границы и своё здоровье. Никто не сделает это за вас.

Крепитесь и верьте в себя.

Вписался я тут на курс «Руководитель отдела» от Стратоплана.

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

Я давно в управлении. Команды, бюджеты, запуск продуктов, тушение пожаров — уже много лет за плечами. Но опыт без формализации — это песня без слов, музыка без нот. Со временем лезут привычки, которые уже не работают — а ты всё тащишь их за собой. Нужна глубокая база без буллшита, без “ставьте задачки по SMART, пнятненько?” и "увольняя - увольняй".

У Стратоплана — высоко поднятая планка. Основатели — Орлов и Панкратов — умные люди, которым я обязан частью управленческих озарений.

А программа курса — вкусняшка:
— директивное управление, но без тоталитарного мракобесия;
— фундаментальные работающие подходы к управлению командами и структурой, здоровые отношения с командами и их лидерами;
— отношения с бизнесом — как выстроить зрелое партнёрство, а не имитировать отчётами бурную деятельность;
— работа с бюджетами (моя прелесть!);
— погружение в бизнесовую часть и как ее понимать и с ней работать;
— построение карьеры, осознанное и последовательное (ой как актуально в нашем подсдувающемся айти рынке).

Весь в предвкушении. Буду делиться своими открытиями в ближайшие месяцы ☺️

Фу, опять какие-то новые модные слова на хайпе. Опять кто-то придумал очередной "мета-фреймворк системной сингулярности". Достали уже, честно.

Или нет?

Я утверждаю: нам всем нужна мода и хайп в IT. Сейчас объясню.

Рынок труда не любит уникальных снежинок. Он любит чёткие ярлыки. Никто не ищет себе в команду "разностороннего энтузиаста по всему и сразу". Ищут мобильного разработчика с опытом в Swift и Kotlin. Или DevOps-инженера с Kubernetes и Terraform. Никому не нужен разработчик-железячник-аналитик-сомелье. Даже если он классный.

Чем проще вы описываете себя и свою зону ответственности — тем проще вас поймут. Чем конкретнее ваша роль — тем проще вас найти и взять в работу вот прям сейчас.
Уникальность — это прекрасно для самовыражения. А на рынке труда — это головная боль для рекрутера и менеджера.

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

Например, никто уже не объясняет, что такое DevOps — хотя лет 10 назад это слово вызывало столько же ненависти, как сейчас "Platform Engineering". Или "SRE". Сначала смеялись, теперь нанимают пачками.

Это неприятно признавать, но без этих "хайповых" слов отрасль бы не смогла сама себя описать. А без общего языка у нас не будет общих рамок, понятных рынку.
И придётся снова объяснять на пальцах, что вы умеете делать и зачем вам платить зарплату.

Так что да, новые термины бесят. Но они — наш инструмент.

Для серьёзного продукта, его инфраструктура — это не тулза. Это тоже продукт. А девопсы — не просто люди с доступом к кластеру, а овнеры этой самой инфры.

Смотрите:
— у инфры есть код (надеюсь, всё-таки в 2025 не надо обсуждать необходимость IaC?), и у этого кода есть овнеры. Те, кто не просто накатывают, а проектируют, развивают и реагирует, если что-то не так;
— у инфры есть product owner. Тот, кто формулирует, куда мы вообще движемся, какую боль лечим, какие косты срезаем, управляет бэклогом, обладает пониманием что перспективно, а что не очень;
— у инфры есть метрики. Доставка изменений, стабильность, скорость развёртывания, NPS среди команд — всё, как у людей. Иногда их даже считают и даже(!) оптимизируют;
— у инфры есть поддержка. Ну вы понимаете, кто чинит, когда всё упало?
— у инфры есть регламенты и может быть даже дока, потому что инфра — часть общего ландшафта, и без договорённостей с остальными командами будет боль и страдания.

И если при этом "тимлид девопсов" говорит: "Ну я тут задачки раскидываю, да, и дежурства составляю", — хочется спросить:
А кто овнит твой продукт?
Кто рулит развитием? Кто отвечает за ценность? Кто следит, чтобы не просто работало, а работало хорошо и стабильно?

А часто никто. Потому что "девопс-инженеры" у нас не про овнерство, да? Они про "мы сделали — а дальше как-нибудь сами". Документации нет, роадмапа нет, техдолг "ну вы чо, у нас тут всё сложно".
DevOps — это development и operations, а не “я тут ямлики поправил, подик вроде поднялся”.

Хочешь, чтобы инфраструктура была надёжной, предсказуемой и удобной?
Начни относиться к ней как к продукту. И овнить её так же.

Если кто-то в айти говорит, что знает как правильно делать, то он или хайпожор или не квалифицированный.

Хватит умножать сроки проекта на π (потому что, ну, «п***ц же!»). Это не научно!
И вообще — π хорош только в кружках и татухах. В оценках — он вреден.

Если хотите реалистичную прикидку по срокам — умножайте на e.
Потому что рост неопределённости — экспоненциален, детка.

Теперь, давайте подушним?! Итак, почему π — фиговый множитель в управлении неопределённостью:

1. В искривлённом пространстве — π плавает. В геометрии Лобачевского, например, сумма углов треугольника уже не 180°, а π там вообще не тот. Ну и как вы собираетесь на этом считать дедлайны?
2. В пространствах с размерностью больше 3 всё ещё веселее: для расчёта объёмов и площадей вместо π всплывает π², πⁿ и прочие сущности, о которых вы точно не думали, когда прибавляли ещё месяц «на всякий».
3. На планковском уровне вообще всё теряет смысл. Там нет ни окружности, ни радиуса, ни уверенности. Оценки становятся вероятностными, и вся эта арифметика — чисто философский экспириенс.

Так что забудьте про π! Хотите работать с хаосом — думайте в терминах экспоненты. Она строго аналитическая, абсолютная и неизменная!
А ещё у экспоненты есть производная. И она равна самой себе. Ещё один повод для уважения!

Как-то раз наблюдал мастер-класс под названием "Принятие решений в условиях неопределённости, которую мы сами же и создали".

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

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

Не надо так.

Принимайте решения “на месте”, а не в облаках.

👀 А код-ревью — вообще нужен для качества?

Мне иногда кажется, что вокруг код-ревью построен культ. Тимлиды часами обсуждают, как "оптимально распределять ревьювера", как "улучшить процесс", как это якобы "повышает качество продукта". Но у меня с этим опытом — по-другому.

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

Но как quality gate — это слабый инструмент. Он не гарантирует, что баг не пройдёт. Не страхует от архитектурной кривизны. И откровенно тормозит delivery.

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

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

Или я чего-то не вижу?
Поговорите со мной в комментах, мне очень кажется, что я что-то упускаю, а для всех это очевидно.

Когда Agile — это не про гибкость, а про хоть какую-то опору

Вы тоже немного устали от того, как насильно пытаются внедрить Scrum и Agile куда ни попадя? Особенно когда, кажется, это делается просто чтобы "как у всех".
Но вот интересный инсайт у меня случился. Сейчас я учусь на курсе "Руководитель отдела" в Стратоплане — и начинает вырисовываться новый уровень понимания того, как работает компания в целом.

Давайте представим: вы — CТО в крупной компании. Не стартап из пятерых человек, а такая развесистая структура, тысячи людей, несколько бизнес-доменов, десятки команд в каждом.

Приходите вы туда — и видите:
— задачи ставятся кто во что горазд
— планирование везде устроено по-разному
— какие-то “проекты”, где-то "инициативы", где-то просто список задач
— поводы у заведению задач у всех тоже разные — кто-то поквартально работает, кто-то в режиме "фигачь и будь что будет"
— трекинг как получится,
— дай бог 20% выполнения обязательств, взятых на себя

И вам прилетает сверху, от борда директоров: "у вас тут плохо всё с выполнением задач, стратегические цели не выполняются, исправь".
И вы такие: а где тут в этом "плохо" — то самое "всё"? Где границы, где процессы, где точка отсчёта?

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

И вот тут Agile и Scrum, какими бы словами их не хотелось назвать — внезапно становятся полезны! Потому что они дают общий язык, потому что они дают возможность нанять людей, которые хоть где-то наводили порядок с морем команд. Пусть не идеально, пусть отчасти формально — но хоть как-то!
А внутри системы, где все заняты выживанием и сохранением статус кво, редко кто способен организовать изменения сам. Нужно внешнее усилие: консультанты, обучение, давление руководства "сверху".

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

Agile — это конечно не решение, но это перила, которые нужны этой лестнице. А идти по ней, конечно, придётся всей компании.

Куда вы деваете людей из своей головы?

Вот вы с кем-то поговорили на конференции/по работе, вроде интересный человек. Полезный, важный, смешной, талантливый. Что дальше?

- Кто-то сохраняет такие контакты в телефоне — и пишет туда кучу заметок.
- Кто-то — кидает себе в "Избранное" в Телеге, чтобы не забыть.
- Кто-то ведёт отдельную таблицу с пометками вроде “Максим — делает мебель" / "Пётр — javascript" / "Василий — devops", "Кристина — Яндекс"
А кто-то — вообще ничего не делает, полагается на мозг. (Удачи, лол!)

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

Я заморочился и сделал бота, который помогает это делать почти без усилий — форварднул сообщение от человека => бот обработал его и положил в базу знаний.

Но вот в чём вопрос.

А вы вообще как? Храните контакты, ведёте базу? Или это всё слишком?

Когда "управление ожиданиями" — это не про честный диалог, а про угадайку

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

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

Спойлер: ты всё равно отвечаешь за эту угадайку. Потому что управление ожиданиями — это всегда задача снизу вверх. Не хочешь — не справишься. Ушёл в обиду — остался в стороне. А в стороне быть не получится — ведь ты в операционке, а значит тебя закрутит по-полной!

И вот тут важно понимать: никакая аргументация "на словах" не пробьёт глухую стену.
Что нужно? Фактура. Прецеденты. Цифры.
Хочешь донести, что начальник выдумал фигню? Приноси доказательства. Не эмоциональные "мы так не вывозим", а "смотри, вот три примера, где мы так делали — и не сработало". И — "а вот тут сделали по-другому — и получилось".

Это не пассивная агрессия. Это конструктивная конфронтация.
Это не бунт. Это одна из важных функций менеджеров как таковых.

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

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