Руководитель проекта без иллюзий. Как начать, не утонуть в хаосе и довести проект до результата

2.4. УСТАВ ПРОЕКТА

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

Чаще всего данный документ создаёт руководитель проекта, подписывает его топ-менеджер компании, ответственный за инициацию и запуск проекта.

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

Бывает, что некоторые компании включают в Устав план-график реализации проекта, в этом нет ничего плохого. Но нужно понимать, что в зависимости от выбранной методологии реализации проекта заказчика, и других факторов, план становится более динамичным, чем сам Устав проекта, который подписывают и редко вносят в него изменения. Поэтому лучшим решением будет вынести план-график реализации проекта из Устава, сделав его отдельным документом, в самом Уставе сослаться на документ «План-график реализации проекта». В Уставе проекта стоит создать раздел «План управления проектом».

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

Замечу:

Устав может быть отдельным документом, а может быть приложением к договору.

Если проект начинается не с готового устава, а только с идеи, полезно сначала коротко упаковать её в продуктовый питч: какую проблему решаем, для кого, какую ценность создаём, какие функции нужны в первую очередь, какие ограничения и риски уже видны. Для этого можно использовать приложение А.7. «Чек-лист продуктового питча».

Далее перейду к описанию структуры и содержания Устава с разбивкой по разделам:

— Титульный лист. Вариантов оформления данного раздела много, укажу только обязательную информацию. В разделе должно быть:

— Название организации.

— Название документа (в нашем случае это Устав или Устав проекта).

— Название проекта (например, «Разработка информационно-развлекательного портала»).

— Номер контракта на разработку данного проекта.

— Год создания документа.

— Оглавление. Идёт второй страницей. Рекомендую сразу прописать структуру и по ней заполнять документ или при правильном оформлении заголовков автоматически сгенерировать оглавление после заполнения документа.

— Изменения документа. В этом разделе нужно фиксировать все изменения документа. В разделе должно быть:

— Версии документа.

— Даты изменения.

— Комментарии.

— Что изменено.

— Лист согласования. По сути, это продолжение прошлого раздела и их можно объединить в одну таблицу. Для удобства восприятия рассмотрим его как отдельный раздел. В разделе должно быть:

— Инициатор (кто инициировал изменение).

— Версия согласуемого документа.

— Дата согласования.

— Сведения о проекте. В разделе должно быть:

— Полное наименование проекта.

— Краткое наименование проекта.

— Область применения.

— Описание проекта.

— Функциональный заказчик и/или его представители.

— Руководитель проекта.

— Исполнители проекта с указанием ролей и контактных данных.

— Соисполнители (если будут).

— Формальные основания для инициации.

— Взаимосвязь с другими проектами.

— Сроки реализации проекта.

— Автор Устава проекта.

— Дополнительная информация.

— Цели и задачи проекта. В этом разделе указывают, какие цели будут достигнуты и какие задачи решены в ходе реализации проекта. В разделе должно быть:

— Наименование цели.

— Наименование задачи (в одной цели их может быть много).

— Метод достижения цели.

— Критерии достижения.

— Статус.

— Целевые показатели (результаты). В этом разделе фиксируют, какие цели и результаты уже достигнуты, какие задачи решены и сколько ещё времени нужно для завершения работ. В разделе должно быть:

— Наименование цели/показателя.

— Текущее значение (или можно сделать стартовое значение).

— Достижение цели: даты проверок (составьте список контрольных точек для проверки показателей).

— Заинтересованные стороны и их ожидания. В этом разделе стоит описать функции спонсора проекта, владельца проекта, любых известных поставщиков или внешних экспертов, которые будут использоваться во время реализации проекта. В разделе должны быть указаны:

— Орган/организация.

— Представляющий интересы (ФИО, должность).

— Ожидания от продукта.

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

— Наименование (название риска).

— Ожидаемые последствия.

— Мероприятия по реагированию.

— Вероятность наступления.

— Уровень влияния на проект (например, по шкале от 1 до 5).

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

— факторы,

— описание каждого (краткое пояснение).

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

— Контрольные точки. Список контрольных точек, определяющих ключевые события проекта, их даты и результаты, которые должны быть получены по состоянию на эти даты. Контрольные точки на первых этапах покрывают проектную деятельность (например, собрать требования, разработать документацию, закупить что-то) без реализации. Когда появляется календарный план реализации проекта, то появляются дополнительные контрольные точки, совмещённые со сдачей сборок или окончанием спринта. В разделе должны быть указаны:

— Этапы/события.

— Результаты на этапах.

— Даты наступления (готовности).

— План проекта. По сути, нужно расписать фазы жизненного цикла проекта. Возможна детализация (степень выбирайте для себя самостоятельно). В разделе должны быть указаны:

— Фазы.

— Временные рамки: общие по проекту и отдельно по каждой фазе.

— Содержание (краткий перечень работ в фазе).

— Участники каждой фазы.

— Ответственные за проект и каждую фазу.

— Результат (основные и промежуточные результаты или продукты на выходе фаз).

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

— роли (с указанием списка людей),

— обязанности (по ролям).

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

— Название документа.

— Разработчик (указать, кто готовит документ, роль).

— Утверждает (указать, кто утверждает документ, роль).

Последней страницей документа будет пространство для подписей всех, кто связан с проектом.

Много всего в Уставе, но это только кажется, не переживайте. Кроме Устава должен быть ещё ряд документов для управления проектом:

— Поэтапные планы работ (про общий план-график реализации проекта писал ранее).

— Бюджетный план проекта.

— Протоколы статусных совещаний.

— Протоколы собраний рабочих групп.

— Отчёты о состоянии проекта.

После создания документа «Устав» и подписания его, нужно переходить к планированию ресурсов и их оценке.

2.4.1. ОТ УСТАВА К РЕАЛЬНОСТИ: КАК РАЗЛОЖИТЬ ПРОЕКТ НА ЗАДАЧИ И НЕ СОВРАТЬ СРОКАМИ

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

Но устав — это ещё не план работ.

Устав отвечает на вопрос: «Что мы в целом хотим получить и зачем?»

Планирование должно ответить на другие вопросы:

— «Что конкретно нужно сделать?»

— «Кто будет это делать?»

— «Сколько времени это займёт?»

— «Какие ресурсы понадобятся?»

— «Что может пойти не так?»

— «Как мы поймём, что результат готов?»

Именно здесь начинается переход от идеи к управляемому проекту.

После подписания устава часто появляется опасная иллюзия: «Ну всё, вроде договорились, теперь можно делать». На практике это не так. Устав задаёт направление, но не заменяет декомпозицию, оценки, зависимости, допущения, план-график и критерии приёмки.

Фразы вроде:

— «примерно понятно»;

— «потом уточним»;

— «там ничего сложного»;

— «команда разберётся по ходу»;

— «это же очевидно»;

— «заказчик потом объяснит подробнее»

почти всегда означают будущие проблемы со сроками, бюджетом, качеством или ожиданиями заказчика.

Задача руководителя проекта — не позволить проекту стартовать на туманных формулировках. Чем раньше неопределённость будет превращена в задачи, допущения, ограничения, оценки и критерии готовности, тем выше шанс, что проект останется управляемым.

РАЗЛОЖИТЕ РЕЗУЛЬТАТ НА ПОНЯТНЫЕ ЧАСТИ

Первое, что нужно сделать после устава, — определить, из каких крупных частей состоит будущий результат.

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

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

Если проект организационный, это могут быть регламенты, процессы, роли, обучение сотрудников, коммуникации, контрольные точки и итоговые документы.

На этом шаге не нужно сразу оценивать всё в часах. Сначала нужно понять, из чего вообще состоит проект.

Хороший вопрос для команды: «Какие крупные результаты должны появиться, чтобы заказчик мог сказать: проект выполнен?».

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

ОТЛИЧАЙТЕ ЗАДАЧУ ОТ РАЗМЫТОГО НАМЕРЕНИЯ

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

Плохо:

— «сделать интеграцию»;

— «разработать личный кабинет»;

— «настроить отчёты»;

— «подготовить документацию»;

— «обеспечить качество»;

— «согласовать с заказчиком».

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

Лучше:

— описать требования к интеграции;

— согласовать протокол обмена данными;

— подготовить тестовые данные;

— реализовать отправку запроса;

— реализовать обработку ответа;

— обработать ошибки интеграции;

— провести интеграционное тестирование;

— подготовить инструкцию по эксплуатации;

— провести демонстрацию заказчику.

Управленческое правило:

Если задачу нельзя поставить конкретному исполнителю, оценить по времени и принять по понятному результату — она ещё не готова для плана-графика.

Это правило помогает быстро отделить настоящие задачи от красивых, но бесполезных формулировок.

НЕ ДЕЛАЙТЕ ЗАДАЧИ СЛИШКОМ БОЛЬШИМИ

Если задача слишком большая, она превращается в «чёрный ящик». Вроде бы работа идёт, исполнитель занят, статус стоит «в работе», но руководитель проекта не понимает, что именно происходит внутри.

Опасные признаки слишком крупной задачи:

— задача оценивается в несколько недель;

— внутри неё участвуют разные специалисты;

— результат нельзя проверить одним действием;

— исполнитель не может кратко объяснить, что будет готово на выходе;

— у задачи нет понятного критерия завершения;

— задача регулярно переносится без ясной причины.

Практическое правило:

Если задача занимает больше 8—16 часов чистой работы, стоит проверить, нельзя ли разбить её на меньшие части.

Это не жёсткий закон. В некоторых проектах задачи могут быть крупнее. Но для начинающего РП такое правило помогает не потерять управляемость.

Мелкая задача лучше видна, легче оценивается, быстрее проверяется и проще передаётся между участниками.

ОПРЕДЕЛИТЕ РЕЗУЛЬТАТ КАЖДОЙ ЗАДАЧИ

У каждой задачи должен быть понятный результат. То есть:

— Не просто «аналитик занимался требованиями», а «подготовлен и согласован раздел требований по регистрации пользователя».

— Не просто «разработчик делал интеграцию», а «реализована отправка заявки во внешнюю систему и обработка успешного ответа».

— Не просто «тестировщик проверял модуль», а «проведено тестирование сценариев регистрации, авторизации и восстановления пароля, заведены дефекты».

Если результат задачи нельзя описать одним-двумя предложениями, задача, скорее всего, сформулирована плохо.

Для каждой важной задачи полезно ответить на вопросы:

— что должно быть готово на выходе;

— кто принимает результат;

— по каким критериям результат считается выполненным;

— какие материалы или данные нужны для начала работы;

— какие зависимости есть от других задач или людей.

Так руководитель проекта постепенно превращает абстрактную идею в управляемый набор работ.

ПРОВЕРЬТЕ ЗАВИСИМОСТИ И ДОПУЩЕНИЯ

После декомпозиции нужно понять, какие задачи зависят друг от друга.

Например:

— нельзя тестировать функцию, пока она не разработана;

— нельзя разработать интеграцию, пока не согласован протокол обмена;

— нельзя запустить обучение пользователей, пока не готова инструкция;

— нельзя подписать акт приёмки, пока не закрыты критические замечания;

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

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

Хорошие вопросы «Что должно быть готово до того, как мы начнём эту задачу?» и «Кто будет заблокирован, если эта задача задержится?».

Кроме зависимостей, нужно зафиксировать допущения.

Допущения — это условия, при которых план считается реалистичным. Например:

— заказчик будет отвечать на вопросы в течение двух рабочих дней;

— состав команды не изменится;

— ключевые специалисты будут доступны в согласованном объёме;

— требования не будут расширяться без процедуры изменения;

— внешняя система будет доступна для интеграции;

— подрядчик передаст материалы в срок;

— тестовая среда будет готова к нужной дате;

— согласующие лица со стороны заказчика не изменятся.

Допущения — это не слабость планирования. Это честное описание условий, при которых план может быть выполнен.

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

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

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

ОТДЕЛИТЕ НЕОБХОДИМОЕ ОТ ЖЕЛАТЕЛЬНОГО

На этапе планирования важно понять, что действительно нужно для первого полезного результата, а что можно отложить.

Хороший вопрос «Без чего результат вообще не имеет смысла, а что можно добавить позже?».

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

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

Важно объяснить заказчику: перенос части функций во второй этап — это не отказ от них, а способ быстрее получить работающий результат и снизить риски.

СВЯЖИТЕ ЗАДАЧИ С ОТВЕТСТВЕННОСТЬЮ

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

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

— Так плохо «Команда разработки», а так лучше «Иван, Backend-разработчик».

— Так плохо «Аналитики», а так лучше «Мария, аналитик, отвечает за согласование требований по интеграции».

Чем яснее ответственность, тем меньше риска, что задача «повиснет между людьми».

Руководитель проекта должен помнить: перед заказчиком за общий результат отвечает не разработчик, не аналитик и не тестировщик. Перед заказчиком отвечает руководитель проекта. Поэтому РП должен видеть не только список задач, но и то, кто отвечает за каждую важную часть результата.

ПРОВЕРЬТЕ РЕАЛИСТИЧНОСТЬ ПЕРЕД ОЦЕНКОЙ СРОКОВ

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

— понятно ли, что именно нужно сделать;

— есть ли критерий готовности;

— понятно ли, кто исполнитель;

— известны ли зависимости;