Про руководство разработкой и продуктом | Олег Мохов

Техника ИСР Представьте: вы поставили сотруднику плохую оценку на ревью. Оценку аргументировали. Привели примеры. Объяснили, чего не хватило до следующего уровня. Вроде бы всё сделали правильно. Но человек услышал совсем другое: «Я плохо работаю». «Руководитель меня не ценит». «Повышения не будет». «Наверное, от меня вообще хотят избавиться». После ревью вы пытаетесь поговорить ещё раз, но нормального разговора не получается. Сотрудник либо спорит с каждым примером, либо замыкается и отвечает односложно. Чем подробнее вы объясняете оценку, тем сильнее он защищается. В книге Talking to Crazy — русский перевод «Как разговаривать с мудаками», на мой взгляд, крайне кликбейтный — Марк Гоулстон предлагает для таких разговоров технику ИСР: извинение, сочувствие, раскрытие. И — извинение. «Прости, я вижу, что наш разговор о ревью сильно тебя задел. Возможно, я слишком сосредоточился на аргументах и не подумал о том, как ты всё это услышишь». С — сочувствие. «Понимаю, что ты много работал, рассчитывал на другую оценку и в итоге мог почувствовать, что все твои усилия просто обесценили». Р — раскрытие. «Возможно, ты сейчас думаешь, что я давно всё решил, не верю в тебя и просто собрал аргументы, чтобы обосновать плохую оценку. А может быть, вообще воспринимаешь эту оценку как первый шаг к увольнению». Последняя часть самая сложная. Нужно вслух назвать то неприятное, что человек, вероятно, уже думает о вас. Это не означает, что оценка была неправильной и теперь её нужно повысить. ИСР вообще не про отказ от своей позиции. Оценка остаётся прежней. Примеры и обоснования никуда не исчезают. Требования к следующему уровню тоже. Но пока человек защищается от приговора, который уже услышал, обсуждать с ним развитие бесполезно. Сначала нужно вернуть возможность разговаривать. И только потом обсуждать, что конкретно не получилось и что делать дальше. И вот вы всё это сказали. Что же дальше? Всё просто — помолчите. Не начинайте снова оправдываться. Не добавляйте новых аргументов. Не пытайтесь заполнить неловкую паузу. Разговор либо начнётся прямо сейчас, либо человеку понадобится ещё немного времени.

Не паниковать и не совершать импульсивных действий Сегодняшняя личная история хорошо дополняет прошлый пост про 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 утра сорвался на поезд, то приехал бы в Москву с небольшой задержкой и всё-таки был бы офлайн. С другой стороны, сегодняшний день явно не из разряда тех дней, которые бывают «обычно». Ну это если вы новости читаете. Правильное решение в моменте не всегда выглядит правильным задним числом. Иногда ты всё сделал разумно, а реальность просто взяла и поехала дальше без тебя. Ещё раз. И ещё раз. И ещё раз. Когда происходит какая-то фигня, я стараюсь действовать по одному принципу: сначала разруливаем то, на что можем повлиять, а потом уже эмоционируем. Сначала понять, что происходит. Потом понять, что ещё можно сделать. Потом сделать. Потом подумать над запасными сценариями. Потом снова проверить, что не появилось новое окно возможностей. А вот потом уже можно злиться, грустить, материться и писать пост. Этот навык надо тренировать, но он крайне полезен всем руководителям. Потому что у руководителя что-то будет идти не так постоянно. Сейчас я всё-таки доехал до Москвы. Завтра на втором мероприятии буду офлайн. А этим постом, кажется, уже даю волю эмоциям. Да, иногда всё идёт не так. Но даже когда всё идёт не так, лучше сначала разрулить, а уже потом эмоционировать.

Метод ABCD: как не разогнать эмоцию до катастрофы В книге «Эмоциональный интеллект. Российская практика» описан интересный метод для работы с эмоциями — ABC. Идея такая: нам часто кажется, что за событием сразу следует эмоция. Любимая не ответила в чате, хотя онлайн — я расстроился. Руководитель не согласовал повышение — я злюсь. Коллега странно посмотрел на встрече — я тревожусь. Выглядит логично. Событие произошло, эмоция появилась. Всё честно. Но метод ABC говорит, что между событием и эмоцией почти всегда есть ещё один слой — наша интерпретация. A — activating event, то есть само событие. B — beliefs, мысли и убеждения по поводу события. C — consequences, эмоции и действия, которые из этого рождаются. То есть не: «Руководитель не согласовал повышение» → «я злюсь». А скорее: «Руководитель не согласовал повышение» → «он меня игнорирует», «ему плевать, буду ли я тут работать», «ему не хочется платить мне больше» → «я злюсь». На само событие мы часто повлиять уже не можем. Руководитель уже не согласовал повышение. Факт случился. Зато мы можем поймать мысль между событием и эмоцией. Но есть важный нюанс. В горячей ситуации не надо сразу лезть в голову и пытаться всё рационально разобрать. Сначала просто заметить: «Я сейчас злюсь», «я тревожусь», «мне обидно». Сделать паузу. Выдохнуть. Можно даже вслух сказать себе «стоп». Потому что, пока эмоция бушует, думать сложно. Мозг в этот момент хочет бить, бежать, спорить, доказывать и писать то самое сообщение, за которое утром будет немного стыдно. И только после паузы можно переходить к разбору: A — что реально произошло? B — что я об этом подумал? C — что я сейчас чувствую и что хочу сделать? Например: A — руководитель не согласовал повышение. B — я подумал, что ему плевать и он меня игнорирует. C — я злюсь и хочу написать что-нибудь ядовитое. И вот здесь появляется четвёртый шаг, которого нет в книге, но без него метод работает вполсилы. D — disputing, оспаривание. Это когда вы спорите с собственной автоматической мыслью. Например, с мыслью «он меня игнорирует»: — Какие у меня есть реальные доказательства? — Есть ли другое, не менее вероятное объяснение? — Что самое плохое случится, если моя интерпретация верна? Может быть, у руководителя правда нет бюджета. Может быть, он ждёт ответа от своего руководителя. Может быть, он думает, как это объяснить. А может быть, он действительно отмахнулся. Но даже если так, мир всё равно не рухнет. Можно поговорить прямо, зафиксировать ожидания или начать искать другой вариант. Писать пассивно-агрессивное сообщение прямо сейчас всё равно не обязательно. После такого разбора часто появляется другое действие. Не: «Ну спасибо, всё понятно». А, например: «Слушай, хочу уточнить про повышение. Я пока не понял причину отказа. Мне важно понимать, над чем работать дальше и когда можно вернуться к разговору». Это не значит, что надо всё оправдывать и давать другим садиться себе на шею. Иногда человек действительно не прав. Иногда руководитель действительно отмахнулся. Иногда ситуация действительно плохая. Но сначала хорошо бы отделить факт от собственной фантазии. Потому что очень часто мы реагируем не на реальность, а на кино, которое сами же быстро смонтировали у себя в голове. Причём с драматичной музыкой, плохим финалом и обязательным «ну всё понятно». Мне кажется, для руководителя это особенно важный навык. Руководитель постоянно получает обрывки информации: кто-то промолчал, кто-то не пришёл, кто-то ответил сухо, кто-то на встрече закатил глаза. И на каждый такой обрывок можно моментально накрутить объяснение. А потом уже не ты управляешь ситуацией, а твоя интерпретация управляет тобой. Простой хинт: — стоп-пауза: заметил эмоцию, выдохнул; — A: что реально произошло? — B: что я об этом подумал? — C: что я чувствую и что хочу сделать? — D: какие есть доказательства, альтернативы и что худшее случится? И только потом — действовать. Часто уже на шаге B злость, тревога или обида перестают бить ураганом.

Выходить в поля Интересно закончился этот кейс с Яндекс Доставкой. Зато, кажется, стало понятно, что скрывалось за «техническими неполадками» и «невозможностью отправить заказ». Всё оказалось и проще, и печальнее. Мама отнесла посылку в ПВЗ, где её несколько дней просто не забирали. Когда стало понятно, что SLA уже про...шли, заказ не отправили дальше, а инвалидировали под видом «технических неполадок». Почему? Потому что иначе, видимо, будет штраф от Яндекса. И вот тут история становится не про мою посылку. И даже не про конкретный ПВЗ. Она становится про продукт. Потому что если у человека есть выбор: 1. честно признать проблему и получить штраф; 2. спрятать проблему за «техническими неполадками» и переложить последствия на пользователя; то это не только человеческая халатность. Это ещё и проблема дизайна процесса. Очень удобно смотреть на сервис из офиса. Есть красивые дашборды, SLA, воронки, статусы, регламенты, CJM и прочие правильные слова. На графиках всё может выглядеть нормально. Заказы едут. Инциденты классифицируются. Техподдержка отвечает. Система работает. А потом ты выходишь в поля и внезапно видишь, что в реальности твой продукт — это не дашборд. Твой продукт — это человек в ПВЗ, который держит в руках чужую посылку и думает, как бы ему не получить штраф. Твой продукт — это сотрудник поддержки, который не может сказать пользователю настоящую причину. Твой продукт — это заказ, который исчезает из интерфейса так, будто его никогда не было. Твой продукт — это пользователь, который уже заплатил деньги, уже отдал вещь, уже рассчитывал на доставку, а теперь ему говорят: «Заберите обратно из пункта отправления». Поэтому так важно иногда выходить из офиса и пользоваться своими же сервисами. Не демо смотреть. Не презентацию слушать. Не отчёт по метрикам читать. А реально пройти путь пользователя руками. Оформить заказ. Отнести посылку. Поговорить с ПВЗ. Написать в поддержку. Посмотреть, где сломается процесс. И главное — посмотреть, как система поведёт себя, когда что-то пойдёт не так. Я помню истории, как топы Яндекса лично садились за руль такси, чтобы протестировать сервис изнутри. Не как пассажиры, а именно с другой стороны процесса. Кажется, теперь кому-то стоит поработать в ПВЗ. Потому что последняя миля продукта часто находится не в приложении. А в руках человека, которого ваш процесс либо учит решать проблему пользователя, либо учит красиво прятать косяки.

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

Один из худших скиллов руководителя В «45 татуировках менеджера» есть неприятная, но очень взрослая мысль: не надо рассчитывать на благодарность бывших сотрудников. Ты можешь вкладываться в человека. Учить, защищать, вытаскивать, давать шанс, продвигать, спорить за него с другими руководителями, прикрывать в сложные моменты. А потом он уйдёт. И, возможно, через пару месяцев будет рассказывать, что ты был не очень руководитель. Что компания была так себе. Что его недооценивали. Что вообще всё хорошее он сделал сам, а всё плохое случилось из-за системы, менеджмента и лично тебя. И это, конечно, вам как руководителю может быть больно. Потому что вы — тоже человек. Вы привыкаете. Помните, как человек пришёл, например, слабым джуном, как рос, как впервые начал брать ответственность, как ошибался, как становился сильнее. И где-то внутри хочется, чтобы человек помнил не только свои обиды, но и то, сколько в него вложили. Но вот здесь и начинается взрослая часть профессии. Привязанность — плохой управленческий скилл. И, если честно, не только управленческий. Это неприятно признавать. Прошлое создаёт опыт. Иногда важный, иногда болезненный, иногда очень дорогой. Но не гарантию, того что со временем с вами обойдутся так, как вы считаете заслуженным. И руководителю особенно важно это понимать. Эмпатия — не плохой скилл. Эмпатия нужна. Человечность? Человечность нужна. Способность переживать за людей — плохо? Нет, это тоже важно. Плохой скилл — привязанность. Работа руководителя — не выращивать людей, чтобы они потом были тебе благодарны. Работа руководителя — создавать среду, в которой люди могут расти, приносить результат и в какой-то момент идти дальше. Иногда они уйдут красиво. Иногда — криво. Иногда — молча. Иногда — с обесцениванием всего, что было. Но если каждый раз эмоционально проваливаться в это как в личную потерю, то очень быстро выгоришь. Руководителю важно уметь отпускать. А ещё, и это один из главных признаков зрелости не только руководительской, но и человеческой — круто если вы сохраните при этом способность продолжать вкладываться в людей на максималках, заранее понимая, что большая часть из них потом не скажет даже спасибо.

Yandex ML Challenge Очень приятно видеть, что дело, которое ты когда-то начинал, живёт и развивается. В 2018 году ко мне перешёл Яндекс Контест. За 6 лет моей работы в нём нам удалось превратить его из сервиса для контестов в платформу для проведения масштабных соревнований. И отдельная моя гордость в том, что Контест давно вышел за пределы спортивного программирования. Теперь на нём можно проводить не только олимпиады и проверять алгосы, но и ML-челленджи. Если вам интересен соревновательный ML, то у Яндекса прямо сейчас идёт Yandex ML Challenge — турнир с задачами по ИИ. Формат: онлайн-контест без жёсткого тайминга на несколько часов. Можно спокойно подумать над решением, попробовать разные подходы и несколько раз улучшить результат. Задачи будут вокруг: — LLM / foundation models — computer vision — reinforcement learning — оптимизации нейросетей Тур проходит с 21 по 31 мая. На каждую задачу есть ограничение в 40 посылок. Топ-100 участников попадут на очный финал на Young Con в Москве. Победитель получит 1 млн рублей, а топ-15 — устройства от Яндекса. Мне кажется, сейчас хороший момент заходить в ML не только через курсы, статьи и видео-уроки, но и через соревнования. Так что если вы только начали заниматься ML — попробуйте. Если занимаетесь давно — тем более попробуйте. Регистрация тут.

AI-DISRUPT PDLC Сбер выложил масштабную работу — документ-концепцию трансформации жизненного цикла разработки ПО в эпоху ИИ. Бегло пробежал, есть интересные поинты. Например, что >50% традиционных мест разработчиков к 2030 году заменит Product Engineer (заметьте, не ИИ, а новая роль, которая сейчас образовывается). Или что внедрение только лишь Copilot-ов через пару лет обернется деградацией производительности на 25%. В общем, есть что обсудить. И я планирую прокомментировать основные поинты. А пока интересно спросить у вас: читали? Что думаете?

Розыгрыш билетов на PeopleSense 2026. upd. Разыграли У меня есть промокод на бесплатный билет на конференцию PeopleSense в Москве 4-5 июня, и я хочу его разыграть. Сначала хотел сделать что-то банальное: подпишитесь, поставьте реакцию, сделайте репост. Но потом подумал, что это какая-то ерунда. Поэтому я решил иначе. Я хочу отдать билет человеку, которому конференция правда будет полезна. Что нужно сделать: 1. Быть подписанным на канал. 2. Написать в комментариях, почему вы хотите попасть на конференцию и какие доклады вас особенно заинтересовали. 3. Верю в силу кармы, но никак не проверю. Если хотите увеличить шансы — перешлите этот пост в рабочий чат / свой канал / кому-то из коллег, кому может быть полезен мой канал. Победителя выберу 25 мая из тех, кому билет, на мой взгляд, может дать больше всего пользы. Если таких будет несколько — разыграю случайно среди них. Если вы уже купили билет, тоже можно участвовать. Тогда билет можно будет подарить коллеге. А мне будет отдельно интересно почитать, зачем люди ходят на конференции сейчас: за докладами, за людьми, за вдохновением, за сменой контекста или просто чтобы на день выбраться из рабочего чата. P.S. Фото не несёт никакого смысла, его просто сделал ребёнок, когда гулял по лесу.

ИИ создаёт когнитивную нагрузку Пока все заняты смакованием новых моделей от Google, я тут прочитал заметку в HBR про прожарку мозга с помощью ИИ. Мы часто думаем про ИИ так: «Раньше я делал задачу сам, а теперь её делает ИИ. Значит, я разгрузился». Ну то есть «вкалывают роботы, а не человек». Но на практике часто получается иначе. Раньше я просто писал текст. Теперь я пишу промпт, читаю ответ, понимаю, что он слишком водянистый, уточняю промпт, читаю второй ответ, вылавливаю галлюцинации, переписываю руками, а потом ещё думаю — не потерялся ли в процессе исходный смысл? То есть задача вроде бы автоматизирована, но вместо неё появилась новая задача — управлять и контролировать. Потому что управлять ИИ — это тоже работа. Причём не всегда эта работа легче той, что ты выполнял до ИИ. Нужно держать в голове контекст, критерии качества, ограничения, источники, риски и ещё постоянно принимать микрорешения: верю / не верю, подходит / не подходит, надо проверить / можно брать. В итоге ИИ может не снять нагрузку, а просто поменять её тип. И внезапно люди устают от этого ещё сильнее. Есть такой феномен — усталость от принятия решений (англ. decision fatigue). Я когда-то читал об этом у Жени Степанищева, но заметку найти не могу. Если найдёте — скиньте. Смысл был в том, что, став руководителем, он настолько уставал к концу дня, что вечером не мог принять элементарное решение, например, чего хочется на ужин. И с ИИ может происходить примерно то же самое. На маленьких задачах это магия. На больших — иногда превращается в диспетчерскую вышку, где у тебя одновременно взлетают пять самолётов, три кружат над аэродромом, один потерял связь, а ты вроде бы просто хотел быстрее написать письмо. И мне кажется, это важный продуктовый вывод для всех AI-инструментов. Нельзя мерить только их использование (ну и потребление токенов, само собой). Стало ли человеку проще делать работу? Если у вас AI-ревьюер кода написал 30 комментариев, а разработчик теперь тратит два часа, чтобы понять, какие из них не бред, то мы не ускорили ревью. Мы добавили ещё одного участника ревью, которого тоже надо ревьюить. Если AI-поиск дал красивый ответ, но человек всё равно пошёл проверять его в документации и спрашивать у коллег, то мы не сократили путь к знанию. Мы добавили ещё один слой сомнений. Если AI-ассистент нагенерил пять вариантов решения, а человек теперь сидит и выбирает между пятью средними вариантами вместо того, чтобы сделать самостоятельно один нормальный, то это тоже не очень-то помощь. Поэтому при внедрении AI-инструментов надо задавать не только вопрос «сколько людей этим воспользуются?», но и: какую нагрузку мы снимем с человека? Если ответа нет, то, возможно, мы вместо снятия нагрузки просто поджарим ему мозг новым способом.