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

Кайтен

Управляйте задачами, проектами и командой в одном месте

Попробовать бесплатно

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

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

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

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

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

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

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

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

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

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

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

Если нужно управлять задачами и проектами

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

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

Можно ли настроить разные типы карточек

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

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

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

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

Есть ли отдельный уровень управления проектом

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

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

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

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

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

Хватает ли уровней иерархии

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

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

• Первая — допустимая глубина. Если компании достаточно структуры «задача → подзадача», дополнительные уровни не нужны. Для крупных проектов может потребоваться более подробное деление.
• Вторая — что происходит с данными нижнего уровня. Посмотрите, может ли система показать на уровне этапа или проекта общий прогресс, ближайший срок и объем незавершенной работы. Если она только хранит вложенные задачи, руководителю придется самостоятельно сводить их состояние.

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

Можно ли связывать задачи из разных процессов

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

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

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

• можно ли связать задачи из разных пространств или досок;
• видит ли первая команда статус и срок второй задачи;
• можно ли при создании связанной карточки автоматически передать нужные поля;
• обновляются ли переданные данные после изменений или копируются только один раз;
• можно ли использовать состояние связанной задачи в автоматизациях и отчетах.

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

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

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

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

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

Если команда работает по Канбану, Scrum или планирует проекты на диаграмме Ганта

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

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

Проверьте, есть ли в системе инструменты для полноценной работы по Канбану

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

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

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

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

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

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

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

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

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

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

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

Проверьте, поддерживает ли система полный цикл работы по Scrum

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

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

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

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

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

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

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

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

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

Проверьте, подходит ли диаграмма Ганта для планирования крупных проектов

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

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

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

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

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

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

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

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

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

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

Если нужно хранить документы и вести базу знаний

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

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

Для файлов проверьте хранилище, версии и права

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

Уточните:

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

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

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

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

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

Для совместной работы проверьте возможности встроенного редактора

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

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

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

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

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

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

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

Для базы знаний проверьте, как сотрудники будут находить материалы

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

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

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

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

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

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

Проверьте права и публичный доступ к базе знаний

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

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

• открыть по ссылке отдельную страницу;
• сделать публичным целый раздел;
• опубликовать всю базу знаний для клиентов;
• при этом оставить внутренние материалы закрытыми.

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

На этом все. Во второй части — процессы между командами и автоматизация

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

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