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

Что такое план IT-проекта и почему универсальные шаблоны дают сбой

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

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

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

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

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

Поэтому этот шаблон меняет порядок. Сначала вы рисуете даты, которые нельзя сдвинуть. Затем выясняете, насколько широким на самом деле является оставшееся окно. После этого вы планируете работы внутри него. Список задач по-прежнему существует — просто он перестаёт быть первым, что вы пишете.

Как настроить этот шаблон в Trupeer

Шаг 1: Откройте раздел Templates

Перейдите в раздел Templates из главного меню.

Шаг 2: Выберите и откройте шаблон

Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

Шаг 3: Разверните просмотр шаблона

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

Шаг 4: Отредактируйте шаблон

Нажмите Edit, чтобы начать изменять выбранный шаблон.

В редакторе вы можете:

• Добавлять новые разделы

• Задавать или обновлять правила форматирования

• Добавить логотип и настроить его позицию и связанные параметры

Шаг 5: Сохраните настроенный шаблон

После того как вы внесёте все необходимые изменения, нажмите Save, чтобы сохранить обновлённый шаблон как свой.

Шаг 6: Предпросмотр и точная настройка шаблона

Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте Preview.

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

С шаблоном плана IT-проекта вы можете:

• Экономить часы на планировании: Пропустите пустую страницу — структура уже создана для IT-инициатив.

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

• Оставаться в фирменном стиле: Применяйте логотип, шрифты и цвета с помощью бренд-набора Trupeer.

• Согласовывать бизнес и IT: Превращайте технические планы в видеообновления, которые понимают бизнес-стейкхолдеры.

• Стандартизировать работу в проектах: Используйте один и тот же шаблон для каждой IT-инициативы.

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

Неподвижные даты и где их найти

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

Вот перечень того, что нужно учесть в первую неделю. Задайте каждому ответственному два вопроса: какая у вас дата и какой у вас срок подготовки (lead time).

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

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

Что входит в план

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

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

2. Результат и критерии успеха. Измеримые и с датами. Добавьте как минимум один критерий про то, что заменяется: например, что унаследованная система не имеет трафика и не несёт лицензионных затрат к указанной дате. Планы, которые заканчиваются на go-live, — это то, как компании в итоге платят за две системы.

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

4. Объём работ. Три списка: включено, исключено и отложено. Список отложенного — самый полезный, потому что именно туда попадает объём работ, когда его урезают, и это прекращает повторение одного и того же разговора четыре раза.

5. Фазы и вехи. Вехи — это события с наблюдаемым ответом, например «обзор безопасности пройден» или «первый магазин запущен в эфир», а не «фаза дизайна завершена».

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

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

8. Среды и данные. Какие среды существуют, какие данные есть в каждой, как защищаются производственные данные в тестовой среде и каков результат профилирования исходных данных.

9. Переключение и откат. Почасовая последовательность переключения, точка принятия решения, когда вы останавливаетесь, кто принимает этот звонок и как вы возвращаетесь назад. Оформите это как исполняемую процедуру — именно сюда относится шаблон метода процедуры.

10. Риски с триггерами. Не матрица вероятности и влияния. Каждый риск получает наблюдаемый триггер и действие, которое срабатывает, когда триггер замечен. «Консультант вендора не подтверждён к 12 мая» — это триггер. «Вендор может задержаться» — не триггер.

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

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

Разбор на примере и во сколько это обошлось

Ashmore Retail, восемьдесят четыре магазина и три распределительных центра, в феврале запланировали заменить систему управления складом во всех трёх DC. Девять месяцев работ, go-live запланирован на середину ноября; в kickoff deck это описали так, будто запуск уверенно опережает пик.

В день того kickoff существовали две неподвижные даты. Обе были опубликованы. Ни одна не была в плане.

Первая — заморозка изменений. Ритейл-операции публикуют её каждый январь, и она действует с 1 ноября по 15 января, покрывая пик торгов. Никакие изменения в продакшене любого рода не вносятся в течение этих одиннадцати недель.

Вторая — контракт на унаследованную систему. Он продлевался 31 декабря ещё на двенадцать месяцев за сто восемьдесят шесть тысяч фунтов, при этом требовалось уведомление за девяносто дней, что сдвигало реальный дедлайн на 2 октября.

Проект шёл по плану в течение весны. Обзор безопасности занял четыре недели при заявленном SLA в две. Консультанты вендора по внедрению были недоступны до октября, потому что их попросили в июле. Оба срыва поглотили, сдвинув go-live с середины ноября на конец ноября — и никто этого не отметил, потому что никто не смотрел календарь заморозок.

Заморозка всплыла на заседании change advisory board в начале сентября. Go-live в ноябре был невозможен, и следующее рабочее окно открылось 16 января.

Это оставило один выбор, который нужно было сделать к 2 октября. Либо уведомить по контракту на унаследованную систему и перейти к работе с 1 января без поддержки той системы, от которой зависел весь бизнес, либо позволить ей продлиться и заплатить за год системы, которую они планировали отключить в ноябре.

Они позволили ей продлиться. Новая система вышла в эфир 4 марта. Контракт на унаследованную систему использовали девять недель из её пятидесяти двух недель — это примерно тридцать две тысячи фунтов ценности против счета в сто восемьдесят шесть тысяч фунтов. Примерно сто пятьдесят четыре тысячи фунтов купили ничего.

Поучительная часть в том, что проект никогда не был «поздним» в том смысле, в котором люди говорят «поздно». Работы выполнялись на приемлемом уровне и в приемлемом темпе. Что пошло не так: окно оказалось на шесть недель уже, чем кто-то нарисовал, и две даты, которые его определяли, с момента до существования проекта уже лежали в опубликованном календаре и подписанном контракте.

Если бы календарь ограничений был нарисован в феврале, последовательность была бы очевидной. Go-live до 1 ноября, с обратным отсчётом через четырёхнедельный обзор безопасности, который на самом деле был шестинедельным, шестинедельным маршрутом закупок и консультантами, которым нужен был квартал уведомления — значит, контракт с вендором нужно было подписать к середине апреля. Его подписали в июле. Проекту не нужно было ускоряться. Нужно было начать свои неподвижные зависимости на одиннадцать недель раньше.

Пять форм IT-проектов и какие разделы несут основную нагрузку

Списки из двадцати шаблонов IT-проектов — частая история в этом поиске: от внедрения ITSM до обновлений инфраструктуры и создания PMO. На практике всё сводится к пяти формам, и форма подсказывает, какие разделы выше заслуживают подробностей.

Замена. Замена работающей системы на другую. Включает WMS, ERP, инструменты ITSM, платформы help desk, HR-системы. Разделы 3, 9 и 2 несут основную нагрузку, потому что сложное — это окно, переключение и подтверждение того, что старая система действительно отключена.

Внедрение. Что-то новое без предшественника. Включает управление SLA, IT-управление и программы compliance, управление активами, управление знаниями. Разделы 11 и 2 несут основную нагрузку, потому что до этого ничего не было сломано, и именно внедрение делает это реальным. Наш digital adoption implementation guide углубляется в это.

Миграция или обновление на месте. Та же система, новая версия, новый хост или новый регион. Включает виртуализацию, консолидацию, миграцию в облако, обновления баз данных. Разделы 8 и 9 несут основную нагрузку, потому что откат — это вся игра.

Разработка. Разработка ПО и автоматизация процессов. Раздел 4 несёт основную нагрузку, потому что объём работ — переменная, которая двигается, а критерии приёмки — то, что останавливает её незаметное смещение.

Программа и гарантии. Создание PMO, IT-аудиты, управление портфелем, управление рисками, compliance по безопасности. Раздел 12 несёт основную нагрузку, потому что результат — это доказательства и согласование, а не рабочая система, а вехи — это даты обзоров, заданные кем-то другим.

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

Соберите план за один день

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

День: напишите разделы 1, 2 и 4, затем вехи. Оставьте подробную декомпозицию работ команде поставки — пусть она заполнит её в течение недели. План полезен в тот момент, когда согласованы окно и объём работ, и он не становится полезнее от того, что в нём четыреста строк.

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

Что нужно исключить

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

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

Подробные процедуры того, как выполняются работы, относятся к IT SOP, а описание того, что вы построили, — к IT documentation, а не к плану. Передача в эксплуатацию команде run заслуживает корректного планирования — для этого и нужен knowledge transfer SOP.

Когда пора перестать использовать документ и перейти на ПО

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

В этот момент перенесите декомпозицию работ в ПО для планирования и оставьте документ для разделов 1–5 и 12 — это части, которые читают люди, никогда не открывающие инструмент. Документ фиксирует договорённости. Инструмент хранит расписание.

Превращаем план во то, что команда поставки реально выполняет

План читают на kickoff и на steering meeting. Runbook по переключению читают в два часа ночи человеком, который не был на ни одном из этих мероприятий.

Trupeer AI превращает запись экрана в документированную процедуру, поэтому шаги переключения из раздела 9 и задачи на первый день из раздела 11 становятся walkthrough’ами ваших реальных систем, а не абзацами, которые их описывают. Запишите последовательность один раз — и вы получите пошаговое руководство, видео и документ в вашем knowledge base, в вашем собственном фирменном стиле.

Запишите. Оформите в бренде. Переведите. Trupeer’ьте.

Для работ по внедрению в разделе 11 change management и training videos закрывают сторону запуска, а documentation удерживает вместе план, runbook и материалы передачи. Инструкции по настройке находятся в document template setup guide.

Часто задаваемые вопросы

Есть ли бесплатный шаблон плана IT-проекта в Excel?

Не как файл от нас — и стоит прямо сказать о компромиссе. Excel действительно лучше подходит как контейнер для декомпозиции работ в разделе 6, потому что даты, зависимости и сводные данные живут в ячейках. Соберите этот лист сами: колонки для задачи, ответственного, начала, окончания, зависимости, статуса и флага неподвижности. Держите разделы 1–5, 9 и 12 как документ, потому что их обсуждают в прозе, и никто не согласовывает объём работ в таблице.

Есть ли версия для Word или бесплатная загрузка Word-документа?

Структура из двенадцати разделов выше написана так, чтобы её можно было копировать прямо в Word или Google Docs. Вставьте заголовки, сохраните нумерацию и заполните в указанном порядке. Нет ограниченной загрузки — а значит, нет и формы между вами и структурой.

Есть ли версия PDF?

Вставьте разделы в ваш редактор и экспортируйте в PDF, когда план согласован. План стоит «заморозить» как PDF в момент, когда его согласовали, и стоит держать редактируемым до этого — поэтому экспортировать собственную копию в нужный момент лучше, чем начинать с фиксированного файла.

Есть ли версия PPT для kickoff deck?

Презентация — это другой документ с другой задачей. Обычно достаточно шести слайдов: результат, окно поставки из вашего календаря ограничений, объём работ «внутри/снаружи», вехи, названные внешние зависимости и кто принимает какие решения. Не помещайте декомпозицию работ в презентацию. Никто не читает полосу Ганта на проекторе.

Могу ли я скачать это бесплатно?

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

План поставки проекта — это то же самое, что план проекта?

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

Нужно ли мне также отдельный шаблон отчёта по управлению проектом?

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

Насколько подробным должен быть план IT-проекта?

Достаточно, чтобы новый участник понимал, что будет дальше, и не больше. На практике документ плана для проекта на девять месяцев занимает примерно восемь–пятнадцать страниц, и большая часть — это разделы 8 и 9. Если документ длиннее runbook по переключению, баланс неверный.

Как часто нужно обновлять план?

Разделы 6 и 7 меняются каждую неделю и должны быть там, где уже работает ваша команда. Разделы 1–5 должны меняться редко, и каждое изменение в них — это решение, которое кто-то должен одобрить. Если ваш раздел с объёмом работ каждую неделю незаметно редактируют, значит у вас нет плана — у вас есть дневник.