Устав: откуда берутся полномочия
Устав отвечает на четыре вопроса: зачем проект нужен компании, кто спонсор, где границы проекта и какими полномочиями обладает руководитель. Одного-двух листов достаточно — объём здесь не имеет значения, значение имеет наличие подписи спонсора.
Без устава руководитель проекта управляет только уговорами. Когда потребуется вывести человека из проекта, изменить приоритет или отказать смежному отделу, окажется, что формального основания нет, а есть только договорённость, о которой все помнят по-разному.
Самый важный и самый пропускаемый пункт — границы полномочий: до какой суммы руководитель принимает решения сам, какие изменения проводит без согласования, кого может привлекать. Формулировка «руководитель проекта управляет проектом» полномочий не даёт.
Содержание: что входит и что не входит
Содержание описывает результат проекта и работы по его получению. Практически всегда его пишут в одну сторону — перечисляют, что делается. Раздел «что не входит» пишут редко, и именно он снимает большую часть споров на приёмке.
Фиксируйте исключения там, где решение неочевидно: миграция исторических данных, обучение пользователей, поддержка после сдачи, работы на стороне заказчика, интеграции со смежными системами, доработки по итогам опытной эксплуатации. По каждому пункту — одно предложение.
Второй элемент — критерии приёмки, сформулированные так, что по ним можно принять однозначное решение. «Система работает корректно» приёмке не подлежит; «сценарии из перечня выполняются, время отклика не превышает N секунд, передан комплект документации по списку» — подлежит.
Заинтересованные стороны: кто и чего хочет
Список заинтересованных сторон полезен не сам по себе, а вместе с ответами на два вопроса по каждой: чего она хочет от проекта и что для неё будет провалом. Перечень фамилий без этого — формальность.
Чаще всего забывают тех, кто не заказывает проект, но кого он затрагивает: смежные подразделения, чьи процессы изменятся, служба поддержки, которой достанется результат, безопасность и юристы, чьё согласование потребуется. Их требования всплывают поздно и стоят дорого именно потому, что о них не спросили вовремя.
Полезно сразу договориться о форме взаимодействия: кто получает отчёт и в каком виде, кто участвует в приёмке, кто согласовывает изменения. Отдельно отметьте тех, чьё влияние велико, а вовлечённость низкая, — с ними нужен персональный контакт, иначе они появятся на приёмке с новыми требованиями.
Матрица ответственности: кто должен был
Матрица распределяет по блокам работ четыре роли: кто исполняет, кто отвечает за результат, с кем консультируются и кого информируют. Смысл в том, чтобы вопрос «а кто должен был» не возникал после того, как что-то не сделано.
Два правила, нарушение которых обесценивает матрицу. У каждого блока ровно один отвечающий: два ответственных означают ноль. И матрицу согласуют с людьми до старта, а не рассылают им по факту — иначе о своей роли человек узнаёт в момент конфликта.
Не расписывайте матрицу до отдельных задач. Достаточно уровня блоков работ и ключевых решений: приёмка, согласование изменений, взаимодействие с заказчиком, эксплуатация после сдачи.
Совещание по запуску
Запуск проекта завершается общей встречей с командой, спонсором и ключевыми заинтересованными сторонами. Её задача — не рассказать план, а убедиться, что все понимают цель, границы и роли одинаково.
Практичный формат: спонсор объясняет, зачем компании этот проект и что будет считаться успехом; руководитель проекта показывает содержание, исключения и вехи; отдельно проговариваются процедура изменений и порядок отчётности. Вопросы участников на этой встрече — самый дешёвый способ найти несогласованность.
Если после совещания у команды остаётся ощущение «непонятно, зачем мы это делаем», проект стартовал с проблемой, которая проявится на первом же конфликте приоритетов.
Документы запуска и что ломается без каждого
| ДОКУМЕНТ | ЧТО ДАЁТ | ЧТО ЛОМАЕТСЯ БЕЗ НЕГО |
|---|---|---|
| Устав | Полномочия руководителя и границы проекта | Управление уговорами, нет основания для решений |
| Содержание с исключениями | Общее понимание результата | Приёмка превращается в спор о том, что подразумевалось |
| Критерии приёмки | Однозначная проверка результата | Сдача зависит от настроения принимающего |
| Карта заинтересованных сторон | Понимание ожиданий и рисков | Поздние требования от тех, кого не спросили |
| Матрица ответственности | Один отвечающий на каждый блок | Вопрос «а кто должен был» после того, как не сделано |
Чек-лист готовности к старту
Пройдите до первой рабочей задачи. Каждый невыполненный пункт — известный источник проблем на приёмке.
Отмечено 0 из 8
Как собрать проект в Shtab
Документы запуска живут рядом с работой: их видно всем участникам и они не теряются при смене состава команды.
- 01Устав, содержание и критерии приёмки — страницами в проекте, с историей изменений.
- 02Матрицу ответственности удобно держать таблицей на той же странице — рядом с содержанием.
- 03Заинтересованные стороны с ожиданиями и форматом отчётности — отдельной страницей или списком.
- 04Уровни доступа разделяют внутреннюю работу и то, что видит заказчик.
- 05Вехи и фазы сразу заводятся на диаграмме Ганта — план виден с первого дня.
- 06Файлы проекта хранят подписанный устав, протоколы и переданную документацию.
Частые вопросы
Нужен, но короткий — половина страницы. Даже во внутреннем проекте возникает вопрос приоритета относительно текущей работы, и без формального основания руководитель проекта проигрывает его линейному руководителю каждый раз. Одного абзаца с подписью спонсора обычно достаточно.