Устав ИТ-проекта: от структуры до готового примера
«А кто вас вообще просил?»
Вас назначили руководителем, заказчик говорит «начинайте», а через месяц никто не утверждал бюджет, заказчик поменял требования, спонсор уехал. Без устава вы не руководитель, а энтузиаст. В любой момент спонсор может сказать: «А кто вас вообще просил?» — и снять ресурсы. Устав — ваш главный защитный документ. Он даёт право управлять проектом, фиксирует цели, границы, бюджет и согласовывает ожидания.
Что такое устав проекта
Устав проекта (project charter) — это документ, который даёт вам легальное право управлять проектом. Он отвечает на пять вопросов. Зачем мы делаем этот проект? Какую проблему решаем. Что именно делаем (и чего не делаем)? Границы проекта. Кто за что отвечает? Роли и ответственность. Сколько у нас времени и денег? Сроки и бюджет. Кто принимает ключевые решения? Governance.
Важно не путать: устав — это не техническое задание. ТЗ говорит «как должна работать система» (кнопка синяя, по нажатию отправляется запрос), а устав говорит «зачем мы это делаем, кто платит, кто принимает результат». ТЗ можно менять в процессе разработки, устав — только через формальное согласование со спонсором.
Зачем нужен устав, даже если вы работаете по Agile
«Мы по Scrum работаем, нам не нужны бумажки» — слышу это постоянно, и это заблуждение. Даже в чистом Agile есть понятие «цель продукта», «бюджет на разработку», «ожидаемый срок выхода релиза», и эти вещи нужно фиксировать. Не в виде 50-страничного документа, а в виде одностраничного устава.
Устав не запрещает гибкость, он задаёт границы. Внутри этих границ вы можете менять приоритеты бэклога, уточнять требования, перепланировать спринты. Но как только возникает предложение выйти за границы (добавить новый модуль, увеличить бюджет, сдвинуть релиз), вы смотрите в устав и запускаете процедуру изменений.
Из чего состоит устав
В уставе должны быть такие разделы. Название и описание — краткое название и 2–3 предложения о проекте. Бизнес-обоснование — какую проблему решаем и зачем. Цели (SMART) — конкретные, измеримые, достижимые, релевантные, ограниченные по времени. Содержание и границы — что входит и что НЕ входит. Бюджет — общий бюджет плюс резерв на риски. Сроки — дата старта, ключевые вехи, дата завершения. Ключевые участники — спонсор, РП заказчика, РП исполнителя. Критерии приёмки — как поймём, что проект успешен. Допущения — что мы предполагаем (и что может стать риском). Ограничения — что нас сковывает (бюджет, время, регуляторика). Основные риски — топ-5 рисков с вероятностью и влиянием. Порядок изменений — кто утверждает изменения и как. И подписи — спонсор, заказчик, РП.
Пример устава для ИТ-проекта
Проект: Внедрение модуля «Командировки и авансовые отчёты» в компании «ТехноЛогистик».
Бизнес-обоснование. Текущий бумажный процесс занимает в среднем 3 дня на одну командировку, содержит до 15% ошибок в авансовых отчётах, что приводит к задержкам выплат и недовольству сотрудников.
Цели (SMART). Сократить время оформления командировки с 3 дней до 4 часов — через 1 месяц после запуска. Снизить количество ошибок в авансовых отчётах на 80% — через 2 месяца после запуска. Обеспечить выгрузку в 1С не позднее 2 минут после формирования отчёта — на старте ОПЭ.
Границы проекта. Входит: автоматизация заявок, маршруты согласования, электронная форма авансового отчёта с чеками, интеграция с 1С, обучение 50 пользователей. Не входит: мобильное приложение, интеграция с CRM, другие виды отчётов (только авансовые), миграция исторических данных за последние 3 года.
Бюджет. 3 000 000 рублей + резерв на риски 10% (300 000 рублей).
Сроки. Старт 01.03.2026 → опытная эксплуатация 20.05.2026 → закрытие 10.07.2026.
Ключевые участники и роли. Спонсор — Петров А.А., финансовый директор, утверждает бюджет, снимает блокеры. РП заказчика — Сидорова Е.В., начальник отдела командировок, предоставляет требования, принимает результат. РП исполнителя — Иванова М.С., менеджер внедрения, управляет командой, отчитывается. Технический архитектор — Смирнов Д.А., главный разработчик, отвечает за интеграцию с 1С.
Критерии приёмки. Все 50 пользователей прошли обучение и могут самостоятельно оформить командировку. Время оформления командировки сократилось до 4 часов (замер на 100 заявках). Данные корректно выгружаются в 1С. Отсутствуют критические ошибки в течение 2 недель ОПЭ.
Допущения. Ключевые сотрудники заказчика уделяют проекту не менее 8 часов в неделю. API 1С остаётся стабильным (версия не меняется в ходе проекта). ИТ-инфраструктура работает штатно. Заказчик предоставляет доступ к тестовой среде до начала разработки.
Основные риски. Сопротивление пользователей — вероятность 60%, влияние высокое, обучение и вовлечение лидеров мнения. Задержка согласований — вероятность 40%, влияние среднее, еженедельный контроль и эскалация при задержке >3 дней. Изменение API 1С — вероятность 15%, влияние высокое, резерв времени 2 недели, анализ версии до начала разработки.
Порядок утверждения изменений. Изменения, увеличивающие бюджет >10% или срок >2 недель, утверждаются управляющим комитетом (спонсор + финансовый директор + ИТ-директор). Остальные изменения утверждаются РП и заказчиком.
Подписи. Спонсор, заказчик, РП.
Как составить устав
Соберите входные данные — договор, коммерческое предложение, бизнес-кейс (1–2 часа). Проведите встречу со спонсором и заказчиком — за час пройдите по пяти вопросам. Заполните шаблон — не больше двух страниц (2–3 часа). Отправьте на согласование — спонсор, заказчик, технический лидер (1–2 дня). Утвердите устав — подписи спонсора и заказчика. Без подписей не начинайте работы. И опубликуйте в общем доступе — команда и стейкхолдеры должны знать (30 минут).
Типичные ошибки
Цели не измеримы («улучшить качество») — непонятно, достигли цели или нет. Формулируйте по SMART.
Нет раздела «Что не входит» — заказчик требует доработки как «очевидные». Явно перечисляйте исключения.
Устав пишет один РП — спонсор не разделяет ответственность. Создавайте устав на встрече.
Допущения не перечислены — ключевое предположение оказывается неверным. Фиксируйте все допущения.
Устав не утверждён до старта — ресурсы могут снять в любой момент. Не начинайте без подписанного устава.
Что в понедельник утром
Проверьте, есть ли у вашего проекта устав. Если нет — начните с самого простого: название, цель (одна строка), бюджет (диапазон), сроки (дата начала и конца), подписи. Одной страницы достаточно для старта, добавляйте детали по мере роста проекта.
Заключение
Устав — главный защитный документ. Он фиксирует цели, границы, бюджет и даёт право управлять проектом. Главное правило: не начинайте проект без утверждённого устава. Даже одностраничный устав лучше, чем ничего.
Хотите научиться составлять устав и другие артефакты управления проектами на практике? В модуле 3 курса «Мастер управления IT-проектами» мы на воркшопах составляем устав для ваших реальных проектов. Подробнее о курсе →