управление интеграцией, управление содержанием, управление сроками, управление стоимостью, управление качеством, управление HR, управление коммуникациями, управление рисками, управление закупками, управление заинтересованными сторонами. Сегодня пробежимся по процессам ведения проектов пятой редакции свода и поговорим о том, что такое управление проектами в целом. Статья подготовлена под влиянием соответствующего курса на курсере. Что такое проект Проект — набор действий, направленных на создание уникального продукта. Последним проект отличается от “процесса” — где конечный продукт не будет уникальным. Пример: рисование картины — проект, печать тысячи копий — процесс. Сдача экзамена TOEFL — проект, но изучение английского языка — процесс. Проект также имеет стадии и ограничения. Процесс может длится бесконечно. Ограничения проекта — срок, стоимость и качество. PMBoK расширяет количество ограничений до шести: добавляются содержание, риски и удовлетворённость клиента. Как правило, ограничения взаимосвязаны: например, если сокращаются время и стоимость, высокого качества можно не ожидать (и удовлетворённости клиента тоже). Этапы выполнения проекта Любой проект имеет начало, выполнение и завершение. PMBoK пятой редакции выносит управление этими этапами в пять процессов: инициация, планирование, выполнение, контроль выполнения и завершение проекта. 1. Инициация Инициация проекта, человеческим языком, это когда понятно, что есть задача и понятно, что нужно стартовать. Основных процессов внутри этого этапа два: вычисление заинтересованных лиц и составление устава проекта. Работа с заинтересованными лицами. В крупных, сложных проектах первый этап — целая система. Заинтересованными лицами могут быть как непосредственно заказчик, так и люди, на которых “последствия” выполнения проекта повлияют напрямую. Представьте проект, в рамках которого потребуется построить детский сад внутри двора жилого дома. Вопросы, которые возникают уже при инициации проекта, решаются менеджером. Думаю, основным вопросом, который возникнет, и который будет исходить не от заказчика — нежелание местных жителей видеть у себя во дворе новую постройку. В проектах типа разработки сайтов вести беседы с конечными пользователями, конечно, не придётся. Однако, если сайт разрабатывается для большой компании с кучей департаментов, эта таблица пригодится, для того чтобы устанавливать решающих лиц и тех, кто получить непосредственное влияние от работы по итогам сдачи проекта. Случай, когда никому ничего не нужно, и никто никакого влияния не получит — самый печальный, как бы эти вводные радужно не звучали. Составление устава проекта. Здесь решаются вопросы с документами: руководство по ведению проекта, примерный тайм-план и техническое задание. Основной вопрос устава проекта — что решает продукт, создаваемый в процессе проекта, что должны получить на выходе (например, “на выходе нужен дом на 250 квартир”). 2. Планирование PMI отводит большой пласт именно планированию. Большинство проблем проекта возникает из-за ошибок при планировании проекта. Посудите сами: если в начале проект спланирован так, что прописано и предусмотрено абсолютно всё — какие могут быть проблемы в будущем? Планирование проекта содержит процессы: риск-менеджмент, определение проектных задач (и их декомпиляция), расписание проекта (тайм-план), формирование команды проекта. Управление рисками Риск — одно из неопределённых событий, которое может произойти. Риски бывают негативными, создающими проблемы (например, в проекте по строительству автобана, разорился подрядчик), так и позитивными, которые помогают проекту. Управление рисками происходит в 4 шага. Определение рисков. Анализ найденных рисков. Разработка плана работы с рисками. Предупреждение рисков. В рамках шага “определение” происходит анализ похожих проектов — своих и чужих, на предмет того, с какими проблемами столкнулись там. Например, конкурент делал электромобили, но разорился, потому что поставщик н-ных деталей не смог предоставить требующийся объём детали, а других поставщиков нет. Разработка плана работы с рисками — что ты будешь делать в случае, если риск наступит? Предупреждение рисков — что можно сделать, чтобы риск не наступил? Здесь же нам нужно оценить триггеры, по которым мы сможем оценить, что риск наступил и с ним нужно что-то делать. Это как когда у вас дома выбивает пробки, вы ищете потребитель, “кладущий” электросеть. Характеристиками рисков являются “последствия” и “вероятность наступления”, где 1 — минимальное значение, 5 — максимальное. Оценка рисков на старте IT-проекта. Вписав риски в таблицу и посчитав “тоталы” последствия/вероятности, мы видим, что нам стоит заняться поиском выхода на лицо, принимающее решение и поиском заменяющего программиста (если уж зачем-то подключаем программиста, который вот-вот уходит в отпуск). “Метеорит” вставил для утрированного примера, когда последствия риска максимальны, но вероятность нулевая. Проектные задачи Здесь берутся задачи, ставящиеся перед проектом в целом и декомпилируются на этапы, подзадачи и зависимости. Техническое задание превращается в задачи, которые требуют прямого решения. Для этого составляется ИСР — Иерархическая структура работ (WBS в оригинале). В качестве примера иерархической структуры — проект разработки веб-сайта. Проект состоит из трёх этапов, каждый из этапов (фаз выполнения проектов) содержит или не содержит свои подэтапы, а те, в свою очередь, содержат конечные задачи. Проект декомпилируется до уровня задач, где каждая задача занимает от 4 до 40 часов работы конкретного исполнителя (рекомендуется PMBoK). В проектах наподобие разработки сайтов, задача может занимать от получаса до 16 часов — я так считаю. Определение задач происходит так: Определить желаемые результаты. Определить, что нужно сделать для достижения этого результата. Детализированная иерархическая структура работ позволяет оценить реальные трудозатраты проекта. Бюджет выполнения задач рассчитывается менеджером, тогда как время выполнения задачи лучше узнать у исполнителя, либо взять из предыдущего опыта решения подобной задачи, если таковой был. Планирование и расписание Помимо иерархической структуры есть ещё одна, интереснее: структура взаимосвязей и зависимостей задач проекта. Такая структура позволяет понять, что за чем следует, моделировать ход проекта. Структура взаимосвязей может составляться на основе верхних уровней иерархической структуры. На примере разработки сайта, взаимосвязи линейны и выглядят так: дизайн => вёрстка => программирование. В случае проекта той же постройки детского сада, количество взаимосвязей стремится к бесконечности, их следует учитывать. По поводу маршрута хода проекта (ака сетевой трафик) в PMBoK есть несколько инструментов — Float Time и Critical Time. Я их [пока] не использую, а желающие могут почитать об этом в интернете. Пример структуры — диаграмма PERT. Тайм-план проекта Тайм-план, это план того, когда и что должно быть сделано. Наибольшую популярность в этом плане обрела диаграмма Гантта. По сути, это универсальный инструмент: помимо таймингов, на диаграмме можно показать этапы проекта и критические подзадачи вместе с их взаимосвязями. Для того, чтобы составить тайм-план в виде диаграммы Гантта, нужно: Перенести задачи в расписание — основные этапы + их детализацию Добавить длительность задач Расставить зависимости и отношение Опционально: Добавить поздний и ранний сроки старта и финиша Добавить добавочную информацию — например, имена исполнителей На тайм-плане отмечаются майлстоуны — этапы с нулевой продолжительностью, вехи проекта. Например, “сдача дизайна” или “запуск сайта”. Это задачи, которые требуют выполнения, но сам момент выполнения может быть отмечен в качестве значимой точки проекта. Диаграмма Гантта ещё тем хороша, что легко составляется — её можно хоть от руки рисовать. На компьютере её можно создать в Ms Project или Ms Excel. Я воспользовался сервисом draw.io — рекомендую. Если базовая линия проекта изменилась и планирование посыпалось, PMBoK предлагает нам два инструмента в помощь в борьбе с проблемой: “Crashing the Project” и “Fast Tracking”. Альтернативные пути, подходящие нам и помогающие оставаться в рамках изначального тайм-плана — это уменьшение содержания проекта и уменьшение качества — время здесь равняется бюджету. Управление командой проекта (Project Leadership) Конечные исполнители проекта — самое важное звено при создании конечного продукта. Команда проекта — люди, которые занимаются непосредственно работой над созданием продукта. Члены команды должны иметь опыт и квалификацию в требующемся направлении. Формирование команды проекта может происходить двумя путями: Рекрутинг Наём исполнителей через функциональных менеджеров (тим-лидов) Например, в диджитал-разработке это может выглядеть так: в компании есть дизайнеры, есть вебпрограммисты. У каждой из групп специалистов есть свой тим-лид — арт-директор у дизайнеров и тех.директор у программистов. Приходит заявка на разработку мобильного приложения. В таком случае, мы “нанимаем” дизайнера и веб-программиста у тим-лидов, а мобильного разработчика нанимаем из вне на время создания проекта — например, фрилансера. После набора в команду проекта требующихся специалистов, требуется провести знакомство членов команды проекта (особенно, если часть их привлечена к проекту из вне). Знакомство команды с проектом состоит из четырёх фаз: Знакомство между собой Прояснение целей проекта. Прояснение плана проекта. Ответы на вопросы. В случае крупных проектов может потребоваться процесс “распределение задач”. Например, если наш проект — это веб-разработка, и у нас 10 программистов и 5 верстальщиков. Распределение происходит путём поиска ответов на вопросы: Может ли он выполнить эту задачу? Выполнит ли он эту задачу? Будет ли он доступен в то время, когда потребуется выполнение задачи? Под “может” подразумевается квалификация и навыки исполнителя. Под “выполнит” — будет ли он её делать. “Будет ли доступен” — в том случае, если команда собирается сразу, а этап работы этого специалиста произойдёт через месяц. Подразумевается, что члены рабочей группы проекта не сидят на одном месте вокруг одного проекта, что до старта проекта у него были другие задачи (проектные или нет), также могут быть задачи во время хода проекта (во время, когда он не вовлёчен в работу). По PMBoK применяется таблица RAM — в ней обозначаются номинальные роли участников проекта. Эта тема больше про отчётность и понимание того, к кому когда обращаться. Не думаю, что есть смысл её вести, если участников проекта меньше 20 человек и каждый выполняет одну-две функции. Менеджеру не стоит забывать, что он тоже член рабочей команды, к менеджеру проекта применимы те же вопросы и процессы. На этом этапе менеджер планирует себя, как ресурс, предполагает изменения ролей и личный тайм-менеджмент. А вот ещё чуток про human resources и выбор исполнителя под проект, чек-лист вопросов по оценке возможностей. Насколько ежедневные обязанности исполнителя пересекаются с задачами проекта. Обладает ли человек специальными навыками, требующимися в проекте. Какой у человека бэкграунд и образование. Каково с этим человеком работалось ранее. Готовность принять назначенные задачи. Общий уровень доверия. Личные амбиции и желания исполнителя. Каждый участник рабочей команды — личность с собственными потребностями, желаниями и слабостями. 3. Выполнение проекта Основной этап проекта, когда работа работается, результаты согласовываются и передаются от специалиста специалисту дорабатываясь. Задачи менеджера проектов на этом этапе — ведение коммуникации и слежение за треугольником время-бюджет-качество. Контроль и наблюдение за проектом выносится в отдельный процесс. Причины быть “быстрее и дешевле” Приближающийся дедлайн. Желание увеличить прибыль. Желание опередить конкурентов. Увеличение жизненного цикла продукта. Основной инструмент менеджера — коммуникация. На этом этапе составляется коммуникационный план. Опять же, вижу смысл его составлять и вести в том случае, если много исполнителей и стейкхолдеров. 4. Наблюдение и контроль выполнения проекта В группе процессов контроля выполнения проекта происходит, соответственно, контроль выполнения проекта. Менеджер мониторит, что происходит с проектом, следит за соблюдением технического задания и сроков. Идентифицирует зоны, где требуются изменения. Инициирует соответствующие изменения. Наблюдение за проектом Мониторинг Оценка ситуации Установка контролирующих действий (если требуется) Доставка результатов работы заказчику Главные инструменты тут — расписание проекта (тайм-план с майлстоунами и дедлайнами) и коммуникационный план. И сама коммуникация. Хорошая коммуникация — основа успеха проекта. В чек-листе менеджера на этапе контроля выполнения проекта стоит три вопроса: С кем нужно держать коммуникацию? Почему и зачем нужно с ним коммуницировать? Как можно держать участников проекта информированными? Участники проекта — и рабочая команда проекта и заказчики. Помимо диаграммы Гантта для контроля сроков используется раздельный треккинг задач — это уровень повыше, в тех же сложных проектах. Трекинг проекта происходит путём сравнения точки, в которой мы находимся на данном этапе с той, в которой должны были быть по плану. Так мы оценим, насколько мы сейчас в плюсе/в минусе по бюджету/времени, сможем провести управление стоимостью проекта: Насколько запланированный объём отличается от действительно завершенного? Насколько “расхождение” отличается от реального объёма? Обычно проблемы на этом этапе выявляют ошибки, допущенные при планировании. Однако, перепланировать весь проект уже вряд ли получится — это в любом случае превратится в катастрофу с позиции бюджета, потому ищем в чём именно у нас проблема в частностях. Вот чек-лист: Цели проекта Стратегия Оценки Планируемое расписание Человеческие ресурсы (команда, организация, клиент) Как я писал ранее, 80–90% проблем возникают по причине ошибок планирования. Только 10–20% проблем по причине ошибок команды проекта. В случае проблем обращаемся к процессам Crashing the Project и Fast Tracking. А вот “лайтовый” список, подходящий для небольших проектов: Уменьшаем качество продукта, чтобы успеть в срок Уменьшение объёма продукта с той же целью Повышение бюджета (!) Разработка новой стратегии Замена участников команды проекта Если изменились ожидания клиента (при плохом обсуждении планирования с клиентом): Переговоры. Естественно — многое можно решить, всего лишь обсудив Обсудить регулировку содержания проекта Переопределить цели и отношения проекта 5. Завершение проекта Закрытие проекта — этап, когда разрабатываемый продукт готов и его нужно сдать в эксплуатацию. К закрытию проекта есть чек-лист, касающийся самого проекта, документации и команды проекта. Закрытие проекта Проверить критерии достижения целей проекта Убедиться, что продукт доставлен потребителю Убедиться в удовлетворении заказчика Закрытие документов Закрытие финансовых документов Закрытие договоров Завершение работы проектной группы Закрывающая встреча с командой проекта Уведомление тим-лидов о завершении проекта Ревью документации проекта Отчёт о проекте с указанием того, что сделано хорошо/плохо и того, что можно было сделать лучше
