Как пощупать эффективность: три вопроса, которые я задаю себе перед любым решением

Полгода назад я перестроил один процесс в команде. Убрал лишнее, сделал удобнее, быстрее. Все были довольны. Команда говорила «наконец-то нормально работает».

Через месяц посмотрел на цифры. Результат не сдвинулся. Вообще. Красивый процесс, ноль эффекта. Я оптимизировал комфорт, а не то, ради чего этот процесс вообще существует.

И вот тут мне стало интересно: а что вообще значит «эффективно»? Не философски, а прямо на практике. Как это пощупать?

Большинство людей оценивают эффективность по ощущениям. Я сам так делал долгое время. «Кажется, стало быстрее». «Вроде меньше багов». «Ну, команда не жалуется». Проблема в том, что ощущения – это паршивый индикатор.

Есть такой принцип: как только начинаешь гнаться за конкретной метрикой, метрика перестаёт отражать то, ради чего её придумали. Звучит как парадокс, но посмотрите вокруг: примеров вагон. Я писал об этом раньше: просьба быть эффективнее без уточнения «в чём именно» это ловушка.

Продакт трекает NPS. Было 32, стало 41. Рост, ура, шампанское. В тот же квартал компания теряет трёх крупнейших enterprise-клиентов. Почему? Потому что NPS измерял удовлетворённость юзеров, которые оценили новый UI. А enterprise-клиенты молча ушли из-за надёжности API, которую никто не мерил. Команда смотрела на один прибор и не заметила, как самолёт теряет высоту.

Я стал задавать себе три вопроса. Не потому что прочитал умную книжку, а потому что устал попадать в одни и те же ловушки.

Первый вопрос про реальное предназначение. Не «что написано в описании задачи», а «что сломается, если это убрать». Звучит же просто?

Пилоты, когда фиксируются на одном приборе, перестают видеть, что вообще происходит с самолётом. У них для этого даже термин есть: tunnel vision. С эффективностью ровно так же: фокусируешься на удобстве процесса и не замечаешь, что он вообще не влияет на результат.

Пример из жизни. Разработчик строит красивый внутренний инструмент для логирования. Три недели работы. Все пользуются, всем нравится. Экономит 60 секунд в день на человека. В команде четыре человека. Итого: 4 минуты экономии в день. За год это примерно 16 рабочих часов. Три недели разработки это 120 рабочих часов. Окупится через 7 лет. Если бы разработчик задал себе вопрос «а для чего?» до начала работы, потратил бы эти три недели на то, что реально двигает продукт.

Возьмём покрупнее. Компания вкладывает кучу денег в HR-бренд: видео снимают, на конференциях выступают, премии получают. А наём буксует. Потому что бутылочное горлышко не в том, что кандидаты не знают о компании. А в том, что из 10 офферов принимают 3. Проблема в конверсии offer→acceptance, а не в воронке сверху. Год усилий в неправильное место.

Я сам долго путал «удобно работать» с «работает эффективно».

Удобный процесс может быть бесполезным. Неудобный может оказаться критически важным.

Адекватность – это про то, чтобы смотреть на вещи на уровне их реального предназначения.

Второй вопрос. Если ты перестанешь за этим следить, что произойдёт?

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

Простой принцип: если человек понимает зачем, он работает сам. Не понимает, и ты становишься его напоминалкой.

Мой любимый тест на автономность из собственной практики с n8n. Построил автоматизацию для анализа контента. Первую неделю проверял дважды в день: всё ли работает, не сломалось ли. Вторую проверял один раз в день. На третью неделю забыл про неё на пять дней. Вернулся, а там 37 запусков без единой ошибки. Вот это автономно. Это отдельная тема, я разбирал её подробнее.

А рядом другой воркфлоу, который я запускаю руками «когда вспомню». Должен работать каждый день, а реально запускается раз в три дня. Не автономный, значит не эффективный, как бы красиво он ни был собран. Автоматизация рутины это не цель, а первый шаг.

То же самое с людьми. Сеньор-разработчик, который закрывает задачи быстрее всех, молодец. Но если после его ухода другие из разработки не могут решить похожие задачи сами, он не был эффективным. Он был быстрым. Эффективность в моём понимании это когда система работает без конкретного человека.

Тест простой: если ты выпадешь из процесса на неделю, что произойдёт? Если всё встанет, у тебя проблема с автономностью. Если ничего не изменится, вопрос к адекватности (зачем ты вообще в этом процессе?). Баланс где-то посередине.

Третий вопрос. Всё вокруг меняется. То, что работало в прошлом квартале, может быть мёртвым грузом сейчас. Нужно уметь это замечать.

Google лет пять копали, что отличает лучшие команды от остальных (DORA, слышали наверное). Главный вывод неожиданный: лучшие команды отличаются не тем, что редко ошибаются, а тем, что быстро восстанавливаются. Ключевая метрика – не частота инцидентов, а время до восстановления. Адаптивность важнее безупречности.

Военные это поняли ещё в 70-х и придумали After Action Review: разбор «что планировали, что вышло, почему, что менять» прямо по горячим следам. Google SRE взяли ту же идею, назвали post-mortem и сделали вид, что придумали сами. Смысл один: встроить рефлексию в рабочий ритм, а не «разбираться, когда всё совсем сломается».

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

У меня то же самое. Когда что-то работает, не хочется трогать. Даже когда сигналы говорят, что контекст изменился. Инерция – штука мощная.

Все три «А» не про последовательность выполнения. Это одновременные фильтры. Можно иметь полностью автономный процесс, который делает не то, что нужно. Или идеально понимать ситуацию, но не иметь возможности ничего изменить.

Сквозной пример. Команда продаж. Проверяем:

Команда может проходить по одному параметру и проваливаться по двум другим. Эффективность – когда все три на месте.

Я для себя называю это тремя А («трипл эй!»): адекватность, автономность, адаптивность. Не потому что красиво звучит. Просто удобно держать в голове три контрольных вопроса вместо абстрактного «подумай об эффективности».

Есть места, где это не работает.

Без данных это бесполезно. Чтобы ответить на три вопроса, нужно что-то измерять. Если у тебя нет цифр, ты снова оцениваешь по ощущениям. А получить правильные данные часто сложнее, чем сам фреймворк.

Адаптивность легко превращается в оправдание. «Контекст изменился, надо всё переделать» это удобная отмазка, когда просто надоело. Я сам попадался: бросал что-то на полпути, потому что якобы «изменились условия». А на самом деле просто потерял интерес. Фреймворк не подскажет, сколько ждать перед тем, как адаптироваться. Это всё ещё человеческое решение.

В бюрократии эти вопросы только злят, но не помогают. Если организация требует трёх уровней согласования на каждый чих, ты можешь хоть сто раз спросить «работает ли это без меня?», ответ будет «нет», и ты ничего с этим не сделаешь. Фреймворк помогает увидеть проблему, но не всегда помогает её решить.

И последнее: три А подсказывают, какие вопросы задавать, но не подсказывают, что именно измерять. Для больницы, для стартапа, для контент-проекта метрики будут совершенно разными. Доменная экспертиза нужна по-прежнему.

Три вопроса. Можно применять к процессу, к инструменту, к человеку в команде, к себе.

1. Для чего это существует на самом деле? (Адекватность) Не что написано в документации, а что сломается, если убрать.

2. Работает ли это без моего постоянного участия? (Автономность) Если нужно постоянно напоминать, мониторить, подталкивать, то это не система, а ручная работа с бюрократическим интерфейсом.

3. Когда последний раз это менялось в ответ на изменение контекста? (Адаптивность) Если ответ «никогда» или «давно», то это уже сигнал, а не ответ.

Их сложность не в том, чтобы запомнить. А в том, чтобы честно ответить. Особенно когда ответ неприятный.

А у тебя есть что-то, что работает, но ты не можешь объяснить зачем? Или процесс, который все хвалят, но цифры не двигаются? Делитесь в комментах, интересно посмотреть на примеры.