Планирование ИТ-проекта — это не просто составление графика и распределение задач. Это момент, когда всё, что будет сделано дальше, получает форму. Именно здесь закладывается основа успеха или, наоборот, первые ошибки, которые потом будут стоить времени, денег и нервов.
Я не раз видел, как хорошие идеи проваливались не потому, что были плохими, а потому что их не умели правильно запустить.
Начинать планирование без подготовки — как строить дом, не зная, кто в нём будет жить. Нужно понимать, зачем проект нужен, кому он нужен и какие у него будут границы. Без этого даже самая сильная команда не спасёт.
Поэтому я хочу здесь поговорить с вами не о шаблонах и формах, а о том, что действительно важно — о том, что стоит проверить, обсудить и понять до того, как вы начнёте писать ТЗ или открывать Jira.
Цели проекта — с чего всё начинается
Прежде чем писать хоть одну строчку в техническом задании, важно сесть с заказчиком и поговорить по-настоящему. Не формально, не по шаблону, а так, чтобы понять, чего он на самом деле хочет. Иногда люди говорят одно, а имеют в виду другое. Например, заявляют, что хотят «удобный сайт», но на деле им нужна система, которая будет автоматически обрабатывать заявки и снижать нагрузку на отдел продаж.
Цель должна быть чёткой. Лучше, если она будет измеримой. Вместо «сделать удобный интерфейс» — «сократить время оформления заказа до 90 секунд». Это даёт ориентир. Без такого ориентира легко уйти в сторону, потратить ресурсы не туда и в итоге получить продукт, который никто не будет использовать.
Многие ошибки на старте связаны с тем, что требования формулируются «на коленке» и без структуры.
🎓 На курсе «Школа проектного специалиста. Системный аналитик» вы учитесь описывать процессы и фиксировать требования так, чтобы избежать хаоса и двусмысленности ещё до начала проекта. Это как раз тот фундамент, который защищает проект от срыва ещё на стадии запуска. Подробнее на сайте.
Кто ещё участвует — стейкхолдеры
Проект редко касается только заказчика. Есть ещё те, кто будет использовать систему, поддерживать её, принимать решение о внедрении. Их тоже нужно учитывать. Иногда технический директор хочет одну архитектуру, а команда поддержки — другую, потому что ей важно, чтобы система была простой в обслуживании.
Если не включить всех ключевых участников в обсуждение, можно столкнуться с сопротивлением уже на этапе внедрения. Лучше выявить всех заранее, понять их интересы и попытаться найти баланс. Это не значит угодить каждому — но важно, чтобы никто из важных лиц не остался в стороне.
Что уже есть — инфраструктура и ресурсы
Не бывает проектов в вакууме. У заказчика уже есть серверы, базы данных, возможно, старые системы, которые нельзя просто заменить. Нужно понимать, с чем предстоит работать. Если не учесть существующую инфраструктуру, можно предложить решение, которое технически невозможно реализовать или потребует слишком дорогостоящих изменений.
То же самое с людьми. Даже если вы строите проект с нуля, важно понимать, кто будет в команде, какие у них навыки, сколько времени они могут уделять задачам. Недооценка ресурсов — одна из самых частых причин срыва сроков. Особенно когда кто-то считает, что один разработчик справится с объёмом, рассчитанным на троих.
Риски — о чём лучше подумать сейчас
Никакой проект не проходит без проблем. Проблемы бывают разные: кто-то уходит из команды, заказчик меняет требования, появляются технические сложности. Хорошее планирование включает не только то, что должно пойти хорошо, но и то, что может пойти не так.
Нужно заранее выделить возможные риски — технические, организационные, человеческие. И для каждого — хотя бы базовый план действий. Не обязательно прописывать всё до мелочей, но понимать, что делать, если что-то пойдёт не по плану, критически важно.
Ещё одна причина провалов — отсутствие системной работы с рисками.
🎓 На курсе «Управление рисками в проектах» вы научитесь выявлять угрозы на старте, оценивать их влияние и строить план действий заранее — чтобы проект не погиб от предсказуемых ошибок. Подробнее на сайте.
Время и деньги — реальность против ожиданий
Одно из самых сложных — объяснить заказчику, что качественный результат требует времени и ресурсов. Часто звучит: «Сделайте за месяц, бюджет — такой-то». При этом объём работы явно требует больше. Соглашаться на такие условия — путь к выгоранию команды и провалу.
Нужно уметь аргументированно объяснять, откуда берутся сроки и стоимость. Разбить проект на этапы, показать, сколько времени займёт каждый. Это помогает выстроить доверие. И да, иногда приходится выбирать — либо меньше функций, либо больше времени, либо больше денег. Но лучше выбрать осознанно, чем потом догонять график.
Как поймём, что всё получилось
Хорошо, когда есть понимание, как будет оцениваться результат. Не «нам понравилось» или «выглядит нормально», а конкретные показатели: скорость загрузки, количество ошибок, время выполнения операций, уровень удовлетворённости пользователей.
Критерии успешности помогают не только в конце, но и в процессе. Они дают ориентир, позволяют корректировать ход работ, если что-то идёт не так. И, что важно, они снижают субъективность. Когда всё измеримо — меньше споров и больше ясности.
Проект не заканчивается после сдачи
Многие думают, что когда система запущена — проект закончен. На самом деле это только начало. Нужно поддерживать, исправлять ошибки, вносить улучшения. Планирование должно включать и эту часть. Иначе через пару месяцев заказчик снова приходит с просьбой «починить», и всё начинается с нуля.
Кстати, у нас в Telegram-канале Анастасия Сюткина делилась постом «Проект закрыт. Но ты ещё месяц закрываешь вопросы». Очень жизненно: формально проект сдан, а реально — РП ещё несколько недель бегает между пользователями и техподдержкой.
Анастасия разбирает, почему так происходит и как планировать пост-роллаут, чтобы не выгореть: от границ поддержки до финального акта завершения. Если тема вам близка — загляните, там есть практические советы.
Техническое задание — не формальность
ТЗ — это не бумажка для галочки. Это основа, на которой строится всё. Оно должно чётко описывать, что должно быть сделано, как это должно работать, какие технологии использовать. Чем точнее ТЗ, тем меньше недопонимания в процессе.
Но и перегружать его деталями не стоит. Главное — баланс. Достаточно информации, чтобы все понимали задачу, но без излишней формализации, которая только тормозит.
Команда — кто и за что отвечает
Планирование — это не только про задачи, но и про людей. Каждый должен понимать, что от него ждут, какие у него полномочия, на кого он может опереться. Размытые роли ведут к пропущенным срокам, дублированию работы и конфликтам.
Если в команде нет кого-то важного — например, тестировщика или системного архитектора — об этом нужно говорить сразу. Лучше скорректировать план, чем пытаться обойтись без необходимых компетенций.
Всё это — не просто набор советов. Это то, что я видел на практике сотни раз. Когда этим пренебрегают — проекты срываются. Когда подходят серьёзно — даже сложные задачи решаются. Главное — не начинать, а подготовиться.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
Подробнее о наших курсах — на сайте