Как выбрать систему управления работой. Часть 1: задачи, проекты и документация

Блог Kaiten · 18 сентября 2026

Разбираем, что проверить при выборе системы, а эксперты рассказывают о функциях, которые оказались полезны в работе

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

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

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

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

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

Часть специализированной работы при этом может остаться в других сервисах. Например, финансовый учет можно продолжить вести в 1С или ERP, а разработчики могут хранить код в Git-репозитории. В систему управления работой достаточно передавать связанные с процессом данные: срок поставки, статус оплаты, готовность разработки или другую информацию, от которой зависят следующие действия команды.

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

Например, Денис Бартоломе, эксперт по управлению проектами и Канбан-тренер, рассказал, что его команда работает в Кайтене и сначала использовала систему довольно просто: записывала задачи на доску и назначала исполнителей.

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

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

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

Пройдемся по этим критериям подробнее.

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

При выборе проверьте, можно ли для каждого типа задачи настроить:

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

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

Заранее определите, какие данные нужны на этом уровне. Это могут быть:

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

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

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

Здесь стоит проверить две вещи.

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

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

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

Для такого процесса понадобится возможность связывать карточки. Проверьте:

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

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

Во втором случае повторения только по фиксированному календарю будет недостаточно. Иначе система создаст задачу автоматически, а дату сотрудникам все равно придется исправлять вручную.

В регулярной работе повторяются не только сами задачи, но и действия внутри них. Со временем такие операции тоже стоит автоматизировать. Игорь Филипьев , старший Delivery-менеджер компании «Лига Ставок» и автор книги «Канбан для менеджера» , говорит, что ценность этой возможности становится особенно заметна уже в процессе работы.

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

Мы не будем разбирать все методы и инструменты управления проектами. Отдельно остановимся на Канбане, фреймворке Scrum и функциональности диаграммы Ганта, потому что для них в системах чаще предусмотрены специализированные функции.

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

WIP-лимиты . Они задают максимальное количество задач, которые команда одновременно держит в работе. Например, на этапе проверки можно установить предел в пять карточек. Когда лимит достигнут, команда видит, что новые задачи пока не стоит брать на этот этап.

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

При работе по Канбану могут пригодиться и менее очевидные функции. Например, Максим Якубочич, руководитель направления «Управление проектами и Agile» в Product Lab и автор канала «Из проджекта в продакты» , рассказал, что уже после перехода одной из команд на Канбан-метод обнаружил в Кайтене возможность отмечать заблокированные карточки.

Блокировки помогают разбирать отдельные задачи, которые застряли в работе. А чтобы увидеть проблемы уже на уровне всего потока, понадобятся метрики.

Потоковые метрики. Для анализа Канбана могут понадобиться:

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

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

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

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

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

Минимальный набор стоит проверить по пунктам:

Особенно внимательно проверьте работу уже после старта спринта. Добавьте новую задачу, уберите одну из запланированных и измените оценку. 

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

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

Что касается отчетов, то в рамках фреймворка используют график сгорания (Burndown) и скорость команды (Velocity). Они нужны не всем Scrum-командам, поэтому их лучше проверять только при реальном использовании этих показателей.

В результате для Scrum полезнее проверить один настоящий спринт целиком, чем просто открыть соответствующую доску. Так станет понятно, какие операции система поддерживает напрямую, а какие придется воспроизводить вручную.

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

Если сроки работ связаны между собой, проверьте следующие возможности:

Возможности Ганта могут оказаться полезными уже после начала работы с системой. Например, Алексей Сохин, руководитель программ из компании «Лидеры изменений» , рассказал нам, что при выборе продукта его команда фокусировалась на гибкости бэклога и канбан-досках, а Гант воспринимала как архаичный инструмент из MS Project. Но позже высшему руководству понадобился план-график для защиты бюджета.

Когда команда начала пользоваться диаграммой, первоначальное отношение изменилось: современная реализация оказалась гораздо практичнее, чем ожидали специалисты:

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

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

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

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

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

Сначала определите, какую роль документы будут играть в работе. Готовый договор или макет достаточно прикрепить к задаче. Техническое задание команда может редактировать вместе. А инструкции и регламенты должны оставаться доступными независимо от конкретного проекта, чтобы сотрудники могли найти их спустя месяцы.

Для этих задач понадобятся разные возможности системы.

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

Уточните:

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

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

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

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

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

Базовый набор понятен: совместное редактирование, комментарии и упоминания. Глубже стоит проверить историю изменений и связь с рабочими задачами.

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

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

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

Связь с задачами. Обычной ссылки может быть достаточно, если документ нужен только как справочный материал. Для крупных проектов полезнее двусторонняя связь: из задачи можно открыть нужный документ, а из документа — перейти к работе, которая относится к конкретному требованию.

Здесь стоит проверить, что произойдет после перемещения или переименования документа. Если связь перестает работать, сотрудникам придется вручную обновлять ссылки.

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

Поэтому сначала проверьте поиск.

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

Если документов много, пригодятся дополнительные возможности: поиск внутри выбранного раздела, фильтры и результаты с фрагментом найденного текста.

Структура базы. Посмотрите, насколько глубоко можно вкладывать разделы и страницы и можно ли потом переносить их без потери ссылок. Это важно, потому что структура базы почти наверняка будет меняться по мере роста компании.

Полезно также проверить, можно ли создавать ссылки между страницами. Так инструкции можно связывать между собой, а не дублировать один и тот же текст в нескольких местах.

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

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

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

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

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

Источник: Блог Kaiten