Доска создана, но колонки «Сделать / В работе / Готово» давно не отражают то, как команда работает на самом деле. В «В работе» лежит двадцать карточек, и половина из них ждёт чьего-то ответа. Задачи «на проверке» живут в чате. Никто не помнит, кто должен сказать «принято». Это не провал дисциплины, а признак того, что структура доски отстала от процесса. Разберёмся, как её пересобрать. Другие материалы по организации работы собраны в блоге Synqo.
Колонка — это этап процесса, а не ярлык
Статус отвечает на вопрос «что с задачей?». Колонка отвечает на другой: «в чьих руках она сейчас и что должно произойти, чтобы она пошла дальше?». Если на второй вопрос нет ответа, колонка превращается в склад.
Слишком общие колонки прячут проблемы. В «В работе» одинаково выглядят карточка, которую час назад открыл исполнитель, и карточка, которая третью неделю ждёт макет от заказчика. Доска показывает движение там, где его нет.
Слишком дробные колонки создают обратную проблему. Если этапов девять, а задача проходит их за день, команда тратит время на перетаскивание, а не на работу. Люди начинают пропускать колонки, и доска снова расходится с реальностью.
Практическое правило для новой колонки: заводите её, только если выполняются три условия.
- У этапа есть понятный «владелец» по договорённости: кто сейчас должен действовать.
- Карточки в этом этапе могут застревать, и вам важно это увидеть.
- Выход из этапа можно сформулировать одной фразой («макет утверждён», «код влит»).
Если хотя бы одно условие не выполняется, достаточно метки или чек-листа внутри карточки.
Базовый набор для большинства команд
Для начала подойдут четыре колонки:
- Backlog (или «К выполнению») — накопитель идей и заявок без обязательств по срокам. Попадание сюда не означает, что кто-то этим займётся.
- В работе — задачу взял конкретный участник и действительно над ней работает.
- На проверке — нужна, если у вас есть отдельный этап согласования или ревью. Без него колонка лишняя.
- Готово — только с явным критерием завершённости: например, «результат передан и принят», а не «мне кажется, я закончил».
Пример: поток заявок в команде из пяти человек
Допустим, команда поддержки и разработки получает заявки от коллег. За неделю набралось 18 карточек. Раньше все они лежали в «В работе», и доска выглядела так, будто команда перегружена на 300%.
Что делаем:
- Все 18 карточек переносим в Backlog. Туда же попадает всё, у чего нет исполнителя.
- Руководитель вместе с командой отбирает то, что берут на ближайшие дни. Допустим, это 5 карточек, по одной на человека, и они уходят в «В работе».
- Договариваемся: исполнитель переносит карточку в «В работе» в момент, когда начинает, и указывает себя назначенным участником.
- Договариваемся о лимите: не больше двух карточек на человека в «В работе». Это правило команды, а не функция системы.
Критерий решения: на ежедневном обзоре в «В работе» не больше десяти карточек и у каждой есть исполнитель. Если карточка без движения несколько дней, её либо возвращают в Backlog, либо выясняют причину. Так исчезает иллюзия загруженности: Backlog честно показывает очередь, а «В работе» показывает текущую нагрузку.
Команды с согласованием и внешними заказчиками
Колонка «На согласовании» нужна, когда решение принимает не исполнитель: заказчик, юрист, руководитель. Отличие от «На проверке» в том, что ждать приходится ответа внешнего человека, и эта пауза не зависит от скорости команды.
Колонка «Ожидает информацию» (или «Заблокировано») отделяет остановку от прогресса. Когда исполнитель ждёт доступы, данные или ответ, карточке здесь самое место. В описании или комментарии стоит записать, чего именно ждём и от кого.
Если заказчик подключён к проекту гостем, учтите ограничения роли. Гость в Synqo может просматривать доступные задачи и комментировать, но не создавать, изменять или перемещать задачи и колонки. Значит, карточку в «Согласовано» или «Правки» переносит участник команды после комментария гостя. Закрепите это в договорённости: «Заказчик пишет решение в комментарии, ответственный в течение рабочего дня двигает карточку». Проверяющий и ответственный за результат здесь тоже договорённости команды, а не системные роли.
Кроме того, гость проекта не получает автоматически доступ к другим приватным проектам. Это удобно для внешних участников, но отдельные карточки или часть доски ему выдать нельзя, поэтому внутренние обсуждения лучше вести в отдельном проекте.
Частые ошибки
«В работе» как склад. Туда попадает всё, что не сделано и не заброшено окончательно. Лекарство: Backlog для невзятого, блокирующая колонка для ожидающего, лимит на текущие задачи.
Слишком много статусов на один этап. «Начато», «В процессе», «Почти готово», «Дорабатывается» различаются только настроением исполнителя. Если команда не может объяснить разницу за десять секунд, оставьте одну колонку.
Нет места для блокеров. Застрявшая карточка среди активных выглядит нормальной, и о ней никто не вспоминает. Отдельная колонка делает проблему видимой.
Колонки скопированы с чужой доски. Чужой процесс не равен вашему. Проверьте каждую колонку тремя условиями из первого раздела.
WIP-лимиты и регулярный обзор
WIP (work in progress) — ограничение числа задач, которые одновременно находятся в работе. В Synqo это не автоматическая функция, а договорённость команды: вы пишете число в названии колонки или в правилах проекта и сами следите за ним. Работает это, пока команда относится к лимиту серьёзно. Для небольшой группы можно начать с простого правила «не более двух карточек на человека».
Регулярный обзор доски замыкает систему. Ежедневно, на пятиминутной встрече, смотрите справа налево: сначала что можно закрыть, потом что на проверке, потом что в работе. Еженедельно разбирайте Backlog и блокеры: что устарело, что пора брать, кого пора подтолкнуть.
Структуру колонок тоже пересматривайте по расписанию, например раз в квартал. Вопрос такой: есть ли колонка, в которой карточки никогда не задерживаются, и есть ли этап, который живёт в чате, а не на доске.
Перенос колонок с другого инструмента
Synqo умеет импортировать данные из Trello, OTask и Kaiten. Важная особенность: импорт создаёт новый приватный проект с досками и не объединяет данные с существующим проектом. Для Trello используется JSON-файл. Чтобы скачать вложения, могут понадобиться API-данные, а сама загрузка вложений при импорте зависит от тарифа и недоступна на бесплатном плане. Условия смотрите на странице тарифов Synqo. Полный перенос любых данных нельзя считать гарантированным, формат и настройки стоит проверить на пробном импорте.
Пример: доска из Trello с восемью списками
Допустим, в Trello списки такие: «Идеи», «Надо обсудить», «К работе», «В процессе», «Ждём ответа», «Проверка», «Выложено», «Архив».
- Выгружаем JSON и делаем пробный импорт. Получаем новый приватный проект, существующие проекты не затронуты.
- Сверяем структуру «проект → доски → колонки» и применяем правило трёх условий:
- «Идеи» и «Надо обсудить» объединяем в Backlog: у обоих нет обязательств и общий владелец.
- «К работе» и «В процессе» оставляем одной колонкой «В работе»: разницу никто не мог объяснить.
- «Ждём ответа» сохраняем как «Ожидает информацию»: здесь карточки действительно застревают.
- «Проверка» оставляем.
- «Выложено» переименовываем в «Готово» и записываем критерий.
- «Архив» не переносим как колонку: старые карточки остаются в импортированном проекте или выгружаются отдельно.
- В Synqo колонки можно создавать, переименовывать и перемещать, поэтому объединение делается уже после импорта.
- Проверка: сравниваем число карточек по спискам Trello и по колонкам Synqo. Открываем 3–5 карточек с чек-листами, комментариями и файлами. Если вложения нужны, проверяем, что они действительно загрузились на вашем тарифе.
Только после этого команда переходит на новую доску, а старую оставляет только для чтения на пару недель.
Как настроить и проверить колонки в Synqo
Иерархия такая: рабочее пространство → проекты → доски → колонки → карточки. В проекте может быть несколько досок, например отдельная для разработки и для контента. Прежде чем заводить новую, проверьте лимиты по доскам и проектам: они зависят от тарифа рабочего пространства. Актуальные условия есть на странице тарифов, а общий список функций смотрите в разделе возможности Synqo.
Порядок действий:
- Создайте или откройте доску и расставьте базовые колонки: Backlog, В работе, На проверке, Готово.
- Добавляйте блокирующую колонку и «На согласовании» только если для них выполняются три условия.
- Колонки можно переименовывать и перемещать, поэтому не стремитесь к идеалу с первого раза.
- Проверьте роли: владелец и администратор управляют структурой проекта, участник действует в рамках настроек проекта, гость только просматривает и комментирует.
- В карточках используйте описание, исполнителя, срок, чек-лист и комментарии, чтобы критерий выхода из колонки был виден.
Проверка через две недели: нет ли колонок, где карточки не задерживаются, и не копятся ли в одной колонке карточки без движения.
Что в итоге
Хорошие колонки отражают то, кто и что должен сделать дальше. Начните с четырёх базовых, добавляйте этапы только когда в них реально застревают задачи, договоритесь о лимитах и обзоре и пересматривайте структуру по расписанию. Доска не гарантирует результата сама по себе, но делает проблемы видимыми, пока они не стали хаосом.
Как проверить, что колонка нужна: разбор на примере команды контента
Правило трёх условий проще понять на конкретном случае. Допустим, команда из четырёх человек ведёт блог и рассылку. На доске стоят колонки «Идеи», «Пишем», «Редактура», «Дизайн», «Согласование с автором», «Публикация», «Готово». Через месяц руководитель замечает, что в «Дизайне» карточки не задерживаются больше чем на день, а в «Согласовании с автором» лежат по две-три недели.
Что делает команда:
- Берёт каждую колонку и отвечает на три вопроса: кто сейчас должен действовать, застревают ли здесь карточки, можно ли выход описать одной фразой.
- «Дизайн» не проходит второе условие: карточки там не застревают, обложку делает один человек за несколько часов. Колонку убирают, а потребность фиксируют чек-листом внутри карточки: «обложка готова», «иллюстрации вставлены».
- «Согласование с автором» проходит все три условия. Владелец этапа: редактор. Застревание очевидно. Выход: «автор подтвердил текст в комментарии». Колонку оставляют и переименовывают в «Ждём автора», чтобы название сразу говорило, кто должен действовать.
- «Публикация» и «Готово» объединяют: между ними нет ожидания, а разница сводится к тому, нажата ли кнопка.
Критерий решения не в красоте схемы. Команда смотрит, станет ли после правки проще ответить на вопрос «что сейчас застряло и у кого». Если после пересборки ответ виден за несколько секунд, структура работает. Если нет, значит, колонки по-прежнему описывают настроение, а не этапы.
Как вести блокеры и исключения
Отдельная колонка для заблокированных задач полезна, только если с ней есть порядок. Иначе она сама превращается в склад, просто с другим названием.
Договоритесь о минимальной записи при переносе карточки в блокирующую колонку:
- что именно мешает: доступ, данные, ответ человека, решение руководителя;
- от кого это зависит;
- до какой даты ждём, прежде чем эскалировать вопрос. Дату удобно указать в сроке карточки или в комментарии.
Карточка без такой записи возвращается исполнителю. Это правило команды, система его не проверяет.
На еженедельном обзоре разберите блокеры по очереди и для каждого выберите одно из действий:
- Снять блокировку. Ответ пришёл, карточка возвращается в «В работе» с комментарием.
- Эскалировать. Ожидание затянулось, руководитель сам связывается с тем, от кого зависит решение.
- Отложить. Задача больше не актуальна в ближайшее время, и её переносят в Backlog с пометкой причины.
- Закрыть. Если ответа не будет и работа не нужна, карточку закрывают, а в комментарии остаётся история решения.
Срочные задачи, которые появляются вне очереди, тоже лучше не прятать. Не заводите для них отдельную колонку заранее: достаточно приоритета или метки, а в правилах команды записать, что срочная карточка может превысить лимит «В работе» только с явным решением руководителя и только на ограниченное время. Если срочное превращается в норму, это сигнал пересмотреть планирование, а не добавлять колонки.
План пилота: как пересобрать доску за две недели
Менять структуру сразу для всех рискованно: команда привыкла к старым колонкам, и резкая смена вызывает сопротивление. Безопаснее короткий пилот.
Первые дни. Выпишите все текущие колонки и для каждой посчитайте карточки. Отметьте те, что давно без движения. Это исходная картина, с которой вы будете сравнивать результат.
Середина первой недели. Соберите команду на двадцать минут и пройдите по колонкам с помощью трёх условий. Решите, что объединить, что переименовать, что добавить. Не больше двух-трёх изменений за раз: так проще понять, какое из них помогло.
Вторая неделя. Работайте по новой структуре. На ежедневном обзоре фиксируйте, где возникали вопросы «а куда это положить?». Каждый такой вопрос показывает неясное правило, а не нерадивость сотрудника.
Итог пилота. Сравните с исходной картиной:
- уменьшилось ли число карточек без движения;
- понятно ли каждому участнику, какие карточки в его зоне ответственности;
- не появились ли колонки, которыми никто не пользуется.
Если большинство ответов положительные, закрепите структуру и запишите правила в описание проекта. Если нет, вернитесь на шаг назад и упростите, а не добавляйте новые этапы. Для больших изменений удобно завести отдельную доску в том же проекте и переносить туда карточки постепенно, пока команда не убедится, что новая схема работает. Лимиты на число досок зависят от тарифа, поэтому заранее проверьте условия.
Проверка после переноса: что сверить помимо числа карточек
После импорта из другого инструмента совпадение количества карточек ещё не означает, что перенос корректен. Составьте короткий чек-лист и пройдите его на выборке:
- Структура. Все нужные доски и колонки на месте, порядок колонок соответствует процессу. Колонки можно переименовывать и перемещать, поэтому расхождения легко поправить.
- Содержимое карточек. В выборке есть описание, чек-листы, комментарии, метки, сроки. Выберите и простые карточки, и самые сложные.
- Участники. Люди из старого инструмента появились в проекте с нужными ролями. Проверьте, кто владелец и администратор, и что внешние заказчики имеют роль гостя, а не участника.
- Вложения. Если файлы важны, убедитесь, что они доступны. Их загрузка зависит от тарифа и от того, какие данные вы предоставили при импорте, поэтому не считайте их перенесёнными без проверки.
- История. Не рассчитывайте на полное совпадение истории изменений со старым инструментом. Если она критична, сохраните выгрузку отдельно, пока не убедитесь, что нужные данные доступны.
Если импорт нужно повторить, помните: он создаёт новый приватный проект. Пробные проекты после проверки лучше удалить или архивировать, чтобы команда не путалась, какой из них рабочий. Дату окончательного переключения объявите заранее и зафиксируйте её в описании старой доски.
