Когда у задачи слишком мало этапов, работа выглядит ровной, хотя на самом деле застревает в проверке, согласовании или ожидании ответа. Когда этапов слишком много, команда перестает воспринимать доску как рабочий инструмент и обновляет статусы формально. В обоих случаях руководитель теряет картину потока, а исполнители — время и внимание.
Проблема обычно не в том, что команде «нужна более детальная доска» или, наоборот, «надо все упростить». Ошибка в другом: этапы выбирают не под управленческие решения, а по шаблону, привычке или желанию описать процесс во всех подробностях. Поэтому доска перестает отвечать на главный вопрос: где именно сейчас находится работа и что с ней делать дальше.
Этапы должны показывать разные типы состояния, а не все микрошаги
Полезный статус — это не просто название шага. Это состояние, по которому команда и руководитель принимают разное решение. Если по двум колонкам действия одинаковые, скорее всего, одна из них лишняя.
Например, статусы «взято», «начато», «делаем», «в процессе» часто не дают новой информации. А вот различие между «выполняем», «ждем внешнего ответа» и «на проверке» уже управленчески важно: в одном случае нужно защищать фокус исполнителя, в другом — снимать блокировку, в третьем — ускорять ревью или тестирование.
Проблема начинается, когда в одну колонку складывают разные типы ожидания и работы. Статус «в работе» особенно опасен: он скрывает и активное выполнение, и паузу из-за зависимости, и очередь на согласование. Формально задача движется, но понять реальную загрузку и узкое место невозможно.
Работая в Scorework стадии задач и их статусы будут разделены: стадия показывает место задачи в процессе, а статус — её текущее состояние. Поэтому доску не нужно раздувать промежуточными колонками вроде «в работе» или «на паузе».
Часто этапы копируют из чужого инструмента или старого процесса. Команда уже изменилась: появились новые роли, часть согласований исчезла, что-то автоматизировали, а доска осталась прежней. В результате люди либо обходят неудобные статусы, либо двигают задачи «для порядка», не связывая это с реальной работой.
Есть и обратная крайность: желание зафиксировать каждый микрошаг. Так появляются доски с 10–15 колонками, где отдельно живут «готово к работе», «в работе», «почти готово», «передано», «на уточнении», «ожидает подтверждения» и другие промежуточные состояния. Такая детализация выглядит аккуратно, но почти не помогает управлять сроками. Чем больше декоративных колонок, тем ниже качество обновления статусов.
Как это выглядит в реальной команде
В продуктовой разработке часто встречается одна колонка «в работе», внутри которой смешаны кодинг, code review и тестирование. Для менеджера все выглядит нормально: карточки двигаются, команда занята. Но сроки плавают, потому что задачи неделями висят не в разработке, а в очереди на проверку. Пока review и тестирование не выделены отдельно, узкое место остается невидимым.
В маркетинговой команде проблема выглядит иначе. Доска может быть очень подробной: «бриф получен», «взято в работу», «черновик», «внутренний просмотр», «доработка», «на согласовании», «ожидает комментариев», «финализация», «подготовка публикации», «готово». Задачи как будто постоянно перемещаются, но предсказуемость не растет. Причина проста: половина колонок не влияет на решения, а реальные задержки происходят в двух местах — ожидание обратной связи и перегруженное согласование.
В support-процессах особенно заметна польза отдельного статуса «ждем клиента». Пока таких задач нет, вся очередь выглядит как активная работа команды. После разделения становится видно, сколько нагрузки реально требует действий, а сколько карточек просто ждут ответа. Это меняет и оценку capacity, и ожидания по срокам.
Если команда ведет работу в Scorework, такие блокеры будут видны без встреч или дополнительных созвонов. Нотификации и командный пульс подсвечивают paused-задачи и внешние ожидания, то есть те моменты, где процесс уже начал ломаться.
Как выбрать минимально достаточные этапы
Начинать лучше не с шаблона доски, а с фактического движения нескольких задач. Полезно взять 10–15 недавно завершенных карточек и пройти по ним вручную: где была активная работа, где ожидание, где проверка, где внешняя зависимость. Обычно уже на этом шаге видно, что часть текущих колонок ничего не отражает, а часть важных состояний вообще не выделена.
Хорошая рабочая логика обычно строится вокруг нескольких разных типов состояния:
задача еще не взята в исполнение;
по ней идет активная работа;
результат проверяется или согласуется;
задача ждет внешнего ответа или входа;
задача действительно завершена.
Это не универсальный шаблон, а каркас. В конкретной команде могут понадобиться дополнительные этапы, если по ним принимаются разные решения. Например, для разработки часто полезно отделять проверку от выполнения. Для кросс-функциональных процессов — явно выделять внешнее ожидание. Для контентных и маркетинговых задач — отдельно держать согласование, если именно там возникает основная задержка.
Хороший проверочный вопрос для каждого статуса звучит так: если задача находится здесь, что команда делает иначе? Если ответ расплывчатый — «ну, просто следующий шаг процесса» — статус, скорее всего, декоративный. Если ответ конкретный — «здесь нужен ревьюер», «здесь мы ждем клиента и не считаем это активной загрузкой», «здесь надо эскалировать зависимость» — этап оправдан.
Еще одно полезное правило: не смешивать выполнение и ожидание. Это самая частая причина искаженной картины. Ожидание внешнего ответа, пауза из-за блокера и активная работа — три разных состояния. Пока они лежат в одной колонке, доска не показывает поток, а маскирует его.
Отдельно стоит пересматривать этапы по фактическим зависаниям, а не по ощущениям. Раз в квартал достаточно посмотреть, где задачи проводят больше всего времени и где чаще всего теряют предсказуемость. Если колонка почти не используется или не помогает принять решение, ее лучше убрать. Если повторяется одна и та же невидимая задержка, этап нужно выделить явно.
Признаки полезной и бесполезной доски
Сигнал | Что это значит | Что делать |
|---|---|---|
Много задач в «в работе» | Смешаны разные состояния | Разделить выполнение, проверку, ожидание |
Карточки двигаются часто, сроки плавают | Есть декоративные этапы | Убрать статусы без управленческой ценности |
Нагрузка команды кажется завышенной | В активной работе лежит ожидание | Вынести внешний wait-статус отдельно |
Колонки почти не обновляют | Доска неудобна для реальной работы | Сократить число переходов |
Узкие места обсуждают на ощущениях | Нет видимости реального потока | Пересобрать этапы по фактическим зависаниям |
Короткий диагностический чек-лист
Если на большинство вопросов ответ «да», этапы задач пора пересматривать.
В одной колонке смешаны работа, ожидание и согласование.
У команды есть статусы, разницу между которыми никто не может четко объяснить.
Задачи формально двигаются по доске, но это не улучшает прогноз по срокам.
Основные задержки обнаруживаются только на встречах или вручную.
Люди забывают менять статусы или делают это задним числом.
По части колонок непонятно, какие действия должны следовать со стороны команды или руководителя.
Доска нужна не для описания процесса, а для управления потоком
Сильная доска не обязана отражать весь процесс во всех деталях. Она должна показывать именно те состояния, которые влияют на решения: где работа идет, где стоит, где упирается в проверку, где зависит от внешней стороны. Все остальное создает визуальный шум.
Минимально достаточные этапы почти всегда лучше избыточных, если они отделяют разные типы состояния и помогают увидеть узкие места. Поэтому хороший набор колонок собирают не «как принято», а из реального потока команды. И затем спокойно пересматривают по мере того, как меняется сама работа.
