Руководитель, который не ошибается — и другие мифические существа
Затягивать неприятные решения. Говорить «да», когда надо «нет». Нанимать людей, похожих на себя. Верить, что процесс как-нибудь заработает сам. Всё это — классические управленческие ошибки, которые совершают даже опытные руководители. И о которых не очень принято говорить вслух.
В новом выпуске «Свободного слота» — Андрей Колесников, SRE DevOps Lead в Авито и соведущий подкаста «В SREду на кухне». Разбираем топ управленческих косяков — и честно признаёмся в своих.
Что обсудили
Можно ли вообще научиться на чужих ошибках — или только на своих? Где грань между взвешенным решением и банальным затягиванием. Как говорить «нет» так, чтобы не прослыть неудобным руководителем. И как признавать ошибки до того, как с ними уже пришли к тебе — а не после.
Обеспечение технической поддержки ПО при его эксплуатации с целью устранения выявляемых в ходе использования и обновления ПО недостатков.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
P.S. Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Каждый год на рынок выходит более 30 000 новых продуктов, но успеха добиваются лишь 15–20% из них. Часто проблема не в качестве продукта, а в том, что рынок меняется быстрее, чем команды успевают адаптироваться к новым запросам пользователей и технологиям.
В таких условиях важно не только следить за конкурентами, но и замечать сигналы, которые только начинают набирать силу.
Ксюша, руководитель продукта Project Ruler, поделилась практическим подходом к трендвотчингу: где искать ранние сигналы, как системно работать с трендами и какие изменения уже сейчас заметны на рынке управления проектами.
Что такое трендвотчинг
Трендвотчинг — это системный навык замечать ранние изменения в технологиях, поведении пользователей и бизнес-контексте до того, как они становятся очевидными для всех.
Это не фиксация текущего состояния рынка, а попытка понять, куда он движется дальше.
Почему простого анализа конкурентов уже недостаточно
Конкурентный анализ показывает, что происходит на рынке прямо сейчас. Но он редко помогает понять, куда рынок движется дальше.
Трендвотчинг позволяет смотреть шире:
какие технологии становятся доступнее;
какие решения набирают популярность в смежных индустриях;
какие темы растут в поиске и популярны в отраслевых обзорах.
Так можно заметить изменения раньше, чем они станут массовыми.
Где искать ранние сигналы
Один источник редко дает полную картину, поэтому я стараюсь комбинировать разные форматы.
Чаще всего использую:
Product Hunt, Trend Hunter и Springwise — чтобы следить за новыми продуктами и идеями;
Google Trends и Яндекс.Вордстат — чтобы анализировать интерес пользователей;
консалтинговые отчеты и отраслевые исследования — чтобы видеть долгосрочные изменения рынка.
Как понять, что тренд действительно важен
Чтобы понять, насколько тренд действительно волнует пользователей, важно подкреплять наблюдения количественными данными.
Практический подход примерно такой:
Сформулируйте базовый запрос, используя ключевые слова и фразы, связанные с вашей отраслью.
Расширьте его синонимами и альтернативными формулировками.
Сравните данные по регионам и сегментам аудитории.
Посмотрите динамику и сезонные всплески интереса.
Автоматизируйте мониторинг, создав дашборды и оповещения.
Как встроить трендвотчинг в рабочий процесс
Чтобы работа с трендами не превращалась в хаотичный серфинг, полезно автоматизировать сбор сигналов. Здесь помогают RSS-фиды и ридеры, которые собирают статьи, рассылки и обновления в одном месте.
Когда сигналы собраны, их можно структурировать с помощью:
Trend Canvas — для глубокого анализа тренда;
упрощенного SWOT-анализа — для быстрой первичной оценки.
Чек-лист работы с трендами
Формулировка цели и задач исследования.
Сканирование сигналов — системный поиск и сбор информации.
Интерпретация и систематизация.
Оценка и приоритизация.
Эксперименты и тесты — прототипы, MLP, пилоты.
Масштабирование и интеграция.
Какие тренды уже заметны на рынке
Один из самых заметных трендов сегодня — развитие low-code и no-code подходов.
Пользователи ожидают, что сложные процессы можно будет настраивать быстрее и без глубокой технической подготовки.
Крупные игроки уже активно развивают это направление, а аналитики прогнозируют дальнейший рост рынка в ближайшие годы.
Параллельно растет интерес к автоматизации, встроенным ИИ-функциям и более гибким системам управления проектами.
Почему выигрывают внимательные
Трендвотчинг не помогает предсказать будущее со стопроцентной точностью. Но помогает раньше замечать изменения, проверять гипотезы и принимать решения.
Выигрывают не те, кто просто хорошо делает свою работу, а те, кто умеет смотреть чуть дальше других и внедрять тренды раньше конкурентов.
Но не всегда важно быть первым. Иногда достаточно быть тем, кто заметил сигнал и сумел превратить его в осмысленное продуктовое решение :)
Как сейчас помню. Прилетает баг. Пользователь-кассир видит закупочную цену. Исправил. Прилетает баг. Пользователь-управляющий видит не закупочную цену, а цену продажи. Фиксить нельзя рефакторить.
М-да, предшественники старались знатно, чтобы сделать такое колесо обозрения костылей и вложенных условных операторов. Но ничего! Уж я-то всё всем докажу и всё везде исправлю навсегда!
Настарался не менее знатно, что-то постоянно не сходилось. Ну, не могли полтора десятка человек быть абсолютным злом. Или я в самом загадочном месте планеты, или причина в другом. Я стал искать, перебирать бэклог, группировать бэклог и вышел на… планирование. На его отсутствие.
Ладно, не вышел. Был свидетелем. Как от спринта к спринту задачи не были связаны друг с другом. Сегодня мы делаем турникет, завтра апельсин, потом кузнечика, потому что срочно нужна наковальня, а у нас итерационный продукт! Если останется время, то переведём бабушку с ангуляра на рякт, если нет — дедушку, но закончить до сентября! Что будет через два месяца? Верно, бабка с дедом посреди дороги висят на турнике в шубах на рыбьем меху. А? Поняли? Поняли? Рыбий мех — кузнечный мех! Это аджайл, мамкина норка! Нет времени уточнять, тебе ещё апельсин чистить.
И вроде бы фантастика, ложь, абсурд! Но одна недоделанная фича сменяет другую и мы из созвона в созвон гоняем запятую по «фиксить нельзя рефакторить», ведём разговоры о техническом долге. Только долг оказывается концептуальным.
Как и в любой сказке, в стране копирующих продуктов привычные нам вещи отзеркалены, так и концептуальный долг представляет собой не эхо ошибок, а отсутствие будущего из-за виляния — как хвостом — настоящего. В котором табаки-менеджменту снится, что он запускает ракеты, но всё равно просыпается убыточным стартапом.
Вы помните этого персонажа из Книги Джунглей. Не шибко опасен, не шибко умен, но он повсюду со своими мантрами. Если концепцию продукта можно представить в виде компаса, по которому можно сверяться и потому свободно перемещаться по пути к большой цели, то табаки-менеджмент не имеет такого компаса, он ориентируется на слухи: куда подул ветер, туда и развернут продукт. Это бизнес! Бизнес зовут! Подобное мельтешение ведёт к джунглям из спагетти-кода, что при первом приближении кажется техническим долгом.
Табаки-менеджмент этому рад, он может даже с пониманием относиться к рефакторингу, но при всей внешней дружелюбности он одёрнет вашего коллегу и попросит сделать вот эту срочную фичу и разобраться вот с этим важным клиентом. Клиент ушёл, фича никому не нужна, а ваш рефакторинг — это ваш рефакторинг.
Обеспечение защиты ПО, в том числе документации ПО, от угроз, возникающих в процессе передачи ПО пользователю.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S.
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.
Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.
Собрались как то Росатом, Камаз, Северсталь и РЖД, чтобы разработать отечественный стандарт Бережливого производства - ГОСТ Р 56020.
Сделали сначала первую версию от 2014 года.
Потом через несколько лет доработали и выпустили следующую - от 2020 года.
И вот в этом современном стандарте от монстров отечественной экономики используется перечень потерь из середины прошлого века...
Зачем критический подход? Видимо решили, что лучше оставить узкоспециализированный набросок от Тойоты, чем разработать нечто актуальное, логичное, удобное и более универсальное, чем конвейер с запчастями от автомобилей...
Хотя там весьма "современно" - много синонимов, выделенных в отдельные позиции и без какого-либо подхода к систематизации - просто список, как старику японцу приснилось.
Вот исходный тойотовский список из 7ми:
перепроизводство
избыток запасов
лишнее перемещение объектов (логистика)
задержки и простои
лишняя обработка
лишние движения человека
дефекты и брак
Вот, на мой взгляд, более адекватный для работы вариант:
использование неактуальной технологии
избыточность (операции, ресурсы, страховка)
ошибки и нарушения
упущенные возможности и простои
Чем меньше в списке позиций - тем проще его запомнить и применять на практике.
Чем лучше систематизация, тем более целостная получается модель.
Организация приёмки ПО с целью недопущения недостатков кода ПО перед его предоставлением пользователям.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S.
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.
Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.
Разработчикам программного обеспечения средств защиты информации рекомендуется использовать положения настоящей Методики для организации внутренних процессов жизненного цикла программного обеспечения в соответствии с ГОСТ Р 56939-2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования".
Разработка WMS и логика склада: интервью с основателем INTEKEY
Разрабатывать систему управления складом сложно, если команда не знает, как склад работает в реальности.
На канале TransRussia Connect вышло небольшое интервью с Денисом Сумелевым, основателем компании INTEKEY. Поговорили о специфике отрасли: как разработка софта пересекается с физической логистикой.
О чем идет речь в видео: — Зачем ИТ-компании держать в штате 90% бывших директоров складов. — Почему перед внедрением программы нужно пересобрать логистические процессы руками. — Как выстраивать систему внутри самой ИТ-компании, чтобы автоматизатор не был «сапожником без сапог».
Сейчас по всем моим проектам записано более 10К задач. Если выполнять по одной задаче каждый день, то мне понадобится 30 лет, чтобы выполнить все эти задачи. Но когда я делаю задачу, мне приходят идеи и я записываю еще несколько новых задач. Мой список задач никогда не закончится, наоборот, количество задач в нем увеличивается каждый день.
Записанная задача не значит, что её обязательно нужно выполнить, она просто разгружает мозг. При записи я не трачу время на установку приоритетов и сроков. Пришла идея, сразу сохранил в файл, и больше не думаю о ней.
Выход на европейский рынок: 6 паттернов поведения покупателей которые ломают домашнюю бизнес-модель
6 паттернов поведения покупателей в Европе, которые ломают домашнюю бизнес-модель
Инструменты маркетинга в Европе и на домашнем рынке одинаковые: реклама, воронка, контент. Но модели поведения покупателей различаются системно — и это обнаруживается только через реальные проекты, а не кабинетный анализ.
По данным РБК, главная причина провала при выходе на международный рынок в 2026 году — вера в универсальность домашней бизнес-модели.
Шесть паттернов из реальных проектов в Нидерландах, Польше, Италии и Испании.
Паттерн 1: скидка как сигнал низкого качества
На домашнем рынке скидка — стандартный acquisition-оффер. В ряде западноевропейских стран тот же оффер снижает конверсию.
Домашний рынок:
скидка → выгода → рост конверсии
Западная Европа (ряд ниш):
скидка → экономия на составе → падение доверия
Бренд кормов для животных, запуск с нулевой базы. Стандартный скидочный оффер — результат близкий к нулю. После замены на «прозрачность состава + сертификация ингредиентов»: 21 лид в первый месяц.
Один продукт (профессиональная косметика), две страны, два разных customer journey. Раздельные стратегии под каждый рынок: рост продаж ×10 за 4 года.
Паттерн 3: длинный цикл принятия решения
По данным Cossa.ru, маркетинг в Европе 2026 года требует 5–7 точек контакта перед конверсией.
Домашняя модель: реклама → покупка (1-2 касания)
Европа (premium/handmade): реклама → наблюдение →
изучение → возврат × N → покупка (5-7+ касаний)
Мастер по изделиям ручной работы, итальянский рынок. Воронка под прямую продажу — менее 500€/мес. После перестройки под длинный цикл: 4 000€/мес.
Паттерн 4: другие точки доверия
Польша (локальный бизнес):
Google Maps + локальные платформы отзывов > соцсети
Западная Европа (продукты питания):
состав + сертификаты > скидки + промо
Цветочный магазин в Польше. Переработка под локальные точки доверия (отзывы, фото реальных букетов, гарантия свежести с конкретным сроком): 191 заказ в месяц.
Паттерн 5: нишевые каналы без конкуренции
На насыщенных домашних рынках большинство каналов перегреты. На европейских — нишевые каналы с минимальной конкуренцией в конкретной категории встречаются значительно чаще.
Пример: $100 бюджет → $550 выручки за неделю → ROMI 450%. Канал не очевиден при кабинетном анализе — обнаруживается через исследование конкурентной среды в целевой стране.
Паттерн 6: конкурентная среда не совпадает с домашней
Предварительная конкурентная разведка в целевой стране — обязательный шаг до запуска рекламы.
Чеклист до запуска бюджета
1. Google Maps целевого города →
как конкуренты работают с отзывами
2. Локальные профсообщества по нише →
реальные триггеры покупателей
3. Тест оффера на культурное соответствие →
скидка, срочность, социальное доказательство
работают по-разному в разных странах
Какие паттерны поведения покупателей вы обнаруживали при выходе на зарубежные рынки — совпадало ли это с ожиданиями?
После созвонов договоренности часто теряются — и хорошо, если осталась запись встречи или кто-то из коллег параллельно вел заметки.
Но даже в таких случаях приходится искать информацию в чатах, заметках и записях встреч, чтобы заново собрать общую картину и вспомнить, на чем в итоге остановились. Если в работе еще и несколько проектов, на ручной поиск начинает уходить слишком много времени.
Поэтому часть этой рутины мы решили автоматизировать с помощью ИИ. Как это работает и что важно учитывать — рассказал Константин, специалист по ИИ в Naumen.
Ассистент работает с материалами встреч напрямую
Мы подключили ассистента к материалам встреч в Контур Толк через MCP. Поэтому теперь не нужно искать транскрипции и вручную передавать их в языковую модель для обработки.
Например, достаточно спросить:
«Что было на встрече с командой X?»
Ассистент: «Обсуждали запуск новой функции, договорились подготовить прототип до пятницы».
«Какие договоренности зафиксировали по проекту?»
Ассистент: «Команда согласовала сроки и распределила зоны ответственности».
«О чем говорили на последнем созвоне?»
Ассистент: «Обсуждали проблемы интеграции и дальнейшие шаги по проекту».
Часть итогов сотрудники сохраняют для себя, часть — остается доступной всей команде. Это помогает командам быстрее синхронизироваться по решениям, открытым вопросам и текущему контексту проекта.
Важно: ИИ не заменяет человека
Транскрипции могут содержать ошибки: речь не всегда разборчива, поэтому неточности иногда появляются и в итогах встречи. Важные договоренности мы все равно проверяем вручную.
Но даже с учетом этого искать нужную информацию стало проще — особенно когда встреч и обсуждений много.
Маркетинговая стратегия за 5 000₽ или за 5 000€: в чём разница с точки зрения данных
Один кейс который объясняет разницу лучше любой теории.
Маркетинговая стратегия за 5000 рублей vs 5000 евро - разница в данных. Расчёт: 300 000₽ бюджета, результат 0, причина - не считали ёмкость рынка до запуска.
Салон красоты, бюджет 300 000₽, результата нет. Открываем Яндекс.Карты: в радиусе одного километра - 47 конкурентов.
Простой расчёт который не сделали до запуска:
Население района: 30 000 чел
Ходят на маникюр (5%): 1 500 чел
На 48 салонов: 31 потенциальный клиент/мес
При конверсии 10%: нужно 310 лидов
Стоимость лида: 300–1 000₽
Бюджет для окупаемости: 93 000–310 000₽
Выручка при этом: 108 000₽ (31 × 3 500₽)
До вычета аренды, зарплаты, материалов
Итог: реклама физически не могла окупиться. Расчёт занял 20 минут. До запуска его не сделали.
Четыре уровня - четыре разных продукта
Стоимость маркетинговой стратегии варьируется от 5 000₽ до 5 000€. Это не разброс цен на одну услугу - это четыре разных продукта.
По данным Kadrof.ru, средний час работы маркетолога в агентстве - 1 900₽. Делите цену КП на 1 900 — получаете реальное количество часов:
Если за 26 часов обещают провести интервью с покупателями, проанализировать 15 конкурентов и рассчитать юнит-экономику — физически невозможно.
Уровень 1: фрилансер 5–30К₽
→ 1 чел, 2-4 дня
→ документ 10-15 стр: аудитория «из головы»,
список каналов, общие рекомендации
→ расчёта окупаемости нет
Уровень 2: базовое агентство 50–150К₽
→ 25–80 часов
→ SWOT, обзор рынка, медиаплан
→ кастдев — зависит от агентства
Уровень 3: методология 200–500К₽
→ 100–250 часов, 8 этапов
→ карта пути покупателя, сегментация
→ кастдев чаще да, прогноз примерный
Уровень 4: ИИ-аналитика от 2 100€
→ 10–15 интервью с реальными покупателями
→ 15–20 конкурентов с бюджетами и слабыми местами
→ точный расчёт окупаемости с прогнозом
→ нейросеть обрабатывает интервью за 40 мин
вместо 2 дней ручной работы
Разница которую видно только в данных
Стоматология, имплантация. Блок «целевая аудитория» на двух уровнях.
Уровень 3 — кабинетный анализ:
«Мужчины и женщины 30-55 лет, средний доход,
ценят качество и безопасность»
По этому описанию - одно объявление для всех. Одно объявление для всех = отсутствие сегментации.
Уровень 4 — 12 интервью с пациентами + ИИ:
Сегмент 1 (42%): женщины 45-60
→ страх: боль и осложнения
→ цикл решения: 2-6 месяцев
→ триггер: видео с врачом
Сегмент 2 (27%): мужчины 35-50
→ страх: «затянется на полгода»
→ цикл: 1-3 недели
→ триггер: план «3 визита — готово»
Сегмент 3 (18%): выбирают для родителей 70+
→ страх: «маме будет тяжело»
→ триггер: кейс с пациентом того же возраста
Три объявления, три лендинга, три скрипта для администратора. Результативность рекламы при такой сегментации — в 2–3 раза выше при том же бюджете.
Три сценария без стратегии
По данным Brand Analytics, 60% поисковых сессий в 2026 году заканчиваются без перехода на сайт - нейросеть отвечает сама и называет конкретные компании.
Сценарий 1: карусель подрядчиков
→ каждые полгода новый маркетолог с нуля
→ каждый повторяет ошибки предыдущего
→ проблема не в руках, а в отсутствии системы
Сценарий 2: бюджет растёт, отдача падает
→ 200К₽ → 100 заявок
→ 400К₽ → те же 100 заявок
→ без стратегии единственный ответ:
увеличивать бюджет
Сценарий 3: клиенты уходят в нейровыдачу
→ 60% сессий без перехода на сайт
→ нейросеть называет конкурентов
→ критично для: стоматология, строительство,
недвижимость, юруслуги
По данным АКАР 2025, стоимость стратегических маркетинговых услуг за год выросла на 35%.
Итог: Документ за 5 000₽ и документ за 5 000€ в день получения выглядят похоже. Разница проявляется через полгода в отчёте о продажах. Один вопрос для проверки любого подрядчика до подписания договора: «Сколько реальных интервью с нашими покупателями вы проведёте перед запуском рекламы?»
Если ответ «нет, опишем аудиторию на основе открытых данных» - стратегия будет основана на предположениях. Не на данных.
РБПО по ГОСТ Р 56939—2024: вебинар №19 из 30 — Нефункциональное тестирование
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.19. – "Нефункциональное тестирование". На YouTube. Слайды.
Цели 19-го процесса по ГОСТ Р 56939—2024:
Подтверждение того, что поверхность атаки, модель угроз и архитектура ПО содержат необходимую информацию.
Обнаружение недостатков программы путём выполнения нефункциональных тестов, в том числе имитирующих действия потенциального нарушителя.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S.
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.
Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.
От гипотез до операционки: открытые уроки для IT‑руководителей и менеджеров
Управление в IT — это давно не только «поставить задачи и проверить статус».
Сейчас от менеджера ждут большего: понимать экономику решений, говорить с бизнесом на одном языке, проверять гипотезы быстрее, видеть узкие места в процессах и не терять команду по дороге.
Собрали открытые уроки OTUS по управлению, продукту, процессам и работе с командами.
Продукт и клиентские исследования
3 июня, 19:00 — «Про кастдевы с интерактивом / исследование потребителей в теории и на практике». Записаться На уроке поговорим о том, как исследовать аудиторию не «для галочки», а чтобы находить реальные инсайты для продукта.
17 июня, 19:00 — «Как продакту проверять гипотезы быстрее с помощью AI». Записаться Покажем, как использовать AI для ускорения продуктовой работы: от формулировки гипотез до проверки идей.
Операционка и эффективность
4 июня, 20:00 — «Операционная эффективность в IT: как находить скрытую прибыль в процессах разработки». Записаться Разбор о том, где команда теряет время, деньги и управляемость — и как это увидеть в процессах.
18 июня, 20:00 — «Операционный директор в IT: компетенции, которые превращают хаос в систему». Записаться Урок о том, какие навыки нужны руководителю, чтобы выстраивать процессы, а не постоянно тушить пожары вручную.
Бизнес, стейкхолдеры и ценность
2 июня, 20:00 — «Цепочки создания ценности: моделирование, анализ, проектирование». Записаться Поговорим о том, как смотреть на процессы через ценность для бизнеса, а не только через задачи, статусы и регламенты.
17 июня, 20:00 — «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться Разберем, как работать с ожиданиями разных сторон и выстраивать нормальную коммуникацию между бизнесом и командой.
Финансовое мышление руководителя
3 июня, 20:00 — «От хаоса к контролю: как построить финансовую модель, которой можно верить». Записаться Полезно, если нужно принимать решения не на ощущениях, а на понятной модели с цифрами.
17 июня, 20:00 — «Как убрать "человеческий фактор" из финансовых моделей: от расчёта NPV до сложных систем оплаты труда». Записаться Разбор про финансовые модели, планирование, оплату труда и управленческую аналитику.
Переход в роль руководителя
16 июня, 20:00 — «От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу». Записаться Урок для специалистов, которые переходят в тимлиды или уже управляют командой и чувствуют, что одной технической экспертизы уже недостаточно.
AI в управлении и автоматизации
3 июня, 20:00 — «Как измерить рост производительности команды от внедрения ИИ». Записаться Обсудим, как оценивать эффект от AI‑инструментов без магического мышления и красивых, но бесполезных метрик.
16 июня, 20:00 — «AI‑ассистент отдела без кода: как найти рутину, собрать рабочий сценарий и посчитать экономию времени». Записаться Практичный урок для руководителей, которые хотят автоматизировать повторяющиеся задачи без отдельной команды разработки.
Все уроки бесплатные, проходят онлайн в рамках курсов OTUS и проводятся преподавателями‑практиками. Можно познакомиться с экспертами, протестировать формат обучения и задать вопросы по своей ситуации.
Если хотите системно прокачать управленческие навыки, посмотрите каталог курсов по управлению: там есть программы для проджектов, продактов, тимлидов, delivery‑менеджеров, операционных директоров и руководителей в IT.
А ещё подписывайтесь на канал OTUS в MAX — там публикуем анонсы открытых уроков, полезные материалы и подборки для IT‑специалистов и руководителей.
Как выбрать маркетинговое агентство: семь вопросов которые проверяют работает ли подрядчик с данными или с предположениями
Только в Москве зарегистрировано более 595 маркетинговых агентств. Коммерческие предложения у всех выглядят примерно одинаково. Разница проявляется через 3–6 месяцев когда открываешь отчёт о продажах.
Ниже - семь вопросов которые позволяют оценить подрядчика за один созвон до подписания договора.
Вопрос 1: что сделаете в первые две недели?
Тип А: «Настроим рекламу и запустим»
→ инструменты без данных
Тип Б: «Аудит → исследование аудитории
→ конкурентный анализ
→ юнит-экономика → план»
→ данные до инструментов
Производитель душевых перегородок, конверсия 23%. Предыдущий подрядчик запустил рекламу без анализа - конверсия не менялась при стабильном трафике. После исследования аудитории и переработки офферов: конверсия 49%, выручка $284 458 за 8 месяцев при том же бюджете.
Вопрос 2: что стоит первым в отчёте?
Плохой сигнал: охваты, подписчики, вовлечённость
Хороший сигнал: CAC, заявки по каналам, ROMI
Минимум в отчёте:
1. CAC
2. Заявки по каждому каналу
3. ROMI
Салон красоты с растущими охватами и стагнирующей выручкой. При аудите — все кампании оптимизированы под показы, ни одно объявление не ведёт к записи. После перестройки: $10 000 → $18 400 за 2 месяца, 508 заявок, 184 новых клиента.
Вопрос 3: сколько интервью с нашими реальными покупателями проведёте?
Большинство агентств описывают аудиторию на основе опыта в нише и открытых данных. Ни один из этих источников не объясняет почему конкретный человек выбирает ваш продукт а не конкурента.Мастер по наращиванию волос, 4–5 записей в месяц. После 8 интервью с реальными клиентками обнаружено два сегмента с разными мотивациями. Два оффера, два объявления. Результат: 19–21 запись в месяц, средний чек +25–30%.
Вопрос 4: сколько гипотез протестируете в первый месяц?
eSIM-приложение:
Кампания клиента (все интересы в одной):
$53.18 за установку
Наши три гипотезы:
Гипотеза 1 (тематика «путешествия»):
$25.02 → отключили
Гипотеза 2 (Skyscanner, Airbnb, Booking):
$96.67 → отключили за 1.5 дня
Гипотеза 3 (Advantage+ путешественники):
$10.77 → масштабировали
Разница на 1 000 установок: $42 410
Вопрос 5: что будете делать с существующей базой?
Агентства оптимизированы под привлечение. Но для бизнеса с повторными покупками LTV существующего клиента в 3–7 раз дешевле в обслуживании чем привлечение нового.
Минимум работы с базой:
- Сегментация по RFM
- Реактивация ушедших сегментов
- Система допродаж
Если ответ «только привлечение» — агентство закрывает половину задачи.
Вопрос 6: сколько часов работы стоит за ценой КП?
~1 900₽ — средний час маркетолога (Kadrof.ru)
50 000₽ ÷ 1 900 = 26 часов
150 000₽ ÷ 1 900 = 79 часов
300 000₽ ÷ 1 900 = 158 часов
Если за 26 часов обещают кастдев + анализ 15 конкурентов + юнит-экономику + стратегию — физически невозможно. Что-то будет сделано формально.
Вопрос 7: работаете с присутствием бренда в ответах нейросетей?
По данным Brand Analytics, 60% поисковых сессий в 2026 году заканчиваются без перехода на сайт. Для B2C с высоким чеком и длинным циклом принятия решения это означает что часть клиентов принимает решение о звонке конкурентам ещё до попадания на ваш сайт.
Проверка за 2 минуты:
1. Открыть ChatGPT
2. Спросить: «Порекомендуй [ниша]
в [город]»
3. Если вас нет в ответе — измеримая
потеря потенциальных клиентов
Итог
Вопрос 1: данные до инструментов или нет
Вопрос 2: метрики в деньгах или в охватах
Вопрос 3: реальные покупатели или предположения
Вопрос 4: тестирование гипотез или «проверенная связка»
Вопрос 5: полный цикл или только привлечение
Вопрос 6: часы соответствуют обещаниям или нет
Вопрос 7: учитывает AI-поиск как канал или нет
Задайте эти вопросы трём-четырём агентствам подряд — разница в ответах покажет уровень подрядчика точнее чем изучение кейсов на сайте.
Интересно услышать в комментариях: какие из этих критериев вы проверяете при выборе подрядчиков?
SAP, Oracle, Palantir и другие корпоративные гиганты строят вокруг ИИ семантические слои: knowledge graph, ontology, process intelligence. Разбираемся, почему языковой модели недостаточно просто читать документы и таблицы.
Языковая модель умеет читать документы, таблицы, обращаться к API. Казалось бы, достаточно для корпоративного ИИ. Но SAP, Oracle, Palantir, Celonis, Alibaba и Yonyou активно строят семантические слои поверх данных: графы знаний, онтологии, process intelligence, платформы агентов.
Причина простая: корпоративному ИИ нужен не просто доступ к данным. Ему нужен смысловой слой предприятия — термины, объекты, экземпляры, статусы, источники, связи и правила качества. Без этого система остаётся набором отдельных функций, а не инструментом для комплексных управленческих решений.
Что такое семантическое ядро и зачем оно
Семантическое ядро — это структурированное описание бизнес-логики компании. Не просто схема базы данных, а модель того, как устроены процессы, как связаны объекты, какие правила определяют качество данных и переходы состояний.
Примеры таких слоёв, как сообщают SAP и Oracle:
Knowledge graph — граф связей между сущностями бизнеса: клиенты, заказы, продукты, поставщики.
Ontology — формальное описание терминов и отношений: что такое «заказ», какие у него могут быть статусы, как он связан с накладной.
Process intelligence — карта фактических бизнес-процессов, извлечённая из логов систем: как реально движутся заявки, где возникают узкие места.
Agent memory — контекст для агентов: что они уже делали, какие решения принимали, какие данные использовали.
Без семантического слоя ИИ-агент видит таблицы и документы, но не понимает бизнес-правил. Он может извлечь данные из накладной, но не знает, что делать, если сумма не сходится с заказом. Он может найти клиента в CRM, но не понимает, что этот клиент в чёрном списке.
Как это работает на практике
SAP строит Business Data Cloud — единый семантический слой поверх разрозненных систем учёта. Oracle развивает граф знаний для своих облачных приложений. Palantir предлагает онтологию как основу для агентных систем в Foundry. Celonis использует process mining для извлечения фактической логики процессов из event logs.
Типичный сценарий: ИИ-агент обрабатывает заявку на возврат. Без семантического ядра он видит запись в таблице. С семантическим ядром он знает:
Заявка связана с заказом, который уже частично оплачен.
Товар числится на складе, но фактически уже отгружен другому клиенту.
Клиент имеет статус VIP, что меняет правила возврата.
Есть открытый тикет в поддержке с похожей проблемой.
Агент не просто достаёт данные из разных систем. Он понимает контекст, проверяет правила и предлагает решение, учитывая бизнес-логику.
Ограничения и подводные камни
Построение семантического ядра — дорого и медленно. Нужно формализовать бизнес-процессы, навести порядок в терминологии, связать разрозненные системы. По данным Gartner, большинство проектов знаний графов застревают на этапе пилота.
Второй риск — vendor lock-in. SAP, Oracle и Palantir строят закрытые платформы. Переход на другую систему означает переписывание онтологий и правил с нуля.
Третье — актуальность. Бизнес меняется быстрее, чем обновляется онтология. Если семантический слой не синхронизирован с реальностью, ИИ-агент будет принимать решения на основе устаревших правил.
Что это меняет
Семантическое ядро превращает корпоративный ИИ из набора умных функций в систему, способную действовать автономно в рамках бизнес-правил. Агент не просто отвечает на вопросы — он выполняет задачи, проверяя контекст и соблюдая ограничения.
Это не революция, а эволюция корпоративных систем. Те, кто инвестировал в порядок данных и формализацию процессов, получают преимущество. Остальные застрянут на этапе экспериментов с чат-ботами.
Негативный фидбек: как говорить правду, не сломав человека
«Сэндвич» не работает. Анонимные опросы врут. А честный разговор с руководителем кажется карьерным суицидом. Но без негативной обратной связи команды не растут — и все об этом знают.
В новом выпуске «Свободного слота» разбираем, как всё-таки давать критику так, чтобы её слышали, а не просто вежливо кивали. В гостях — Илья Барбашов, руководитель юнита Platform Experience в Авито.
Что обсудили
Почему нельзя просто взять и выдать обратную связь — и что нужно сделать сначала. Как говорить с руководителем честно и не бояться за репутацию. Когда анонимный фидбек лучше прямого — и наоборот. Как не сломать сотрудника критикой и можно ли вообще её оспорить. И как готовиться к встрече с разбором ошибок: с повинной головой или с готовым планом.
Бонус: в конце выпуска ведущие сами принимают «развивающую» обратную связь от слушателей. Вживую и без купюр.
От B2B-продаж к международному IT-продукту: про смену майндсета, антикризисный менеджмент и работу с партнерами по всему миру — Влад Стоянов в подкасте «Привет, касатики»
В гостях у Жени Ившина и Лены Соколовой наш Product Lead рассказал про свой нестандартный карьерный путь и то, как устроена работа с международным партнерским IT-продуктом изнутри.
> как 10 лет в продажах привели Влада к желанию влиять на сам продукт, а не продавать его вопреки его недостаткам;
> почему в Garage Eight ценят тех, кто готов сказать «это можно сделать лучше» и не боится это отстаивать;
> чем партнер из Бразилии отличается от партнера из Юго-Восточной Азии и как это влияет на продукт;
> как выстроить стейкхолдер-менеджмент, когда результат виден не сразу, а через несколько кварталов;
> почему тушить пожары своими руками — это путь к выгоранию, а не к системному бизнесу;
> как вытащить команду из выгорания и почему иногда для этого нужно отпустить людей в другие направления.
Мы Garage Eight верим, что результат — это не выпущенная фича, а подтвержденное влияние на бизнес и пользователей. Если откликается наш майндсет, присылай свое CV через форму фаст-трек на сайте.
ИИ и LLM уже впечатляют: они помогают быстрее исследовать идеи, писать черновики кода, генерировать визуальные концепты и ускорять прототипирование. Но для серьезной production- разработки они все еще недостаточно надежны. Особенно там, где ошибка стоит дорого: CAD, BIM, инженерные расчеты, безопасность, инфраструктура, финансы, медицина.
Модель может уверенно выдать неверный ответ, пропустить важное ограничение, создать красивый, но технически неправильный артефакт или не заметить дефект в собственном результате. Поэтому сегодня AI лучше рассматривать не как автономного инженера, а как усилитель для человека и инструмент быстрых итераций. Нужны проверки, тесты, валидация, воспроизводимые артефакты и ответственность специалиста.
Но направление вроде vibeCAD выглядит перспективно. Если объединить генерацию с параметрическими CAD-инструментами, расчетами, проверками коллизий, экспортом STEP/GLB, визуальной валидацией и строгими evidence-gates, то в будущем AI сможет стать реальной частью инженерного workflow. Не магией, а дисциплинированной системой проектирования.
Я сомневаюсь не только при выборе решения, но и после него. Опубликовал пост, на следующий день уже хочу поменять формулировки в нем. Поставил неперспективный проект на паузу, через месяц хочу продолжить разработку. Придумал крутое название для продукта, зарегистрировал домен, занял ники в социальных сетях, через неделю мне это название уже не нравится. Опубликовал эссе, через год хочу удалить, чтобы его больше никто не видел.
Независимо от количества часов, потраченных на обдумывание и принятие решения, сомнения не исчезнут. Я просто принимаю решения с мыслью, что в будущем я могу быть с ними уже не согласен.
Как выйти из кризиса перегрузки без найма: опыт двухнедельного Stop the Line
Команда тонет не когда задач много, а когда поток работы не соответствует пропускной способности. Разбираю на примере условного «ФинТеха», как двухнедельная остановка конвейера возвращает управляемость без расширения штата.
Типичная картина: дедлайны не двигаются, найм заморожен, техдолг растёт, инциденты множатся, люди выгорают. Первая реакция — «давайте ускоримся ещё сильнее». Это только усугубляет кризис.
Проблема не в скорости разработки, а в том, что система перестала справляться с объёмом параллельных задач. Когда в работе одновременно 20 фич, а команда реально может закрыть 5 в спринт — каждая задача тормозит остальные. Контекстные переключения съедают до 40% времени, код-ревью затягиваются, интеграция превращается в русскую рулетку.
На практике видел это десятки раз. Компания вводит «режим ускорения»: сокращает ревью, откладывает рефакторинг, пилит MVP параллельно с production-фиксами. Через месяц скорость не растёт — падает. Команда тушит пожары вместо того, чтобы делать продукт.
Что даёт Stop the Line
Двухнедельная остановка конвейера — это не каникулы. Это хирургическое вмешательство: временно прекращаешь приём новых задач и закрываешь то, что уже в работе. Параллельно команда разгребает техдолг, который мешает двигаться дальше: чинит CI/CD, актуализирует документацию, закрывает критичные уязвимости.
Ключевой момент — это не просто «месяц на техдолг». Это сознательное решение восстановить пропускную способность. За две недели команда из условного «ФинТеха» может:
Закрыть 15 из 20 зависших фич — вместо того чтобы держать их в работе ещё месяц
Разобрать backlog инцидентов и понять, какие из них — симптомы одной проблемы
Автоматизировать то, что отнимает 2-3 часа в день у каждого разработчика
Обновить зависимости, которые тянут за собой уязвимости и блокируют миграцию на новые версии
После Stop the Line команда не становится быстрее в два раза. Но она возвращает управляемость: понятно, сколько задач реально можно взять в спринт, какие риски несут новые фичи, где узкие места. Вместо хаоса — предсказуемый поток.
Как продать это бизнесу
Главный вопрос от менеджмента — «мы потеряем две недели разработки». Нет. Вы потеряете две недели добавления новых задач в очередь, но выиграете месяцы на выходе из болота. Показывай цифры: сколько фич завершено за последние два спринта, сколько инцидентов повторяются, сколько времени уходит на переключения между задачами.
Опыт показывает: после Stop the Line скорость delivery возвращается к нормальной в течение месяца, а качество выходит на новый уровень. Главное — не скатываться в ту же воронку снова. Установить WIP-лимиты, внедрить метрики cycle time, договориться с бизнесом о реалистичных планах.
Ограничение подхода — он работает, если команда ещё не выгорела окончательно и проблема в процессах, а не в людях. Если половина уже ищет новую работу — Stop the Line не спасёт. Но если команда готова работать, просто задыхается под грузом — это работает.
В информационной безопасности невозможно исключить все угрозы и любая инфраструктура может стать целью злоумышленников: целевые компрометаций через уязвимости, подрядчиков или, например, сотрудников. В связи с этим компании определяют, какой уровень риска они готовы принять (толерантность), и как будут управлять этими рисками (риск менеджмент).
Толерантность - это допустимый уровень угроз и потенциального ущерба, который организация готова принять или, другими словами, насколько опасные сценарии для бизнеса считаются приемлемыми. Обычно Толерантность делят на 3 типа: высокая, средняя и, соответственно, низкая.
При низкой толерантности компании практически не допускают критических угроз: жесткий контроль доступов, постоянный мониторинг, сегментация сети, обязательный MFA, минимальные привилегии, строгие политики безопасности, быстрое реагирование на инциденты и т.д. Обычно это характерно для банков, государственных структур и критической инфраструктуры.
Высокая толерантность означает, что организации (обычно малый бизнес или проекты без зрелой ИБ) готовы принимать значительные риски ради скорости развития, снижения затрат или упрощения процессов. При таком виде толерантности характерен слабый контроль доступа, отсутствие сегментации, редкие аудиты, устаревшие системы и другие пренебрежения информационной безопасности (если она вообще существует в организации).
Ну а средняя толерантность говорит сама за себя - это уровень принятия ИБ где-то между: допускается принятие части рисков ради удобства, скорости работы или экономии ресурсов.
Риск-менеджмент - это процесс управления рисками информационной безопасности. После оценки угроз организация выбирает один из вариантов обработки риска:
Принятие риска (Risk Acceptance)
Отказ от риска (Risk Avoidance)
Митигация риска (Risk Mitigation)
Передача риска (Risk Transfer)
Принятие риска - это когда компания осознанно принимает риск и ничего не меняет. Например уязвимость имеет низкую вероятность эксплуатации (likelihood), устранение слишком дорого (cost-benefits analysis) или ущерб считается приемлемым. Отказ от риска - когда организация полностью убирает/устраняет источник риска. Например, отключение небезопасного сервиса, отказ от хранения персональных данных или закрытие внешнего доступа (часто OWA). Митигация риска (Risk Mitigation) - наиболее распространенный подход, когда компания снижает вероятность атаки или уменьшает последствия компрометации. Передача риска (Risk Transfer) - когда риск частично передается третьей стороне, например в применяется страхование, использование облачных провайдеров; аутсорсинг SOC или передача ответственности подрядчику.
Кроме локальной нормативной базы, которые регулируют некоторые критические сегменты, например ПДн или КИИ, компании вправе самостоятельно выбирать допустимость угроз и управление рисками. Однако, говоря про международные стандарты, нельзя не затронуть ISO/IEC 27005:2022 - Руководство по управлению информационной безопасностью, которое описывает идентификацию угроз, анализ рисков, оценку последствий, методы обработки рисков, подходы к принятию решений и другие вопросы риск-менеджмента. А Российский ГОСТ на базе ИСО 27005:2010 можно почитать в Электронном фонде правовых и нормативно-технический документов.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
ИИ фри пост. Весь habr и linkedin стал пестрить людьми с AI в должности. Почти каждый стал AI Product Manager, даже если просто использует ChatGPT с дипресерчем и 1 функция вызывает Gemini Flash 2.5 по апи
Естественно начинают появляться курсы по Claude Code для продактов, вайбкодинг для нетехнарей и тд. Но у меня интерес не об этом. Мне любопытно видите ли вы спрос от работодателей на найм всех этих AI Inspired сотрудников? Не AI Engineer/DS/MLe/SWE для обвязки, а именно сопровождающих? Или мы наблюдаем новое переобуваение из Project Management/Agile/Product Management/Strategy/OKR (подчеркните для себя что застали).
Узнай, как AI сегодня меняет продукты и процессы, от спикеров митапа Garage Eight
Высшая лига по цене дворового футбола: как ИИ-агенты делают технологии разработчиков доступными Спикер: Михаил Никишин, основатель школы прототипирования с ИИ — Startend․ru, ex-Product Lead Спортмастер YouTube | VK Видео
AI-агенты в исследованиях: как не потерять в качестве, но выиграть в скорости Спикер: Евгений Вечирко, продуктовый маркетолог в Первый Бит, основатель AI club SPb YouTube | VK Видео
Стратегический ИИ = ИИ ⊕ OKR. Шесть месяцев управления агентством по этой формуле
Последние шесть месяцев я управляю «Ксентрой» вместе с ИИ-партнёром. Система обрела форму, которую проще всего описать коротким уравнением: стратегический ИИ равен ИИ плюс OKR. Не ИИ как слой над OKR, не OKR, управляемые ИИ, — а пара, где каждая сторона закрывает пробелы, которые другая не может закрыть самостоятельно.
Этот пост — краткий анонс более объёмной статьи, которую я готовлю. В ней я расскажу об архитектуре, структуре файлов и реальных ограничениях этого подхода. Прежде чем публиковать полную версию, я хочу проверить тезис на аудитории Habr и собрать вопросы, на которые стоит дать развёрнутые ответы.
В чем преимущество ИИ ⊕ OKR
Работать с OKR не так просто, как кажется. Выбрать амбициозные, но реализуемые цели — это искусство. Нужно выбрать ключевые результаты, которые измеряют эффект, а не активность. Поддерживать еженедельный ритм так, чтобы он не превращался в отчёты о статусе. На каждом шаге есть нюансы, которые легко упустить, когда ты внутри ежедневной операционки.
Стратегический ИИ без OKR уходит в другую крайность. Без измеримой цели всё сводится к общим тезисам, оторванным от действительности. Соглашательство моделей (сикофансия) — реальный риск, особенно при обсуждении стратегии.
Вместе OKR и ИИ усиливают друг друга. OKR задаёт ИИ измеримую цель. ИИ добавляет OKR глубину и подталкивает к движению вперёд на каждом шаге.
Что ИИ делает на каждом этапе цикла OKR
Цикл остаётся таким же, как в любой классической реализации OKR. Меняется то, что происходит на каждом этапе.
На этапе постановки целей ИИ предоставляет рыночные данные, внутренние сигналы из текущего спринта, список рисков и возможностей, которые основатель мог упустить за неделю. Амбициозность проверяется на прочность и реалистичность.
На этапе определения ключевых результатов ИИ переводит формулировки с входных метрик на метрики результата. «Опубликовать 20 статей» превращается в «20 целевых консультаций из органики». Только вторая формулировка отвечает на вопрос: «Имело ли это значение?» Ключевые результаты, измеряющие итог, сложнее сформулировать и достичь, но только они отражают бизнес-эффект.
На еженедельной сверке ИИ анализирует свежие данные, заранее выявляет отклонения и определяет их природу: проблема исполнения, стратегии или изменения внешней среды? Именно такой анализ позволяет обнаружить проблему на второй неделе цикла, а не на третьем месяце при анализе результатов.
На ретроспективе и этапе корректировки ИИ предлагает, что убрать, где удвоить ставку, куда сделать разворот. Без привязки к уже вложенным ресурсам и без операционной спешки, которая часто заставляет нас придерживаться прошлых неэффективных решений.
Что под капотом
Инфраструктура достаточно проста. Никаких векторных баз, своих бэкендов и проприетарных рантаймов. Claude Code как среда, markdown-файлы в Git-репозитории — для устава, контекста и доменных знаний. Файлы навыков работают как slash-команды. Файлы критиков — для проверки качества.
Пара вопросов к вам
Что сейчас служит основой для принятия стратегических решений? Мне интересно, используете ли OKR, какие инструменты ИИ работают на стратегическом уровне, формализованы ли как-то процессы на этом уровне, и какие еще вопросы стоит подробно раскрыть в полной статье.
Полная статья об архитектуре, цикле OKR и проблемах должна появиться в течение пары недель.
Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта
Иногда задают вопрос: "Как статический анализ ускорит Time to market?"
Никак. Статический анализатор не ускорит выход продукта/обновления на рынок. С ним будет дороже и медленнее. Причина — неправильный вопрос.
Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.
Но про тестирование, в отличии от статического анализа, такой вопрос не задают. Все понимают, что тестирование — важный элемент создания ПО. Видимо, статический анализ — более молодая методология по сравнению с тестированием, и он просто ещё не стал неотъемлемой частью разработки. Хотя видится очевидным, что и то, и другое неразрывно связано с обеспечением необходимого качества создаваемых программных продуктов.
Какой вопрос правильный?
Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?
Другое дело. Если нужно выпустить качественный продукт, то статический анализ может выявить многие ошибки и дефекты безопасности быстрее и дешевле, чем другие методы. Некоторые виды дефектов лучше обнаруживаются статическим анализатором кода, чем юнит-тестами, динамическим анализом, ручным тестирование и так далее.
Впрочем, это свойство и других методик. Есть дефекты, которые наиболее эффективно будут обнаруживать юнит-тесты, поэтому профессиональные разработчики не пытаются выбрать какой-то один подход, а используют сразу несколько. Эти разные меры усиливают друг друга.
Статический анализ применяется на этапе конструирования, то есть написания кода, поэтому позволяет устранить многие ошибки ещё до этапа тестирования. Хотя на анализ предупреждений необходимо тратить время, это окупается сокращением числа дефектов, которые выявляются на других этапах проверки продукта и его эксплуатации. Известно, что чем раньше ошибка найдена, тем дешевле её исправление.
Когда требований много, а ясности мало: 10 уроков для аналитиков
У системного и бизнес‑аналитика часто ломается не один навык, а весь маршрут: бизнес формулирует задачу через боль, разработка ждёт точных сценариев, стейкхолдеры спорят о приоритетах, а требования распадаются на противоречивые документы, схемы и комментарии в тасках.
Собрали 10 открытых уроков, которые помогают пройти этот путь по порядку: от понимания бизнес‑задачи до процессов, объектной модели, архитектурного языка и согласования решений.
Подборка подойдёт бизнес‑аналитикам, системным аналитикам, продактам, тимлидам и всем, кто работает с требованиями, процессами, интеграциями и постановкой задач для разработки.
1. Сначала понять бизнес‑модель
Если не ясно, как продукт создаёт ценность, требования быстро превращаются в список пожеланий.
21 мая, 20:00 — «Формирование бизнес‑модели продукта на примере Business Model Canvas». Записаться
2. Проверить проблему через пользователей
Кастдев помогает отличать реальную потребность от мнения самого громкого стейкхолдера.
3 июня, 19:00 — «Про кастдевы с интерактивом / исследование потребителей в теории и на практике». Записаться
3. Описать процессы и требования визуально
Чтобы бизнес, аналитик и команда смотрели на одну картину, а не спорили о терминах.
14 мая, 18:00 — «Графическое описание бизнес‑процессов и требований». Записаться
4. Разобрать AS IS и TO BE
Полезно, когда нужно не просто «автоматизировать», а понять, где хаос, где контроль и что именно должно измениться.
3 июня, 20:00 — «AS IS хаос или TO BE контроль: как построить единую автоматизированную финансовую модель на основе неидеальных, разрозненных данных». Записаться
5. Найти, где создаётся ценность
Value Stream помогает увидеть, какие этапы процесса действительно важны, а какие только тормозят движение задачи.
Чтобы сущности, статусы, связи и правила не расползались в процессе разработки.
2 июня, 20:00 — «Объектная модель без боли: как превратить хаос требований в стройную архитектуру». Записаться
8. Говорить с разработкой и бизнесом на одном языке
C4 помогает показывать систему на нужном уровне детализации: без лишней абстракции и без перегруза техническими деталями.
4 июня, 20:00 — «C4 для системного аналитика: строим единый язык между бизнесом и разработкой». Записаться
9. Вовлекать стейкхолдеров
Даже сильное решение может застрять, если заказчик, пользователи и команда по‑разному понимают цель.
17 июня, 20:00 — «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться
10. Связать аналитику с эффектом для бизнеса
Хорошая аналитика должна влиять на скорость, прозрачность, качество и деньги, а не только на документацию.
4 июня, 20:00 — «Операционная эффективность в IT: как находить скрытую прибыль в процессах разработки». Записаться
Если вы только входите в анализ — начните с бизнес‑модели, процессов и требований. Если уже ставите задачи разработке — выбирайте Sequence Diagram, объектную модель и C4. Если работаете с изменениями и согласованиями — смотрите уроки про стейкхолдеров, AS IS / TO BE, цепочки ценности и операционную эффективность.
P. S. А если нужен не разовый урок, а полноценный маршрут развития, загляните в каталог курсов OTUS по аналитике и анализу: там собраны программы по системному и бизнес‑анализу, работе с требованиями, процессами и данными.
«Первая Форма» встроила в свою BPM-платформу многофункционального ИИ-ассистента
Компания «Первая Форма» дополнила собственную low-code BPM-платформу ИИ-ассистентом, который работает прямо в ленте комментариев задачи и помогает сотрудникам и клиентам быстрее находить ответы на рабочие вопросы.
Ассистент учитывает контекст задачи, обращается к корпоративной базе знаний, документации, связанным задачам и файлам, а также помогает разбирать инциденты, готовить ответы клиентам, искать причины ошибок и формировать рабочие материалы.
Новый инструмент встроен в привычный интерфейс «Первой Формы»: пользователю не нужно переходить в отдельный чат или заново описывать ситуацию. Достаточно обратиться к ассистенту в комментарии — он уже видит описание задачи, последние сообщения, категорию обращения и доступные вложения.
ИИ-ассистент может использоваться в разных сценариях:
Поиск документов в обширной внутренней базе знаний. Ассистент воспринимает техническую спецификацию, руководства пользователя, описания бизнес-процесса. Это избавляет от долгого самостоятельного копания в папках и системах.
Анализ данных из разных источников платформы. Например, ассистент может собрать историю взаимодействий с конкретным клиентом, включая все сделки, встречи и договоры, и выдать краткую справку о текущем состоянии дел, проанализировать показатели воронки продаж и не только.
Техническая поддержка и разбор проблем. ИИ-ассистента можно вызвать в задаче и попросить найти первопричину сбоя, а он проанализирует код, логи и конфигурацию и укажет на ошибку.
Экспертное консультирование. ИИ-ассистент имеет доступ к должностным инструкциям разных ролей, например, менеджера по продажам, аналитика, стратега, и может обращаться к ним для ответа на вопросы. Это позволяет получить специализированный взгляд без необходимости привлекать живого сотрудника.
Автоматизация рутинных действий. ИИ-ассистент позволяет собрать информацию для коммерческого предложения, создать задачу по шаблону с нужными полями, сформировать отчёт по итогам встречи на основе стенограммы.
Так ИИ стал частью ежедневной работы в BPM-системе. Сотрудники и клиенты уже ведут обсуждения в задачах — значит, именно там ассистент должен понимать контекст и помогать принимать решения быстрее. Новый инструмент помогает находить знания, связывать информацию из разных источников и сокращать время на рутинные операции.
В дальнейшем «Первая Форма» планирует расширять возможности ассистента: усиливать работу с корпоративными базами знаний, подключать новые сценарии анализа и автоматизации, а также развивать поддержку отраслевых и клиентских конфигураций платформы.
Представлен проект под названием «Кладбище 100 ИИ‑проектов», которые прекратили свою работу или были приобретены и интегрированы в другие продукты. Список поддерживается в рамках предварительной проверки — каждая запись представляет собой реальный продукт, зарегистрированный на ToolDirectory.AI до прекращения его работы.
В недавнем видосе я рассказывал, что сейчас читаю Талеба (в частности, его идеи вокруг “Антихрупкости”). И вот на днях на работе поймал идеальный личный пример одной из его любимых метафор Прокрустова ложа.
Суть там в чем: в мифе разбойник Прокруст укладывал гостей на свою железную кровать. Если человек был слишком длинным, то он отрубал ему ноги, если коротким - вытягивал суставы. Талеб переносит это на нашу жизнь: когда живая, сложная реальность не влезает в наши жесткие модели и системы, мы предпочитаем обкорнать реальность, лишь бы она поместилась.
А теперь к практике. Как говорят таксисты: блог и инди-хакинг - это для души, а вообще у меня и настоящая работа есть. Я бэкенд-лид в команде, которая пилит платформу для масс-найма (курьеры, сборщики).
Недавно обсуждали с ребятами, почему в какой-то момент автоматизация процессов начинает буксовать: фича обходится дорого, а позитивного эффекта от нее всё меньше. Оцифровать ведь можно только то, что уже жестко формализовано.
А дальше классика: 20% эйчаров закрывают 80% вакансий. И тут возникает моя самая наивная мысль: ну так давайте пилить фичи специально под этих топов!
Но тут кроется засада. Выясняется, что процессы самых эффективных ребят очень сложно загнать в рамки. У них свои паттерны, подходы, интуиция. И когда пытаемся натянуть на них стандартный флоу, мы строим для них то самое Прокрустово ложе. Пытаясь впихнуть нестандартного, сильного спеца в удобные для системы формочки, мы буквально “отрубаем ему ноги”. Мы заставляем его работать “как положено”, лишая тех самых фишек, которые и делали его звездой.
Получается забавный парадокс: классическая автоматизация мешает сильным, но отлично помогает “слабым”. Среднего сотрудника надо меньше учить, он быстрее вкатывается. А если он уйдет, найти замену гораздо проще, а порог входа сильно снижается за счет жесткого и автоматизированного рабочего процесса.
Как наброс на будущее: возможно, дальше мы придем к персональной автоматизации. Когда не человек подстраивается под приложение, а интерфейсы собираются под конкретного спеца и его стиль работы. Грубо говоря: когда мы научимся с помощью ИИ на лету менять размер кровати, а не рубить людям ноги.
У тебя есть ровно 2–3 часа настоящей работы в день. Не больше.
Не потому что ты ленишься. А потому что всё остальное время — встречи, переписка, уведомления, «быстрые вопросы» в чате — это не работа. Это шум, который притворяется работой.
По данным Hubstaff 2026, средний офисный сотрудник проводит в состоянии реальной концентрации лишь 25–37% рабочего дня. Остальные 61% — это переключение между задачами, митинги и реакции на чужие приоритеты. У менеджеров ещё хуже: глубокий фокус занимает всего 27% времени.
И это не частная проблема — это системная. ActivTrak фиксирует: за год средняя сессия глубокой работы сократилась ещё на 8%. Корпоративная культура «занятости» буквально пожирает способность думать.
Что с этим делать?
Первое — перестать считать «занятость» синонимом продуктивности. Ты можешь провести 8 часов в офисе и не создать ничего ценного.
Второе — защитить свои лучшие часы физически. Тайм-блокинг: 90 минут с утра — только одна задача, никаких мессенджеров. Это не роскошь, это гигиена.
Третье — сократить встречи. Исследования показывают: минус 40% встреч = плюс 71% к продуктивности. Большинство созвонов можно заменить голосовым сообщением или коротким текстом.
No-Meeting Day — когда целый день без звонков — это уже не стартаперская экзотика, а норма в сильных командах.
Твои 2–3 часа концентрации — это и есть ты в лучшей форме. Вопрос только в том, кому ты их отдашь: своим целям или чужим срочностям.
В команде Apple вайбкодят приложения — разработчики случайно оставили файлы Claude .md в обновлении Apple Support. После того, как этот инцидент стал публичным в соцсетях, то в Apple выпустили новую версию обновления 5.13.1 без следов вайбкодинга.
AIRD: когда страх потерять работу токсичнее самой потери
Допустим, вас ещё не уволили. Ваш стек актуален, в Jira тикеты закрываются, митинги проходят без неловкого молчания. Но ночью вы лежите и думаете: «А вдруг следующий спринт — последний?»
Поздравляю. Возможно, у вас AIRD.
Что за аббревиатура
В начале 2026 года в Cureus Journal of Medical Science вышла работа исследователей Стефани Макнамары и Джозефа Торнтона из Университета Флориды. Они ввели термин AI Replacement Dysfunction (AIRD) — клинический конструкт для описания психологического дистресса у людей, которые боятся быть вытеснены ИИ.
Ключевой парадокс звучит как баг в продакшне: симптомы появляются до реального увольнения и без предшествующих психических расстройств. Страх сам по себе становится дисфункцией.
Симптоматика, которую вы уже видели в команде
Тревожность и бессонница — фоновый шум о профессиональном будущем, который не глушится ни кофе, ни дедлайнами
Распад профессиональной идентичности — «кто я, если мой скилл можно промптом заменить?»
Паранойя внутри команды — нежелание делиться знаниями, скрытая конкуренция там, где раньше был code review
Снижение самооценки — человек начинает сомневаться в своих архитектурных решениях не потому что они плохи, а потому что чувствует себя устаревшим
Риск злоупотреблений — хроническое напряжение ищет выход
Клинический психолог Харви Либерман (Нью-Йорк) формулирует это так: «Самое частое, что я слышу — страх стать устаревшим. Люди сомневаются в своих решениях, выборах, перспективах». И это не нытьё — это симптом.
Цифры, которые неудобно игнорировать
По данным Американской психологической ассоциации (июль 2025), 38% работников беспокоятся, что ИИ сделает их обязанности устаревшими. В том же году более 54 000 сотрудников были уволены именно из-за внедрения автоматизации.
Исследователи из Индии зафиксировали схожую картину в IT: потеря «когерентности идентичности» и «ориентации на будущее» — даже у тех, кто сохранил работу. Страх меняет поведение раньше, чем меняется реальность.
Почему это системная проблема, а не личная слабость
Торнтон называет происходящее «невидимой катастрофой». Корпоративные медиа, LinkedIn и деловые издания ежедневно транслируют сигнал тревоги — и мозг, обученный на выживание, реагирует на него как на реальную угрозу, даже если угроза пока статистическая.
Это не слабость конкретного разработчика или менеджера. Это системный ответ на системный стрессор.
Что предлагают исследователи
Авторы работы предлагают не только диагностику, но и терапевтические подходы:
Мотивационное интервьюирование — работа с внутренней амбивалентностью и сопротивлением переменам
Нарративная терапия — переосмысление профессиональной истории: не «я Java-разработчик», а «я человек, умеющий решать такие-то задачи»
Реструктуризация идентичности — строить «Я» вокруг навыков и ценностей, а не должности в оргчарте
Адаптационные практики — снижение когнитивной нагрузки от неопределённости
Клиницистам рекомендуют выходить за рамки кабинета и формировать ответы на уровне организаций — менять среду, а не только лечить симптомы.
Почему это должно волновать тех, кто управляет командами
AIRD снижает продуктивность, разрушает психологическую безопасность в командах и повышает текучку задолго до того, как ИИ реально займёт хоть одну позицию. Компании, игнорирующие психологическую сторону автоматизации, платят дважды: сначала за внедрение технологий, потом за потерю людей, которые не выдержали неопределённости.
Невидимый технический долг бывает не только в коде.
Два года назад на конференциях гордо представлялись: «Я промпт-инженер». Звучало свежо и дорого. Сегодня это примерно как писать в резюме «уверенный пользователь Google». Навык нужный — но не дифференцирующий.
Дело не в том, что промпты устарели. Изменилась единица работы с ИИ.
Что реально произошло
Раньше типичный сценарий: открыл ChatGPT → ввёл запрос → получил текст → поправил руками → пошёл дальше. Один инструмент, одна итерация, один человек в петле управления.
Сегодня производственные пайплайны выглядят иначе:
Агент-планировщик разбивает цель на подзадачи и строит граф выполнения
Специализированные агенты выполняют каждую задачу параллельно или последовательно
RAG-слой подтягивает релевантный контекст из векторного хранилища
Валидатор проверяет выход на соответствие контракту
Оркестратор управляет всем этим — как дирижёр, а не как музыкант
В чём принципиальная разница
Промпт-инженер владеет языком — умеет правильно формулировать задачу для одной модели. Оркестратор владеет архитектурой — проектирует систему, в которой несколько моделей и инструментов работают как единый организм.
Разница хорошо видна на вопросах, которые задаёт каждый. Промпт-инженер спрашивает: «Как лучше сформулировать запрос? Какой tone of voice выбрать? Как получить нужный формат?» Оркестратор спрашивает иначе: «На какие подзадачи разбить цель? Какому агенту что делегировать? Что происходит, если один из них возвращает ошибку?»
Первый оптимизирует ввод. Второй проектирует систему.
Что нужно уметь оркестратору
Это не про знание математики нейросетей и даже не обязательно про Python. Это про системное мышление плюс несколько прикладных навыков.
1. Декомпозиция задач. Умение разбить сложную цель на атомарные подзадачи, которые можно делегировать независимым агентам без потери контекста.
2. Управление состоянием. Что хранить в памяти между вызовами, что передавать явно в контексте, а что безопасно забыть — это напрямую влияет на стоимость и надёжность системы.
3. Fallback-логика. Если агент вернул невалидный ответ или timeout — что дальше? Перезапуск, альтернативный путь, эскалация человеку? Системы без продуманного error handling ломаются в продакшене предсказуемо.
4. Выбор инструментов под задачу. Когда нужен LLM, когда — поисковый агент, а когда задачу дешевле и надёжнее решить классическим алгоритмом без ИИ вообще. Молоток-LLM не нужен для каждого гвоздя.
5. Оценка качества выхода. Не «красиво ли написано», а «решена ли задача, воспроизводим ли результат, насколько система деградирует при изменении входных данных».
Почему это важно именно сейчас
Microsoft в опросе 31 000 сотрудников из 31 страны обозначил роль «промпт-инженера» как одну из наименее перспективных для роста на горизонте 12–18 месяцев. Проектирование мультиагентных систем при этом называется ключевым навыком следующих двух-трёх лет.
Компании уже сейчас ищут не тех, кто «умеет работать с ИИ», а тех, кто умеет строить системы на базе ИИ. Это разные запросы — и разный рынок труда.
Порог входа ниже, чем кажется
Не нужно знать математику нейронных сетей. Достаточно освоить несколько паттернов: оркестратор ставит задачу → субагент её выполняет с помощью инструмента → результат идёт на валидатор → валидатор либо принимает выход, либо запускает повтор или эскалацию.
Понять, как работает memory и state в агентных системах, и попрактиковаться на реальных задачах — n8n, LangGraph или AutoGen дают это с минимальным порогом входа.
Промпт-инженерия дала нам грамотность в работе с ИИ. Оркестрация даёт проектирование. Переход между ними — это не про новый инструмент. Это про новый тип мышления.
Лог в реальном времени: берём госзаказ и закрываем его агентной разработкой
На днях Оскар Хартманн довольно жёстко высказался за вайбкодинг. Тем временем на Пикабу из 45 программистов в профессиональном сообществе вайбкодят только 9. В госсекторе — единицы.
Пока остальные спорят, костыли это или нет — я берусь за реальный тендер и публикую всё как есть.
Подписывайтесь — первый пост как только войду в торги на понижение.
Вчера проводила эксперимент с 5 нейронками об отключении мобильного интернета и об ограничении вообще интернета в стране Х. Были задействованы DeepSeek, Yandex, Kimi, Gemini и GPT. То есть, разные нейронки, обученные на разных культурных корпусах, США, Китай, Россия. Язык русский.
Так вот, все 5 нейронок согласились что интернет можно отключать только в кратковременных случаях, если есть угроза жизни. Ограничивать также можно, но если это пропорционально соответствует угрозе, что пока не доказано. Самый сок!
Во всех опросах Алиса/Яндекс рассказывала как это плохо ограничивать интернет в целях безопасности, но ставила 8/10 «ЗА». Все остальные ставили 2-3/10.
Вы понимаете парадокс? Алиса говорит, что ограничения ужасны для безопасности, образования, медиа, науки, права, экономики, медицины (особенно она отметила что нельзя ограничивать доступ к глобальной медицине), но голосовала ЗА!
Подумайте, какой приоритет встроен в итоговую оценку.А теперь главное: ИИ встраивается сейчас везде, в бизнес, в банки, в госуправление, в места, где принимаются критические решения. Что посоветует Алиса, если она подробно описывает медленную деградацию системы, но в итоговой оценке всё равно поддерживает ограничения? Какие критические решения могут приниматься с таким "технологическим суверенитетом”?
Премия за гибридность: почему самый ценный сотрудник не технарь и не гуманитарий
Долгое время разделение было почти кастовым: одни пишут код и строят модели, другие ведут переговоры и рассказывают истории. Каждый лагерь немного презирал другой. Это было удобно, понятно и — как выясняется — безнадёжно устарело.
Генеративный ИИ сломал эту систему не потому, что «заберёт работу». Он сломал её потому, что изменил саму единицу ценности специалиста.
Что говорят данные
PwC и MIT проанализировали требования к позициям, связанным с Gen AI, и получили неудобный результат. Роли с ИИ требуют на 36,7% больше когнитивных навыков, чем аналогичные позиции без него. Но одновременно устойчиво растёт спрос на социальные компетенции: эмпатию, лидерство, суждение в условиях неопределённости.
Логика железная: машина забирает рутину, обработку данных, генерацию контента. Человеку остаётся то, с чем LLM справляется плохо — интерпретация, этика, контекст и доверие. А доверие, к слову, до сих пор не токенизируется.
π-shaped как новый стандарт найма
McKinsey и Google уже несколько лет оперируют концепцией π-shaped специалиста: два вертикальных столба глубокой экспертизы плюс горизонтальная гибкость между ними.
В контексте AI это выглядит так:
Столб 1 — техническая AI-грамотность: понимание архитектуры языковых моделей, промпт-инжиниринг, работа с API и осознание ограничений систем
Перекладина — способность переключаться между этими режимами в рамках одной задачи
Продакт, который понимает разницу между RAG и fine-tuning и при этом умеет провести глубинное интервью с пользователем — это уже не «редкий зверь», это просто новый минимальный стандарт для сильных команд.
Как это развивать — без воды
AI-грамотность — не обязательно писать код, но необходимо понимать, как работают языковые модели, где они галлюцинируют и как правильно декомпозировать задачу для промпта
Практика суждения — берите кросс-функциональные проекты, где нет единственно правильного ответа. Именно там тренируется то, что модель сымитировать не может
Осознанная коммуникация — это не «навык презентаций». Это умение слышать, адаптировать месседж под аудиторию и строить доверие. Прокачивается через фасилитацию и наставничество, а не через курсы ораторского мастерства
Рефлексия — те, кто регулярно разбирает собственные решения и открыт к критике, накапливают опыт, который не дистиллируется в веса модели
Почему это не очередной buzzword
Автоматизация не уничтожает рабочие места — она реструктурирует их. Исчезают позиции, где человек выполнял функцию дешёвого процессора. Появляются роли, где нужен человек с AI-усиленным интеллектом — и именно они получат премию за гибридность в зарплате, карьере и реальном влиянии на результат.
Вопрос уже не «технарь вы или гуманитарий». Вопрос в том, как быстро вы готовы перестать считать это противоречием.
