Lapidus

Эффективное управление


Прошлогодний метаанализ управленческих практик (охвативший данные тысяч проектов за 2025 год) дал полезный результат.
Часто говорят, что главное искусство руководителя — это делегирование.
Но статистика показывает: само по себе делегирование даёт лишь умеренный эффект. Просто передать/распределить задачи — мало.

Исследователи сопоставили стили руководства (как ставятся задачи, как выстраивается коммуникация) с фактическими бизнес-результатами (соблюдение бюджетов, сроков, достижение целей/метрик).
С помощью статистического анализа они выявили три фактора, которые дают наиболее сильный положительный эффект.

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

2. Отсутствие серых зон в ролях
Команда работает эффективно, когда каждый сотрудник точно знает рамки своих полномочий, зону своей ответственности. Никто не тратит время на выяснение, кто несёт ответственность за конкретный участок работы

3. Ясная связь рутины с целями компании
Сотрудники выгорают не от сложной работы, а от бессмысленной. Эффективные лидеры дают контекст: как именно задача, которую человек делает сегодня, повлияет на продукт, клиента или бизнес-метрики завтра

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

P.s. Значения на диаграмме (вроде 0.28) — это сила связи. Чем больше это число, тем сильнее прямое влияние действия руководителя на итоговый результат

ИИ в образовании


Система «Антиплагиат» запустила пилот версии 2.0 в ряде вузов: описание и короткое объяснение.
Ключевое изменение: система переходит от оценки итогового текста к мониторингу процесса написания работы в реальном времени в онлайн-редакторе сервиса. Если студент вставляет фрагменты текста или не демонстрирует естественную динамику набора текста, работа помечается как подозрительная.

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

Происходит подмена понятий. Вузы смешивают академическую честность с цифровым садомазохизмом.
Отслеживание нажатий клавиш и запрет на вставку текста не имеет никакого отношения к борьбе за самостоятельность и критичность мышления.
Это классика иллюзии контроля.

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

Вузы начнут наказывать студентов за эффективный рабочий процесс!
Будут воспитывать тех, кто создаёт красивую картинку вместо смысла: студент работает не над содержанием, а над тем, как угодить алгоритму: делать искусственные паузы, имитировать набор текста, бояться закрыть вкладку.
Это воспитывает не исследователя, а параноика, не профессионала, а безвольного унылого лузера.

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

Что ж. Путь запретов — любимая форма существования одной скрепоносной территории.
Делаем выводы и разумный выбор.

Новая школа


Раньше профессиональный навык означал способность дать результат.
Сотрудник был ремесленником: написал код, сверстал макет, составил отчет — и за это платили.

Сегодня ИИ взял на себя рутинное исполнение.
Мы описываем контекст — и получаем удовлетворительный артефакт.

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

Вот этому и надо учить — новой роли: Оркестратор-Аудитор, вместо Ремесленника.

Но вот нюанс, который многие визионеры образования игнорируют: вы не можете быть Оркестратором-Аудитором, если никогда не были Ремесленником.

Решение есть.
Классическая система образования разделяется на два трека:

1. Компонентный
Здесь ИИ используется только как ассистент, чтобы помочь заложить базу, каркас знаний и навыков;

2. Системный
Здесь ИИ используется на полную. Оценивается не артефакт (его генерирует машина), а способность управлять хаосом.

Старая школа ставила задачу так:

сдай текст сочинения или код программы

Новая школа ставит задачу иначе:

сдай архитектуру решения

Оцениваются умения:

— Формулировать проблему. Постановка задач и приоритизация дороже решения;
— Управлять командой и оркестром инструментов. Декомпозиция, выстраивание итераций и цепочек получения ценности, ответственность за решения;
— Верифицировать и адаптировать. Критическое мышление, привязка к уникальному офлайн контексту.

Оценка ставится не за артефакт (повторю: его генерирует машина), а за качество мышления и способность управлять инструментами.

Генерация результата — забота ИИ.
Навык профессионала — это верификация, ответственное управление и стратегия.


P.s. Моим любимым студентам желаю успешного учебного года

PoDPR приоритизация


PoDPR — расширение идей RICE (Intercom) и WSJF (SAFe), пересобранное под контекст продуктовой команды/продукта, где часть задач необратимые, доказательная база гипотез неоднородна, а зоопарку технологий позавидует любой энтерпрайз.

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

Базовая формула
PoDPR = Pain ÷ Difficulty × Probability × Reversibility, где

- Pain — выраженность проблемы для пользователя/бизнеса. Шкала 1-10;
- Difficulty — сложность реализации с учётом неопределённости. Шкала 1-10;
- Probability — вероятность того, что гипотеза сработает. Шкала 0,1-1,0. Подтверждена ли она данными, прошлыми экспериментами, исследованиями или «по ощущениям норм»? Чем слабее доказательная база, тем сильнее множитель снижает приоритет;
- Reversibility — стоимость отката. Шкала 0,1-1,0. Если фичу можно запустить и в случае провала бесследно убрать — отлично, пробуем. Если цена ошибки высока (миграции данных, публичные обещания, необратимые изменения в UX), модель подталкивает поискать более безопасный вариант.

Эти четыре параметра обязательны.

Декомпозиция Pain
Когда боль сложно оценить, коэффициент раскладывается на три множителя:
Pain = Severity × Frequency × Reach ÷ 2,5 , где

- Severity — серьёзность проблемы или задачи. Шкала 1-5. Насколько проблема бьёт по ключевому сценарию, воронке или бизнес-метрике. 1 - косметика; 3 - деградация ключевого сценария; 5 - блокировка монетизации;
- Frequency — частота проблемы. Шкала 1-5. 1 - разовый инцидент; 3 - еженедельный поток тикетов; 5 - каждый пользователь ежедневно;
- Reach — охват. Шкала 0,01-1,0. Доля пользователей или доля выручки, затронутые проблемой.
- 2,5 — нормировочный коэффициент, чтобы вернуться в диапазон 1..10

Декомпозиция Difficulty
Для крупных или незнакомых задач единая оценка сложности часто даёт ошибку. Тогда раскладываем:
Difficulty = Effort ÷ Confidence ÷ Expertise, где

- Effort — суммарные трудозатраты. Шкала 1-10. Полный цикл: проектирование, дизайн, разработка, тестирование, интеграции, миграции, релиз, согласования;
- Confidence — уверенность в оценке Effort. Шкала 0,3-1,0. Задача знакомая — уверенность высокая (0,8..1,0). Много неизвестных, оценка «на ощущениях» — уверенность низкая (0,3..0,5), и итоговая сложность растёт;
- Expertise — компетенция команды именно в этом типе задач. Шкала 0,3-1,0

Нижняя граница 0,3 для Confidence и Expertise введена сознательно: при значениях ниже 0,3 формула даёт неадекватный рост, и задача автоматически получает приоритет «не делать», что не всегда верно. Если уверенность < 0,3 — это сигнал не считать, а идти исследовать.

Главное достоинство PoDPR — модульность.
В базовую формулу легко встраиваются дополнительные множители под конкретный контекст:
- Urgency (0,8..1,2) — коэффициент срочности, если дедлайн диктуется рынком или регулятором.
- Blast Radius (≤ 1, где 1 - локальный масштаб; а 0,1 - нам всем конец) — индикатор масштаба возможного ущерба. Понижает приоритет там, где ошибка затрагивает критичные процессы, большие объёмы данных или значимые суммы.
- Sustainability (≤ 1, где 1 - решение не увеличивает сложность, легко поддерживается) — стоимость владения и долговечность решения. Сколько ресурсов потребует поддержка через полгода и не превратится ли фича в технический долг.
- Strategic fit — cтратегическое соответствие. Шкала: 0|1, булевый множитель. Инициатива вне фокусов квартала просто не проходит в шорт-лист, независимо от балла.

Каждый новый множитель увеличивает стоимость оценки и риск двойного учёта (например, Reach и Blast Radius могут пересекаться). Поэтому базовая формула из четырёх переменных — вариант по умолчанию. Расширения добавляют точечно, когда базовой модели объективно не хватает для принятия решения.

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

Дурные совещания


Не люблю большие, бессмысленные совещания, потому что теряю нить уже на третьей минуте =)
Лишь усилием воли держу внимание на объекте обсуждения.

Но есть три вида совещаний, от которых у меня подгорает и я становлюсь едким комментатором:

1. Совещание-монолог
Бывает инициатор встречи хочет донести свою мысль, а выслушивать другие мнения не хочет. В таком случае стоит просто написать в общий чатик готовое решение, а не устраивать имитацию совещания.
Помню в одном продукте CЕО собрал совещание по стратегии, где сначала заслушал со скучающим лицом доклады директоров по направлениям, постоянно нервничая, что приходится создавать видимость демократии, а потом сказал: всё фигня, ваши идеи не годятся, вот стратегия, по которой мы будем жить.
Артём С., привет!

2. Совещание-ритуал
Священнодействие, на котором надо быть, чтобы быть.
Обычно я пытаюсь найти для себя что-то полезное в ритуале. В конце концов это хоть какая-то предсказуемость бытия.

3. Совещание-чёрная-дыра
Длятся дольше, чем существует само время. Количество участников больше, чем атомов во вселенной. Отказаться от участия почти невозможно, выйти нельзя. Тебя туда просто засасывает.

Не надо таких совещаний, пожалуйста

Бриф проблемы


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

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

Бриф состоит из трёх блоков, которые нужно заполнить до обсуждения решения.

Блок 1. Контекст и Реальность (где мы сейчас и почему это важно)
- Суть проблемы: Формулировка (по формуле) от текущего состояния, as is - к желаемому, to be. В чем именно боль?
- Триггер: Почему мы занимаемся этим именно сейчас?
- Масштаб: Сколько денег, времени или людей затрагивает проблема?
- Факты и История: Что мы уже пробовали сделать? Почему это не сработало? (это спасёт от изобретения велосипеда).

Блок 2. Анализ и Ограничения (с чем работаем и в какие рамки мы зажаты)
- Корневые причины: Почему система пришла в это состояние на самом деле?
- Связь со стратегией — как проблема связана с целями организации (если не связана — может, и не надо решать?)
- Цена бездействия: Что произойдет с системой, если мы вообще ничего не будем делать?
- Стейкхолдеры и интересы: Кто влияет на решение? Чьи интересы задевает проблема? Кто может саботировать изменения из-за потери ресурса или влияния?
- Ограничения: Бюджет, дедлайны, регуляторика, легаси-технологии. Что нам запрещено менять? Какие барьеры на пути можем встретить
- Допущения: Что мы считаем истиной, но на самом деле это просто гипотеза? (самая опасная зона: здесь рождаются главные риски)
- Риски решения — какие побочные эффекты может создать решение, какие части системы могут быть затронуты

Блок 3. Результат и Фокус (как мы поймем, что победили)
- Владелец проблемы: Кто лично отвечает за доведение этого брифа до результата?
- Outcome: Как будет выглядеть мир, когда проблема решена?
- Метрики успеха: Как поймём, что достигли цели
- Критерии выбора решения: По каким принципам мы будем оценивать идеи? (например: "решение не должно требовать найма новых людей" или "должно окупиться за 3 месяца").
- Слепые зоны: О каких политических, исторических или скрытых зависимостях мы можем забыть в пылу борьбы?

Структурирование проблемы в Брифе за час-два экономит команде десятки (иногда сотни) часов бесполезной работы

Три вывода для тех, кто принимает решения

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

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

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

Развивайте умение видеть эти длинные цепочки и отложенные эффекты. А еще лучше — создавайте свои.

Новые слова


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

Те из вас, кто знает меня достаточно близко, слышали, что я нежно и глубоко люблю лингвистику (во всех смыслах).
Нашёл классный ресурс Института лингвистических исследований РАН: "Новое в русской лексике".

Это настоящая машина времени!
Смотришь на слово и узнаёшь, когда оно впервые фиксируется в русском языке. И сразу вспоминаешь, когда впервые услышал, в каком контексте, кто был рядом или кто сказал.

Вот вам небольшая подборка русских слов для ностальгии (и лёгкого шока):
— 5 лет назад впервые зафиксированы — ковидарий, буст, дистант-учёба
— 10 лет назад — божечки-кошечки, дронобоязнь, газлайтить, сасный, трампокалипсис;
— 20 лет назад — лайф-коуч, букридер (превратился в читалку), бенто-бокс;
— 30 лет назад — аутсорсинг, боди-пирсинг, кейтеринг, медиафайл, релокация;
— 40 лет назад — бебиситтер, креативный, евробюрократия, морпех, блистер;
— 50 лет назад — бейгл, ароматерапевтический, аудио-видео;
— 60 лет назад — бодибилдинг и лазанья.

И да, я не ошибаюсь, когда говорю, что все эти слова — русские.
Тут я могу разве что процитировать моего любимого игрока в "Что? Где? Когда?" Фёдора Двинятина (кандидата наук, филолога-русиста): "Любое слово, употребляемое в русском языке, записываемое русскими буквами и включаемое в словарь русского языка, является русским словом" (вот вам ссылка на знаменитый раунд про серсо)

А какое слово из этого списка (или из современного сленга) бесит вас больше всего?
Или, может, вы сами недавно придумали крутой неологизм?
Делитесь в комментах и в личке.

Давайте полингвистируем!

Типы стратегий


Я видел сотни документов (и цветных схемок), которые компании и "эксперты" выдают за стратегию.

Все их можно разделить на два больших кластера: те, что сфокусированы на результате, и те, что сфокусированы на решениях. В кластере "Решения" есть два типа: план действий и модель поведения.

Тип 1. Стратегия-Цель (кластер "Результат")
Объект: конечные метрики
Суть: описывает, чего мы хотим достичь (выручка х3 за год, доля рынка 20%, выход в Азию до конца 20-х).
Пример: Похудеть на 10 кг за лето

Тип 2. Стратегия-План (кластер "Решения")
Объект: последовательность шагов
Суть: описывает, что и в каком порядке мы будем делать. По своей сути это детализированные роадмапы (в Q1 делаем Х, в Q2 — Y).
Пример: Сначала я попробую меньше есть, а потом попробую больше ходить. В первом квартале уберу углеводы, во втором добавлю жиры и белки.

Часто встречается микс этих двух типов.
Описывает цели, метрики и шаги, которые будем предпринимать в таком-то порядке.
Ничего не напоминает? ;)

Тип 3. Стратегия-Модель (кластер "Решения")
Объект: процесс принятия решений в условиях неопределённости.
Суть: описывает поведение компании и сотрудников. Это набор принципов, которые регламентируют, как мы реагируем на внешние шоки и распределяем ресурсы.
Пример: Не ем калорийную еду за 2 часа до сна. Не хожу за продуктами на голодный желудок. Создаю дефицит калорий. Ем сбалансированную по КБЖУ еду. Держу достаточный уровень витаминов. Ем маленькими порциями, но регулярно.

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

Цели, метрики и планы — это не стратегия, даже если всё это упаковано в цветную схемку.
Стратегия — это то, как вы себя ведёте, когда плана уже нет, а цель ещё в силе.

Реестр принципов


Принципы, которые не зафиксированы, со временем забываются, размываются или трактуются каждым сотрудником по-своему.

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

Самый простой и рабочий инструмент фиксации — реестр принципов.
Достаточно одной страницы в корпоративной базе знаний.

В самом простом виде реестр содержит пять полей:
— Короткое имя. Помогает быстро ориентироваться и использовать в обсуждениях (например, "Коллеги, это нарушает Принцип Только b2c").
— Полная формулировка. Эталон для сверки. Исчерпывающее описание того, что мы делаем и чего НЕ делаем
— Тип. Ограничивающий, приоритизационный и т.д. — смотри предыдущий пост
— Владелец. Сотрудник, который следит за соблюдением принципа. Человек, который отвечает за неукоснительность принципа. Его главная задача — принимать финальное решение или накладывать вето, когда принцип пытаются обойти или нарушить.
— Коллизии. С какими другими принципами этот может конфликтовать и правило победы (как выбрать приоритетный). Арбитражом занимаются владельцы (например, "Конфликтует с принципом Быстрого роста, но в спорных ситуациях Принцип Качества всегда имеет приоритет")

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

Пример записи из реестра:

Принципы стратегии


Вопрос из лички: "Ты несколько раз писал, что стратегия это принципы. Покажи примеры"

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

Принципы бывают следующих типов

1. Ограничивающие
Запрещает определённое действие. Отсекают возможности, которые кажутся выгодными, но уводят компанию от фокуса. Это защита от распыления ресурсов.
Принцип: Не выходим на рынки, где не можем объективно стать №1 или №2 за 5 лет.
Принцип: Не работаем с SMB-сегментом, даже если там есть быстрый рост. Исключение: пилотный проект, который даст доступ к новому Enterprise-клиенту.
Принцип: Не масштабируем продукт, пока не доказан product-market fit.

2. Приоритизационные
Разрешают внутренние конфликты интересов и задают правила распределения ресурсов.
Принцип: Всегда выбираем долгосрочную ценность для клиента вместо краткосрочной прибыли.
Принцип: Растем за счет сетевого эффекта, а не за счет линейного наращивания отдела продаж.
Принцип: Направляем 80% инвестиционного бюджета только в те направления, где у нас уже есть защищенное конкурентное преимущество.
Принцип: Если принципы конфликтуют друг с другом, то запускаем арбитраж

3. Качественные
Определяют стандарт, ниже которого мы не опускаемся, даже если горят сро(а)ки.
Принцип: Никакая новая функциональность или изменение ключевых сценариев не попадает к пользователю без UX-ревью.
Принцип: Новый продукт перед масштабированием должен доказать свою экономическую модель: NPS выше отраслевой медианы, LTV / CAC > 3

4. Реактивно-диагностические
Это правила того, как мы реагируем на внешние шоки, чтобы не впадать в панику или отрицание. Самый сложный тип.
Принцип: Не списываем падение ключевых метрик на «сезонность», пока не проверим эту гипотезу двумя независимыми источниками данных.
Принцип: Если конкурент демпингует в нашем ключевом сегменте, мы не ввязываемся в ценовую войну.


P.s. Задавайте вопросы в комментариях, директе канала или в личке

Стратегия ≠ План


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

Стратегия — это не презентация.
Не многостраничный документ.
Не красивая разноцветная схема.
Не план действий.
Даже если в этом плане есть цели, метрики, "субъекты", гипотезы и задачи — это не стратегия.

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

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

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

План гибок: его нужно регулярно корректировать, опираясь при этом на стратегические принципы.

Посмотрим простейший пример, опираясь на вопросы

Стратегия
Почему мы выбираем выращивать вишнёвый сад, а не виноградник? Почему мы выбираем сельское хозяйство, а не тяжёлое машиностроение? Кто клиент и какую ценность он ищет в вишне?

План
Когда и как мы поливаем сад? Какие удобрения вносим и когда? Какую урожайность и в какие сроки хотим достичь? Как поймём, что невероятная урожайность достигнута не ценой "химии"? Какие есть подходы к выращиванию вишни и как будем проверять разные подходы? Кто входит в команду и как мы проверяем результат на выходе?

Контрольный тест
Как узнать, что перед вами: стратегия или план.
Ответьте на вопрос: «Если мы не достигнем целевой метрики, мы изменим нашу конечную точку, принципы/ценности (стратегию) или скорректируем методы работы, попробуем другие гипотезы из списка (план)?».

Стратегия задаёт фокус, отсекая лишнее.
План распределяет ресурсы, структурируя необходимое.
Одно без другого не работает.
Но Стратегия ≠ План

Принятие изменений


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

Кейс рентгеновского излучения
От открытия до массового применения прошло менее года.
Факторы ускорения:
- Низкий порог входа: аппаратура была относительно дешевой и не требовала перестройки больничной инфраструктуры.
- Очевидность пользы: результат (снимок кости) получался и был интерпретируем мгновенно.
- Комплементарность: технология не отменяла существующие практики хирургии и диагностики, а дополняла их, повышая статус врача, а не обесценивая его квалификацию.
- Медийный резонанс: публикация снимка руки Берты Рентген "завирусилась", подняла волну хайпа, который больницы не могли игнорировать.

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

Кейс антисептики Листера
Напомню, что Листер предложил обрабатывать раны и инструменты карболовой кислотой. Несмотря на снижение смертности вдвое, стандартом метод стал через 25 лет.
Барьеры носили системный характер:
- Высокая цена переключения: требовалась полная реорганизация операционных, новые протоколы работы (стерилизация, хранение), изменение цепочек поставок.
- Побочные эффекты: карболовая кислота вызывала химические ожоги у пациентов и дерматиты у персонала. Сопротивление врачей было частично вызвано реакцией на несовершенство ранних версий технологии.
- Институциональная инерция: внедрение требовало признания того, что предыдущие десятилетия практики были ошибочными. В медицине, где авторитет строится на опыте, такая ревизия встречает сопротивление, так как угрожает профессиональной идентичности старшего поколения.

Это медленный цикл внедрения.
Схожая ситуация была с мытьём рук перед операций (после вскрытия) у врача Земмельвейса.

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

Это экстремально длинный цикл внедрения.

P.s. съешьте лимон ;)

Настройки мышления


Много копий сломано о тему того, каким должен быть стратег, продакт, системный инженер (это всё - один человек).

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

1. Толерантность к хаосу
Ничего не понятно, нет стройной системы, у всех противоположные интересы. Но человек не боится войти в эту "горящую комнату".

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

3. Эго на паузе
Умение признать, что что-то не знаешь, не умеешь, что есть эксперты в теме покруче тебя самого

4. Память на паттерны
Опыт помогает сформировать набор шалонных подходов, видеть эти паттерны в системе, применять простые надёжные решения. При этом важно регулярно проверять свои шаблоны на актуальность и адекватность контексту

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

Будущее в прошлом


В английском языке есть такое виртуальное грамматическое время: Prophetic Perfect Tense. Пророческое Совершенное время.

Употребляется при описании будущих событий (прогнозы, предсказания, пророчества).
При этом степень уверенности говорящего в том, что событие произойдёт столь велика, что он говорит о событии, как об уже свершившемся факте.
Так будто описывает его из далёкого будущего, когда событие уже наступило.
Сделал схему для понимания

Пример: Next Monday has been exhausting
Перевод: Следующий понедельник уже вымотал меня
В русском языке нет такой грамматической формы, поэтому приходится использовать глагол в прошедшем времени и маркер "уже", но это конечно не полный эквивалент.

В Amazon есть подход Working Backwards, основанный на этой грамматической форме. В рамках подхода пишут PR/FAQ (Press Release / Frequently Asked Questions).
Команда начинает не с технических требований или бизнес-плана, а с написания пресс-релиза для ещё не существующего продукта, как если бы он уже был запущен и успешно продавался.
Помогает заранее понять, в чём же успех продукта, какую ценность он несёт, и тд и тп

Модель PIG


В прошлом посте я обещал рассказать про Авангард — модель Власть vs. Интерес (Power-Interest Grid — PIG).

RACI и DACI помогают разобраться, кто что делает. Матрица PIG помогает понять, как с кем общаться.

Матрица делит всех людей на 4 категории и диктует предпочтительную (но не единственную) модель поведения - см.картинку.

Все три модели (RACI, DACI, PIG) дополняют друг друга. Использовать стоит все вместе

Важный инсайт: матрицы показывают ещё и проблемы.
Если квадрант "Работать сообща" пустой — значит у вас нет драйвера, проект заглохнет.
Если квадрант "Мониторить" или "Информировать" переполнен — у вас куча избыточных коммуникаций

RACI & DACI


Хаос в продукте (и в команде) начинается с фразы "я думал, это делает кто-то другой"

Напомню, что есть такая штука: матрица ответственности.
Это инструмент, с помощью которого распределяют ответственность, полномочия, роли.

Классика: RACI
Подходит для распределения задач
Распределяем всех по зонам:
— R (Responsible) — делает своими руками
— A (Accountable) — отвечает головой (строго один на задачу)
— C (Consulted) — эксперт, который консультирует, помогает
— I (Informed) — держит руку на пульсе, его оповещают обо всём

Модерн: eRACI
Расширение классической модели новыми ролями для сложных проектов
— V (Verifier) — верифицирует качество и результат
— Q (Quality) — проверяет качество
— S (Support) — поддерживает ресурсами
— Sig (Signatory) — финально аппрувит результат и даёт добро на выпуск

Неоклассика: DACI
Подходит для распределения ответственности при принятии решений
— Driver — двигатель процесса, тот, кому "больше всех надо"
— Approver — лицо, принимающее финальное решение
— Contributors — эксперты и консультанты, предоставляют релевантные данные
— Informed — участники, которых держат в контексте

Авангард: Власть vs. Интерес
Об этом в следующий раз

Формулировка проблемы


Часто вместо проблемы мы описываем факт: низкий уровень продаж, долгий онбординг, и тд, и тп.
Решить факт невозможно.
Решить можно только проблему.

Вот стартовый шаблон формулировки проблемы.

В [процесс/зона] наблюдается [X — текущее значение метрики за период], а должно быть [Y — стандарт/план], поэтому [владелец проблемы] теряет [Z — измеримый ресурс], что создаёт риск [конкретное последствие при сохранении динамики], {связь между разрывом и потерью ресурса}

Он описывает два состояния системы: as is и to be, владельца проблемы и риски и потери, убирает субъективность за счёт точных данных, а не оценочных прилагательных.

Примеры:
— В процессе обработки возвратов доля ручных согласований составила 42% за октябрь, а целевое значение 15%. из-за этого отдел логистики теряет 120 человеко-часов, что создаёт риск срыва SLA по доставке при росте сезонного потока (т.к. логисты занимаются не приоритетными задачами)
— В B2B воронке доля сделок с просроченными этапами составила 28% за 2026-Q1, а должно быть 10%, поэтому отдел продаж теряет 14% конверсии, что создаёт риск дефицита cash flow в следующем отчётном периоде
— При онбординге срок выхода на плановую производительность составляет 115 дней, а должно быть 70 дней; поэтому руководитель отдела RnD теряет 680 часов, что создаёт риск перегрузки наставников и снижения качества обработки клиентских обращений

Обратите внимание, что в шаблоне описания проблемы нет никакого описания (или даже намёка) решения.
Потому что решение всегда выбирается из альтернатив.

UPD: рекомендую посмотреть шаблон Тойоты