Как неправильные статусы задач сорвали мне срок на три недели
С чего началась проблема
Этот кейс начался не с провала, а с ощущения, что работа идёт нормально. В режиме Канбан список задач выглядел прилично: что-то было «в работе», что-то «на проверке», часть карточек уже якобы близилась к финалу. Но через несколько дней стало ясно, что задача в статусе и реальное выполнение — это не одно и то же.
Ошибка была простой: мы собрали слишком расплывчатый набор статусов. У нас не было чётко описано, что означает каждый статус задачи, кто может менять его и какой переход между статусами считается допустимым. Исполнитель двигал карточку, когда считал нужным, а контролирующий сотрудник подключался слишком поздно. В результате контроль был формальным, а отчётность — красивой только на экране.
Где сломался жизненный цикл задачи
Позже я понял, что мы не описали жизненный цикл задачи от создания новой задачи до финального закрытия. Формально задача имела статус, но состояние было непонятным: она готова, ждёт тестирование, заблокирована или её нужно вернуть на доработку? Эти сущности смешались в один поток.
Когда нет правил перехода, команда начинает трактовать процесс по-своему. Один сотрудник считал, что можно завершить задачу сразу после разработки. Другой переводил её на проверку только после внутреннего тест-кейса. Третий вообще оставлял всё в одном статусе по умолчанию, потому что так быстрее, чем нажимать кнопка и выбирать следующий шаг. На короткой дистанции это удобно. На длинной — катастрофа.
Как именно я потерял три недели
Критический сбой случился на стыке разработки и проверки. Несколько задач были помечены как выполненные, хотя по факту их ещё должен был принять контролирующий сотрудник. В нормальном бизнес-процессе такие элементы должны были переходить в отдельный статус вроде «На контроле», а не считаться закрытыми. Но у нас такого правила не было.
Из-за этого я смотрел на список задач и видел ложный прогресс. Планирование следующего этапа строилось на неверных данных. Пока команда создавала новые задачи и распределяла исполнителей, старые дефекты тихо копились. Когда мы начали разбирать хвосты, выяснилось, что часть работы нужно вернуть на доработку, часть — повторно принимать, а часть вообще не дошла до тестирования.
Главный урок был неприятным: проблема редко в людях. Чаще ломается сама система значений, которую команда вкладывает в статусы.
Что я увидел в других системах
Когда я разбирал ошибку, мне помогли примеры из разных сервисов. В Planfix давно обсуждали, как набор статусов и статус по умолчанию влияет на создание задачи. Если система или шаблон задачи присваивает не тот стартовый вариант, пользователь уже начинает процесс с искажённой логики. Похожая история была у пользователя, которому новым задачам автоматически ставился кастомный статус, и без службы поддержки это не исправлялось.
В SaveTest логика, наоборот, жёстче: статусы тестирования разделены, а для некоторых действий открывается отдельное окно. Там хорошо видно, что статус «Провален» — это не просто метка, а сигнал создавать задачу в баг-трекере. То есть статус определяет следующее действие. У нас этого принципа не было вообще.
Даже в 1С заметно, насколько важен контекст выполнения: если работа делается не из самого списка задач, системе может не хватить сигнала, чтобы корректно завершать процесс. А в Moo.team автоматизация меняет статус по дате старта. Это полезно, но только если жизненный цикл задачи заранее продуман.
Что мы поменяли после провала
Сначала мы сократили список до понятных статусов: «Новая», «В работе», «На проверке», «На контроле», «Выполнена», «Отменена». Для каждого статуса прописали, кто может его выбирать и что должно быть сделано до перехода. Отдельно договорились, что завершить задачу может не исполнитель, а только тот, кто принимает результат.
- описали правила перехода между статусами;
- убрали двусмысленные формулировки;
- пересобрали шаблон, чтобы статус по умолчанию не искажал процесс;
- развели выполнение, тестирование и контроль по отдельным этапам;
- проверили архив и старые карточки, чтобы не тащить мусор дальше.
После этого Канбан перестал быть декоративной доской. Он начал визуализировать реальное состояние задач. Стало видно, где процесс тормозит, какой сотрудник завис на этапе согласования и почему выполнение не равно завершению.
Вывод для команды
Если статусы в вашей системе живут сами по себе, дедлайн однажды всё равно сломается. Неважно, работаете вы в Jira, GitHub, Planfix или другой SaaS-платформе. Задача должна иметь не просто красивый ярлык, а понятный маршрут: кто её принимает к исполнению, когда можно завершать, в каком случае нужно вернуть на доработку и кто отвечает за контроль.
Мой провал стоил трёх недель не потому, что команда плохо работала. Мы просто недооценили, насколько статус определяет процесс. И с тех пор я сначала проектирую жизненный цикл задачи, а уже потом запускаю работу.
