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