Системный подход к планированию проекта

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

Пиэмбок говорит, что есть следующие стадии проекта:

1. Инициация.
2. Планирование.
3. Исполнение.
4. Мониторинг и контроль.
5. Завершение.

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

Выявление проблем

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

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

• Текущая команда не владеет технологиями, которые нужны для решения проблемы.
• Вы не умеете «сшивать франкенштейнов».
• Пришли к выводу, что найм собственных штатных дизайнов и фронтов нерентабельно.
• Даже если ваша команда обладает необходимыми навыками, усилия, требуемые для реализации проекта, могут быть настолько большими, что негативно скажутся на работе компании в целом
• Как писал выше, проектная работа — не ваш профиль. В штате нет опытного менеджера проектов.

А проваливаются проекты чаще всего по этим трём причинам:

1. Недооценка на этапе планирования.
2. Изменения в требованиях на разных стадиях проекта.
3. Недостаток ресурсов.

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

Перед тем, как стартовать какие-либо работы по проекту, следует определиться со следующими моментами:

• Определите, что конкретно хотите получить от проекта и как это согласуется со стратегией компании.
• Определите, пользователей, которые получат профит от проекта. Соответствует ли смысл проекта реальным потребностям этих пользователей.
• Осознайте, что ваша основная задача в самом начале — определить проблему и задачу, а не решение. Как только вы реально хорошо сформулируете проблему, формулировка решения придёт сама собой.

Вопросы

Для того, чтобы определиться с точной формулировкой проблемы и бизнес-задач, вам потребуются вопросы типа «Почему?» и «Что для этого требуется?»

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

Например:

• Мы хотим сделать так, чтобы генерировать наполнение для сайта было проще — Почему?
• Потому что текущая CMS устарела и тяжела в использовании — Почему?
• Потому что ее сделали 7 лет назад и с тех пор не развивали — Почему?
• Потому что не было инвестиций — Почему?
• Потому что мы были сосредоточены на других задачах (увеличение посещаемости сайта), а теперь готовы переключиться на эту.

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

Например:

• Мы хотим увеличить посещаемость сайта — Что для этого нужно?
• Единая база структурированного наполнения сайта, а также план генерации этого наполнения на постоянной основе — Что для этого нужно?
• Стратегия определения, что требуется пользователям и как реализовать эту стратегию — Что для этого нужно?
• Кто-то в организации, кто мог бы курировать этот процесс — Что для этого нужно?
• Команда экспертов и авторов контента, координируемых указанным лицом — Что для этого нужно?
• Информационная архитектура для структурирования и организации контента — Что для этого нужно?
• Разработать технологию рабочего процесса, порядок утверждения контента и правила взаимодействия — Что для этого нужно?
• Набор инструментов для авторов контента, включая современную CMS — Что для этого нужно?
• Обучить технологическому процессу и работе в CMS — Что для этого нужно?
• Стратегия SEO для того, чтобы убедиться, что поисковые системы выдают нужные результаты — Что для этого нужно?
• Аналитика для оценки эффективности размещения контента и работы стратегии SEO.

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

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

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

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

По выгодам нужно сделать следующие моменты:

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

Чёткие планы — наше лучшее оружие.

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

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

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

• Конечный дедлайн.
• Невозможность разработки маркетинговых материалов параллельно с разработкой продукта.
• Законодательные и правовые ограничения.
• Совместимость с устаревшими технологиями.
• Необходимость обучения команды саппорта.

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

Составление плана

Вроде как определились с допроектными вещами, давайте говорить о планировании. Что оно даёт:

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

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

Нужно выявить всех лиц, заинтересованных в вашем проекте. Например:

• Спонсор.
• Команда управления проектом.
• Конечные пользователи.
• Бизнес пользователи.
• Любой отдел, вовлечённый в выпуск проекта.
• Гос. регуляторы
• Любые внешние лица и компании: производители оборудования, клиенты, партнеры и т. д.

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

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

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

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

На самом деле, удовлетворённость заинтересованных лиц — главнейший критерий успешности проекта, а вовсе не проектный треугольник, о котором ниже.

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

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

Каждая сторона треугольника — ограничение, нельзя изменить одну сторону, не изменив при этом другие две. Если удлинить только одну сторону — у вас «протечёт» качество, являющееся площадью треугольника.

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

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

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

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

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

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

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

График хорошо делать вместе с тимлидом, аналитиком и лидом QA, они вам помогут с закладыванием рисков и выравниванием ресурсов.

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

Положа руку на сердце, мало кому из коллег-пиэмов удаётся сделать проект с принципиально новым продуктом. Скорее всего, вы будете проходить путь, которые до вас проходили многие, пусть и с некоторыми изменениями (помните определение проекта, что это мероприятие, нацеленное на создание уникального продукта? Такая вот диалектика). Надо учиться.

Какие есть способы перенятия опыта:

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

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

В общем, перенятие опыта важно, но это не основной инструмент.

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

У меня есть статья об управлении рисками, читайте её.

Работайте с рисками. Профессионально «думайте о плохом» не реже раза в неделю. Привлекайте коллег и стейкхолдеров к выявлению рисков. Грамотно реагируйте на риски и всё будет хорошо (не будет, но вы предвидите и обработаете эти ситуации).

Сотрудничество

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

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

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

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

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

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

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

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

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

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

RACI:

• R — тот, кто фактически работает над исполнением задачи, исполнитель.
• A — тот, кто отвечает за исполнение задачи.
• С — тот, кто консультирует по задаче.
• I — тот, кого нужно держать в курсе дел по задаче.

Подробно в статье о RACI.

Ресурсный план и штатное расписание

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

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

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

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

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

• Доступен ли работник для участия в проекте? Или он уже на двух-трёх проектах впахивает?
• Если да, сколько времени может посвятить проекту? Хватит ли вам такой загрузки?
• Насколько вероятно, что его будут дёргать?

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

• Есть ли в вашей компании сотрудники с требуемыми компетенциями?
• Доступны ли эти сотрудники для включения в команду проекта?
• Если нет, планируете ли вы обучать, нанимать или отдавать на аутсорсинг задачи?

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

• Что это за компетенции?
• Есть ли у вас план использования услуг аутсорсинга?
• Вы определили сопутствующие риски?

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

Вы удивитесь, но и про матрицу компетенций у меня есть статья. Если конкретно, то этот план должен быть составлен PM и содержать следующее:

• Определение требуемых компетенций для проекта. Включает:
  • Определение типов требуемых компетенций.
  • Уровня компетенций.
  • Требуемого количества сотрудников.
• Оценка доступных ресурсов.
• Определение требований ко времени выполнения.
  • Выявление временных промежутков, когда сотрудники с необходимыми.
  • Навыками будут находиться в штате, но не не смогут принимать участи в проекте по причине отсутствия времени.
• Разработка плана заполнения выявленных промежутков.
  • Переработка описания работы и назначения задач исполнителям.
  • Обучение требуемым навыкам (долгосрочный период).
  • Наём новых сотрудников (краткосрочный период).
  • Организация партнёрства со сторонними организациями — решение, которое очень распространено в последнее время.

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

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

• Назначение задачи группе.
  • Предотвращает рассеивание ресурсов и переключение между задачами.
  • Сокращает время на разработку плана и отслеживание результата.
• Избегание слишком привлекательных (nice-to-have в первоисточнике) задач.
  • Сводит к минимуму нагрузку на ресурсы.
  • Удерживает внимание на критически важные аспекты задачи.
• Указание конкретного результата, который должен получиться после выполнения задачи.
  • Обеспечивает точное отслеживание процесса выполнения.
• Учёт зависимостей.
  • Определяет порядок действий в соответствии с доступностью ресурсов (рассмотрено ранее, график заполнения промежутков, когда не доступен сотрудник с требуемыми навыками).

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

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

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

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

Держите заинтересованных лиц в курсе статуса по проекту, сроков и верхнеуровневых рисков. Не забывайте о 1-2-1 с членами команды.

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

Аутсорсеры могут помочь, если вы не можете закрыть задачу своими силами, когда, например, не хватает компетенций. Например, однажды в Инвитро нам потребовалось создать телеграм-бота. Мы не планировали создавать ботов массово в дальнейшем, нанимать своих ботоводов было совершенно нерационально. Обратились к аутсорсерам, оценили, заплатили, получили результат. Это ок.

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

Продукт

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

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

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

Для этого вам потребуются KPI и аналитика.

KPI

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

Аналитика

Яндекс.Метрика и другие системы аналитики вам в помощь.

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

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

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

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

Резюме от Грока

Я так устал писать эту статью, что решил доверить Гроку написание заключения.

В общем, удачи вам в планировании проектов.