В одной компании мы передавали задачи между отделами в чатах. В другой — по почте. Где-то использовали таблицы. Схемы отличались, результат был один и тот же.
Ты отдаёшь задачу в другой отдел, а дальше не понимаешь, что с ней происходит. Вроде передали, но взяли ли её в работу? Чтобы узнать статус, нужно писать и напоминать. А в день дедлайна выясняется, что задачу никто ещё не трогал.
И процессы вроде бы есть, но они плохо организованы, и тут проблема не в конкретной команде или в людях.
В статье показываю пять простых способов, как можно эффективно организовать передачу задач между командами и перестать тратить время на ручной контроль.
Процесс 0. Все работают на одной доске
Этот сценарий подходит для маленьких проектов. Все задачи создаются в одном проекте на канбан-доске и просто переходят от одного исполнителя к другому. Статусы обновляются по ходу работы, а вся история обсуждений остаётся в карточке задачи.
Такой формат хорошо работает там, где задачи передаются между небольшим количеством людей внутри команды, а не между независимыми подразделениями.
Процесс 1. Передача задачи с сохранением контроля
Этот сценарий подходит для задач, которые нельзя просто «отдать в работу» и забыть: важно видеть статус и понимать, когда будет результат.
Пример: в компании есть системный администратор, который выполняет задачи для нескольких отделов. Ему постоянно прилетают запросы в чат или на почту.
Формально задачи передаются, но по факту они не встроены в работу исполнителя и никак не отслеживаются.
В результате:
инициатор не видит текущий статус задачи;
у исполнителя нет упорядоченных входящих;
у руководителя нет точки, где можно посмотреть фактическую загрузку и очередь работ.
Как организовать процесс
В этом сценарии задачу важно передать так, чтобы она была на доске исполнителя и не требовала ручного контроля дальше. Например, в системе управления проектами YouGile для этого можно использовать инструмент «зеркальные задачи».
Вот как выглядит процесс:
Сотрудник создаёт обычную задачу и её «зеркало». Это копия основной задачи, синхронизированная с ней. Если изменить описание, сроки или комментарии в одной задаче, изменения автоматически появляются и в другой — и наоборот.
Администратор берёт в работу зеркальную задачу. Он работает только с ней на своей доске: меняет статус, пишет комментарии, задаёт вопросы.
Когда работа завершена, инициатор может сразу проверить результат. Ему не нужно писать в личку исполнителю: достаточно открыть основную задачу.
Показываю, как это выглядит:
Процесс 2. Автоматическая маршрутизация задач
Этот сценарий подходит, когда есть постоянный поток однотипных запросов, которые регулярно нужно передавать в конкретный отдел.
Пример: в техподдержке есть первая линия. Она принимает обращения и решает, нужно ли подключать разработку. Часто поддержке нужно понять сроки — сколько времени займёт исправление бага. Для этого она пишет разработчикам с просьбой оценить задачу.
Но такие запросы остаются отдельными сообщениями:
у них нет приоритета и ответственного;
к ним возвращаются тогда, когда до них доходят руки.
В итоге поддержка не может дать клиенту понятные сроки, и клиентский сервис проседает.
Как организовать процесс
Задачу нужно передавать так, чтобы она сразу попадала в рабочую очередь нужного отдела, с понятным приоритетом и ответственным.
Например, в системе управления проектами YouGile для этого можно настроить правила автоматизации. Дальше пошагово разберу, как это работает.
Сотрудник создаёт задачу на доске своего отдела — там, где он обычно работает с задачами, и добавляет всю исходную информацию.
Для таких задач в системе заранее настраивается правило передачи — по какому действию задача должна уходить в другой отдел. Это может быть присвоение определённого тега, перевод задачи в нужную колонку или смена статуса.
При срабатывании правила задача попадает в зеркальную колонку на доске нужного отдела. Зеркальная колонка — это связанная колонка на другой доске: всё, что происходит с задачей у исполнителей, автоматически отражается и в исходной задаче.
При передаче параметры задачи меняются автоматически: назначаются нужный исполнитель, приоритет и сроки.
Другой отдел работает с задачей как обычно: учитывает её в плане, меняет статусы, оставляет комментарии.
Инициатор видит весь процесс в своей задаче. Ему не нужно писать и уточнять — статусы, комментарии и результат обновляются автоматически. Когда работа завершена, это сразу видно по задаче.
Вот как это выглядит:
Процесс 3. Последовательная передача задачи через несколько отделов
Этот сценарий для задач, которые проходят через несколько этапов и команд по заранее известному маршруту.
Пример: компания получает заказ на изготовление детали. Юристы оформляют договор → проектировщики делают чертежи → инженеры делают расчёты → производство запускает изготовление.
Обычно каждый отдел работает со своим этапом, но в целом заказ распадается на куски: непонятно, что сейчас происходит и кто следующий отвечает за ход работ.
Как организовать процесс
В этом сценарии важно сохранить одну общую задачу и последовательно вести её через этапы работы разных отделов.
Как это организовать в YouGile:
Создаётся одна задача на весь заказ. В ней фиксируют суть, сроки и ключевые вводные.
Этапы работы оформляются как подзадачи. Каждая подзадача соответствует своему этапу: договор, проектирование, расчёты, производство.
Для удобства используют шаблон задачи — в нём заранее заданы этапы, исполнители и метки, которые показывают, на каком этапе сейчас находится заказ.
Подзадачи выстраиваются в нужной последовательности. Когда один этап завершён, следующий становится активным — без ручной передачи и напоминаний.
В результате весь заказ остаётся виден целиком. В любой момент понятно, на каком этапе сейчас задача, при этом каждый отдел работает на своей канбан-доске.
Показываю, как это выглядит:
Ещё можно проставить зависимости между задачами и лаги — время на согласование. Это поможет запланировать передачу задач в нужные сроки. В системе управления проектами YouGile это удобно делать в диаграмме Ганта.
Процесс 4. Передача задачи без дальнейшего участия в работе
Подходит для задач, которые нужно отдать в работу и дальше не сопровождать, но при этом понимать, что с ними происходит.
Пример: в компании есть сервисная служба с выездными мастерами. Заявки приходят от клиентов или менеджеров. Координатор принимает заявки, распределяет их между мастерами и переключается на другие обращения.
Координатору не нужно следить за каждой заявкой, но периодически важно понимать, сколько в работе, какие уже закрыты, где есть просрочки и кому что передали.
Если заявки направляют в чатах или устно, картину приходится просматривать переписки и вспоминать, что кому отдавали. Это неудобно и отнимает время.
Как организовать процесс
В этом сценарии исполнитель работает с задачей, а координатор следит за ней через сводку. Это подборка задач по определённому признаку, которая выводится отдельной колонкой на его доске.
Вот как устроен процесс передачи со сводками в YouGile.
Координатор настраивает сводку. Задаёт правило, по которому задачи будут в неё попадать. Например: все задачи, переданные выездным мастерам или помеченные определённым тегом.
Координатор создаёт задачу и передаёт её исполнителю. Оформляет заявку, назначает человека и отправляет задачу на доску мастеров.
После этого координатор больше не участвует в работе.
Исполнители работают с задачей в своём пространстве.
Координатор работает со сводкой. В ней видно, какие заявки в работе, какие закрыты и где есть просрочки. Сводка обновляется автоматически по мере действий исполнителей, поэтому не нужно вручную проверять статусы или переписки.
Завершённые задачи остаются в сводке и доступны для отчётности или проверки.
Выглядит это так:
Эти процессы пригодятся не только разработчикам, производству и ремонтным бригадам, но и любым другим отделам.
На их настройку уйдёт немного времени: в YouGile можно создать проект, пригласить коллег и настроить правила передачи задач примерно за 15 минут. Система доступна бесплатно для команд до 10 человек — без ограничений по функциям и времени.
