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