Как мы пересобрали воркфлоу дизайнеров и перестали терять задачи на согласовании

Что у нас было раньше

Мы работаем по Канбану — точнее, по нашей адаптации, которую называем Agimaban. Все задачи в компании делятся на три потока (или сервиса):

• Management — задачи по обслуживанию процессов.
• Requirements — проработка требований и подготовка артефактов.
• Features — реализация функциональности в разработке.

Каждому потоку соответствует своя Канбан-доска со своим воркфлоу. Нас в этом кейсе интересует Requirements — доска, где работают дизайнеры, аналитики и проектировщики. Именно тут задача «созревает» до момента, когда её можно отдавать в разработку.

На доске Requirements задачи проходят через стандартные колонки:

To Do → In Progress → Validation → Client Acceptance → Done

Когда задача уходит на доработку, она всё это время формально остаётся в Client Acceptance, даже если по сути над ней снова работают дизайнеры и аналитики. Это приводило к проблемам.

Что нас не устраивало

Мы стали отслеживать Cycle Time — время прохождения задачи через доску. И быстро заметили: задачи доходят до стадии согласования и… застревают.

Например, дизайн сделали за 10 рабочих дней. Но потом он мог лежать на согласовании у заказчика ещё 20–30 дней. Иногда — дольше. Всё остальное шло быстро, а в колонке Client Acceptance копились задачи.

Это мешало управлять приоритетами. Мы не видели, на каком этапе задача: только отправлена на согласование или уже во второй итерации правок? И какая из них критичнее? Все они были в одном столбце — и визуально были равнозначны. А на самом деле — нет.

Как мы изменили процесс

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

Теперь, если заказчик прислал комментарии, задача не «зависает» в Client Acceptance, а уходит в To Do следующего свимлайна. То есть формально это новая итерация, но в рамках той же задачи.

Мы обычно добавляем два свимлайна:

• Итерация 1 — первая волна правок;
• Итерация 2+ — последующие доработки, если потребуется.

Иногда добавляем третий — Post-production. Это задачи, которые приняты заказчиком, но дорабатываются для внутренних целей: доп. состояния интерфейсов, документация, UI Kit и т.д. Новую задачу под это создавать не хочется — это та же самая работа.

Почему так лучше

1. Прозрачность

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

2. Управляемость

   Руководители дизайн-цеха и проектирования теперь могут быстрее принимать решения по задачам: распределять нагрузку, подключать новых специалистов, управлять дедлайнами.

3. Контроль

   Если задача перешла во второй свимлайн — значит, с ней не всё гладко. Можно вовремя отреагировать: провести ревью, перераспределить работу или просто спросить, что не так.

4. Проекты с фиксированной ценой

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

Какие сомнения у нас были

Сомнение 1: не перебор ли с детализацией?

Классический Канбан работает с тремя статусами: Open → In Progress → Done. Мы же добавляем свимлайны, которые визуально усложняют доску. Но именно в нашем случае это разгружает колонку Client Acceptance и делает процесс визуально и управленчески понятным. Мы чётко видим, что находится в ревью, что — в доработке, что — на повторной проверке. Без этого просто «мыло» из десятков задач в одной колонке.

Сомнение 2: почему не колонки?

Можно было бы сделать дополнительные колонки, но это утяжелило бы доску. Кроме того, задача при каждой итерации всё равно проходит путь заново: To Do → In Progress → Validation. Поэтому логичнее вынести повторные итерации в горизонтальные полосы, а не в ширину.

Чем мы довольны

1. Воркфлоу стал понятнее

   И менеджерам, и исполнителям. Теперь видно, где «зависают» задачи, как быстро продвигается работа, и где горят сроки. Один взгляд на доску — и приоритеты очевидны.

2. Взаимодействие с заказчиком стало чище

   Если задача перешла в To Do новой итерации — это сигнал и для команды, и для клиента, что начался новый цикл работы. Меньше путаницы, больше ясности.

3. Руководителям проще управлять ресурсами

   Появился инструмент, который показывает, где команда тратит время. Особенно полезно на кросс-проектных цехах: видно, где требуются силы, а где всё уже на финишной прямой.

4. Можно быстрее оптимизировать процессы

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

Коротко

Мы не изобрели новый метод, а просто добавили немного структуры и визуализации в существующий Канбан-процесс. Это дало:

• Прозрачность по задачам на согласовании.
• Возможность точно управлять приоритетами.
• Контроль над итерациями и временем.
• Более стабильный процесс в фикс-прайс-проектах.

Сейчас мы используем новый воркфлоу не только для дизайна, но и для ТЗ, аналитики и других артефактов на доске Requirements. Везде, где возможны повторные итерации, эта модель работает отлично.