Неделя вместо демо: как понять, подходит ли вам таск-трекер

Проверять таск-трекер на пяти карточках — всё равно что выбирать машину по фотографии. Пока в системе не появились реальные дедлайны, зависшие согласования, подрядчики и задачи из лички, вы не знаете, выдержит ли она настоящую работу. Разбираемся, как проверить таск-трекер за неделю так, чтобы результат был полезнее любого демо.

Возьмите один живой проект

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

Для проверки нужен проект, который уже идёт и проживёт ещё хотя бы неделю. Это может быть запуск страницы, подготовка мероприятия, работа с подрядчиком или небольшой внутренний проект. Главное, чтобы внутри уже были реальные задачи, несколько участников, сроки и хотя бы пара зависимостей.

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

Начните с четырёх состояний

Желание сразу построить идеальную доску лучше переждать. Иначе уже в первый вечер появляются «Запланировано», «В очереди», «В работе», «На проверке», «На согласовании», «На утверждении», «Ждёт клиента» и ещё несколько колонок, смысл которых через два дня никто не помнит.

На старте хватит простой схемы:

Новые → В работе → Ждёт → Готово

«Новые» — всё, что ещё не начали. «В работе» — только задачи, которыми действительно занимаются сейчас. «Ждёт» — всё, где следующий шаг зависит от другого человека, решения или внешнего события. «Готово» — работа, для которой больше ничего делать не нужно.

Новый этап стоит добавлять только после того, как команда несколько раз столкнулась с ситуацией, которую эти четыре состояния плохо описывают. Если задачи регулярно проходят отдельную проверку перед завершением, тогда появляется смысл в колонке «На проверке». Так процесс формирует доску, а не наоборот.

Поставьте WIP-лимит

WIP — work in progress, количество незавершённых задач. В канбане его ограничивают, чтобы команда меньше начинала и больше заканчивала.

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

Это быстро отрезвляет. Без ограничения у сотрудника легко оказывается восемь карточек «В работе», хотя прямо сейчас он занимается максимум двумя. Доска показывает бурную деятельность, а задачи неделями путешествуют между «почти начал» и «скоро вернусь».

Если команда работает тесно вместе, можно поставить общий лимит на колонку. Например, максимум пять активных задач на всю команду. Цифра здесь не догма: через неделю её можно увеличить или уменьшить, если станет понятно, что ограничение мешает или, наоборот, ничего не меняет.

В Канбано такой лимит сейчас нужно соблюдать как правило команды — автоматически система его не контролирует.

Не назначайте человеку десять следующих задач

С WIP-лимитом хорошо работает pull-принцип — следующая работа «вытягивается» только после того, как освободилось место.

В привычной схеме руководитель постепенно складывает исполнителю целую очередь: это сделай сегодня, это завтра, вот это тоже твоё, а это срочное. Формально задачи назначены, фактически человек каждый раз заново решает, за что хвататься.

При pull-подходе ситуация проще. Закончилась одна карточка — только тогда человек берёт следующую из очереди. Колонка «В работе» показывает настоящее состояние дел, а не планы на ближайшие две недели.

На время пилота можно даже запретить заранее переносить карточки в активную работу. Если задачу никто сейчас не делает, ей там нечего находиться.

Введите Definition of Ready

Иногда задача попадает в работу раньше, чем её вообще можно выполнить.

Карточка называется «Сделать баннер». Исполнитель открывает её и обнаруживает, что нет текста, размера, исходников и понимания, когда результат нужен. Первые полчаса работы превращаются в поиск автора и раскопки старой переписки.

Чтобы этого не происходило, команде полезно определить Definition of Ready — минимальные условия, при которых задачу разрешено брать в работу.

Для небольшого проекта хватит простого правила: понятен ожидаемый результат, назначен ответственный, приложены необходимые материалы, а срок указан там, где он действительно существует. Если чего-то критичного не хватает, карточка остаётся в очереди.

Не нужно превращать Definition of Ready в анкету на двадцать пунктов. Его смысл как раз в том, чтобы ловить несколько типичных причин, из-за которых команда регулярно начинает работу слишком рано.

И договоритесь, что значит «Готово»

Обратная проблема возникает в конце. Дизайнер считает макет готовым, потому что закончил работу. Менеджер считает, что задача ещё выполняется, потому что клиент ничего не согласовал. В итоге статус одной карточки зависит от того, кого спросили.

Здесь помогает Definition of Done — общее определение завершённой задачи.

Например, для одной команды «готово» означает «результат выполнен и передан следующему участнику». Для другой — «материал проверен и опубликован». Для работы с клиентом — «результат согласован и больше не требует действий команды».

Запишите определение одной-двумя фразами. Если после перемещения карточки в «Готово» она регулярно возвращается обратно, значит, критерий завершения выбран плохо или команда понимает его по-разному.

Не прячьте ожидание внутри работы

Допустим, текст написан и ждёт комментариев руководителя. Исполнитель больше ничего с ним сделать не может, но карточка продолжает лежать в «В работе».

Рядом стоит макет, который ждёт ответа клиента. Ещё одна активная задача. Третья остановилась, потому что подрядчик не прислал данные.

В итоге колонка полна, хотя половина задач фактически простаивает.

Поэтому всё заблокированное на время пилота стоит сразу переносить в «Ждёт». Полезно также написать в карточке, чего именно не хватает: «ждём согласование от клиента с 30 сентября» гораздо информативнее обычного «ждём».

Через неделю эта колонка даст довольно честную картину узких мест. Может оказаться, что команда выполняет свою часть быстро, а основное время съедают согласования, передачи и чужие ответы.

На короткой планёрке идите справа налево

Есть ещё одна простая канбан-практика: начинать обсуждение не с вопроса «что возьмём сегодня», а с «что можем сегодня закончить».

Сначала посмотрите на «Ждёт». Можно ли кого-то подтолкнуть, получить ответ или снять блокировку? Потом — на старые карточки в «В работе». Что мешает довести их до конца? И только после этого имеет смысл открывать очередь новых задач.

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

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

Проведите тест «исполнитель исчез на три дня»

К середине недели откройте несколько чужих карточек и попробуйте разобраться в них без помощи авторов. Представьте, что человек внезапно ушёл в отпуск и спросить его сейчас нельзя.

Понятно, что требуется получить? Видно, что уже сделано? Есть необходимые файлы? Можно определить следующий шаг?

Если большую часть контекста всё ещё приходится добывать в личке, таск-трекер пока используется как список заголовков. Для нормальной карточки чаще всего достаточно короткого описания результата, исполнителя, даты при необходимости, чек-листа для небольших действий и материалов, без которых работу невозможно продолжить.

В Канбано для этого есть исполнители, даты, чек-листы, вложения и метки. Но проверять нужно не наличие функций, а результат: способен ли другой человек понять задачу без пятиминутного пересказа.

Не превращайте доску в вечерний отчёт

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

Получается аккуратный отчёт о работе, который самой работе почти не помогает.

На семь дней стоит договориться об одном жёстком правиле: если новая задача относится к тестовому проекту, она появляется на доске сразу. Обсуждать детали можно в чате, но сама договорённость не должна существовать только там.

Если правило постоянно нарушается, не спешите обвинять сотрудников. Посмотрите, почему систему обходят. Может быть, карточку слишком долго создавать, непонятно, куда её положить, или доска вообще не соответствует тому, как команда реально работает. Для пилота это не провал, а полезный результат.

На седьмой день забудьте вопрос «ну как вам?»

Впечатления от интерфейса легко обсуждать час и так ни к чему не прийти. Один человек любит минимализм, другому хочется больше настроек, третьему всё равно.

Гораздо полезнее посмотреть на конкретные изменения за неделю:

• сколько задач осталось только в переписках;
• можно ли понять статус проекта без отдельного сбора информации;
• получилось ли соблюдать WIP-лимит;
• сколько работы регулярно зависает в ожидании;
• какие задачи начали без нужных данных;
• сколько карточек пришлось возвращать из «Готово»;
• какие колонки и правила ни разу не пригодились.

Из этого уже можно принимать решения.

Если WIP-лимит постоянно нарушается, возможно, цифру выбрали слишком маленькую. А возможно, команда действительно привыкла запускать новое раньше, чем заканчивать старое. Если переполнено «Ждёт», стоит разбираться с согласованиями. Если задачи постоянно возвращаются из «Готово», нужно уточнить Definition of Done.

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

Почему 0 ₽ важны для честного теста

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

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

Для первой недели достаточно одной доски. Оставьте минимальный поток, поставьте WIP-лимит, договоритесь о Definition of Ready и Definition of Done, вынесите ожидание отдельно и каждый день сначала разбирайте уже начатую работу.

Через семь дней у вас будет намного более полезный ответ, чем «интерфейс вроде удобный». Станет понятно, помогает ли система видеть работу такой, какая она есть, и где сам процесс теряет время.

Проверить недельный пилот  можно сразу на текущем проекте — без учебных карточек и необходимости покупать подписку ради эксперимента.