В чате снова «это горит, сделай прямо сейчас», а список задач на неделю состоит из одних «срочных» пунктов. Вы открываете доску и не можете понять, что из этого действительно нельзя отложить. Исполнители тоже не понимают: они выбирают то, о чём напомнили громче всех.
Статья про то, как договориться о правилах приоритизации в команде из 5–12 человек и отразить их на доске. Сравнения сервисов здесь не будет: речь о договорённостях и о том, как их поддержать в Synqo. Другие материалы по организации работы есть в блоге Synqo.
Почему «всё срочное» — это не про задачи, а про отсутствие правил
Срочность и важность часто путают. Срочная задача имеет близкий срок или последствия от задержки. Важная задача влияет на цели команды, даже если её срок не скоро. Отчёт клиенту к пятнице срочен и важен. Просьба коллеги «глянуть макет прямо сейчас» может быть срочной только для него самого.
Когда общего критерия нет, каждый расставляет приоритеты по своей тревоге. Метка «срочно» становится способом привлечь внимание, а не описанием задачи. Через пару недель она обесценивается, и в ход идут «очень срочно» и заглавные буквы.
Поэтому новый инструмент проблему не решит. Доска покажет то, что вы в неё внесёте: если все карточки помечены «срочно», она красиво покажет хаос. Сначала нужна договорённость, потом настройка.
Как договориться о критериях приоритета до того, как открывать доску
Обсудите три вопроса на короткой встрече.
Кто назначает и меняет приоритет. Рекомендуемое правило: приоритет ставит владелец задачи или тимлид. Остальные могут запросить повышение в комментарии с обоснованием, но сами не меняют.
Какая шкала. Трёх уровней обычно достаточно:
Блокер — стоит работа других людей или есть внешний срок с реальными последствиями;
В плане недели — делаем в текущем цикле;
Потом — без срока или можно сдвинуть без ущерба.
Что считается блокером. Блокер — то, что останавливает других или клиента. «Мне нужно к обеду» — личная срочность одного человека, и это повод договориться, а не автоматический блокер.
Учебный пример: команда из 8 человек
Допустим, в команде 8 человек и на неделю набралось 30 карточек, из них 22 помечены «срочно». Договариваются так:
Приоритет ставит только исполнитель или тимлид.
Шкала — три уровня, описанные выше.
Блокеров одновременно не больше трёх на всю команду. Появляется четвёртый — тимлид решает, какой из прежних понижается.
Раз в неделю на летучке просматривают всё высокоприоритетное. Карточки, которые провисели больше недели без действий, снимают с высокого уровня.
Как проверить итог: после первой летучки блокеров должно остаться не больше трёх, а у каждой снятой карточки в комментарии записана причина понижения.
Как отразить договорённости в структуре проекта и досок Synqo
В Synqo карточка поддерживает приоритет, метки, сроки, назначенных участников, комментарии и историю изменений. Подробнее о функциях — на странице возможности Synqo.
Приоритет держите в поле приоритета и метках, а не в названиях колонок. Колонки отвечают на вопрос «на каком этапе работа», приоритет — «насколько это важно сейчас». Если смешать их, получится колонка «Срочно», куда сваливается всё.
Колонка «На согласовании» нужна, чтобы отделить ожидание от работы. Карточка, которая ждёт ответа заказчика, не должна выглядеть как горящая задача в работе. Колонки можно создавать, переименовывать и перемещать, так что подстроить их под процесс несложно.
Роли. Владелец, администратор и участник работают с задачами, гость только просматривает и комментирует. Кто из участников вправе менять приоритет, система не ограничивает, это правило команды. Зафиксируйте его в описании проекта. Проверяющий и ответственный за результат — тоже ваши договорённости, отдельных ролей для них нет.
Историю изменений полезно открывать на летучке: видно, кто и когда поднял приоритет.
WIP-правила и регулярный обзор: как приоритеты не превращаются в хаос через месяц
Ограничение числа задач в работе (WIP) — практика команды, а не автоматическая функция доски. Правило: не больше двух карточек «В работе» на человека. Нарушения видны при взгляде на доску, поэтому проверяет их обзор, а не система.
Обзор раз в неделю занимает 20–30 минут:
Пройдите по блокерам: они всё ещё блокеры?
Найдите карточки высокого приоритета без движения больше недели и понизьте или закройте их.
Проверьте колонку «На согласовании»: кто должен ответить и когда.
Убедитесь, что новые задачи получили приоритет по шкале.
Если «срочных» снова много, не добавляйте колонку «Супер-срочно». Вернитесь к критериям: возможно, определение блокера слишком широкое или тимлид не отказывает в запросах. Пересмотрите правило и запишите изменение.
Что делать с гостями и подрядчиками, у которых своё понимание срочности
Гость проекта видит доступные ему задачи и комментирует, но не создаёт и не перемещает задачи и колонки. Это удобно: подрядчик не переставит приоритеты, но может сообщить, что задача для него горит. Доступ к остальным приватным проектам гость автоматически не получает. Доступ к отдельным карточкам или частям доски не обещаем: права определяются проектом.
Заранее договоритесь о канале эскалации. Например: гость пишет комментарий в карточке с пометкой «прошу пересмотреть приоритет» и объясняет последствия задержки. Тимлид отвечает в течение рабочего дня: принимает, отклоняет или предлагает срок. Так срочность гостя не растворяется в личных сообщениях, а решение остаётся в истории карточки. Число гостей зависит от тарифа рабочего пространства.
Перенос текущих задач и приоритетов при переходе с другого инструмента
Synqo умеет импортировать из Trello, OTask и Kaiten. Импорт создаёт новый приватный проект с досками и не объединяет данные с существующим проектом. Для Trello подходит JSON-файл, а для скачивания вложений могут понадобиться API-данные. Вложения зависят от тарифа и на бесплатном плане недоступны, так что проверьте это до переноса и не рассчитывайте на полный перенос любых данных.
Учебный пример: проект из Trello
Допустим, команда переносит проект, где метки «urgent», «ASAP» и «важно» стоят на большинстве карточек. Действия:
Экспортируют доску в JSON и запускают импорт. Получают отдельный приватный проект.
Сверяют результат: количество карточек, метки, сроки, наличие вложений.
Сводят метки к трём уровням: «urgent» и «ASAP» с реальным сроком становятся блокером, «важно» переходит в план недели, остальное — в «Потом».
Назначают, кто отвечает за актуальность меток: тимлид на еженедельном обзоре.
Старые метки убирают, чтобы они не вернули прежний хаос.
Критерий готовности: в новом проекте нет меток вне договорённой шкалы, а блокеров не больше согласованного лимита.
Как проверить, что договорённости о приоритетах реально работают
Плохой признак — снова все задачи «горят», а приоритеты меняют в чате мимо доски. Тогда правило не работает или его никто не проверяет.
Краткий чек перед стартом:
критерии и шкала записаны там, где их видит вся команда;
определено, кто ставит и меняет приоритет;
назначены день и ведущий еженедельного обзора;
согласованы лимит блокеров и WIP;
для гостей описан канал эскалации.
Когда команда и число проектов растут, проверьте лимиты участников, гостей, проектов и досок. Они зависят от тарифа, актуальные условия — на странице тарифы Synqo.
Начните с одной встречи и трёх уровней шкалы. Через две недели посмотрите, сколько блокеров осталось, и поправьте правила.
Как провести первую встречу о приоритетах: сценарий на 45 минут
Договорённость легко сорвать хаотичной встречей, где обсуждают всё сразу. Поэтому у первой встречи должны быть повестка, ведущий и результат, который записывается письменно.
Подготовка (за день до встречи). Ведущий, обычно тимлид, выгружает или просто выписывает все активные задачи и отмечает те, что сейчас считаются срочными. Цель не оценивать их, а увидеть масштаб: сколько карточек «горит» и у скольких из них есть реальный внешний срок. Эту цифру можно показать команде в начале встречи как отправную точку.
Ход встречи.
Десять минут: разбор трёх–четырёх реальных случаев. Возьмите недавние ситуации, когда задачу сделали «срочно», а потом выяснилось, что подождать можно было. Без поиска виноватых: важно понять, какой признак должен был подсказать, что это не блокер.
Пятнадцать минут: определения. Вместе формулируете, что такое блокер, что входит в план недели, что уходит в «Потом». Определение проверяйте вопросом: «Кто и что потеряет, если сделать это на следующей неделе?» Если ответа нет, задача не блокер.
Десять минут: права и процедура. Кто ставит приоритет, кто может его оспорить, в каком виде подаётся запрос на повышение (комментарий в карточке с последствиями задержки).
Десять минут: применение к текущим задачам. Пройдите по списку и расставьте приоритеты по новой шкале прямо на встрече. Так правила сразу проверяются на практике.
Результат. Короткий документ на одну страницу: определения трёх уровней, лимит блокеров, правило запроса на повышение, день обзора. Разместите его в описании проекта, чтобы он был рядом с доской, а не в чьей-то переписке.
Как обрабатывать исключения и споры о приоритете
Даже хорошее правило столкнётся с ситуациями, которые в него не укладываются. Заранее решите, как с ними поступать, иначе исключения станут нормой.
Руководитель или клиент просит сделать «немедленно». Не отказывайте молча и не выполняйте молча. Тимлид задаёт один вопрос: «Что из текущих блокеров сдвинуть?» Лимит блокеров тогда работает как инструмент переговоров: новая срочная задача не добавляется сверху, а вытесняет другую, и заказчик видит цену своей просьбы. Итог фиксируется комментарием в карточке.
Два человека считают свои задачи блокерами, а ресурса на обе нет. Решение принимает тимлид, а не тот, кто настойчивее. Он записывает причину выбора в обеих карточках. Проигравшая сторона получает ориентировочный срок, а не молчание.
Настоящая авария. Инцидент, из-за которого стоит работа клиента, — законный повод нарушить план недели. Условие: после разбора команда на ближайшем обзоре возвращает доску к лимитам и отмечает, что ушло в «Потом» из-за аварии. Если такие «аварии» случаются каждую неделю, это сигнал не о доске, а о процессе: возможно, не хватает планирования или технической поддержки.
Задача без владельца. Приоритет не ставится, пока не назначен исполнитель или ответственный. Это правило команды: оно не даёт карточкам копиться «на всех» и остаться без движения.
Для каждого исключения полезно оставлять след в истории карточки: кто решил, когда и почему. Через месяц по этим записям видно, какие типы исключений повторяются, и правила можно уточнить.
Как провести пилот на одной доске и не сломать текущую работу
Переход всей команды на новые правила за один день обычно вызывает сопротивление. Надёжнее взять две недели и одну доску.
Неделя 0. Выбор границ. Выберите один проект или одну доску, где проблема заметнее всего. Назначьте ведущего пилота. Зафиксируйте исходные цифры: сколько карточек в работе, сколько помечено срочными, сколько раз за неделю приоритет менялся через чат. Это не тест продукта, а ваши собственные наблюдения для сравнения.
Неделя 1. Работа по правилам. Все новые задачи получают приоритет по шкале. Запросы на повышение идут только комментарием в карточке. В конце недели проведите первый обзор по списку из четырёх шагов.
Неделя 2. Корректировка. Посмотрите, где правила мешали. Типичные находки: определение блокера оказалось слишком широким, лимит WIP не учитывает совещания и поддержку, гостям неясно, куда писать. Поправьте формулировки в документе проекта и объявите изменения команде.
Критерии решения по итогам пилота:
доля карточек с высоким приоритетом заметно ниже исходной и не превышает согласованного лимита;
споры о приоритетах переместились из чата в комментарии карточек;
команда может объяснить, почему задача стоит именно на своём уровне;
обзор укладывается в отведённое время.
Если хотя бы два критерия не выполнены, не расширяйте пилот. Сначала выясните причину: неясные определения, отсутствие дисциплины у тимлида или перегрузка команды. Только после этого переносите правила на другие проекты, а при росте числа проектов проверьте, что лимиты тарифа рабочего пространства это позволяют.
Типичные ошибки при внедрении
Правила есть, но их не применяет сам руководитель. Если тимлид сам присылает «срочно» в личные сообщения мимо доски, команда быстро перестанет верить шкале. Начинайте с собственных привычек.
Слишком много уровней. Пять–шесть градаций снова размывают границы, и люди выбирают средний вариант наугад. Три уровня легче помнить и обсуждать.
Обзор превращается в отчёт. Если на летучке каждый пересказывает свои дела, до приоритетов не доходят. Держите фокус на блокерах, зависших карточках и колонке «На согласовании».
Понижение воспринимается как наказание. Объясняйте: сниженный приоритет означает «не сейчас», а не «неважно». Причину всегда записывайте в комментарии.
Правила не пересматриваются. Команда меняется, проекты тоже. Раз в квартал сверяйте определения с реальностью и обновляйте документ в описании проекта.
