В данной статье приведен перевод, или, скорее, пересказ, книги "Guide For Planning Complex Digital Projects" компании Atlantic BT. Сама книга досталась мне из третьих рук, поэтому ссылку на источник не предоставляю. Не являюсь ни переводчиком ни писателем, поэтому прошу строго не судить за точность и стиль изложения. Думаю, что моя статья будет полезна для тех, кто так же как и я, находится в самом начале пути изучения методик организации и руководства разработкой сложных цифровых проектов.

Введение: Фазы разработки проекта

Существует 5 фаз жизненного цикла проекта: исследование, разработка стратегии, разработка продукта, выпуск и анализ.

В этой книге рассмотрены все эти фазы:

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

• Вторая часть посвящена разработки стратегии: плана разработки продукта

• В третьей части рассмотрены подходы к набору команды и распределения задач между ее участниками для разработки продукта

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

Часть первая: Выявление проблем

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

Сложные проблемы всегда требуют сложных решений. Большинство IT проектов - сложные решения.

Факторы, усложняющие IT проекты:

• Требуемые технологии находятся за пределами компетенций команды

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

• Собственная разработка графического дизайна и фронт-энда не рентабельна

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

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

Причины провала проектов

1. Плохие оценки на этапе планирования

2. Изменения ТЗ на этапе разработки

3. Недостаточность ресурсов

Четыре подхода, которые помогут повысить эффективность проекта

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

• Изучайте технологии и содержимое проекта, привлекая для этого критически важных внутренних и внешних специалистов

• Создавайте эффективные команды, мотивация которых соответствует целям продукта

• Действуйте в строгом соответствии с принципами разработки: малые циклы и жесткий контроль качества.

Определение целей проекта

Прежде чем давать характеристику проекту (для определения ожиданий от него), требуется проделать следующее:

• Определите, чего вы пытаетесь достичь — как это согласуется с бизнес-целями?

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

• Сосредоточьтесь на определении проблемы, а не на решении. Как только проблема действительно четко определена, решение становится простым.

Вопросы

Если бы у меня был один час для решения какой-то проблемы и моя жизнь зависела бы от ее разрешения, я бы потратил первые 55 минут на то, чтобы сформулировать вопрос; потому что если ты задаешь правильный вопрос, проблему можно разрешить менее чем за 5 минут

Альберт Эйнштейн

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

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

Например:

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

• потому что текущая CMS устарела и тяжела в использовании - Почему?

• потому что ее сделали 7 лет назад и с тех пор не развивали - Почему?

• потому что не было инвестиций - Почему?

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

Спрашивая "что для этого нужно", можно прийти к тем же выводам (использование современной CMS системы), но лишь как часть более сложного решения.

Например:

• Мы хотим увеличить посещаемость сайта. - что для этого нужно?

• единая база структурированного наполнения сайта, а так же план генерации этого наполнения на постоянной основе. - что для этого нужно?

• стратегия определения, что требуется пользователям и как реализовать эту стратегию. - что для этого нужно?

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

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

• Информационная архитектура для структурирования и организации контента. - что для этого нужно?

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

• набор инструментов для авторов контента, включая современную CMS. - что для этого нужно?

• обучить технологическому процессу и работе в CMS. - что для этого нужно?

• стратегия SEO для того, чтобы убедиться, что поисковые системы выдают нужные результаты. - что для этого нужно?

• Аналитика для оценки эффективности размещения контента и работы стратегии SEO. - что для этого нужно?

• ...

Выгоды и ограничения

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

Выявление выгод

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

Ключевые элементы реализации выгод

• Определите желаемые выгоды

• Установите количественные и/или качественные показатели этих выгод

• Перед началом работы над проектом установите общий оценочный уровень получения выгод по времени

• Составьте план измерения и отслеживания реального уровня выгоды

• Создайте график отчетности

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

Выявление ограничений

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

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

Примеры ограничений:

• конкретные сроки реализации

• невозможность разработки маркетинговых материалов параллельно с разработкой продукта

• соответствие нормам права, законам

• несовместимость с устаревшими технологиями

• поддержка требует обучения IT команды новым технологиям

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

Часть вторая: Составление плана

Цели планирования:

• гарантия вовлеченности в проект всех участников

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

• избежание дорогих ошибок и переделок

• помощь в задействовании лучших ресурсов в реализации проекта

• обеспечение полностью сформированных ролей и требований для выполнения задач реализации решений

• выявление, смягчение и планирование рисков

Выявление участников проекта

Это люди, которые имеют отношение к продукту на всех его этапах. Например:

• спонсоры

• команда управления проектом

• конечные пользователи

• бизнес пользователи

• любой отдел, вовлеченный в выпуск проекта

• гос. регуляторы

• любые внешние лица и компании: производители оборудования, клиенты, партнеры и т.д.

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

Установка критериев успеха

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

Разработка треугольника управления проектом

Основные ограничения продукта: объем (функции, качество), время и стоимость. Каждая сторона треугольника - ограничение, нельзя изменить одну сторону, не изменив при этом другую. Сторона ограничения объема имеет не изменяемую составляющую - качество. Поэтому менять объем - чаще всего, это значит менять набор функционала.

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

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

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

Не уверены, что знаете, как расставлять приоритеты? Мы рекомендуем такой порядок

1. установка критериев успеха

2. установка объема

3. установка сроков (графика)

4. установка бюджета

Разработка плана этапов проекта

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

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

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

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

Учитесь у других

Давайте смотреть правде в глаза: вы не изобретаете велосипед. До вас этот путь прошли многие. Это отличная новость для нас, потому что мы можем учиться у них. Это почти как преимущество младших братьев и сестер, наблюдающих за тем, как их старший брат или сестра первыми преодолевают полосу препятствий жизни. Они узнают, что работает, а что нет. Как только у вас появится четкое представление о том, чего вы хотите достичь и почему, вы можете начать смотреть на то, как это сделали другие. Что им потребовалось, чтобы достичь своих целей? Существует множество способов сбора данных. Они включают:

• изучение опыта членов команды, имеющих опыт ведения подобных проектов

• Общение с представителями других компаний на собраниях профессиональных ассоциаций или торговых выставках об их опыте и работе.

• Получение информации и обратной связи от поставщиков оборудования или услуг

• Изучение отраслевых тенденций и лучших практик

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

Управление рисками

Даже тщательно спланированный проект может быть сорван из-за непредвиденных рисков. Неопределенные условия или события, влияющие на получение ожидаемых результатов проекта, подстерегают каждого. Заблаговременная оценка рисков позволяет вам подготовиться к немедленному плану смягчения последствий, если какие-либо проблемы все же возникнут во время выполнения проекта. Без такого плана вы можете в конечном итоге реагировать на проблемы реактивно, не рассматривая все варианты рационально. Это может привести к долгосрочным последствиям. Определите все возможные риски проекта. Конечно, никто не может заглянуть в будущее, но в каждом проекте обычно есть явные потенциальные проблемы, которые легко обнаружить. Начните с них. Рассматривайте все, что мы рассмотрели до сих пор в этом руководстве, как помощь в определении других, трудно распознаваемых рисков.

Оцените риски, которые вы обнаружите, расставив их по приоритету по двум шкалам

1. Вероятность возникновения

2. Ущерб, в случае возникновения

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

Часть третья: Сотрудничество

Лучшие люди в нужных местах обеспечат выполнение вашего проекта в соответствии с планом.

Набор команды

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

Спонсоры проекта - они владеют проектом и финансируют его. Спонсоры должны рассмотреть и утвердить все основные аспекты плана проекта.

Назначенные бизнес-эксперты — они будут управлять конечным продуктом. Ярким примером этой роли для продукта "веб-сайт" является директор по маркетингу. Они помогают определить объем продукта.

Менеджер проекта (PM) - этот человек создает, выполняет и согласовывает план проекта с внутренней командой. Является связующим звеном со внешними партнерами. Он приобретает необходимые ресурсы, управляет персоналом и корректирует план по мере необходимости.

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

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

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

Выбор менеджера проектов

Роль менеджера проекта имеет решающее значение, поэтому она требует уточнения. Знание того, какие критерии использовать при выборе менеджера по проектам, может иметь решающее значение для успеха продукта. Не делайте поспешных выводов о том, что навыки работы с существующими и новыми технологиями являются лучшим критерием для управления проектами. Большинство организаций считают коммуникацию, лидерство, управление персоналом и способность влиять на других более важными, чем технические знания. Тем не менее, не всегда легко найти одного человека со всеми этими навыками. В среднем менее 40% организаций очень довольны этими навыками своих менеджеров проектов.

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

Заполнение RACI матрицы

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

RACI:

• R - ответственный - лицо, или группа назначенные на выполнение работы

• A - требующий отчета - лицо или группа, кто принимает окончательное решение и владеет продуктом

• С - консультант - лицо или группа, которые обязаны предоставить свое мнение (проконсультировать) перед принятием окончательного решения

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

Используйте этот инструмент, чтобы назначить задачи проекта подходящим людям. Диаграмма RACI полезна, потому что она:

• Уменьшает избыточность в задачах

• Обеспечивает четкое взаимодействие

• Сокращает время на согласование

• Позволяет заинтересованным сторонам сосредоточиться на дополнительных действиях

Пример RACI матрицы:

Производственные ресурсы и штатное расписание

Сложные проекты обычно включают как минимум две проблемы с персоналом.

1. Временная потребность в кадрах, навыки которых уже существуют внутри компании

2. Временная или постоянная потребность кадров с компетенциями, не доступными внутри компании

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

Оценивая штатное расписание вашего проекта, рассмотрите следующие вопросы.

1. Кто должен быть в команде и для чего?

• Доступен ли работник (специалист, человек: в первоисточнике обезличено - "штат") для участия в проекте?

• Если да, сколько времени может посвятить проекту?

• Какова вероятность перераспределения приоритетов (например, отвлечение на срочные задачи, не связанные с проектом: аварии, текучка)?

2. Какие конкретные знания и умения (подтверждаемые сертификатами) требуются вашей команде для этого проекта?

• Есть ли в вашей компании сотрудники с требуемыми компетенциями?

• Доступны ли эти сотрудники для включения в команду проекта?

• Если нет, планируете ли вы обучать, нанимать или отдавать на аутсорсинг задачи?

3. Вы готовы передать на аутсорсинг задачи, требующие компетенций, которых нет в вашей компании?

• Что это за компетенции?

• Есть ли у вас план использования услуг аутсорсинга?

• Вы определили сопутствующие риски?

Матрица оценки компетенций

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

• Определение требуемых компетенций для проекта. Включает:
  

  • определение типов требуемых компетенций

  • уровня компетенций

  • требуемого количества сотрудников

• Оценка доступных ресурсов

• Определение требований ко времени выполнения
  

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

• Разработка плана заполнения выявленных промежутков
  

  • переработка описания работы(?) и назначения задач исполнителям

  • обучение требуемым навыкам (долгосрочный период)

  • наём новых сотрудников (краткосрочный период)

  • организация партнёрства со сторонними организациями - решение, которое очень распространено в последнее время

Распределение задач

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

• Назначение задачи группе
  

  • предотвращает рассеивание ресурсов и переключение между задачами

  • сокращает время на разработку плана и отслеживание результата

• Избегание слишком привлекательных (nice-to-have в первоисточнике) задач
  

  • Сводит к минимуму нагрузку на ресурсы

  • Удерживает внимание на критически важные аспекты задачи

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

  • обеспечивает точное отслеживание процесса выполнения

• учет зависимостей
  

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

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

Облегчение процесса разработки проекта

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

Взаимодействие в команде

Предлагается использовать Slack и Hipchat для взаимодействия между сотрудниками, обмена документами, и общения.

Для управление проекта рекомендуется Trello или Mavenlink

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

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

Работа с внешними партнерами

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

Часть четвертая: Продукт

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

Отслеживание эффективности

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

KPI

Ключевые показатели эффективности (KPI) - упрощенный способ измерения результатов вашего проекта. Должны быть именно "Ключевыми" - большое количество разных показателей распыляют внимание и усложняют аналитику

Аналитика

Так как данное руководство по продукту "сайт", предлагается использовать встраиваемые инструменты аналитики от Google и другие. Суть в том, что нужно анализировать как созданный продукт, так и рынок, в течение всего времени эксплуатации, чтобы постоянно этот продукт развивать и совершенствовать.

Управление контентом

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

Безопасность

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