Что-то давно я не пишу, времени пока не так много, в жизни поменялось примерно всё, но канал не об этом 😊

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

В общем, очень рекомендую подписаться!

FrontendConf 2026 — Skip!

Глеб написал пост о FrontendConf. Теперь всё, уже официально. Глеб, конечно, драматизирует, всё-таки мы не закрыли конференцию, а просто пропускаем в этом году.

Я присоединился к ПК FrontendConf в прошлом году, и несмотря на то что я давно в ПК DUMP и даже когда-то сам делал конференцию, но даже за этот год успел почувствовать различия.

Главное — это то сколько времени мы тратили на отбор и подготовку докладчиков. Организовать один поток на крупном фестивале, или сделать конференцию в один поток — это не то же самое, что сделать конференцию в 4 потока и на два дня.

Что меня поразило — это то как докладчики реагировали на фидбек. Некоторые доклады мы прогоняли больше 10 раз в течение 4-х месяцев. И при этом когда мы встретились очно, то докладчики не хотели убить меня 😊

Что ж, в этом году мы немного выдохнем, надеюсь, увидимся на FrontendConf 2027.

Правило половины дня

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

Не планировать онбординг-встречи во второй половине дня.

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

Где-то после 15:00 у меня просто отключается мозг.

Я продолжаю слушать. Даже что-то записываю. Могу задавать вопросы. Со стороны всё выглядит нормально.

Только новая информация уже почти не оседает в голове. Она превращается в шум.

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

Поэтому я стараюсь ставить важные ознакомительные встречи на первую половину дня. А вторую оставлять на чтение док, заметки, самостоятельное ковыряние продукта, сбор вопросов и просто подумать.

И я всегда заранее предупреждаю людей:

«Я, возможно, к вам ещё вернусь и ещё раз переспрошу всё то, что вы мне сейчас рассказали».

Мне кажется, это сильно снижает напряжение. Человек понимает, что я могу тупить, но не игнорирую. Я просто честно признаю: с первого раза новый контекст редко укладывается в голову целиком.

Хороший онбординг — это не когда тебе за день рассказали всё. А после 15:00 лучше погулять и подумать)

Кейс с Яндекс Доставкой

«То, что мы не оправдали ваши ожидания — это не наши проблемы. Это ваши проблемы»
© Андрей Аршавин

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

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

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

Я достаточно часто отправляю посылки родителям или обратно через Яндекс Доставку. Это удобно и, главное, дешевле, чем везти те же вещи в багаже самолёта. Обычно всё происходит очень просто: создал заказ, отнёс в ПВЗ, a few minutes later, заказ уже в другом городе, в ПВЗ, где его забирает получатель.

Недавно я заказал запчасть к автомобилю, но с доставкой до Екатеринбурга. Запчасть приехала, родители её получили, и дальше всё по старой схеме, создаю заказ на доставку Екатеринбург -> Петербург, родители относят в ПВЗ, жду. Потом мне приходит пуш, что заказ можно забирать. Иду в ПВЗ, открываю приложение и вижу:

«Заберите заказ из пункта отправления».

Подождите, что?

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

Красиво.

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

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

И вот тут для меня начинается уже не бытовая, а продуктовая история.

Пользователь покупает не «перемещение коробки из точки А в точку Б». Пользователь покупает обещание: я отдам вам вещь, а вы сделаете так, чтобы она оказалась там, где я ожидаю. Если это обещание по каким-то причинам нельзя выполнить, то дальше начинается самая важная часть сервиса.

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

Плохой сценарий:
«У нас технические причины. Какие — не скажем. Деньги вернём когда-нибудь. Заказ в интерфейсе не ищите».

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

Потому что если ошибка техническая — отправьте, блин, повторно. Это ваш косяк.

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

Продукт — это не только кнопка «создать заказ». Продукт — это ещё и то, что происходит, когда заказ по какой-то причине не приехал.

И в этом смысле кейс с Яндекс Доставкой для меня выглядит очень тревожно. Потому что сервис как будто говорит пользователю:

«Мы не оправдали ваши ожидания. Но это ваши проблемы». Увы(

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

Ниже текст ребят, но в ближайшее время от меня тоже будет небольшой сюрприз, а пока просто обратите внимание на очень неплохую конфу в начале июня в Москве

📍 4–5 июня 2026
📍 Москва + онлайн-участие

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

Как решают эти проблемы в других компаниях?

Разбирать будут на PeopleSense’26 — конференции об управлении командами, процессами и собой. Организаторы — команда ProductSense.

Среди спикеров — руководители из «Авито», «Сбера», «Циана», «МегаФона», Dodo Brands.

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

Всего в программе — 50+ докладов и мастер-классов, объединенных в 5 треков: 
— Современное лидерство
— Операционка и процессы 
— Культура и коммуникация 
— Личная эффективность
— ИИ-инструменты

Плюс организованный нетворкинг, активности от партнеров и вечерняя программа.

👉🏻 Посмотреть программу и спикеров

ИИ создаёт когнитивную нагрузку

Пока все заняты смакованием новых моделей от Google, я тут прочитал заметку в HBR про прожарку мозга с помощью ИИ. Мы часто думаем про ИИ так: «Раньше я делал задачу сам, а теперь её делает ИИ. Значит, я разгрузился». Ну то есть «вкалывают роботы, а не человек».

Но на практике часто получается иначе.

Раньше я просто писал текст. Теперь я пишу промпт, читаю ответ, понимаю, что он слишком водянистый, уточняю промпт, читаю второй ответ, вылавливаю галлюцинации, переписываю руками, а потом ещё думаю — не потерялся ли в процессе исходный смысл?

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

В итоге ИИ может не снять нагрузку, а просто поменять её тип. И внезапно люди устают от этого ещё сильнее. Есть такой феномен — усталость от принятия решений (англ. decision fatigue). Я когда-то читал об этом у Жени Степанищева, но заметку найти не могу. Если найдёте — скиньте. Смысл был в том, что, став руководителем, он настолько уставал к концу дня, что вечером не мог принять элементарное решение, например, чего хочется на ужин.

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

И мне кажется, это важный продуктовый вывод для всех AI-инструментов. Нельзя мерить только их использование (ну и потребление токенов, само собой).

Стало ли человеку проще делать работу?

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

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

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

Поэтому при внедрении AI-инструментов надо задавать не только вопрос «сколько людей этим воспользуются?», но и: какую нагрузку мы снимем с человека?

Если ответа нет, то, возможно, мы вместо снятия нагрузки просто поджарим ему мозг новым способом.

Розыгрыш билетов на PeopleSense 2026.

upd. Разыграли

У меня есть промокод на бесплатный билет на конференцию PeopleSense в Москве 4-5 июня, и я хочу его разыграть.

Сначала хотел сделать что-то банальное: подпишитесь, поставьте реакцию, сделайте репост.

Но потом подумал, что это какая-то ерунда.

Поэтому я решил иначе.

Я хочу отдать билет человеку, которому конференция правда будет полезна.

Что нужно сделать:

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

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

Если вы уже купили билет, тоже можно участвовать. Тогда билет можно будет подарить коллеге.

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

P.S. Фото не несёт никакого смысла, его просто сделал ребёнок, когда гулял по лесу.

AI-DISRUPT PDLC

Сбер выложил масштабную работу — документ-концепцию трансформации жизненного цикла разработки ПО в эпоху ИИ.

Бегло пробежал, есть интересные поинты. Например, что >50% традиционных мест разработчиков к 2030 году заменит Product Engineer (заметьте, не ИИ, а новая роль, которая сейчас образовывается). Или что внедрение только лишь Copilot-ов через пару лет обернется деградацией производительности на 25%. В общем, есть что обсудить. И я планирую прокомментировать основные поинты.

А пока интересно спросить у вас: читали? Что думаете?

Один из худших скиллов руководителя

В «45 татуировках менеджера» есть неприятная, но очень взрослая мысль: не надо рассчитывать на благодарность бывших сотрудников.

Ты можешь вкладываться в человека. Учить, защищать, вытаскивать, давать шанс, продвигать, спорить за него с другими руководителями, прикрывать в сложные моменты.

А потом он уйдёт.

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

И это, конечно, вам как руководителю может быть больно.

Потому что вы — тоже человек. Вы привыкаете. Помните, как человек пришёл, например, слабым джуном, как рос, как впервые начал брать ответственность, как ошибался, как становился сильнее. И где-то внутри хочется, чтобы человек помнил не только свои обиды, но и то, сколько в него вложили.

Но вот здесь и начинается взрослая часть профессии.

Привязанность — плохой управленческий скилл.

И, если честно, не только управленческий.

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

И руководителю особенно важно это понимать.

Эмпатия — не плохой скилл. Эмпатия нужна.
Человечность? Человечность нужна.
Способность переживать за людей — плохо? Нет, это тоже важно.

Плохой скилл — привязанность.

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

Иногда они уйдут красиво.
Иногда — криво.
Иногда — молча.
Иногда — с обесцениванием всего, что было.

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

Руководителю важно уметь отпускать.

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

Дожили...)

Перевод: MrBeast (известный блогер) планирует запереть 1000 вайб-кодеров в одной комнате без Claude. Первый кто отцентрует div выигрывает миллион долларов

Выходить в поля

Интересно закончился этот кейс с Яндекс Доставкой.

Зато, кажется, стало понятно, что скрывалось за «техническими неполадками» и «невозможностью отправить заказ».

Всё оказалось и проще, и печальнее. Мама отнесла посылку в ПВЗ, где её несколько дней просто не забирали. Когда стало понятно, что SLA уже про...шли, заказ не отправили дальше, а инвалидировали под видом «технических неполадок».

Почему? Потому что иначе, видимо, будет штраф от Яндекса.

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

Она становится про продукт.

Потому что если у человека есть выбор:

1. честно признать проблему и получить штраф;
2. спрятать проблему за «техническими неполадками» и переложить последствия на пользователя;

то это не только человеческая халатность. Это ещё и проблема дизайна процесса.

Очень удобно смотреть на сервис из офиса. Есть красивые дашборды, SLA, воронки, статусы, регламенты, CJM и прочие правильные слова. На графиках всё может выглядеть нормально. Заказы едут. Инциденты классифицируются. Техподдержка отвечает. Система работает.

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

Твой продукт — это человек в ПВЗ, который держит в руках чужую посылку и думает, как бы ему не получить штраф.

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

Твой продукт — это заказ, который исчезает из интерфейса так, будто его никогда не было.

Твой продукт — это пользователь, который уже заплатил деньги, уже отдал вещь, уже рассчитывал на доставку, а теперь ему говорят: «Заберите обратно из пункта отправления».

Поэтому так важно иногда выходить из офиса и пользоваться своими же сервисами. Не демо смотреть. Не презентацию слушать. Не отчёт по метрикам читать. А реально пройти путь пользователя руками.

Оформить заказ. Отнести посылку. Поговорить с ПВЗ. Написать в поддержку. Посмотреть, где сломается процесс. И главное — посмотреть, как система поведёт себя, когда что-то пойдёт не так.

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

Кажется, теперь кому-то стоит поработать в ПВЗ.

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

Метод ABCD: как не разогнать эмоцию до катастрофы

В книге «Эмоциональный интеллект. Российская практика» описан интересный метод для работы с эмоциями — ABC.

Идея такая: нам часто кажется, что за событием сразу следует эмоция.

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

Выглядит логично. Событие произошло, эмоция появилась. Всё честно.

Но метод ABC говорит, что между событием и эмоцией почти всегда есть ещё один слой — наша интерпретация.

A — activating event, то есть само событие.
B — beliefs, мысли и убеждения по поводу события.
C — consequences, эмоции и действия, которые из этого рождаются.

То есть не:

«Руководитель не согласовал повышение» → «я злюсь».

А скорее:

«Руководитель не согласовал повышение» → «он меня игнорирует», «ему плевать, буду ли я тут работать», «ему не хочется платить мне больше» → «я злюсь».

На само событие мы часто повлиять уже не можем. Руководитель уже не согласовал повышение. Факт случился.

Зато мы можем поймать мысль между событием и эмоцией.

Но есть важный нюанс. В горячей ситуации не надо сразу лезть в голову и пытаться всё рационально разобрать. Сначала просто заметить: «Я сейчас злюсь», «я тревожусь», «мне обидно».

Сделать паузу. Выдохнуть. Можно даже вслух сказать себе «стоп».

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

И только после паузы можно переходить к разбору:

A — что реально произошло?
B — что я об этом подумал?
C — что я сейчас чувствую и что хочу сделать?

Например:

A — руководитель не согласовал повышение.
B — я подумал, что ему плевать и он меня игнорирует.
C — я злюсь и хочу написать что-нибудь ядовитое.

И вот здесь появляется четвёртый шаг, которого нет в книге, но без него метод работает вполсилы. D — disputing, оспаривание.

Это когда вы спорите с собственной автоматической мыслью.

Например, с мыслью «он меня игнорирует»:

— Какие у меня есть реальные доказательства?
— Есть ли другое, не менее вероятное объяснение?
— Что самое плохое случится, если моя интерпретация верна?

Может быть, у руководителя правда нет бюджета. Может быть, он ждёт ответа от своего руководителя. Может быть, он думает, как это объяснить. А может быть, он действительно отмахнулся.

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

После такого разбора часто появляется другое действие. Не:

«Ну спасибо, всё понятно».

А, например:

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

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

Но сначала хорошо бы отделить факт от собственной фантазии.

Потому что очень часто мы реагируем не на реальность, а на кино, которое сами же быстро смонтировали у себя в голове. Причём с драматичной музыкой, плохим финалом и обязательным «ну всё понятно».

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

А потом уже не ты управляешь ситуацией, а твоя интерпретация управляет тобой.

Простой хинт:
— стоп-пауза: заметил эмоцию, выдохнул;
— A: что реально произошло?
— B: что я об этом подумал?
— C: что я чувствую и что хочу сделать?
— D: какие есть доказательства, альтернативы и что худшее случится?

И только потом — действовать.

Часто уже на шаге B злость, тревога или обида перестают бить ураганом.

Не паниковать и не совершать импульсивных действий

Сегодняшняя личная история хорошо дополняет прошлый пост про ABCD.

Сегодня я должен был в 7 утра лететь из Петербурга в Москву.

Вечером лёг в 22, чтобы попытаться выспаться. Проснулся в 4:45, сел в машину и поехал в Пулково. Заранее посмотрел, что небо закрыто, но из практики моих наблюдений Москву крайне редко закрывают дольше чем на 2–3 часа. Плюс у меня был запас времени.

Когда я в 6 утра заходил в аэропорт, мой рейс отменили.

Меня пересадили на рейс в 8 утра. Я посмотрел билеты на ближайшие Сапсаны. Был поезд на 6:50, следующий — в 9. Построил маршрут до Московского вокзала через Яндекс Карты, они показали час пути.

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

В 6:50 небо открыли. Я окончательно успокоился. В 7:20 началась посадка, мы доехали на автобусе до самолёта, посмотрели на него... и нас повезли обратно.

Небо снова закрыли.

Наш рейс в 8 утра отменили. Да, вот так вот. Буквально 5 минут назад я смотрел на самолёт, которым должен был лететь, а по возвращении в терминал рейс уже был отменён.

Новый рейс поставили на 10 утра.

Небо открыли буквально в момент, когда я возвращался в терминал. Я выругался. Уже было понятно, что к 11 на мероприятие я не успею, поэтому я написал второму организатору инструкцию, что делать. Презентацию, к счастью, скинул ещё накануне.

С грустью посмотрел на людей, которые садились на рейс в 8:30, попытался попасть к ним на борт, безуспешно, и пошёл дальше готовиться к мероприятию.

Забегая вперёд, в отличие от нас, кому просто показали самолёт, у них случилось путешествие из Петербурга в Петербург. См. скрин.

Потому что в 9:05 небо снова закрыли.

Рейс в 10 сначала перенесли на 12, но буквально через несколько минут тоже отменили. Новое время вылета было 20:00.

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

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

С другой стороны, сегодняшний день явно не из разряда тех дней, которые бывают «обычно». Ну это если вы новости читаете.

Правильное решение в моменте не всегда выглядит правильным задним числом. Иногда ты всё сделал разумно, а реальность просто взяла и поехала дальше без тебя. Ещё раз. И ещё раз. И ещё раз.

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

Сначала понять, что происходит.
Потом понять, что ещё можно сделать.
Потом сделать.
Потом подумать над запасными сценариями.
Потом снова проверить, что не появилось новое окно возможностей.

А вот потом уже можно злиться, грустить, материться и писать пост.

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

Сейчас я всё-таки доехал до Москвы. Завтра на втором мероприятии буду офлайн. А этим постом, кажется, уже даю волю эмоциям.

Да, иногда всё идёт не так.

Но даже когда всё идёт не так, лучше сначала разрулить, а уже потом эмоционировать.

Техника ИСР

Представьте: вы поставили сотруднику плохую оценку на ревью.

Оценку аргументировали. Привели примеры. Объяснили, чего не хватило до следующего уровня. Вроде бы всё сделали правильно.

Но человек услышал совсем другое:

«Я плохо работаю».
«Руководитель меня не ценит».
«Повышения не будет».
«Наверное, от меня вообще хотят избавиться».

После ревью вы пытаетесь поговорить ещё раз, но нормального разговора не получается. Сотрудник либо спорит с каждым примером, либо замыкается и отвечает односложно. Чем подробнее вы объясняете оценку, тем сильнее он защищается.

В книге Talking to Crazy — русский перевод «Как разговаривать с мудаками», на мой взгляд, крайне кликбейтный — Марк Гоулстон предлагает для таких разговоров технику ИСР: извинение, сочувствие, раскрытие.

И — извинение.

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

С — сочувствие.

«Понимаю, что ты много работал, рассчитывал на другую оценку и в итоге мог почувствовать, что все твои усилия просто обесценили».

Р — раскрытие.

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

Последняя часть самая сложная. Нужно вслух назвать то неприятное, что человек, вероятно, уже думает о вас.

Это не означает, что оценка была неправильной и теперь её нужно повысить. ИСР вообще не про отказ от своей позиции.

Оценка остаётся прежней. Примеры и обоснования никуда не исчезают. Требования к следующему уровню тоже.

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


И вот вы всё это сказали. Что же дальше?

Всё просто — помолчите.

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

Разговор либо начнётся прямо сейчас, либо человеку понадобится ещё немного времени.

Метод чекпоинтов

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

Асинхронные вещи — это всё, что нельзя сделать мгновенно в тот момент, когда ты про это вспомнил.

Нужно привезти детей в сад к 8:30.
Нужно не забыть купить домой бытовые штуки.
Нужно довести проект до октября.

Проблема обычно не в том, что мы не понимаем финальную точку. С ней как раз всё понятно.

Паста закончилась.
В детский сад опоздали.
Проект не готов.
Все грустят.

Проблема в том, что финальная точка — это уже поздно.

Метод чекпоинтов устроен иначе: нужно заранее найти момент, когда ещё не поздно.

Разберем пример, дома должна быть зубная паста. Да не колгейт, который доставка привезет за 5 минут, а специальная, которая обычно идёт около 20 дней.

Тогда главный вопрос , который я бы задал себе — «как выглядит тюбик за 20 дней до того, как паста закончится?».

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

Вот это и есть чекпоинт.

Не «паста закончилась, надо заказать».
А «тюбик дошёл до состояния Х, пора заказать, потому что через 20 дней он закончится».

С детским садом то же самое.

Если нужно быть там в 8:30, а дорога занимает 30 минут, то чекпоинт не в 8:30. В 8:30 уже всё, вы либо молодец, либо объясняете воспитателю, почему сегодня опять пробки, снег, дождь, ретроградный Меркурий и маленькие человеки двадцать минут выбирали носки.

Чекпоинт раньше: в 7:50 надо выйти из дома.

А ещё раньше может быть другой чекпоинт: в 7:30 дети должны быть одеты.
А ещё раньше: в 7:10 они должны закончить завтрак.
И так далее.

С проектами сложнее, потому что тюбика пасты у проекта обычно нет. Нельзя посмотреть на него и сказать: «О, он уже скручивается, пора заказывать аналитику».

Поэтому чекпоинты приходится делать искусственно.

Если проект должен быть готов к октябрю, надо не просто сказать «ну к октябрю сделаем», а декомпозировать: что должно быть готово к июлю, к августу, к сентябрю. Причём не в формате «мы активно работаем», а в формате проверяемого результата.

Не «идёт разработка».
А «есть прототип».
Не «обсуждаем интеграцию».
А «интеграция работает на тестовом контуре».
Не «почти всё готово».
А «пользователь может пройти основной сценарий».

Хороший чекпоинт — это не напоминание в календаре. Это состояние мира, по которому понятно: всё идёт нормально или пора вмешиваться.

Мне кажется, в этом и есть главная польза метода. Он помогает не обнаруживать проблему в момент, когда уже почти поздно. Потому что «паста закончилась» — это не чекпоинт. Это уже инцидент.

Умение вовремя сказать стоп

В работе руководителя очень важно научиться иногда говорить: «Стоп».

Допустим, вы поставили таргет по метрике. Технари хотят uptime в 99,95%, продакты — месячный retention в 20%, а руководитель отдела продаж — 10% успешных тёплых звонков.

Вы настроили графики, дашики и еженедельные процессы. Проходит полгода, но метрика не достигнута.

Вы требуете план. Команда приносит план, вы его утверждаете, проходит ещё месяц — ничего не меняется. Тогда появляется новый план. Потом план исправления предыдущего плана.

А можно в какой-то момент остановиться и спросить: мы вообще всё ещё делаем что-то разумное?

Как-то раз мне позвонил менеджер банка и предложил рефинансировать кредит.

Зная текущие ставки, я отнёсся к предложению скептически, но всё-таки решил послушать. Менеджер спросил, на какую сумму у меня текущий кредит. Допустим, я ответил: 100 000 рублей.

Он немного подумал и сказал:

— Мы можем выдать вам кредит на 102 000 рублей. Правда, ежемесячный платёж будет выше нынешнего и срок будет больше.

Я, конечно, отказался. Но дальше произошло неожиданное, потому что менеджер спросил:

— А почему?

— А какой в этом смысл?

— Ну как же, у вас появится ещё 2 000 рублей. Вы сможете позволить себе дополнительные траты.

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

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

Поэтому иногда нужно остановиться и проверить:

Мы всё ещё решаем важную проблему?

Эта метрика действительно связана с нужным результатом?

Цена достижения цели остаётся разумной?

Или мы продолжаем только потому, что уже потратили на неё полгода?

Сказать «стоп» не означает сдаться при первой неудаче. Иногда надо поменять способ достижения цели. А иногда — признать, что сама цель больше не имеет смысла.

Настойчивость без проверки реальностью превращается в упрямство.

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