Проектный план и таск-трекер часто пытаются объединить в одну систему. На первый взгляд это кажется логичным: и там, и там есть работы, исполнители и даты.
Но у этих инструментов разная управленческая задача. Команде нужно понимать, что делать сегодня и на этой неделе. Руководителю проекта нужно понимать, реалистична ли дата завершения, какие этапы определяют срок и что произойдёт, если ключевой сотрудник станет недоступен.
Из-за смешения этих уровней проектный план часто превращается в огромный список мелких задач, который дорого поддерживать и почти невозможно использовать для анализа сроков портфеля.
Разберём, чем отличаются эти два уровня и почему их совершенно не обязательно объединять в одном продукте.
Разный горизонт планирования
Таск-трекер обычно работает на коротком операционном горизонте.
Типичные вопросы:
- что находится в работе;
- что нужно сделать следующим;
- кто отвечает за задачу;
- какие задачи заблокированы;
- что вошло в текущий спринт;
- что уже завершено.
Проектный план смотрит на работу крупнее:
- какие этапы должны быть завершены;
- как они связаны;
- какие ресурсы им потребуются;
- когда эти ресурсы доступны;
- какой срок получается после расчёта;
- что произойдёт при изменении исходных условий.
Например, в проектном плане может существовать этап:
В таск-трекере внутри этого этапа команда может вести десятки элементов:
- создать страницу профиля;
- реализовать API настроек;
- добавить восстановление пароля;
- настроить валидацию формы;
- исправить мобильную версию;
- провести code review;
- исправить найденные дефекты.
Для ежедневной работы команды такой уровень необходим. Для расчёта портфеля из двадцати проектов — часто избыточен.
| Уровень | Типичный горизонт | Главный вопрос |
|---|---|---|
| Таск-трекер | Дни / недели | Что делаем сейчас? |
| План проекта | Недели / месяцы | Когда получим результат и почему? |
| Портфель | Месяцы и несколько проектов | Как проекты делят общие ограничения? |
Разная детализация
Есть соблазн считать, что чем подробнее проектный план, тем он точнее. На практике чрезмерная детализация может сделать модель менее полезной.
Представим проект из 12 крупных этапов. Внутри каждого команда выполняет примерно по 20 операционных задач.
Если перенести всё в календарный план, вместо 12 элементов получится около 240.
При каждом изменении появляются новые связи, даты, назначения и необходимость поддерживать актуальность сотен строк.
Для проектного плана стоит выделять работы, которые действительно влияют на:
- срок;
- последовательность проекта;
- занятость ограниченного сотрудника;
- ключевой результат;
- управленческое решение.
Например:
| Операционная задача | Нужна в проектном плане? |
|---|---|
| Исправить отступ кнопки | Обычно нет |
| Проверить текст уведомления | Обычно нет |
| Разработать новый модуль | Да, если влияет на срок |
| Интегрироваться с внешней системой | Да, если это отдельное ограничение |
| Пройти обязательную приёмку | Да |
| Запустить продукт | Да, как этап или веху |
Это не означает, что мелкие задачи не нужны. Они просто живут на другом уровне управления.
Команда может продолжать вести их в привычной системе, а проектный план — использовать агрегированные этапы.
Разные пользователи
У таск-трекера и проектного планировщика отличаются основные пользователи.
| Роль | Что ей обычно важно |
|---|---|
| Исполнитель | Мои текущие задачи, сроки, комментарии, приоритет |
| Тимлид | Работа команды, блокеры, распределение текущих задач |
| Руководитель проекта | Этапы, зависимости, срок, риски |
| Руководитель портфеля | Общие сотрудники, конфликты, приоритеты проектов |
| Руководство | Когда будет результат и почему дата изменилась |
Если один интерфейс пытается одинаково хорошо обслуживать все эти роли, он неизбежно становится сложнее.
Например, руководителю портфеля редко нужно знать, что разработчик сегодня исправляет конкретное поле формы. Ему значительно важнее другое: разработка проекта А требует Сергея до 20 октября, а проект Б рассчитывает на Сергея уже с 15 октября.
Для исполнителя ситуация обратная. Ему может быть совершенно не нужен график загрузки двадцати проектов, зато нужна конкретная задача с описанием и критериями готовности.
Поэтому наличие отдельного планировщика не означает появление «ещё одного места, где всем сотрудникам нужно вести задачи».
Почему не обязательно объединять планировщик и таск-трекер
Частый аргумент против отдельной системы планирования звучит так: «У нас уже есть Jira, YouTrack, Битрикс24, Trello или другая система задач. Зачем ещё один инструмент?»
Если существующий инструмент хорошо решает операционную работу команды, менять его действительно необязательно.
Вопрос в другом: отвечает ли он на задачи календарно-ресурсного планирования?
Например:
- видно ли одного сотрудника одновременно во всех проектах;
- учитывается ли его отпуск при расчёте сроков;
- пересчитываются ли зависимые этапы;
- можно ли сравнить сценарий изменения;
- видно ли влияние нового проекта на существующие;
- можно ли объяснить, почему получилась конкретная дата.
Если эти задачи уже закрыты текущей системой — отдельный продукт может быть не нужен.
Но если для этого параллельно ведутся Excel-файлы, сводные таблицы, презентации и ручные графики, фактически отдельный слой планирования уже существует. Просто он реализован набором файлов.
| Подход | Операционная работа | Календарный план |
|---|---|---|
| Всё в таск-трекере | Да | Зависит от возможностей системы и процесса |
| Таск-трекер + Excel | Да | Вручную |
| Таск-трекер + отдельный планировщик | Да | Отдельная расчётная модель |
Именно поэтому КОРДО сознательно не строится как система, где каждый сотрудник обязан закрывать каждую маленькую задачу.
Как связать два подхода
На практике проектный план и таск-трекер могут существовать рядом.
Простейшая схема:
| План проекта | Таск-трекер |
|---|---|
| Этап «Дизайн» | Конкретные макеты, правки и согласования |
| Этап «Разработка» | Stories, задачи, bugs, technical tasks |
| Этап «Тестирование» | Тест-кейсы и дефекты |
| Веха «Релиз» | Конкретные действия релизного процесса |
Проектный план определяет временной и ресурсный контур.
Операционная система помогает команде выполнить работу внутри этого контура.
Что переносить в проектный план
Имеет смысл переносить элемент, если он:
- заметно влияет на срок;
- имеет важную зависимость;
- требует ограниченного ресурса;
- является управленческой контрольной точкой;
- нужен для понимания состояния проекта руководителем.
Что можно оставить только в таск-трекере
- мелкие технические задачи;
- подзадачи внутри этапа;
- локальные исправления;
- операционные чек-листы;
- текущую коммуникацию команды;
- дефекты, не влияющие на плановый контур.
Пример
В проектном плане есть:
| Этап | Длительность | Ресурс |
|---|---|---|
| Дизайн | 7 рабочих дней | Анна |
| Разработка | 15 рабочих дней | Сергей |
| Тестирование | 5 рабочих дней | Мария |
Внутри этапа «Разработка» в таск-трекере может существовать 40 задач.
Если одна небольшая задача переносится со вторника на среду, нет необходимости тут же менять верхнеуровневый проектный план.
Если команда понимает, что этап разработки вместо 15 рабочих дней потребует 22, это уже значимое изменение исходной модели — его нужно отразить и пересчитать последующие сроки.
Когда интеграция действительно нужна
Со временем две системы можно связать технически — например, автоматически получать факт выполнения этапов или агрегированную оценку.
Но это уже следующий уровень зрелости. Начинать можно без сложной двусторонней интеграции.
Важнее сначала договориться:
- какой уровень детализации относится к плану;
- кто обновляет оценку этапа;
- когда изменение считается существенным;
- когда требуется пересчёт сроков;
- какая система является источником каких данных.
Короткий чек-лист
- таск-трекер используется для ежедневной работы команды;
- проектный план не копирует все мелкие задачи;
- в плане остаются этапы, влияющие на срок и ресурсы;
- уровень детализации понятен всем участникам;
- общие сотрудники учитываются между проектами;
- изменение оценки этапа приводит к пересчёту плана;
- операционные изменения не требуют постоянного ручного дублирования;
- каждая система имеет понятную управленческую роль.
Что делать дальше
Посмотрите на текущий проект и попробуйте разделить его работы на два уровня.
Сначала выделите 5–15 крупных этапов, которые действительно определяют срок и потребляют ключевые ресурсы. Это кандидат на календарный план.
Затем оставьте внутри каждого этапа привычные рабочие задачи команды в текущем таск-трекере.
Если после такого разделения руководитель всё ещё может понять дату проекта, зависимости и ресурсные ограничения, значит нет необходимости переносить в планировщик сотни операционных задач.
КОРДО построен именно вокруг этого принципа: планировать проекты и портфель, а не становиться ещё одним таск-трекером для сотрудников.