Плоский список задач работает ровно до того момента, пока у компании один проект, одна команда и один набор дедлайнов. В свежей публикации про управление проектами авторы Infostart показывают, где именно таск-трекер перестает быть системой управления и превращается просто в аккуратный журнал поручений. Для русскоязычных IT-команд это знакомый сценарий: сначала доска задач кажется достаточной, а потом выясняется, что она не отвечает на главный вопрос бизнеса — что происходит с проектом целиком.
Как пишет Habr / Менеджмент, проблема проявляется не на старте, а на этапе роста. Пока команда небольшая, действительно хватает базовых функций: поставить задачу, назначить исполнителя, зафиксировать срок, обсудить детали, прикрепить файл, закрыть карточку. Но когда проектов становится несколько, в работу включаются разные подразделения, одни и те же специалисты распределяются между несколькими инициативами, а у менеджмента появляются вопросы к бюджету, трудозатратам, план-факту и себестоимости, простого таск-трекера уже мало. Он по-прежнему отвечает на вопрос «что делаем и кто отвечает», но почти не помогает с вопросом «что происходит с проектом как с управленческим объектом».
В этом и проходит граница между операционным контуром и полноценным управлением проектами. Авторы статьи специально разводят эти уровни. Задача — это минимальная единица исполнения: подготовить документ, настроить интеграцию, протестировать релиз, передать результат заказчику. Проект — конструкция сложнее: у него есть цель, этапы, вехи, зависимости, роли, ресурсы, бюджет, риски, изменения и критерии завершения. Поэтому закрытая в срок задача еще не означает, что с проектом все в порядке. На нее могли потратить вдвое больше часов, чем планировалось. Ее мог выполнить специалист, который в этот момент был нужен на другом критичном проекте. Она могла сдвинуть зависимую работу, увеличить себестоимость или вообще не приблизить команду к контрольной вехе. В таск-трекере карточка будет зеленой. Для руководителя проекта это вполне может быть красная зона.
Первый элемент, которого обычно не хватает, — структура. В статье прямо сказано: проект не должен существовать как папка со списком задач. Нужна управляемая модель, где видно проект, этапы, подэтапы, задачи, подзадачи, вехи, контрольные точки, зависимости и ответственные роли. Без этого руководитель видит активность, но не видит картину. Пример из публикации показательный: в системе может висеть 200 задач, часть уже закрыта, часть просрочена, часть в работе. Но без структуры непонятно, какие из них влияют на ключевые этапы, какие можно безболезненно перенести, а какие уже ломают сроки. Для бизнеса это важная разница. Разработчикам и тимлидам нужен список работ. Руководителю проектного офиса нужен критический путь и понимание, что именно сломается при очередном переносе дедлайна.
Второй слой — планирование и перепланирование. Здесь статья довольно жестко приземляет популярную иллюзию, будто перенос срока в карточке равен актуализации плана. Не равен. План проекта — это не набор дедлайнов, а логика выполнения: что делается, в какой последовательности, где зависимости, где контрольные точки, какие ресурсы нужны и что считать отклонением. В реальной жизни план почти никогда не остается неизменным: заказчик уточняет требования, команда переключается на срочные задачи, всплывают дополнительные работы, ресурсы перераспределяются. Значит, система должна не просто хранить новый срок, а показывать последствия изменений: что сдвинулось, какие вехи под угрозой, где вырос риск, как изменится загрузка команды. Для продуктовых и аутсорсинговых компаний это особенно болезненная тема, потому что внешний контур — обещания заказчику или бизнесу — обычно живет по датам, а внутренний контур давно живет по компромиссам.
Третий провал таск-трекеров — ресурсы. Назначить исполнителя на задачу еще не значит спланировать ресурс. В проектной компании аналитик, архитектор, разработчик или тестировщик почти всегда работают сразу в нескольких направлениях, и локальная видимость по карточкам здесь только мешает: в одном проекте человек выглядит доступным, в другом уже перегружен, в третьем на него начинают рассчитывать через две недели. Именно поэтому ИСУП, о которой говорят авторы, должна показывать не просто фамилию в поле «ответственный», а общую картину загрузки: кто занят, где дефицит, какие роли понадобятся на следующих этапах, можно ли запускать новый проект без удара по текущим. Для CTO, руководителей разработки и PMO это, пожалуй, главный аргумент. Если ресурсная модель отсутствует, компания почти неизбежно управляет людьми постфактум: сначала срываются сроки, потом выясняется, что ключевой специалист уже две недели сидит в трех критических инициативах одновременно.
Четвертый слой — трудозатраты и деньги. Статус задачи не показывает, сколько стоило ее выполнение. А без учета трудозатрат разговор про управление проектами быстро превращается в самоуспокоение. Если команда уложилась в календарный срок, но систематически тратит больше часов, чем планировала, проект может выглядеть успешным только на доске задач. Для компании это уже вопрос рентабельности. Авторы подчеркивают, что трудозатраты должны быть связаны не только с конкретной задачей, но и с проектом, этапом, планом, ресурсом, бюджетом и отчетностью. Иначе невозможно честно ответить на базовые вопросы: где команда недооценивает объем работ, какие этапы постоянно оказываются дороже прогноза, как фактические часы влияют на себестоимость и почему формально «зеленый» проект на деле съедает маржу.
На практике это означает довольно неприятную, но полезную мысль для рынка: таск-трекер не нужно выбрасывать, но его нельзя назначать ИСУП просто потому, что в нем есть доски, статусы и диаграмма Ганта. Для небольших продуктовых команд, саппорта или внутреннего бэклога его часто достаточно. Но как только проектная деятельность становится частью экономики бизнеса, нужен другой уровень зрелости: реестр проектов, структура работ, план-факт, управление изменениями, ресурсная модель, трудозатраты и понятная отчетность для руководителей. И вот здесь главный вопрос уже не в выборе очередного инструмента, а в готовности компании признать, что управление задачами и управление проектами — это разные дисциплины, а не разные вкладки одного сервиса.