Как не превратить пилотный проект в тестирование нервов

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

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

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

Постановка цели.

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

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

Постановка задач.

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

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

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

Согласование.

Данный этап я бы предложил проводить в две стадии.

Первая стадия – это общение с подразделением-инициатором и куратором пилотного проекта.

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

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

Вторая стадия – это встреча расширенным составом, с участием назначенных исполнителей со стороны заказчика.

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

Реализация.

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

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

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

Подготовка предварительного отчета.

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

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

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

Финальный отчет.

Этот отчет формируется на базе предварительного отчета заказчика с внесением в него пояснений и комментариев интегратора по выявленным разночтениям. Он должен отражать объективную оценку решения и квалификации интегратора заказчиком.

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

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