Best practice по планированию работ. Опыт проектного менеджера
Прежде всего я хотел бы представиться — меня зовут Игорь Думбур, я профессиональный руководитель проектов. Имею опыт в реальном секторе экономики с выскобюджетными промышленными high tech проектами в строительном консалтинге, а также в коммерческой разработке ПО (fixed price, time and material и dedicated team модели).
В этой статье хочу поделиться опытом с моими коллегами и всеми, кто интересуется темой проектного менеджмента.
Каждый менеджер проектов сталкивается с вызовами, связанными с декомпозицией и планированием работ, а также с выдерживанием сроков по релизам, промежуточным билдам и прочим ключевым датам. В этой статье я предлагаю рассмотреть два case-study, которые я взял из собственного опыта.
Сase study 1: Структурная схема работ (WBS)
В компании-разработчике кастомного Web-based ПО и мобильных приложений я руководил проектом по созданию небольшого сайта, основной функционал которого позволял пользователям просматривать открытые вакансии и присылать свои резюме на открытые позиции. Это case-study кратко проведет вас по процессу создания структурной схемы работ для этого проекта, WBS (Work Breakdown Structure).
Итак, я уже имел исходные данные для WBS — краткую спецификацию по основному функционалу, которую я написал до этого (также это может быть бэклог по основным фичам которые планируются в спринте), руководство по установленным в компании политикам и процедурам, а также прочие полезные инпуты.
Выделяем основные компоненты
Первый шаг который я предпринял — назначение Planning meeting’a со своей проектной командой. Проектная команда состояла из необходимых для этого проекта специалистов: дизайнер, frontend разработчик, backend разработчик и тест-инженер. Я пояснил команде, что цель нашего митинга — создание основной структурной схемы работ, чтобы представить и разбить на составляющие все основные компоненты сайта, которые нам необходимо зарелизить в MVP версии.
Совместно с командой мы разбили сайт на высокоуровневые компоненты — основные группы страниц сайта и привязанные к ним виды работ. Основная модель структуры получилась примерно такая:
- Компоненты и субкомпоненты веб-сайта:
- Design;
- Content;
- Frontend;
- Backend;
- Testing;
- Deployment;
- Прочие работы;
- Основная project management документация.
Эти категории захватили весь основной объем работ, который мы с командой собирались запустить в жизнь. Обратите внимание, что одна из категорий включает в себя основную документацию. Это важно, так как эта категория конечных результатов поможет будущим PMам сделать свою работу лучше, используя документацию в качестве исторической информации.
В процессе создания WBS я использовал специальную систему идентификации элементов структурной схемы работ. Название каждого элемента включало в себя:
— Название высокоуровневого компонента (группы страниц сайта);
— Названия суб-компонента (конкретные страницы сайта);
— Название конкретного вида работы (например Frontend).
Разбиваем на сегменты
Я попросил Настю, нашу тестировщицу, нарисовать на доске несколько сегментов. Каждый сегмент представлял основной высокоуровневый компонент сайта, подписанный соответствующим образом. Дальше мы с командой начали разбивать высокоуровневые компоненты на более мелкие. Как только команда приходила к консенсусу по поводу каждого низкоуровневого компонента — я клеил на доску стикер в определенный сегмент. Вот на что наша WBS стала похожа через некоторое время:
Разбивая высокоуровневые компоненты на более мелкие, команда использовала метод деление на 2, так как любую работу довольно сложно разложить на более чем две составляющие, но делить на 2 все умеют отлично. Таким образом, мелкие работы в составе крупного компонента размножаются методом деления=).
Также мы с командой использовали метрику «правило шести-восьми часов». То есть никакая отдельная работа не должна занимать меньше
Проверяем целостность
После первого раунда декомпозиции мы оставили всё висеть на доске до следующего дня, чтобы потом вернуться и провести второй раунд, на котором мы совместно проверили целостность структурной схемы работ и добавили то, что забыли в первом раунде.
Спустя два раунда декомпозиции, мы с командой создали детальную WBS, которая отражала все основные компоненты сайта, а также вспомогательные работы. После этого я перенес нашу WBS с доски в Redmine, а также создал файлик проекта в Google Gantter (принятые на тот момент в компании project management tools).
Добавлю также, что в случае необходимости WBS в дальнейшем можно и нужно использовать для составления бюджетов, плана управления ресурсами, оценки рисков, плана закупок и много другого в зависимости от потребностей проекта. В данной статье я ограничусь только определением сроков.
Сase study 2: График работ
После того, как мы создали WBS, настало время сетевой диаграммы работ, PND (Project Network Diagram). А точнее, ее простейшей формы, которая была достаточна для нашей цели — определение срока, в который релиз MVP версии сайта выйдет в жизнь. Для этого мы с командой собрались на следующий раунд митинга по планированию работ.
Устанавливаем связи
Для получения ответа на извечный вопрос менеджмента: «Когда будет готово???», нам предстояло разобраться:
— С каких именно элементарных работ из нашей WBS мы собираемся стартовать?
— Когда мы с ними стартуем?
— Какие работы должны следовать после тех, с которых мы начнем, и по какой цепочке все пойдет дальше?
— Как разные задачи из WBS связаны между собой логически (связи «предшественник — последователь»)?
— Какие работы мы можем безболезненно выполнять параллельно?
По мере получения ответов на эти вопросы мы переклеивали стикеры на доске и связывали каждую последующую работу с предыдущей в цепочку, принимая во внимание логические связи и прочие влияющие факторы. После коллективного обсуждения и согласия по последовательностям выполнения работ, наша PND начала обретать форму:
Как только все работы были увязаны в ходе наших обсуждений, я установил соответствующие зависимости в Google Gantter файле (который я сделал на этапе составления WBS). Таким образом, перенося зависимости работ и эстимейты в Google Gantter, я получил возможность понять предварительную минимальную продолжительность выполнения работ по MVP версии нашего сайта, а также предварительный критический путь по работам проекта.
Корректируем график работ
Однако до того, как я смог получить четкое представление о дате релиза и промежуточных билдов, я должен был откорректировать график работ, принимая во внимание некоторые очень важные вещи:
— Зависимости, исходящие извне (инпуты от высшего менеджмента, например: «Игорь, этот сайт должен быть готов к числу „N“, т.к. мы ведем переговоры с потенциальными работодателями и мы договорились начинать работать с MVP с этой даты» и другая важная информация);
— Наличие ресурсов (члены проектной команды не были доступны 8 часов в день, т.к. в компании была принята матричная организационная структура, и каждый из ребят был задействован на нескольких проектах);
— Риски, связанные с проектом, которые могут повлиять на сроки сдачи (а их масса: риск болезни членов команды, пропущенные работы, неадекватные эстимейты и прочее);
— Учет календаря проекта (выходные, праздники и прочие возможные помехи);
— Учет персональных календарей членов команды.
Остановлюсь более подробно на двух последних пунктах:
Учет календаря проекта. Календарь проекта описывает, когда работа может быть выполнена. Например, с 10:00 утра до 19:00 вечера. Ничего особенного. Но представьте, что в силу определенных причин заказчик затребовал, чтобы рабочие часы на его проекте были приняты с 8:00 по 15:00 pacific time. Или это заказчик из Израиля, где пятница должна быть выходным. Таким образом, заказчик задает рабочее время календаря проекта. Теперь прибавим к этому праздники, принятые в компании выходные дни, и это еще больше ограничит рабочее время проекта. Обращать внимание на календарь проекта нужно обязательно, если вы хотите знать реальную дату получения того или иного результата. Ваш проект может закончится гораздо позже, если праздники, выходные и прочее нерабочее время повлияет на его ход.
Учет календаря ресурсов. Ваша проектная команда живет не только вашим проектом. У них есть отпуски, назначения к врачу, болеющие дети и прочее. Вдобавок, члены вашей команды могут работать также на параллельных проектах, как было в моем случае. Когда вы составляете график проекта, эти вещи нужно держать в голове. График ресурсов берет во внимание параллельные проекты, личные праздники и отпуски членов вашей проектной команды. Скорее всего, это повлияет на общую продолжительность проекта (но не повлияет на трудозатраты). Представьте себе, что один из ключевых разработчиков был отправлен к заказчику on-site, чтобы выполнить свою часть работы с рабочими часами, скажем, с 8.00 до 16.00 pacific time. В этом случае заказчик задал конкретному разработчику его персональный календарь, который вам нужно будет учесть (это 100% повлияет на срок сдачи проекта, или спринта).
Оцениваем результат
На последующем этапе остается только оценить влияние рисков (что не входит в содержание этой статьи, так как это совсем другая история=)).
Таким образом, когда все аспекты графика работ по проекту были покрыты, проектная команда, я и высший менеджмент получили возможность построить и оценить реалистичный график проекта.
В результате мы получили реалистичные даты окончания ключевых работ, выявили работы, требующие повышенного внимания (так как они лежат на критическом пути проекта), а также даты разработки MVP версии сайта в целом.
Надеюсь, эта статья будет вам полезна на ваших проектах. Если возникли вопросы — прошу обращаться. Добавлю также, что данные методики разработки WBS, превращения ее в PND и увязки в график проекта были обкатаны не на одном проекте, как в сфере разработки софта, так и в проектах по инженирингу и строительству large scaled промышленных объектов.
Удачных релизов и билдов, коллеги! =).
