Таймлайн проекта: пример временной шкалы задач

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

Что показывает проектная шкала

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

Когда команде нужна общая шкала

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

Чем она отличается от других планов

Проектная шкала отличается от дорожной карты уровнем подробности, от календарного плана — способом показа уже оценённых работ, а от диаграммы Ганта — глубиной модели связей. Форматы можно сравнить по одному критерию: какое решение читатель принимает по каждому из них.

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

Какие данные собрать перед построением

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

Даты и роли — учебные условия. Они не описывают реальный проект клиента или автоматический расчёт в Strive.

Как выбрать работы для шкалы

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

Как оценить продолжительность

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

Как проверить доступность команды

Доступность команды проверяют по занятости каждого исполнителя в выбранные дни. В учебном примере редактор ведёт сценарий 9–10 ноября, затем содержание 11–17 ноября; организатор параллельно готовит страницу регистрации 11–16 ноября. Две полные работы одного человека на одни и те же дни потребовали бы пересмотра оценки или назначения другого исполнителя. Изображение шкалы само по себе загрузку не выравнивает.

Как расположить работы во времени

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

Рисунок 1. Исходная шкала: шесть строк работ, дневной масштаб и событие «эфир готов к запуску».

Какие работы идут по очереди

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

Где отметить контрольное событие

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

Какой масштаб выбрать для обзора

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

Как выглядит заполненная шкала

Заполненная шкала учебного вебинара охватывает работы с 9 по 25 ноября 2026 года. Редактор отвечает за тему и содержание, организатор — за страницу регистрации, проверку, репетицию и эфир. Ответственный в таблице означает владельца результата работы; руководитель отдельно подтверждает контрольное событие. Даты включены в интервалы работ.

Рисунок 2. Заполненная шкала: содержание и страница регистрации идут параллельно, затем сходятся перед проверкой.

Где сходятся параллельные работы

Параллельные работы сходятся 18 ноября, когда организатор начинает общую проверку содержания и страницы регистрации. Если редактор закончил материалы 17 ноября, а страница готова 16 ноября, проверка начинается после более позднего результата. У организатора есть конкретный вход для проверки, а не расплывчатое поручение «посмотреть готовность».

Что меняется после задержки

После задержки содержания на два рабочих дня редактор передаёт материалы 19 ноября вместо 17-го. Проверка сдвигается с 18–19 на 20 и 23 ноября, репетиция — с 20 на 24 ноября. Дата эфира 25 ноября в учебном примере пока остаётся прежней, но резерв между репетицией и эфиром сокращается. Руководитель подтверждает новый порядок и решает, приемлем ли однодневный промежуток. Без подтверждения новая дата репетиции остаётся прогнозом, а не обещанием команды.

Рисунок 3. Версии «было/стало»: сдвиг содержания меняет проверку и репетицию, но не переносит эфир автоматически.

Как поддерживать шкалу актуальной

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

Какие даты обновлять при переносе

При переносе обновляют прогнозные даты затронутых работ и отдельно сохраняют исходное обещание и состоявшийся факт. Для содержания исходное окончание — 17 ноября, новый прогноз — 19 ноября, фактическое окончание появится после передачи материалов. Для репетиции исходная дата — 20 ноября, новый прогноз — 24 ноября. Такое разделение не выдаёт прогноз за уже состоявшееся событие.

Кто подтверждает новую версию

Новую версию подтверждает руководитель после сообщения исполнителя о задержке и оценки последствий для общей даты. Редактор сообщает, когда передаст материалы; организатор предлагает новое окно проверки и репетиции; руководитель решает, оставлять ли эфир 25 ноября. После решения организатор обновляет шкалу и сообщает участникам дату её пересмотра. Одного молчаливого перемещения полосы недостаточно для согласования обязательства.

Как увидеть сроки задач в Strive

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

Рисунок 4. Представление «Таймлайн» в Strive: актуальный экран доски с задачами по времени.

Где открыть представление Таймлайн

Представление «Таймлайн» выбирают среди форматов отображения доски Strive. На подтверждённой продуктовой странице оно указано рядом со «Списком» и «Календарём». После открытия команда сверяет сроки задач с согласованной шкалой проекта и при необходимости переходит к рабочей карточке. Названия конкретных кнопок внутри приложения могут отличаться от сайта; инструкция не предполагает неподтверждённого меню.

Чего режим не рассчитывает автоматически

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

Какие ошибки делают шкалу бесполезной

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

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

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