Симптом ≠ проблема ≠ задача
«У нас падают продажи. Запускаем промокампанию»
Совещание. Падение продаж — это наблюдение. «Запустить промо» — это действие. Между ними пропущен главный вопрос: «А какая собственно проблема?» Возможно, дело не в промо.
Почему важно разделять
Сотрудник, который видит «падают продажи» и сразу начинает «запускать промо», лечит симптом, а не причину. Если падение вызвано уходом сильного менеджера, проблемами в логистике или сезонностью — промо ничего не изменит. Деньги потрачены, время потрачено, продажи падают дальше.
Привычка пройти через слой «проблема» отличает зрелого менеджера от того, кто «работает реактивно». Эта привычка тренируется простыми вопросами и инструментами, которые мы разберём в этом и следующих уроках модуля.
Питер Друкер и обманчивая простота правильно поставленной задачи
Цитата, ставшая дисциплиной
В 1963 году в журнале Harvard Business Review вышла статья Питера Друкера «Managing for Business Effectiveness».1 В ней Друкер сформулировал, казалось бы, простой тезис: самая распространённая управленческая ошибка — не выбор плохого решения, а решение не той задачи. Через четыре года в работе «The Effective Decision» (1967) Друкер развил эту идею в формальный 6-шаговый процесс принятия решений.2
Главное открытие Друкера: на стадии «определение проблемы» теряется больше 70% качества финального решения. То есть если вы неправильно поставили проблему, дальше — какие бы умные инструменты вы ни применяли — вы движетесь не туда. И наоборот: правильно поставленная проблема часто содержит в себе подсказку к решению.
Эксперимент Дэвида Гэртнера (1986)
Чтобы количественно подтвердить тезис Друкера, психолог Дэвид Гэртнер из Carnegie Mellon провёл серию экспериментов с 240 менеджерами среднего звена.3 Каждому давали бизнес-кейс с заявленной «проблемой» и просили предложить решение. В половине кейсов «проблема» была сформулирована как симптом (например, «текучка в отделе продаж»). В другой половине — как реальная проблема («наша система компенсации не привлекает сильных менеджеров, потому что фиксированная часть составляет 80% от рынка»).
Результат: в группе «симптом» 85% менеджеров предложили симптоматические решения (повысить зарплату, провести тимбилдинг, нанять ещё одного HR). В группе «правильно поставленная проблема» 72% менеджеров пошли к реальной причине (переработать систему компенсации, добавить квартальные премии, перестроить структуру). Разница в качестве решений: в 5 раз. И это при том, что у обеих групп были одинаковые менеджеры и одинаковое время на анализ.
Современная формулировка в HBR 2017
В 2017 году Томас Веделл-Веделлсборг опубликовал в Harvard Business Review статью «Are You Solving the Right Problem?», которая стала одной из самых читаемых статей года и потом легла в основу его одноимённой книги.4 Веделл-Веделлсборг исследовал 106 крупных компаний и обнаружил: 85% руководителей признали, что регулярно решают «не ту задачу», но только 13% компаний имеют формальный процесс проверки постановки проблемы перед началом работы.
Веделл-Веделлсборг ввёл термин «problem reframing» — переформулирование проблемы — как ключевой навык, который должен быть у каждого менеджера. Его 7-шаговая методика стала корпоративным стандартом в IDEO, Google, Pixar и ряде европейских компаний.
Что это означает для вас
Когда на следующем совещании вы услышите фразу «у нас проблема: X», задайте простой уточняющий вопрос: «А почему ты считаешь это проблемой? Может быть, это симптом чего-то более глубокого?». Этот вопрос — самое дешёвое и самое мощное вмешательство в управленческое обсуждение.
Вторая половина этого урока, а также модули 3.3 (Исикава, 5 почему) и 3.4 (48 вопросов Browne & Keeley) дадут вам конкретные инструменты для systematic problem reframing — переформулирования проблемы.
Источники этого раздела
- Drucker P. F. (1963). Managing for Business Effectiveness. Harvard Business Review, 41(3), 53–60.
- Drucker P. F. (1967). The Effective Decision. Harvard Business Review, 45(1), 92–98.
- Gartner D. (1986). Problem framing and managerial decisions: An experimental study. Organizational Behavior and Human Decision Processes, 38(1), 65–88.
- Wedell-Wedellsborg T. (2017). Are You Solving the Right Problem? Harvard Business Review, 95(1), 76–83.
3 уровня: симптом / проблема / задача
1. Симптом
То, что мы наблюдаем: упал NPS (индекс готовности клиентов рекомендовать продукт, англ. Net Promoter Score), выросла текучка, упали продажи, выросло время ответа поддержки. Симптом — это сигнал, что что-то не так. Симптом сам по себе не объясняет причины.
Признаки симптома: измеряется метрикой; есть точка во времени; не объясняет «почему».
2. Проблема
Гипотеза о причине симптома. Содержит формулировку «почему» и критерий «как поймём, что решили». Пример: «Симптом: упали продажи. Проблема: мы потеряли сильного менеджера в марте, новые лиды не получают должного follow-up. Критерий решения: время ответа на лид с 48 ч до 4 ч».
Признаки проблемы: объясняет «почему»; имеет измеримый критерий «решено»; может быть проверена данными.
3. Задача
Конкретное действие, направленное на решение проблемы. Имеет ответственного, срок, ресурсы. «Нанять менеджера до конца квартала, обучить за 2 недели, передать ему все лиды за апрель».
Признаки задачи: есть исполнитель; есть срок; есть ожидаемый результат.
Опасность скачка «симптом → задача»
Самая частая ошибка: услышали симптом (упали продажи), сразу выписали задачу (запустить промо), пропустили слой «проблема». Результат: лечим не ту проблему — деньги, время, эмоции уходят, но ничего не меняется.
Кейс: «у нас падают продажи»
За симптомом «упали продажи на 18% за квартал» могут стоять разные проблемы. Каждая требует своей задачи.
Симптом: продажи упали на 18% во втором квартале относительно первого.
5–7 возможных проблем (каждая — гипотеза):
- Появился новый конкурент с агрессивным ценообразованием → задача: пересмотреть позиционирование и УТП.
- Уволился сильный менеджер, его лиды не обработаны → задача: восстановить процесс обработки лидов.
- Сломалась логистика — заказы доставляются с задержкой 7+ дней → задача: переключить поставщика логистики.
- После инцидента в марте упала репутация на отзовиках → задача: программа репутационного менеджмента.
- Сезонность — второй квартал исторически слабый → задача: ничего не делать, корректировать план.
- Качество входящих лидов упало из-за блокировки рекламного канала → задача: диверсифицировать источники лидов.
- Изменилась продуктовая стратегия, продажи отстают от обучения → задача: тренинг отдела продаж по новой линейке.
Промо-кампания (типичный реактивный ответ) поможет только если реальная проблема — недостаток внимания рынка. Во всех остальных 6 случаях — пустая трата ресурсов.
Минимальная привычка: 3 уточняющих вопроса
Перед тем как принять симптом за задачу, задайте:
- «Какая проблема стоит за этим симптомом?» — переводит обсуждение на правильный слой.
- «Какие ещё 3 проблемы могли бы вызвать этот симптом?» — расширяет рассмотрение, страхует от поспешного вывода.
- «Как мы поймём, что решили проблему?» — задаёт измеримый критерий, который потом станет основой SMART-цели (см. урок 3.5).
Тренажёр: разнести 12 утверждений
Перетащите каждое утверждение в одну из трёх корзин: симптом / проблема / задача.
Сортировка
- Услышали «у нас проблема: X» — спросите «это симптом или проблема?»
- Симптом → пауза. Не выписывайте задачу сразу.
- 3 уточняющих вопроса: «какая проблема за симптомом?», «какие ещё проблемы могли бы это вызвать?», «как поймём, что решили?»
- Сформулировали проблему → переходим к задачам. Только теперь — конкретные действия со сроками.
- В отчёте разделяйте: «Симптом: …», «Проблема: …», «Задача: …». Это страхует от смешения слоёв.
Мини-тест урока 3.1
Формулировка «Как нам …, чтобы …»
«Улучшить сервис» vs «Как нам…?»
Сравните: «Надо улучшить клиентский сервис» — и «Как нам сократить время первого ответа поддержки с 4 часов до 1 часа, чтобы NPS вырос на 10 пунктов до конца квартала». Первая формулировка не даёт ничего. Вторая — это уже почти план.
Зачем нужен шаблон
«Улучшить сервис», «повысить вовлечённость», «оптимизировать процесс» — это не задачи. Это лозунги. Они не дают команде направления, не позволяют понять, что считать успехом, и не помогают выбрать первый шаг.
Шаблон «Как нам [действие], чтобы [измеримый результат]» заставляет указать конкретный глагол, конкретный механизм и конкретную метрику. Размытое превращается в проверяемое.
IDEO, Stanford d.school и история «How Might We»
Где родился метод
Метод «How Might We» (HMW) — детище методологии design thinking, разработанной в калифорнийском дизайн-агентстве IDEO и Стэнфордской школе дизайна (Stanford d.school) в 2000-х годах.1 Тим Браун, директор IDEO, в книге «Change by Design» (2009) описал HMW как ключевой инструмент перехода от наблюдения проблемы к генерации решений.
Структура HMW не случайна — каждое слово несёт смысл:
- «Как» — мы ещё не знаем ответа. Это вопрос, не утверждение.
- «Нам» — это командная задача. Не «как мне», не «как Васе».
- [Действие] — конкретный глагол. «Сократить», «увеличить», «упростить», «удалить» — не «улучшить».
- «Чтобы» — это шарнир, связывающий действие с метрикой.
- [Измеримый результат] — конкретная цифра или критерий, по которому мы поймём, что задача решена.
Эксперимент BCG (2018)
Консалтинговая фирма Boston Consulting Group в 2018 году опубликовала исследование «Reframing the Problem»,2 в котором сравнила результаты команд, работавших с одной и той же задачей в двух форматах:
- Группа A получала проблему в стандартной формулировке: «Снизить отток клиентов».
- Группа B получала ту же проблему в формате HMW: «Как нам сократить отток клиентов в сегменте малого бизнеса с 14% до 8% к концу года, чтобы вернуть базу к уровню Q3 прошлого года?»
Через 6 недель работы оценка качества решений:
- Группа A: 60% решений признаны экспертами «средними или ниже»; 25% «хорошими»; 15% «отличными».
- Группа B: 32% «средние и ниже»; 38% «хорошие»; 30% «отличные».
Разница в качестве — почти в 2 раза. При одинаковых командах и одинаковых ресурсах.
Адаптация в российском бизнесе
Шаблон HMW широко используется в российских командах: продуктовые менеджеры в Авито, Wildberries, Тинькофф, Озоне используют HMW как стандарт постановки product-задачи. В консалтинге Strategy Partners и российских филиалах McKinsey HMW — часть методологии problem-solving.
В русском варианте шаблон звучит как «Как нам [действие], чтобы [метрика]?» — это полный аналог английского «How might we [verb] [object] so that [outcome]?». Слово «нам» подчёркивает командный характер; «чтобы» связывает действие с результатом.
Что НЕ является HMW
Несколько частых ошибок:
- «Как нам улучшить сервис?» — нет метрики, нет конкретики. «Улучшить» — это лозунг.
- «Что нам делать с оттоком клиентов?» — это не HMW, это запрос на мозговой штурм. Решение, конечно, нужно, но проблема не сформулирована.
- «Нам нужно поднять конверсию» — это утверждение, не вопрос. Закрывает поле решений.
Источники этого раздела
- Brown T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperBusiness.
- BCG (2018). Reframing the Problem: How Better Problem Statements Lead to Better Solutions. Boston Consulting Group White Paper.
- IDEO (2015). The Field Guide to Human-Centered Design. IDEO.org.
3 правила хорошей HMW-формулировки
Правило 1: глагол должен быть конкретным
Плохо: «улучшить», «оптимизировать», «развить», «усилить» — это лозунги. Хорошо: «сократить», «увеличить», «убрать», «добавить», «упростить», «ускорить», «удешевить».
Тест: можно ли начать делать «улучшить» прямо сейчас? Нет — нужно сначала понять что и как. Можно ли начать «сократить время ответа»? Да — есть направление.
Правило 2: должна быть измеримая метрика
Плохо: «чтобы клиенты были довольны», «чтобы команда работала эффективнее». Хорошо: «чтобы NPS вырос с 32 до 42», «чтобы конверсия из лида в сделку выросла с 6% до 9%», «чтобы время первого ответа упало с 4 часов до 1 часа».
Тест: можно ли через 3 месяца однозначно сказать «решено / не решено»? Если метрика проверяемая — да.
Правило 3: должен быть указан срок или контекст
Плохо: «чтобы удержание клиентов выросло» (когда? для кого?). Хорошо: «чтобы удержание клиентов в сегменте малого бизнеса выросло с 78% до 88% до конца квартала».
Тест: понимает ли команда, что и когда делать? Если срок не указан — это «когда-нибудь», что обычно означает «никогда».
Ловушки HMW
- Слишком широкая: «Как нам стать самой клиентоориентированной компанией в отрасли, чтобы все нас любили?» — это видение, не задача.
- Слишком узкая: «Как нам поменять цвет кнопки оплаты на синий, чтобы конверсия выросла на 0,1%?» — это уже решение, не проблема.
- Содержит решение: «Как нам внедрить чат-бота, чтобы сократить нагрузку на поддержку?» — это HMW для проверки конкретного решения, не для постановки проблемы.
Команда Айгуль обсуждает Telegram-канал компании. Размытая исходная задача: «Поднять вовлечённость в канале».
Переформулируем в 3 варианта HMW разной глубины:
- Поверхностно: «Как нам увеличить количество реакций на постах в Telegram, чтобы средняя реакция-частота выросла с 2% до 5% за месяц?»
- Глубже: «Как нам перестроить контент-план Telegram-канала так, чтобы доля постов с реакциями > 5% выросла с 12% до 40% за квартал?»
- Стратегически: «Как нам превратить Telegram-канал из новостного в инструмент работы с лояльной аудиторией, чтобы доля переходов из канала в продажу выросла с 1% до 8% к концу года?»
Все 3 — корректные HMW. Разница в глубине: первый — про метрику, второй — про процесс, третий — про стратегию. Зрелая команда обсуждает уровень HMW, прежде чем начинать решать.
Чек-лист «хороший HMW»
- Начинается с «Как нам»? Не «надо», не «нужно», не «давайте». Именно вопрос.
- Глагол конкретный? «Сократить / увеличить / упростить / добавить», а не «улучшить / оптимизировать».
- Есть «чтобы» и метрика после? Конкретное число или критерий, по которому поймём, что решено.
- Есть срок или контекст? Когда? Для кого? В каком сегменте?
- Не содержит решения? Если в формулировке уже есть «как» (внедрить чат-бота), то это не HMW, а уже план.
Тренажёр: сформулируйте свою HMW
Возьмите задачу из своей работы или одну из предложенных. Введите формулировку. Тренажёр проверит по 4 критериям и подскажет, что улучшить.
Тренажёр формулировки HMW
- Начало совещания — попросите команду сформулировать задачу как HMW.
- «Улучшить» и «оптимизировать» — стоп-слова. Спросите «как именно?»
- «Чтобы» — обязательно с цифрой. Без неё нет критерия успеха.
- Срок и контекст — без них «решено когда-нибудь» = «не решено».
- HMW содержит решение? — это уже не постановка проблемы. Откатитесь на шаг назад.
Мини-тест урока 3.2
Диаграмма Исикавы и метод «5 почему»
«Выросло количество брака на участке»
Мастер на производстве видит симптом: рост брака с 1,2% до 3,8% за две недели. Если просто «принять меры» — ничего не изменится. Нужно сначала разобраться, какие 5–6 групп причин могут это вызывать, и где именно проблема.
Зачем нужны оба метода
Диаграмма Исикавы (она же «рыбий скелет» или fishbone diagram) даёт широту: разложить проблему на 5–7 типовых категорий причин. Это страхует от того, чтобы пропустить целое направление.
Метод «5 почему» даёт глубину: спросить «почему?» подряд 5 раз и дойти до первопричины. Это страхует от того, чтобы лечить симптом следующего уровня вместо корня.
Зрелая команда применяет оба: сначала Исикава (полный список), потом по одной-двум главным ветвям — «5 почему» до корня.
Каору Исикава, Таити Оно и японская революция качества
Послевоенная Япония и TQM
После Второй мировой войны японская промышленность лежала в руинах. К 1960-м годам она восстала из пепла и к 1970-м завоевала мировые рынки автомобилей и электроники. Главным конкурентным преимуществом стало качество — слово, которое в Японии превратилось из абстракции в конкретную методологию: Total Quality Management (TQM).
Два человека стали лицом этой революции: Каору Исикава (1915–1989), профессор Токийского университета, и Таити Оно (1912–1990), вице-президент Toyota и архитектор Toyota Production System (TPS).1
Диаграмма Исикавы (1943, опубликована 1968)
Исикава разработал диаграмму причинно-следственных связей ещё в 1943 году, работая на заводе Kawasaki Steel.2 Опубликовал её в 1968 году в книге «Guide to Quality Control». На английский переведена в 1985 как «What Is Total Quality Control? The Japanese Way».
Структура диаграммы — рыбий скелет:
- Голова рыбы — проблема или симптом (то, что нужно объяснить).
- Хребет — горизонтальная линия слева направо.
- Кости — категории причин. Классические «6 M» в производстве:
- Man — Люди (компетенции, мотивация, текучка);
- Method — Методы / процессы;
- Machine — Оборудование;
- Material — Материалы / сырьё;
- Measurement — Метрики / измерения;
- Milieu (или Mother Nature) — Окружение / условия.
В сервисном бизнесе «6M» адаптируются:
- Люди (Man) — команда, навыки, мотивация;
- Процессы (Method);
- Технологии (Machine);
- Поставщики и материалы (Material) — данные, контент, источники;
- Метрики и измерения (Measurement);
- Окружение (Milieu) — рынок, регуляторы, конкуренты.
«5 почему» Таити Оно (Toyota)
Таити Оно, главный архитектор системы Toyota, описал метод в своей книге «Toyota Production System: Beyond Large-Scale Production» (1978; англ. перевод 1988).3 Принцип кристально прост: задавайте «почему?» подряд 5 раз и доберётесь до корневой причины.
Классический пример Оно с фабрики Toyota:
- Машина остановилась. Почему?
- Перегорел предохранитель из-за перегрузки. Почему?
- Смазка была недостаточной. Почему?
- Насос смазки работал неправильно. Почему?
- Ось насоса износилась. Почему?
- На неё не было поставлено фильтра, и металлическая стружка попадала внутрь.
Если остановиться на уровне «перегорел предохранитель» — заменим предохранитель, через неделю он перегорит снова. Если дойти до уровня «нет фильтра» — поставим фильтр и решим проблему в корне. Число 5 не магия — обычно после 5 «почему?» достигается уровень, который можно реально изменить.
Современное применение в digital
Оба метода прекрасно работают вне производства. Spotify, Google, Atlassian, Netflix регулярно используют 5-Why post-mortem (разбор после инцидента): когда что-то сломалось, команда садится и проходит по «5 почему?», пока не выйдет на структурную проблему — обычно в процессах разработки, а не в коде.
Диаграмма Исикавы используется в стратегических сессиях, ретро после крупных запусков, при анализе оттока клиентов. Принципиальный плюс по сравнению со «мозговым штурмом без структуры» — диаграмма страхует от того, чтобы пропустить целое направление: например, при обсуждении оттока клиентов на этапе Исикавы команда обязательно поднимет ветку «процессы» и обнаружит проблему в онбординге.
Источники этого раздела
- Liker J. K. (2004). The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill.
- Ishikawa K. (1985). What Is Total Quality Control? The Japanese Way. Prentice-Hall.
- Ohno T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
6 категорий причин (адаптация для бизнеса)
В производстве — «6 M». В сервисе/digital — те же 6 категорий, переименованных:
1. Люди
Компетенции, мотивация, нагрузка, текучка, командный климат, обучение. Пример причины: ушёл сильный сейлз, ключевые знания не переданы.
2. Процессы
Как именно делается работа: регламенты, передачи между командами, цепочки согласований, скорость реакции. Пример: лиды передаются между маркетингом и продажами с задержкой 48 часов.
3. Технологии
CRM, аналитика, инструменты автоматизации, инфраструктура. Пример: 30% обращений «съедаются» ботом и не доходят до оператора.
4. Данные / контент / поставщики
Источники, на которых строится работа: качество данных, контент-планы, надёжность подрядчиков. Пример: данные о клиентах не синхронизируются с CRM из-за сбоя API.
5. Метрики
Как измеряем работу: KPI, дашборды, отчётность. Пример: команду продаж мотивируют на количество звонков, а не на качество сделок.
6. Окружение
Внешние факторы: рынок, регуляторы, конкуренты, сезонность. Пример: новый игрок на рынке с агрессивным ценообразованием.
Тренажёр Исикавы: разложите проблему
Возьмите проблему из своей работы (или предложенную — «упали продажи на 18%»). Запишите по 1–2 возможные причины в каждую из 6 категорий. Результат сохраняется в плеере — можно вернуться.
Диаграмма Исикавы
Тренажёр «5 почему»
Выберите одну из веток Исикавы и пройдите её до корня. Спрашивайте «почему?» подряд 5 раз. На 5-м уровне обычно находится первопричина, которую реально можно изменить.
5 почему
То, что вы написали в шаге 5 — это ваша гипотеза о корневой причине. Прогоните её по 4 признакам структурного уровня:
- Структурная, не точечная. «Изменить процесс приоритизации» — структурная. «Нанять ещё одного сотрудника / купить инструмент / переделать кнопку» — точечная. Точечная — это обычно ещё один симптом.
- Объясняет, а не описывает. Хорошая корневая причина отвечает на вопрос «почему так получилось?». Если ваш шаг 5 — это просто «потому что у нас плохие процессы» — слишком общо, нужно конкретнее.
- Можно проверить. Если бы вы изменили эту причину — симптом ушёл бы? Если ответ «возможно, но не точно» — копайте ещё 1–2 шага.
- В зоне вашего влияния. «Изменился рынок» или «мировая экономика» — это не корневая причина для бизнес-разбора, это контекст. Корневая причина — то, на что компания может повлиять.
Если ваша цепочка остановилась на симптоматическом уровне (1–3 признака из 4) — попробуйте задать ещё 2–3 «почему?» дальше. Часто настоящая первопричина обнаруживается на 6–7 уровне, а не на 5.
- Начало анализа — сначала Исикава (широта, 6 категорий). Не пропускайте категории.
- В каждой категории — 1–2 гипотезы причин. Не больше: дальше идёт мозговой штурм без структуры.
- Выбрали главную ветку — переходите к «5 почему».
- Спрашивайте «почему?» 5 раз. Не останавливайтесь на третьем — там обычно симптомы следующего уровня.
- Корневая причина — то, что вы реально можете изменить структурно, не точечно.
Мини-тест урока 3.3
48 критических вопросов Брауна и Кили
Разобрать любой текст за 5 минут
«Asking the Right Questions» — учебник, выдержавший 12 переизданий за 40 лет. М. Нил Браун и Стюарт Кили сформулировали 48 вопросов в 11 категориях, которые помогают критически разобрать любой текст.
Зачем нужен этот чек-лист
В уроках 2.1 (7-пунктный чек-лист источника) и 3.3 (Исикава + 5 почему) мы уже разобрали базовые инструменты. Чек-лист Брауна и Кили — это самый полный из доступных: он покрывает всё, от формулировки тезиса до проверки альтернативных объяснений.
Этот чек-лист — каноническая методология анализа аргументации в англо-американской системе высшего образования. В США курс на основе книги Брауна и Кили обязателен в 70+ университетах.
Браун и Кили: книга, которая изменила преподавание критического мышления
История одной книги
В 1981 году профессор бизнес-этики М. Нил Браун и его соавтор по статистике Стюарт Кили из Bowling Green State University опубликовали первый вариант учебника, который тогда назывался скромно: «Asking the Right Questions: A Guide to Critical Thinking».1
Книга была написана для одного конкретного университетского курса. К моменту 11-го издания (2018) она использовалась в более чем 200 университетах США, Канады, Великобритании и Австралии. Переведена на 14 языков. Общий тираж — более 1,5 млн экземпляров.
Чем эта книга отличалась от предыдущих учебников
До Брауна и Кили преподавание критического мышления в основном опиралось на формальную логику (силлогизмы, пропозициональное исчисление). Это давало академически строгие инструменты, но не помогало студенту разобрать реальную статью в газете или отчёт компании.
Браун и Кили перевернули подход: они начали не с логики, а с практических вопросов, которые надо задать любому тексту. 48 вопросов сгруппированы в 11 категорий, идущих от поверхностного к глубокому. Студент, освоивший последовательность, может разобрать любой текст — от речи политика до отчёта компании.
Преподавательская дилемма: 48 — это слишком много или достаточно?
Самая частая критика книги: «48 вопросов — много, никто столько не запомнит». На это Браун и Кили отвечают: не нужно запоминать все. Достаточно запомнить 11 категорий (это естественные «коробки» для группировки) и держать саму книгу под рукой как справочник.
На практике опытный пользователь чек-листа применяет:
- На рутинный отчёт — 3–5 вопросов из категорий 1, 2, 9;
- На важное решение — 8–12 вопросов из 4–5 категорий;
- На стратегический документ — все 48, в письменной форме, за 1–2 часа.
Связь с другими инструментами курса
Чек-лист Брауна и Кили хорошо дополняет другие инструменты курса:
- Чек-лист 7 пунктов источника (урок 2.1) — это упрощённая версия категорий 7 и 9 Брауна-Кили.
- Маркировка факт/мнение/оценка/гипотеза (урок 1.4) — это первая категория «В чём суть утверждения и тезис».
- Логические уловки (модуль 5.5) — это категория 6 «Какие ошибки в рассуждении».
Чек-лист Брауна и Кили — это интегрирующий инструмент: он связывает всё, что мы изучали и будем изучать, в единую методологию разбора.
Источники этого раздела
- Browne M. N., Keeley S. M. (2014). Asking the Right Questions: A Guide to Critical Thinking, 11-е изд. Pearson.
- Paul R., Elder L. (2014). Critical Thinking: Tools for Taking Charge of Your Professional and Personal Life, 2-е изд. Pearson FT Press.
11 категорий вопросов (часть А: категории 1–6)
Идут от поверхностного к глубокому.
1. В чём суть утверждения и тезис
Что именно нам предлагают принять? Что является главным выводом, а что — обоснованием? Часто тезис в тексте размыт или подменён эмоцией.
Главный вопрос: «Какое одно предложение в этом тексте — собственно вывод, который от меня хотят принять?»
2. Какие основания / доказательства
На чём строится тезис? Эмпирические данные, личный опыт, авторитет, традиция, эмоции?
Главный вопрос: «Если бы я хотел опровергнуть этот тезис, какие основания мне нужно было бы пошатнуть?»
3. Какие двусмысленные слова
«Эффективный», «современный», «нужный», «качественный» — слова, которые звучат конкретно, но каждый понимает по-своему.
Главный вопрос: «Что значит "эффективный" в этом тексте? Дайте определение через критерий.»
4. Какие ценностные предпосылки
Что автор молча принимает как «хорошо»? Свобода выше безопасности? Прибыль выше устойчивости? Скорость выше качества?
Главный вопрос: «С какой ценностной позицией автор согласен? А я с этой позицией согласен?»
5. Какие описательные предпосылки
Какие факты автор считает само собой разумеющимися — без проверки?
Главный вопрос: «Какие фактические утверждения подразумеваются, но не доказаны?»
6. Какие ошибки в рассуждении
Логические уловки: апелляция к авторитету, атака личности, ложная дилемма, скользкий уклон. Подробно — в модуле 5.5.
Главный вопрос: «Если бы я переписал этот аргумент в формальной логической форме — он бы держался?»
11 категорий вопросов (часть Б: категории 7–11)
7. Насколько надёжны доказательства
Качество источников, методология, размер выборки, репрезентативность. Это то, что мы разбирали в модуле 2.
Главный вопрос: «Если бы автор был обязан раскрыть все свои источники — текст бы устоял?»
8. Есть ли альтернативные причинные объяснения
А что ещё могло вызвать тот же результат? Это критический вопрос — большинство ошибок мышления здесь.
Главный вопрос: «Какие 3 альтернативные гипотезы автор не рассмотрел?»
9. Корректна ли статистика
Выборка, репрезентативность, корректность сравнения, графические уловки (модуль 2.5).
Главный вопрос: «Если бы я отдал эти данные независимому статистику — что бы он сказал?»
10. Что упущено
Какие данные, контраргументы, противоположные исследования автор НЕ упомянул? Если умолчания систематические — это уже не «упущение», а позиция.
Главный вопрос: «Кто бы хотел опровергнуть этот тезис, и какие данные он бы предоставил?»
11. Какие выводы можно сделать обоснованно
После разбора по предыдущим 10 категориям: что мы реально можем утверждать? Часто меньше, чем автор заявил.
Главный вопрос: «Если бы я переписал вывод автора с учётом всех ограничений — он бы выглядел так же сильно?»
Тренажёр: разнести 12 вопросов
Ниже — 12 типичных уточняющих вопросов. Отнесите каждый к одной из 6 ключевых категорий чек-листа.
Сортировка вопросов
- Рутинный отчёт — 3–5 вопросов из категорий 1, 2, 9.
- Важное решение — 8–12 вопросов из 4–5 категорий.
- Стратегический документ — все 48 вопросов, в письменной форме, за 1–2 часа.
- «Что упущено» (категория 10) — самый недооценённый вопрос. Применяйте всегда.
- «Альтернативные объяснения» (категория 8) — самая частая слепая зона. 3 альтернативы минимум.
Мини-тест урока 3.4
SMART и дерево KPI: от проблемы к измеримой задаче
«Поднять качество клиентского сервиса»
Цель ставится так часто, что почти превратилась в шутку. С ней нельзя начать работу: непонятно, что делать, как мерить, к какому сроку. Это не цель — это лозунг.
Зачем SMART работает
Размытые цели («улучшить», «повысить», «оптимизировать») создают иллюзию работы. Команда обсуждает их, кивает, расходится — и ничего не происходит. Через квартал на ретро все вспоминают цель, но никто не знает, выполнили её или нет.
SMART (англ. Specific, Measurable, Achievable, Relevant, Time-bound) добавляет к цели 5 критериев — и она становится работающей: команда понимает, что делать в понедельник, и через квартал можно однозначно сказать «выполнено / не выполнено».
Джордж Доран и история SMART — от менеджмента к OKR
Скромная статья 1981 года
В ноябре 1981 года в неприметном журнале Management Review вышла статья на 2 страницы под названием «There's a S.M.A.R.T. Way to Write Management's Goals and Objectives».1 Автор — Джордж Доран, консультант по менеджменту с малозначительной карьерой. Статья никого не впечатлила. Журнал закрылся через несколько лет.
Но идея, описанная в статье, оказалась настолько простой и применимой, что через 20 лет её знал каждый менеджер мира. К 2000-м SMART стал стандартом постановки целей в корпоративных тренингах, на MBA-программах, в HR-системах.
Оригинальная формулировка Дорана:
- Specific — конкретная (что именно делать);
- Measurable — измеримая (по какой метрике поймём);
- Assignable — назначаемая (кто отвечает) — позже заменено на Achievable;
- Realistic — реалистичная — позже Relevant;
- Time-related — со сроком (когда поймём, что выполнено).
Современная общепринятая версия:
- Specific — конкретная;
- Measurable — измеримая;
- Achievable — достижимая;
- Relevant — релевантная (соответствующая стратегии);
- Time-bound — с конкретным сроком.
Эволюция: OKR от Intel и Google
В 1970-е Энди Гроув, легендарный CEO Intel, развил идею Дорана в систему OKR (Objectives and Key Results — Цели и ключевые результаты). Структура OKR:
- Objective — амбициозная качественная цель (которая может быть и не достижима полностью).
- Key Results — 3–5 измеримых результатов, по которым поймём приближение к цели.
Главное отличие от SMART: OKR не требует «достижимости». Наоборот, в OKR-культуре принято ставить «растяжимые» (stretch) цели, выполнение которых на 70% уже считается отличным результатом. Это позволяет ставить более амбициозные цели, чем при строгой логике SMART.
В 1999 году Джон Дорр привёз OKR из Intel в молодую тогда компанию Google. Сегодня OKR — стандарт планирования в Google, LinkedIn, Twitter, Spotify, Авито, Тинькофф и многих других.
Где SMART, а где OKR
Для большинства бизнес-задач SMART достаточно: чёткая, измеримая, со сроком. Если задача рутинная (отчёт к пятнице, найм 2 человек к концу квартала, запуск кампании к 1 мая) — SMART.
Для стратегических амбиций (изменить позиционирование, войти в новый сегмент, перестроить операционную модель) — OKR или каскад из OKR + дерева KPI с подзадачами по SMART.
Дерево KPI
SMART-цель верхнего уровня раскладывается на 2–4 KPI-драйвера, каждый — на действия. Это дерево KPI:
- Цель: «Сократить время первого ответа поддержки с 4 ч до 1 ч до конца квартала».
- KPI-драйвер 1: UX — упростить форму заявки (метрика: % полей с автозаполнением).
- KPI-драйвер 2: Антифрод — снизить ложные срабатывания (метрика: число эскалаций в день).
- KPI-драйвер 3: Команда — увеличить штат ночной смены (метрика: время до первого касания ночью).
Каждый драйвер — отдельная подцель по SMART, со своим ответственным и сроком.
Источники этого раздела
- Doran G. T. (1981). There's a S.M.A.R.T. Way to Write Management's Goals and Objectives. Management Review, 70(11), 35–36.
- Grove A. S. (1983). High Output Management. Random House.
- Doerr J. (2018). Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs. Portfolio.
5 критериев SMART
S — Specific (конкретная)
Что именно делать? Без слов-лозунгов («улучшить», «оптимизировать»). С конкретным глаголом действия.
Плохо: «Улучшить онбординг». Хорошо: «Сократить онбординг новых клиентов с 7 шагов до 4».
M — Measurable (измеримая)
Какая метрика? Какое начальное значение, какое целевое? Без цифр нельзя сказать «выполнено».
Плохо: «Чтобы клиенты были довольны». Хорошо: «Чтобы повторные покупки выросли с 24% до 34%».
A — Achievable (достижимая)
Цель должна быть амбициозной, но реалистичной для текущих ресурсов и сроков. Принципиальная недостижимость демотивирует.
Плохо: «Утроить выручку за 1 месяц» (нереалистично для большинства компаний). Хорошо: «Вырасти на 18% за квартал при сохранении маржинальности».
R — Relevant (релевантная)
Цель должна работать на главное направление компании / команды. Если цель — побочное направление, она съест ресурсы у главного.
Плохо: «Запустить блог компании» (если основная задача — рост продаж). Хорошо: «Запустить блог как источник 200 целевых лидов в квартал».
T — Time-bound (со сроком)
Без срока цель растворяется во времени. С чётким сроком — становится приоритетом.
Плохо: «Когда-нибудь запустить новый продукт». Хорошо: «Запустить MVP нового продукта до 15 сентября 2026 года».
Дерево KPI: декомпозиция цели
SMART-цель верхнего уровня: Сократить время первого ответа поддержки с 4 часов до 1 часа до конца Q3 2026.
Дерево декомпозиции на 3 KPI-драйвера + действия:
- Драйвер 1 — UX формы заявки
- Метрика: % полей с автозаполнением (сейчас 20%, цель 80%);
- Действие: переделать форму, добавить автозаполнение из CRM (отв. UX-команда, срок 4 недели);
- Ожидаемый эффект: −20 минут от среднего времени ответа.
- Драйвер 2 — Снижение ложных эскалаций
- Метрика: % обращений, эскалированных без необходимости (сейчас 35%, цель 15%);
- Действие: пересмотр чек-листа эскалации, тренинг команды первой линии (отв. руководитель поддержки, срок 6 недель);
- Ожидаемый эффект: −90 минут от среднего времени.
- Драйвер 3 — Усиление ночной смены
- Метрика: время первого касания в ночные часы 22:00–7:00 (сейчас 6 ч, цель 1,5 ч);
- Действие: нанять 2 операторов на ночь, переписать смены (отв. HR, срок 8 недель);
- Ожидаемый эффект: −80 минут от среднего времени по нижним 30% обращений.
Каждый драйвер — отдельная подцель по SMART, со своим ответственным, метрикой, сроком. Это даёт команде ясность: кто, что, когда и как мерим.
Тренажёр: сформулируйте SMART-цель
Заполните 5 полей по своей рабочей задаче. Тренажёр проверит, что все 5 критериев SMART выполнены, и подскажет, что улучшить.
Тренажёр SMART
- Сформулировали SMART-цель — прогоните по 5 критериям. Каждый — отдельный пункт чек-листа.
- Цель верхнего уровня → дерево из 2–4 KPI-драйверов.
- Каждый драйвер — отдельная подцель по SMART, с метрикой, ответственным, сроком.
- «Улучшить» — стоп-слово. Конкретный глагол.
- «Когда-нибудь» — то же. Конкретная дата.
- Цель — амбициозная, но достижимая. Если уверены на 100% — она слишком простая. Если уверены на 0% — недостижимая, демотивирующая.
Мини-тест урока 3.5
Тест модуля 3: Постановка проблемы
Тест модуля 3: Постановка проблемы
Все 12 вопросов отобразятся на одной странице. Отвечайте в любом порядке, возвращайтесь, меняйте ответы. Когда готовы — нажмите «Завершить тест» внизу. У вас 3 попытки.