Статусы проектов часто выглядят убедительно: “Новый”, “В работе”, “На согласовании”, “Завершён”. Но сами по себе слова ничего не управляют. Если команда по-разному понимает, что значит “почти готово”, доска становится красивым способом не знать реальность.
Рабочий статус — это не цветная метка. Это договорённость: какие условия должны быть выполнены, кто отвечает за переход, какие действия запускаются дальше и что видит руководитель в отчёте.
В Plancy статусы проектов существуют рядом с задачами, участниками, временем и отчётами. Это важно: статус проекта должен отражать состояние работы, а не настроение менеджера перед планёркой.
Антипаттерн. Если статус можно поменять без понятного основания, он быстро становится ручным комментарием. Через месяц команда перестаёт ему верить.
Статус должен отвечать на вопрос
Хороший набор статусов начинается не с названий, а с вопросов руководителя.
Где проект застрял? Кто должен сделать следующий шаг? Можно ли выставлять счёт? Нужен ли клиентский фидбек? Ресурс уже занят или проект только в воронке? Есть ли риск по срокам?
Если статус не помогает ответить хотя бы на один такой вопрос, скорее всего, он лишний.
Например, “В работе” полезен только до определённого масштаба. Когда проектов становится больше, внутри него прячутся разные состояния: команда ждёт вводные, задача у дизайна, разработка заблокирована, клиент не согласовал этап, документы не подписаны.
Правила входа и выхода
У каждого важного статуса должны быть два набора условий.
Правила входа отвечают на вопрос: когда проект может попасть в этот статус. Например, проект можно перевести в “На согласовании”, если ключевые задачи этапа закрыты, результат приложен, а ответственный назначен.
Правила выхода отвечают на вопрос: что должно произойти дальше. Из “На согласовании” проект может уйти в “Доработка”, “Следующий этап” или “Завершён”. Это уже не просто поле в карточке, а рабочий сценарий.
Такие правила можно держать в wiki или в шаблоне проекта. Главное, чтобы они были видны команде.
Владельцы статусов
Статусы не должны обновляться “кем-нибудь”. Для каждого перехода полезно определить владельца.
Менеджер проекта отвечает за операционный статус. Руководитель направления может подтверждать переход к этапу с высоким риском. Финансовая роль может закрывать статус, связанный с документами и оплатой. Поддержка может переводить внутренний запрос в работу или закрывать обращение.
Когда владелец не определён, статус устаревает первым.
Как связать статусы с отчётами
Проектная отчётность становится полезнее, когда статусы превращаются в измеримые состояния. Можно смотреть:
- сколько проектов застряло на согласовании;
- сколько времени проекты проводят в каждом статусе;
- какие статусы чаще всего возвращают работу назад;
- где копятся проекты без ответственного следующего шага;
- какие команды чаще сталкиваются с блокировками.
Такая аналитика помогает улучшать процесс, а не просто спрашивать “ну что там?”.
Минимальный набор для старта
Для сервисной или продуктовой команды обычно хватает 6-8 статусов:
- Черновик.
- Запланирован.
- В работе.
- Заблокирован.
- На согласовании.
- На доработке.
- Готов к закрытию.
- Завершён.
Не обязательно использовать именно эти названия. Важно, чтобы у каждого статуса была своя управленческая функция.
Главный критерий
Статусы работают, когда они уменьшают число уточняющих сообщений. Если руководителю всё ещё нужно спрашивать в чате, что происходит с каждым проектом, значит доска не выполняет свою работу.
Хорошая система статусов делает состояние проекта понятным без лишнего шума: где мы сейчас, кто держит следующий шаг и что мешает двигаться дальше.
