Когда за дело берется настоящий мастер, результат говорит сам за себя. Проблема в том, что настоящих мастеров не так много. Хотя секрет мастерства прост ー знание предметной области и 10,000 часов осознанной практики. Это более пяти лет работы в идеальных условиях, где каждый новый проект даёт возможность расти. Но в жизни идеальные условия встречаются редко: слишком много рутинных задач. Поэтому путь к мастерству может занять как 10 лет, так и больше.
Не каждый готов ждать столько времени, поэтому в таких случаях на помощь приходят процессы. В нашем случае ー это Проектный регламент, внутренняя инструкция, которая помогает нам двигаться вперёд. Рассказываем, что это за документ и почему он так важен.
Что такое Проектный регламент?
Проектный регламент (так же известный как Регламент управления проектами) ー это набор процессов, инструментов и методов, определяющих наш подход к управлению проектами. В нашем случае это своего рода версия PMBoK (Свод знаний по управлению проектами), адаптированная под IT и дополненная опытом и ошибками, с которыми мы сталкивались. Регламент охватывает весь жизненный цикл проекта ー от его передачи после пресейла до финального закрытия. Каждый PM (Менеджер проекта) в компании обязан работать в соответствии с этим документом.
Первую версию Регламента управления проектами мы выпустили более 10 лет назад. С тех пор документ почти не изменился ー процесс оказался стабильным. Сейчас Проектный регламент занимает 14 страниц и описывает, что именно должен делать PM на каждом этапе проекта ー от начала и до завершения сотрудничества.
Обычно знать что делать ー уже достаточно. А как делать ー можно найти в других фреймворках, методологиях и инструментах. Но если этого недостаточно, мы создаем дополнительные документы ー все зависит от ситуации.
Один из примеров ー наша собственная версия EVM (Метода освоенного объема). Мы создали свой вариант этого документа, так как существующие шаблоны не подошли: они были либо слишком поверхностными, либо наоборот, слишком сложными. Мы нашли баланс между прозрачностью для клиента и нужным уровнем детализации. Теперь клиенты в любой момент могут посмотреть прогресс и, если нужно, инициировать встречу. Мы за полную прозрачность на всех этапах и готовы тратить время, чтобы объяснить клиенту, зачем нужен каждый документ.
Рекомендуем прочитать Метод освоенного объема (EVM): Как прогнозировать результаты IT-проекта и когда применять EVM?
Как Проектный регламент помогает командам
С момента внедрения Проектного регламента менеджеры проектов стали быстрее вникать в суть работы и совершать меньше ошибок. Они получили своего рода универсальную «шпаргалку», которая учитывает разные типы проектов:
- Проекты полного цикла (фронтенд разработка + бэкенд, с нашим бизнес-аналитиком, PM и QA, включая развертывание продукта) по модели Time & Materials (T&M) ー самые прямолинейные. Договорились с клиентом о сроках и объёме и работаем по методологии Agile.
- Проекты неполного цикла (чаще всего без бэкенда или QA) ー тоже по модели T&M, но с внешними командами. Успех зависит от общей координации.
- Кастомизации компонентов по фиксированной цене (Fixed-price) ー здесь все по классике: фиксированный объём, фиксированная стоимость, модель Waterfall.
- Расширение IT-команды ー когда мы подключаемся к уже работающей над проектом команде и находимся под управлением менеджера проекта со стороны клиента. Мы не можем заранее знать уровень опыта другого PM в управлении, но и полностью снимать с себя ответственность не можем. Поэтому у нас есть роль XB Officer — это человек, который следит за состоянием проекта через контрольные точки и вмешивается только при возникающих рисках или негативной динамике. Об этой роли мы сообщаем клиенту на предварительной рабочей встрече (kick-off meeting), где также обсуждаем зоны ответственности с использованием матрицы ответственностей (Responsibility Matrix).
- Бюджет с плавающим объемом работ (Budget with Float Scope) ー наш собственный формат проектов для клиентов с амбициозной идеей, но ограниченным бюджетом. Здесь начинается всё с идеи и фиксированного бюджета, а требования формируются уже в процессе. Каждая функция системы может быть реализована несколькими способами с разными затратами. Поэтому процессы управления проектом адаптированы с учетом фиксированного бюджета (как в Fixed-price), неизвестной стоимости будущего функционала (как в Т&М), постоянному поиску компромисса и балансированию оценки по завершению (Estimate-to-Complete). В такого рода проектах мы придерживаемся подхода Disciplined Agile Delivery (DAD). Общий успех будет зависеть напрямую не только от мастерства проектного менеджера и опыта команды, но и от доверия к нам клиента.
В дополнении к Проектному регламенту, на каждом проекте, обычно, вводятся дополнительные правила, индивидуальные для этого проекта. Команда сама их формирует, сама придерживается и делает ревью по завершению промежуточного этапа разработки.
Рекомендуем прочитать Как гибкий бюджет меняет мнение о разработке продукта или Что такое Бюджет с плавающим объемом работ
Что важно учитывать при следовании Проектному регламенту
Немного про человеческий фактор
Как бы хорошо не был написан регламент, проектом управляют люди, а значит в список возможных рисков включается “человеческий фактор”. И один из самых опасных рисков ー это постепенное отклонение от правил. Оно может происходить почти незаметно, день за днем, до тех пор пока не возникают существенные проблемы.
Например, сначала вы договорились с клиентом о еженедельных созвонах. Первое время все приходят, обсуждают, делятся новостями. Потом разговоры становятся короче («ведь все указано в Jira»), позже кто-то пропускает один митинг, потом второй. В конечном счете, совместные встречи прекращаются. Команды начинают двигаться в разные стороны. И цели, как потом может выясниться, уже тоже разные.
Чтобы не допускать таких ситуаций, мы проводим аудиты проектов ー как code review, только для управления. Если найдена проблема, ее фиксируют, PM устраняет и отчитывается о проделанной работе. Может звучать строго, но на деле это нормальный рабочий процесс. Все понимают: лучше обнаружить проблему заранее, чем потом вытаскивать проект из кризиса. Вдобавок к этому, полученные знания распространяются между участниками команд. Иногда, замечание — не ошибка, а всего лишь альтернативный подход к решению проблемы.
Практики, которые нельзя игнорировать
Есть ряд правил, которые обязательно нужно соблюдать. Например:
- Нумерация системных функций должна быть неизменной.
Номера в списке фич не могут меняться на протяжении проекта ー от планирования до отчетов. Это обязательное условие регламента. Если по каким-то причинам сохранить нумерацию невозможно ー лучше вообще не использовать номера, чем в процессе менять их и создавать путаницу между участниками процесса. - MoM (Протокол встречи) после каждого созвона с клиентом.
Если о чем-то договорились ー это должно быть зафиксировано письменно. MoM ー это как точка в конце предложения. Все участники митинга уходят с одинаковым пониманием процесса. Если на встрече обсуждался новый функционал, это непременно должно быть добавлено в список с нумерацией (Feature List). Такой список становится одновременно и повесткой для следующей встречи и частью MoM, либо дополняется отдельным документом.
Даже самый лучший регламент не гарантирует успех проекта, но он снижает риски. Особенно когда в дело вступает человеческий фактор. А такие вещи, как неизменная нумерация и качественные MoM, помогают сохранить общий фокус и согласованность.
Рекомендуем прочитать Клиент в Зазеркалье или Как не обесценить проект отсутствием документации
Подводя итоги: Процесс ー это защита
Каждый проект уникален. Регламент управления проектами не дает всех ответов — он лишь описывает то, что мы уже проходили. Следовать ему — не значит гарантировать успех, но значит повысить его вероятность. Поэтому в конце документа всегда отмечено:
«Эти эмпирические правила ー не серебряная пуля. Иногда они не нужны. Иногда могут даже навредить. Но если вы решаете от чего-то отказаться, должна быть веская причина. И вы должны быть готовы объяснить ее. А еще лучше ー предложить улучшение. Но потом будьте готовы объяснить свой выбор на аудите проекта.»
Таким образом, регламент ー это не про контроль. Это про поддержку. Он помогает командам избежать типичных ошибок и сосредоточиться на том, что действительно важно — создании качественного продукта. А если у вас в проекте возникают сложности, хаос или просто хочется поговорить о процессах — свяжитесь с нами. Мы всегда рады поделиться опытом или даже стать вашим партнером.
