Цифровой проект в крупной компании: 11 важнейших действий, которые надо выполнить на старте

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

Разберитесь с решением 

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

Ключевые моменты:

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

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

Определите расстановку сил

Важно понимать распределение полномочий, целей и KPI основных заказчиков проекта. Еще важнее — понимать, как и кем реально принимаются ключевые решения по проекту (сроки, объемы, бюджет). 

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

А матрица ожиданий поможет не упустить из вида ничего важного. 

Выровняйте информационное поле

Паспорт проекта, устав проекта, план управления проектом, контракты с подрядчиками — документов, регулирующих проект, много. Читаются они тяжело и времени на них, как правило, ни у кого нет. В то же время важно, чтобы команда (особенно руководители рабочих групп) хорошо понимали ключевые предположения и ограничения. 

Для этого бывает полезно сделать выдержки ключевых условий на простом, неюридическом языке и проводить встречи (общие и по направлениям), на которых нужно проговаривать эти условия и отвечать на вопросы. Эта работа должна быть включена в общий план коммуникаций по проекту. 

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

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

Уточните, кто за что отвечает 

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

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

Детализируйте план 

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

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

Четко проговорите порядок работы с ЗНИ

На многих проектах fixed price запросы на изменения (ЗНИ) — больной вопрос, а работа с ними отбирает немало сил у проектной команды. Поэтому следует постараться в самом начале сделать процесс работы с ЗНИ максимально эффективным.

• Для небольших ЗНИ (например, меньше пяти человекодней) можно рассмотреть «зеленый коридор» — принятие решения по упрощенной схеме, без выхода на комитет для утверждения изменений. 
• Для более крупных — лучше применять ступенчатый подход. Сначала согласуем трудозатраты (и бюджет) на проработку (ведь оценка и проработка решения тоже потребуют времени), после — договариваемся о реализации. 

Целесообразно применять концепцию «окон» — временных периодов, в рамках которых осуществляется анализ и рассмотрение ЗНИ (а не в любое время проекта). 

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

Мобилизуйте команду

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

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

Возьмите бюджет под контроль 

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

Внедрите процедуру ежемесячного контроля исполнения бюджета и прогнозирования необходимого бюджета на завершение проекта. 

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

Заложите основы для расчета метрик 

Состав метрик на проекте зависит от его типа и фазы реализации. Их смысл — в количественном прогнозировании рисков. 

Есть базовые метрики: 

• SPI (индекс выполнения сроков), 
• CPI (индекс выполнения стоимости), 
• VAC (отклонения от бюджета по завершении).

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

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

На старте в ней формируется набор метрик, необходимых для конкретного проекта с учетом его характеристик, а в течение проекта боты myWizard подсвечивают метрики, которые говорят о приближающихся рисках (или уже случившихся проблемах). 

Сделайте процедуры легкими

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

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

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

Проведите первый QA-review

Директор по качеству может уберечь от многих ошибок. Но эту роль нужно правильно использовать, чтобы она не превращалась в пустую формальность. 

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

Как достичь максимума

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

Именно поэтому нужно к мобилизации проекта привлекать наиболее опытных специалистов, успевших на собственном опыте понять, что работает — что нет, что важно — что не важно. 

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

Фото в тексте и на обложке: Unsplash