Метки статусов рабочего процесса: 7 понятных статусов для вашей команды

Почему неясные статусы замедляют работу

Расплывчатые метки статусов рабочего процесса создают путаницу, которая выглядит как бурная деятельность. Люди двигают карточки вперёд, но никто не уверен, что именно изменилось. Тикет со статусом «In Progress» может означать «я только задумался над этим», «я заблокирован» или «я сделал и жду проверки», в зависимости от того, кто последний с ним работал.

Это несоответствие вызывает три предсказуемые проблемы: переделки, пропущенные передачи и шумные уведомления. Если статус не говорит, что должен сделать следующий человек, работа перелетает туда‑сюда. Если передача спрятана в расплывчатой метке, задача лежит, пока кто‑то не заметит. Если все просто меняют статусы, чтобы «показать», что они что‑то делают, лента становится размытым фоном, и реальные изменения легко пропустить.

Ещё одна распространённая проблема — одна и та же метка используется по‑разному на разных экранах. Один коллега использует «Ready», чтобы обозначить «готово к проверке». Другой — «готово к началу работы». Менеджеру, который смотрит доску, непонятно, команда ждёт, работает или закончила.

Цель не в том, чтобы описать каждую крайность. Цель — сделать нормальный путь очевидным с меньшим количеством статусов и более чёткими значениями. Когда статусы одинаково понятны везде, передачи происходят быстрее и меньше вопросов вроде «Это точно сделано?».

Если команда не знает, с чего начать, стремитесь к 5–7 статусам, которые покрывают большую часть работы: один для новых элементов, один для активной работы, один для ожидания или блокировки, один для проверки или утверждения и один для завершённых задач. Добавляйте детали только после того, как базовая система стабильно используется всеми в одном смысле.

Что должна (и чего не должна) означать метка статуса

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

Хорошие метки описывают текущую реальность работы, а не чьё‑то мнение о ней. Если метка правдива, команда понимает, движется ли элемент, ждёт или заблокирован, и кто должен с ним работать дальше.

Статус — это не приоритет, не исполнитель, не категория и не заметки о прогрессе. Эти поля важны, но смешивать их в статусе делает сам статус ненадёжным.

Также полезно отделять «состояние» от «этапа». Состояние — что верно прямо сейчас (например, «заблокировано ожиданием ответа клиента»). Этап — где задача находится в процессе (например, «review»). Можно их сочетать, но когда одна метка пытается описать и то, и другое, она часто становится расплывчатой.

Полезный статус должен вызывать одно из трёх:

• Следующего владельца (кто подхватывает)
• Следующее действие (что будет дальше)
• Условие ожидания (чего мы ждём)

Быстрая проверка реальности: может ли кто‑то прочитать метку в компактном списке и всё равно понять, что делать дальше? Если ответ «зависит от ситуации», метка, вероятно, скрывает решение, которое должно быть принято в другом поле (например, правила приоритета или назначение).

Сколько статусов использовать и почему 5–7 — это оптимально

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

Для большинства команд 5–7 статусов — это золотая середина. Они помещаются на одном экране, хорошо работают в канбан‑доске или простом списке и дают достаточно сигналов, чтобы ответить на ежедневные вопросы: что заблокировано, что в работе и что ждёт проверки.

Малое количество статусов также уменьшает «охоту за статусом» (угадывание, какой из 12 вариантов ближе), упрощает отчётность и заставляет держать приоритет, владельца и тип как отдельные поля.

Названия могут различаться — это нормально. Одна команда скажет «In Progress», другая — «Doing». Нельзя допускать различий в значении. Если «In Review» иногда означает «ждёт QA», а иногда «ждёт клиента», доска превратится в шум.

Чтобы значения оставались согласованными, заведите один источник правды: короткий командный документ с каждой меткой, её значением и правилами входа/выхода. Читайте его за две минуты. Затем используйте тот же набор статусов везде, где показываете работу.

Простой набор из 7 статусов, с которого можно начать

Если вы хотите метки, которые останутся понятными со временем, начните с небольшого набора, отвечающего трем вопросам: кто владеет сейчас, что будет дальше и как выглядит «готово».

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

Главное правило: не используйте просто «Waiting». Если что‑то стоит, называйте это Blocked и указывайте причину в заметке (например, «Blocked: ожидание ответа клиента» или «Blocked: предоставление доступа»).

Определения для каждого статуса (правила входа и выхода)

Чёткие метки работают лучше, когда каждая отвечает на простой вопрос: что верно сейчас?

New

Что верно: элемент зафиксирован, но ещё никто не оценивал.

Что неверно: не согласованы приоритет, объём или владелец.

Вход: отправлен запрос.

Выход: кто‑то посмотрел и перевёл в Triaged.

Пример: «Саппорт зарегистрировал баг с одним скриншотом.»

Triaged

Что верно: команда понимает запрос достаточно, чтобы его направить и подтвердить валидность.

Что неверно: он готов к началу работы.

Вход: добавлен базовый контекст (сводка, влияние, область).

Выход: либо подготовлен к работе (Ready), либо намеренно отклонён (обработан вне workflow).

Пример: «PM пометил как реальный баг и указал шаги воспроизведения.»

Ready

Что верно: можно начать без недостающей информации.

Что неверно: работа уже началась.

Вход: критерии приёма ясны и зависимости в порядке.

Выход: человек начинает работу и делает первый значимый шаг (In Progress).

Пример: «Согласованы поля формы и правила валидации.»

In Progress

Что верно: идёт активная работа.

Что неверно: задача просто в очереди.

Вход: кто‑то берёт задачу и начинает работу.

Выход: либо готово к проверке (In Review), либо возникла зависимость (Blocked).

Пример: «Разработчик создал выпадающее меню статусов и сохранил логику.»

In Review

Что верно: идёт проверка (peer review, QA или утверждение заинтересованной стороны).

Что неверно: добавляются новые фичи.

Вход: исполнитель отправил работу на проверку.

Выход: утверждённо и соответствует определению done (Done), или возвращено с правками (In Progress).

Пример: «QA подтверждает, что всё работает и в вебе, и в мобильном приложении.»

Blocked

Что верно: работа не может продолжаться из‑за конкретной, именованной зависимости.

Что неверно: элемент просто понижен в приоритете.

Вход: исполнитель столкнулся с зависимостью, которую не может решить самостоятельно.

Выход: зависимость устранена и работа возобновлена (обычно In Progress).

Пример: «Blocked: нужен доступ к логам продакшна.»

Done

Что верно: соответствует критериям приёма и выпущено или готово к выпуску.

Что неверно: требует проверки, тестирования или доработки.

Вход: проверка пройдена и выполнены релизные шаги (в соответствии с определением команды).

Выход: нет; повторное открытие начинается с новой причины.

Пример: «Исправление в проде, баг больше не воспроизводится.»

Пошагово: создайте систему статусов за 60 минут

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

60‑минутная рабочая сессия (с одним результатом)

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

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

Далее уберите дубликаты и переименуйте неясные метки. Объедините метки с одинаковым смыслом («In Progress» vs «Doing»). Переименуйте расплывчатые («Pending») в понятные действия («Blocked: ожидание ответа Самуила»). Если вы не можете объяснить метку одним предложением, она ещё не готова.

Затем добавьте определения с правилами входа и выхода. Для каждой метки напишите, что должно быть истинно для входа и что — для выхода. Коротко. Пример: «In Review — входит, когда работа отправлена, выходит, когда правки внесены и ревьюер одобрил.»

После этого назначьте владельцев для каждой передачи. У каждого статуса должен быть стандартный владелец (роль подойдёт). Это предотвращает застревание задач. Пример: карточки в «In Review» принадлежат ревьюеру, а не исполнителю.

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

После встречи опубликуйте определения в одном месте и сделайте метки одинаковыми везде, где люди их видят.

Поддерживайте статусы согласованными в вебе и на мобильных экранах

Если статус на вебе означает одно, а на мобильном чуть иначе, люди перестают ему доверять. Они начинают спрашивать в чате, перепроверять детали или придумывать «реальный статус» в комментариях. Цель меток статусов — общая правда, а не украшение.

Рассматривайте статус как одно общее поле с одним источником правды. Одна и та же метка должна появляться с одинаковым написанием, каптализацией и значением везде: в списках, деталях, уведомлениях, экспортируемых отчётах и push‑сообщениях.

Правила для небольших экранов, которые реально работают

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

• Держите названия короткими (1–2 слова, если возможно).
• Используйте согласованные цвета, но никогда не полагайтесь только на цвет.
• Дизайн делайте с учётом самой длинной метки, чтобы ничего не обрезалось до нечитаемого фрагмента.
• Сохраняйте порядок одинаковым на всех платформах.
• Избегайте «похожих» меток вроде «In Progress» vs «Working». Выберите одну.

Также важно расположение. Помещайте статус рядом с заголовком в деталях, чтобы его увидели до прочтения полного описания. В списках показывайте его в одном и том же месте каждый раз.

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

Распространённые ошибки, из‑за которых статусы уходят в сторону

Статусы дрейфуют, когда перестают означать «где сейчас работа», а начинают означать «как люди относятся к работе». После этого доска выглядит загруженной, но доверия к ней нет.

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

Ещё одна точка дрейфа — смешение разных измерений в одном поле. Приоритет и срочность важны, но они должны быть в отдельных полях, не в статусе. Если «Urgent» становится статусом, он будет конкурировать с «In Review», и отчётность потеряет смысл.

Следите за такими паттернами:

• Несколько «похожих на done» меток без чёткой разницы
• Личные метки типа «Ждёт Сэма»
• «In Progress» превращается в парковку
• Нет письменных правил входа/выхода
• Новые экраны показывают другие имена или порядок статусов

Чтобы избежать дрейфа, назначьте одного владельца за набор статусов и делайте изменения редко. Когда меняете — запишите, что и почему изменилось и что было заменено.

Пример: один запрос от начала до конца

Клиент пишет в поддержку: «На мобильном экране история заказов пуста, хотя у меня есть заказы». Support заводит одну запись, которая станет фиксом продукта и затем релизом.

New: Support прикладывает скриншоты, данные устройства и описание того, как должно выглядеть правильно.

Triaged: Product Owner подтверждает, что это реальный баг, относит его к мобильному приложению и уточняет влияние.

Ready: Шаги воспроизведения подтверждены, критерии приёма понятны.

In Progress: Инженер воспроизводит проблему, выясняет, что API возвращает данные, а экран их фильтрует неправильно, и начинает исправление.

Blocked: Инженер обнаруживает, что UI зависит от поля, которого нет в старых аккаунтах, и нужен бэкенд‑фикс. Элемент помечают Blocked с одной заметкой: «Blocked: бэкенду нужен мэппинг поля для legacy‑аккаунтов.»

In Review: После решения зависимости QA проверяет iOS и Android и подтверждает, что пустое состояние отображается правильно только при отсутствии реальных заказов.

Done: Исправление одобрено и выпущено (или попало в следующий релиз, если для вашей команды это считается Done). Support подтверждает, что всё в проде, и отвечает клиенту.

Обратите внимание, что устраняет путаницу: у «Blocked» одна причина и один следующий шаг, а владение не перескакивает. Любой может открыть карточку и понять, у кого «мяч».

Быстрый чек‑лист, чтобы команда оставалась согласованной

Если ваша доска кажется запутанной, обычно можно найти причину за 10 минут.

10‑минутная быстрая проверка доски

Пройдитесь по доске и ищите следующие признаки:

• Каждая метка отвечает на вопрос «Что верно сейчас?»
• У каждого статуса есть стандартный владелец (роль подходит) и ясное следующее действие
• Ни одна пара статусов не может описать один и тот же элемент одновременно
• Задачи не припаркованы без точки решения (если может лежать дни — добавьте правило выхода)
• Одинаковые типы работ проходят через одни и те же основные шаги, если нет письменного исключения

Если люди спорят, куда поместить карточку, значит статусы перекрываются или плохо определены.

Проверка согласованности веб + мобайл

Откройте тот же workflow на телефоне и убедитесь, что метки работают в узких пространствах.

• Метки короткие и читаемы в списках (нет обрезания)
• Текст понятен без опоры на цвет
• Изменения статусов утверждаются одним владельцем (тимлид или ops), а не решаются каждым по‑своему
• При изменениях оставляются краткие заметки, чтобы определения не «дрейфовали»

Следующие шаги: поддерживайте, измеряйте и улучшайте со временем

Системы статусов полезны, когда вы относитесь к ним как к правилам: стабильным, но подконтрольным. Цель — не постоянные изменения, а последовательное использование.

Установите лёгкий ритм, например 30‑минутный ежемесячный обзор с одним представителем от каждой роли. Возьмите 5–10 недавних элементов и найдите исключения, которые можно исправить.

Пара простых метрик, которые стоит отслеживать:

• Время в статусе Blocked (и главные причины)
• Карточки, которые постоянно прыгают между двумя статусами
• Элементы, которые лежат без движения дольше обычного цикла

Когда что‑то кажется неправильным, не спешите добавлять новый статус. Добавляйте статус только если новое состояние действительно другое, меняет поведение людей и встречается часто. Чаще всего решение проще: уточнить определение, добавить правило входа или прояснить владение.

Если вы встраиваете workflow в внутренний инструмент, рассматривайте статусы как общие данные, а не как текст для экрана. В AppMaster (appmaster.io), например, вы можете определить поле статуса один раз в Data Designer и переиспользовать его в веб‑ и нативных приложениях, что помогает избежать дрейфа «на телефоне это значит другое».