Доска задач для non‑IT команд: как настроить Kanban под HR, продажи и операции — с готовыми макетами колонок

Анна, HR-менеджер производственной компании, завела Kanban-доску в феврале. Скопировала шаблон из туториала: «To Do / In Progress / Done». К марту в колонке «In Progress» висело 47 карточек. Часть из них не двигалась с первой недели. Анна решила, что Kanban «не работает для HR», и вернулась к Excel.

Проблема была не в методе. Проблема в том, что шаблон из IT-туториала описывает цикл разработки фичи, а не процесс закрытия вакансии. В разработке задача либо делается, либо нет. В найме — задача может неделями ждать ответа от кандидата, и это нормальная часть процесса, а не затор.

По данным State of Kanban Report 2022, 86% организаций планировали расширить Kanban на новые функциональные области — HR, продажи, операции, финансы. При этом 87% респондентов считают метод эффективнее других подходов управления работой. Разрыв между намерением и результатом объясняется одним: команды берут IT-доску и ставят её поверх принципиально другого процесса.

Эта статья — готовые макеты колонок для HR, продаж и операций, объяснение логики за каждым из них и сценарий того, как за 15 минут объяснить метод команде без IT-бэкграунда.

Почему стандартная IT-доска не работает для HR, продаж и операций

Процессы в разработке ПО устроены предсказуемо: задача берётся в работу, делается, тестируется, выкатывается. Цикл короткий, зависимости внутренние, результат бинарный. Именно под такую логику заточен шаблон «To Do / In Progress / Done».

Non-IT процессы устроены иначе — и вот ключевые отличия.

Длинные внешние ожидания. Рекрутер отправил оффер кандидату и ждёт три дня. Менеджер по продажам отправил КП и ждёт неделю. Закупщик ждёт подтверждения от поставщика. В IT-доске всё это время задача висит в «In Progress» — хотя по факту никто над ней не работает. Доска перестаёт отражать реальность: непонятно, что заблокировано, что ждёт внешнего ответа, а что реально делается прямо сейчас.

Задачи разного масштаба на одной доске. В HR одновременно живут «закрыть вакансию senior-разработчика» (три месяца работы) и «обновить шаблон оффера» (два часа). В продажах — «согласовать контракт на 50 млн» и «отправить follow-up после звонка». Когда всё это попадает в одну колонку «In Progress», WIP-лимит теряет смысл: одна карточка весит как двадцать других. Для разграничения крупных и мелких задач полезно использовать декомпозицию и оценку по Value vs Effort — это отдельная тема, но она напрямую влияет на то, насколько честно работает ваша доска.

Отсутствие итераций. В Scrum есть спринт — фиксированный цикл с чётким началом и концом. Non-IT задачи приходят непрерывно и непредсказуемо. Вакансия открывается в среду. Срочный запрос от клиента — в пятницу вечером. Логика «закончим к концу спринта» здесь не работает.

Множество заинтересованных сторон за пределами команды. В IT-разработке основные зависимости — внутренние: фронтенд ждёт API от бэкенда. В HR, продажах и операциях ключевые зависимости — внешние: кандидат, клиент, поставщик, юридический отдел, руководство. Каждая такая зависимость — потенциальная точка, где задача зависнет на неопределённый срок.

The Kanban Guide 2025 формулирует базовые практики метода: визуализация потока работы, управление работой через явные правила и WIP-лимиты, постоянное улучшение самого потока. Ни одна из них не требует итераций и не предполагает однородности задач. Но все требуют, чтобы доска точно отражала реальный процесс — не абстрактный «прогресс», а конкретные этапы с конкретными правилами перехода.

Ниже — сравнение того, как выглядит типичная IT-доска и что нужно non-IT команде:

Правила Kanban, которые работают одинаково в любом отделе

Прежде чем строить доску под конкретный отдел, стоит зафиксировать принципы — они одинаковы и для рекрутинга, и для логистики.

Визуализация потока. Доска должна показывать не «над чем работает команда», а через какие этапы проходит работа. Каждая колонка — конкретный статус с понятным смыслом. Не «В работе», а «Подготовка КП» или «Ожидание ответа кандидата». Когда этапы названы точно, сразу видно, где задачи накапливаются.

WIP-лимиты. Ограничение одновременной работы — самый контр-интуитивный принцип для non-IT команд. Менеджер привык брать всё, что пришло. WIP-лимит говорит: не берём новую вакансию в работу, пока не закрыли одну из текущих. Не готовим новое КП, пока предыдущее не отправлено клиенту. Подробнее о том, как настроить WIP-лимиты и почему они сокращают сроки, — в статье про WIP-лимиты в Kanban.

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

Регулярная обратная связь от доски. Доска без анализа — это просто красивый стикерборд. Раз в неделю команда смотрит на доску и задаёт один вопрос: «Какие карточки стоят дольше нормы и почему?» Ответ на этот вопрос запускает улучшения — от пересмотра WIP-лимитов до изменения самих этапов.

Эти принципы — каркас. Дальше начинается отраслевая специфика.

Макет доски для HR: воронка вакансии от заявки до выхода сотрудника

Главная особенность HR-процессов — 60–70% времени закрытия вакансии уходит не на работу рекрутера, а на ожидание: ответа от кандидата, решения нанимающего менеджера, подписания документов. Если эти ожидания не вынести в отдельные колонки, доска будет врать: рекрутер выглядит загруженным, хотя реально ждёт три дня ответа на оффер.

Макет колонок для HR-доски:

Логика каждой колонки здесь принципиальна.

«Заявка на вакансию» — входящий поток без лимита: заявки приходят от бизнеса, и это не зона ответственности рекрутера. «Поиск кандидатов» с лимитом 5 — рекрутер не может одновременно качественно вести больше пяти активных поисков. Буферная колонка «Ожидание отклика» вынесена отдельно: задача здесь не у рекрутера, а у кандидата. Это делает видимым реальный затор — если в этой колонке 15 карточек, значит, либо источники привлечения слабые, либо вакансия непривлекательная.

«Ожидание решения» после собеседования — аналогично: здесь работа у нанимающего менеджера, не у HR. Если карточки здесь зависают на 10 дней, это сигнал к разговору с бизнесом, а не к ускорению рекрутинга.

Это не теория. HR-команда итальянской компании Grow после внедрения Kanban сократила onboarding с 14 дней до 6 уже за первый месяц — подробнее об этом кейсе в отдельном разделе ниже. Перуанский HR-отдел, внедривший Kanban, зафиксировал рост продуктивности с 0,41 до 0,80 — почти вдвое, согласно исследованию в репозитории UCVV.

Для HR-команд, которые хотят связать закрытие вакансий с целями компании, полезно читать в связке с материалом о том, как внедрить целеполагание в HR и операции.

Макет доски для продаж: от лида до закрытой сделки — и почему CRM недостаточно

CRM-система фиксирует статус сделки. Kanban-доска управляет потоком действий менеджера. Это разные вещи, и путаница между ними — одна из причин, почему продажники считают Kanban «ещё одним инструментом для галочки».

В CRM карточка сделки переходит из «Переговоры» в «Договор» тогда, когда менеджер сам это поставит. Доска же показывает: КП готово или нет? Договор у юриста или ещё у менеджера? Клиент получил счёт или ждёт? Это операционная прозрачность, которую CRM-воронка не даёт.

Макет колонок для доски продаж:

WIP-лимит на «Подготовка КП» — 5 карточек — работает против главного греха менеджера по продажам: брать новые лиды вместо того, чтобы дожимать существующие. Если лимит достигнут, новый лид не берётся в работу, пока одно КП не отправлено. Это неудобно психологически. Но по данным о семи non-IT командах, внедривших Kanban по модели Kanban Maturity Model, уже через три месяца фиксировалось сокращение «пожаров», более чёткие критерии приоритизации и улучшение координации — в том числе в продажах. Ограничение параллельной работы напрямую влияло на сокращение цикла сделки.

Буферная колонка «КП у клиента» — зеркало «Ожидания отклика» в HR. Здесь менеджер не работает активно, но карточка видна. Если КП висит здесь дольше условленного срока (например, пяти рабочих дней), — это триггер для follow-up, а не для тревожного ощущения «что-то пошло не так».

Отдельного внимания заслуживает правило для колонки «Закрыто»: она принимает и Won, и Lost. Проигранная сделка должна закрываться явно — с указанием причины. Иначе доска засоряется карточками, которые менеджер не хочет закрывать, потому что это «признание поражения». Через месяц такие карточки превращаются в мёртвый груз.

Макет доски для операций: поставки, логистика, внутренние запросы

Операционная доска отличается от HR и продаж двумя свойствами: задачи часто повторяются (еженедельные поставки, плановое обслуживание, регулярные отчёты) и критически зависят от внешних контрагентов. Это требует двух структурных решений — swimlanes и отдельной колонки «Заблокировано».

Макет колонок для операционной доски:

Swimlanes (горизонтальные строки): Поставки / Внутренние запросы / Логистика.

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

Swimlanes дают ещё одно измерение прозрачности: руководитель видит не просто «сколько задач в работе», а где именно скапливается нагрузка. Если строка «Поставки» переполнена, а «Внутренние запросы» пустая — это сигнал о дисбалансе ресурсов, а не о проблеме с конкретной задачей.

По данным самой компании Würth Industrie Service India, после перестройки процесса обработки заказов удалось сэкономить почти 38 часов в месяц — не за счёт автоматизации, а за счёт устранения ручных шагов и ожиданий, которые стали видны после визуализации потока.

Контр-интуитивный вывод: меньше колонок — не значит проще

Команды без IT-бэкграунда инстинктивно упрощают доску. «Нам не нужно всё это — давайте три колонки, чтобы не усложнять». Логика понятна, но она ведёт к тому, с чего началась эта статья: 47 карточек в «In Progress» и ощущение, что метод не работает.

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

6–8 колонок с буферами ожидания дают больше ясности, а не меньше. Именно детализация этапов — а не их сокращение — позволила HR-команде Grow сократить onboarding с 14 дней до 6 за первый месяц, а к марту 2024 довести наиболее вероятный lead time до 1 дня. Когда каждый этап выделен, сразу видно, на каком именно шаге задача стоит дольше нормы.

Согласно The Kanban Guide 2025, фокус метода — управление потоком, а не статусами. Центральные элементы: WIP-лимиты, работа с узкими местами и измерение реального времени прохождения задачи через доску, а не просто факт её завершения.

Упрощение уместно на старте — чтобы команда привыкла к доске. Но упрощение не должно убирать буферные колонки ожидания: именно они делают Kanban инструментом диагностики, а не красивым списком задач.

Как объяснить Kanban команде без IT-бэкграунда — за 15 минут

Главная ошибка при внедрении Kanban в non-IT команде — начинать с инструмента. «Вот доска, вот колонки, создавайте карточки». Команда создаёт карточки, не понимая зачем, и через две недели перестаёт их обновлять.

Начинайте с вопроса: «Покажите мне, через какие шаги проходит ваша типичная задача». Дальше — пошаговый сценарий первой встречи:

1. Попросите команду назвать этапы, через которые проходит их типичная задача — заявка, заказ, вакансия. Пишите их на стикерах или сразу в доске. Это будущие колонки. Обычно команда называет 9–12 этапов. Смело режьте до 7.
2. Спросите: «Где задачи чаще всего застревают?» Если отвечают «когда ждём ответа от клиента» или «когда нужно согласование от директора» — добавьте буферную колонку ожидания именно для этого этапа.
3. Договоритесь о WIP-лимите: сколько задач одновременно может находиться «В работе» у одного человека? Для non-IT ролей это обычно 2–4 задачи. Зафиксируйте число прямо на доске. Это самый спорный момент встречи — будьте готовы объяснить, что лимит защищает фокус, а не ограничивает продуктивность.
4. Договоритесь о правилах перехода: что именно должно произойти, чтобы карточка перешла в следующую колонку? Запишите это как краткое условие в описании колонки.
5. Запустите доску с реальными задачами текущей недели. Через неделю — 15-минутная встреча: что застряло, что оказалось лишним, чего не хватает.

Для создания доски под конкретный отдел удобно использовать отдельное рабочее пространство — так, чтобы HR-доска, доска продаж и операционная доска не смешивались. В Shtab каждый отдел может вести свою доску в изолированном пространстве, а руководитель видит прогресс по задачам в связке с целями отдела — не просто карточки, а движение к конкретным OKR.

Реальный кейс: как HR-команда Grow сократила onboarding с 14 дней до 1

Итальянская компания Grow столкнулась с типичной проблемой роста: onboarding новых сотрудников занимал в среднем 14 дней, сроки были непредсказуемы, нанимающие менеджеры не понимали, на каком этапе находится каждый новый человек.

HR-команда не нанимала новых людей и не автоматизировала процессы. Вместо этого она визуализировала этапы onboarding на Kanban-доске, ввела WIP-лимиты для каждого активного этапа, начала измерять lead time (время от создания карточки до перехода в «Готово») и установила явные правила перехода между колонками — в частности, IT-доступы стали запрашиваться за три дня до выхода сотрудника, а не в день выхода.

Результат первого месяца: onboarding сократился с 14 дней до 6. К марту 2024 наиболее вероятный lead time снизился до 1 дня. 97% новых сотрудников проходили onboarding за 6 дней, средний показатель составил 1,5 дня — согласно кейсу Kanban Help.

Что именно дало такой результат? Команда увидела, где задачи зависали — не в работе рекрутера, а в ожидании подписей и доступов от IT и административного отдела. До визуализации этот затор был невидим. После — его устранили за счёт одного конкретного правила: запрос доступов заранее.

Kanban для non-IT команд работает именно так: не люди начинают работать быстрее, а потери в потоке — ожидания, согласования, забытые запросы — становятся видимыми и устранимыми.

Что мешает Kanban прижиться в non-IT команде — и как это предотвратить

Вот главные причины, по которым Kanban в бизнес-командах умирает в первый месяц.

Нет правил перехода между колонками. Симптом: карточки перемещаются произвольно, у каждого своё понимание того, когда задача «готова» к следующему этапу. Доска отражает субъективное ощущение прогресса, а не реальное состояние работы. Рецепт: для каждой колонки — одно конкретное условие перехода, записанное в описании. Не «когда примерно готово», а «когда отправлено письмо клиенту с подтверждением получения».

WIP-лимиты игнорируются. Симптом: лимиты выставлены, но при перегрузке команда молча их нарушает. Через месяц лимиты воспринимаются как декоративный элемент. Рецепт: нарушение WIP-лимита — это не штраф, это сигнал к обсуждению. Почему пришлось взять сверх лимита? Что это говорит о пропускной способности команды? Именно это обсуждение и делает Kanban живым инструментом, а не доской для галочки.

Нет регулярного ревью. Симптом: доска обновляется первые две недели, потом карточки перестают двигаться. Команда возвращается к чатам и таблицам. Рецепт: еженедельная 15-минутная встреча у доски с конкретным вопросом: «Какие карточки стоят дольше нормы и почему?» В Shtab отчётность по задачам позволяет за минуту увидеть, какие карточки зависли дольше установленного срока, без ручного просмотра каждой колонки. Для повторяющихся операционных задач удобно использовать функцию операций с повтором — чтобы регулярные задачи создавались автоматически, а не терялись в памяти.

Доска не обновляется в реальном времени. Этот пункт часто упускают. Если менеджер перемещает карточку раз в три дня «по памяти», доска перестаёт быть источником правды. Рецепт: договоритесь, что карточка двигается в момент события, а не в момент «когда руки дойдут». Если это требует слишком много дисциплины — значит, этапов на доске слишком много и стоит упростить.

Хорошая новость: все эти проблемы проявляются в первые 2–3 недели. Если команда прошла этот период и не бросила доску — дальше процесс стабилизируется. О том, как не срывать сроки в процессе перестройки работы, — в статье «Дедлайны без давления».

FAQ — частые вопросы о Kanban для бизнес-команд

Какие существуют базовые практики Kanban?

Согласно The Kanban Guide 2025, базовые практики — визуализация потока работы (каждый этап виден на доске), управление работой через явные правила и WIP-лимиты (не берём новое, пока не завершили текущее), и постоянное улучшение самого потока на основе наблюдений за доской. Все они одинаково применимы к HR, продажам и операциям.

В чём разница между Kanban и Scrum?

Scrum работает итерациями — спринтами фиксированной длины (обычно 2 недели) с чёткими ролями и церемониями. Kanban — непрерывный поток без итераций: задачи берутся в работу по мере готовности команды, а не по расписанию. Для non-IT команд Kanban подходит лучше именно потому, что задачи приходят непредсказуемо — срочный запрос от клиента не будет ждать начала следующего спринта. Подробное сравнение Kanban и других инструментов — в отдельной статье.

Какие сервисы для ведения задач по Kanban существуют в России?

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

Можно ли вести Kanban-доску в Excel?

Технически — да. Практически — Excel не поддерживает drag-and-drop карточек, WIP-лимиты, уведомления о зависших задачах и аналитику потока. Для команды из двух человек с десятком задач в неделю это допустимо как временное решение. Для отдела с потоком 50+ задач в месяц Excel превращается в источник ошибок и ручной работы, которую как раз и должен устранять Kanban.

Kanban для non-IT команды — это способ увидеть, где на самом деле застревает работа. Не в людях, не в мотивации, а в конкретных переходах между этапами, которые раньше были невидимы.

Макеты из этой статьи — отправная точка. Через неделю реального использования команда сама скажет, какие колонки оказались лишними, а каких не хватило. Это нормальная эволюция доски.

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