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

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

Правило половины дняИзучая когнитивную нагрузку, я вывел для себя правило, которым пользуюсь, когда вхожу в новые проекты или, например, когда менял работу.Не планировать онбординг-встречи во второй половине дня.Объём информации при входе в новый контекст огромный. Люди, роли, процессы, архитектура, цели, политический контекст, исторические причины, почему «вот так нельзя», а «вот так можно, но осторожно».Где-то после 15:00 у меня просто отключается мозг.Я продолжаю слушать. Даже что-то записываю. Могу задавать вопросы. Со стороны всё выглядит нормально.Только новая информация уже почти не оседает в голове. Она превращается в шум.В теории когнитивной нагрузки есть простая мысль: рабочая память человека ограничена. Если в неё слишком долго и слишком плотно складывать новое, она перестаёт нормально это обрабатывать. Это особенно заметно на онбординге, где почти каждая фраза — новая сущность.Поэтому я стараюсь ставить важные ознакомительные встречи на первую половину дня. А вторую оставлять на чтение док, заметки, самостоятельное ковыряние продукта, сбор вопросов и просто подумать.И я всегда заранее предупреждаю людей:«Я, возможно, к вам ещё вернусь и ещё раз переспрошу всё то, что вы мне сейчас рассказали».Мне кажется, это сильно снижает напряжение. Человек понимает, что я могу тупить, но не игнорирую. Я просто честно признаю: с первого раза новый контекст редко укладывается в голову целиком.Хороший онбординг — это не когда тебе за день рассказали всё. А после 15:00 лучше погулять и подумать)

FrontendConf 2026 — Skip!Глеб написал пост о FrontendConf. Теперь всё, уже официально. Глеб, конечно, драматизирует, всё-таки мы не закрыли конференцию, а просто пропускаем в этом году.Я присоединился к ПК FrontendConf в прошлом году, и несмотря на то что я давно в ПК DUMP и даже когда-то сам делал конференцию, но даже за этот год успел почувствовать различия.Главное — это то сколько времени мы тратили на отбор и подготовку докладчиков. Организовать один поток на крупном фестивале, или сделать конференцию в один поток — это не то же самое, что сделать конференцию в 4 потока и на два дня.Что меня поразило — это то как докладчики реагировали на фидбек. Некоторые доклады мы прогоняли больше 10 раз в течение 4-х месяцев. И при этом когда мы встретились очно, то докладчики не хотели убить меня 😊Что ж, в этом году мы немного выдохнем, надеюсь, увидимся на FrontendConf 2027.

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

Три уровня решения задачЗа последние два года я насмотрелся на кучу ситуаций, где люди по-разному понимают, что такое «решённая задача». Я сейчас не говорю про шизофрению, когда было чёткое ТЗ, а исполнитель зачем-то решил «добавить себя» и сделал не то. Я говорю про более распространённый класс задач — сформулированных достаточно общо и предполагающих люфт в трактовке. Например, «подмести двор».И я давно выделил три способа решать задачи.▫️. Сделать как-тоИли, если честно, «на отъе@ись».Это когда задача решена формально.Двор мели? Мели. Грязь осталась? Ну и что такого, двор-то подметён, работа сделана.▫️. Сделать нормЭто самый частый вариант.Задача действительно решена. Более-менее качественно. Обычно в срок. Иногда даже без особых вопросов.Честно говоря, большая часть мира живёт именно в категории «норм». И в целом это то где работают менеджеры.▫️. Сделать зашибисьНу или, если без цензуры, вы поняли.Это мой любимый тип.Когда человек не просто решает задачу, а выжимает максимум из решения. Его реально прёт делать хорошо. Он замечает детали. Ищет нестандартные ходы. Думает не только о том, как закрыть задачу, но и о том, как потом будет использоваться результат.Недавно был на концерте группы Tritia и узнал, что гитарист отдельно заморачивается над тем, чтобы оборудование подключалось максимально быстро и без лишней возни. Казалось бы, мелочь. Но для него это важно. А ещё это удобно всем вокруг: воткнулись и погнали.Это и есть «сделать зашибись».Я вижу три типа конфликтов вокруг результата, которые руководителям нужно уметь грамотно разруливать или вообще купировать заранее.▫️. Рассогласование «норм»Это классическая история.Вот, например, на выходе со двора есть калитка и ещё пара метров прохода. Сам двор подмели, но сразу за калиткой лежат сугробы. Казалось бы, можно было бы подмести ещё чуть-чуть и сделать отлично.Обычно такие проблемы решаются уточнением ТЗ, рамок и договорённостей. То есть нужно просто лучше фиксировать, где проходит приемлемая граница результата

Большая новость для тех кто, кто хочет эффективно использовать ИИ в бизнесе 🔥21–23 апреля наши коллеги из Kaiten организуют конференцию «AI в управлении компанией: тренды 2026».В программе три насыщенных дня с мощным составом спикеров:🟣 21 апреля — день стратегии Применение ИИ для роста прибыли и построения стратегии вместе с Павлом Алферовым, Светланой Берендеевой, Александром Бындю и Алексеем Халезовым.🟣 22 апреля — день кейсов Реальные практики использования ИИ в продажах, управлении и продукте от Игоря Филипьева, Елены Полозовой, Марины Вербицкой и Ивана Зверева.🟣 23 апреля — день трансформаций Как внедрять ИИ без саботажа — опыт Марии Савельевой, Ильи Павличенко, Давида Асатряна и Андрея Гирина.Только практика, реальные кейсы и выводы, что работает в 2026 году.Конференция полностью онлайн, участие бесплатно.👉 Подробности и регистрация по ссылке До встречи!

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

Как писать код с ИИ. Мнение сообществаКажется, у меня начинает складываться ответ на вопрос «как писать код с ИИ».Я вчера спросил у вас, как вы это делаете на практике. И если убрать названия тулов, то картина на удивление цельная.Главная мысль:ИИ не заменяет разработку. Он делает быстрее цикл: ресерч -> план -> реализация -> ревью -> доработки.То есть выигрывают не те, кто «дал царь промпт и пошёл пить кофе», а те, кто встроил ИИ в нормальный инженерный процесс.Основные инсайты, которые я бы выделил.1. Сначала не код, а пониманиеЛюди сначала просят ИИ исследовать кодовую базу, тикет, логи, репозиторий, иногда даже приложение через playwright.Всё это для того чтобы ИИ он сразу не полез править файлы, а чтобы собрать контекст и помочь сложить картину в голове.Это, кстати, важный паттерн.Многих кто входит в тему разработки ИИ откровенно раздражает, что агент сразу бежит что-то менять. В ответ появился почти универсальный закон:сначала план, потом код.2. Лучший режим работы — пошаговая стратегияТиповой цикл у большинства выглядит примерно так:— дать задачу— попросить исследовать кодовую базу— собрать верхнеуровневый план— провалидировать его своей головой— заставить расписать какие-то куски подробнее, ещё раз провалидировать, этот цикл может быть несколько раз— только потом реализовать— потом отдельно натравить на это ревьюера— потом ещё раз посмотреть самомуТо есть ИИ хорошо работает не как «магический программист», а как очень быстрый джун/мидл/команда мидлов, которых ты всё равно контролируешь.3. Артефакты решаютМногие пишут, что складывают контекст в .md-файлы: описание тикета, контекст, ожидаемое решение, план, документацию по итогам.Условно: у вас не просто чатик с агентом, а внешняя память.Часто встречаются такие штуки:— CLAUDE.md / AGENTS.md как онбординг для агента— вложенные AGENTS.md по подпапкам (backend, frontend, infra)— skills / commands под типовые режимы работы (/new-feature, /fix-bug, /do-review)— rules / workspace / project-specific skillsПо сути, лю

Как вы пишете код с ИИ?А вот расскажите.Я понимаю что есть Claude, Opus, GLM, Cursor. Что там есть чат и можно задавать команды. И всё что ли?Верю что уже есть лайфхаки, интересный опыт, опыт команд и компаний. Поделитесь что у кого есть, и как не сжечь миллионы токенов.

Разработчик сделал пасхалку на 1 апреля. РазборНастало время разобрать кейс.Почему-то многие в комментариях зацепились за то, что в современном SDLC такое в принципе невозможно — чтобы что-то закоммитить без ведома команды.Что я могу сказать? Ребятам из бигтеха не понять…Ладно, шутки в сторону. Давайте чуть ослабим это допущение: организованная группа разработчиков сделала маленькую шалость. И вот мы здесь.Я лично очень люблю пасхалки. На мой взгляд, они повышают ощущение сопричастности к продукту и делают его «живым».В разное время мы, например, делали алерт «Наши люди в булочную на такси не ездят» или включали «гравитацию» HTML-элементов, если тапнуть по экрану пятью пальцами.Это безобидные и весёлые шутки, которые мы внедряли, будучи ответственными не только за фронтенд, но и за продукт в целом.Если вы руководитель и в вашем проекте случилась такая шалость, о которой вы не знали, первое, что я бы сделал — проговорил бы правило:о любых таких историях я должен быть в курсе.Почему это важно.Вернёмся к истории с «булочной». Представим, что из-за бага часть пользователей не может вызвать такси.Поддержка не понимает, что отвечать, проблема копится, эскалация доходит до вас.Если вы в курсе — вы знаете, что нужно просто откатить релиз или выключить фичефлаг. Лажанули — бывает.Если нет — вы тратите время на разбор, пока теряете деньги и пользователей.Второе — я бы вовлёк команду в продуктовые процессы.Если людям хочется «играться» с продуктом — это хороший сигнал. Эту энергию можно направить в развитие, а не в скрытые инициативы.И третье — я бы посмеялся и похвалил команду.Особенно если шутка действительно смешная.