Ирина Сергеевна Шишкина
Молекулярное управление: периодическая система проектных элементов. Свод инструментов проектного управления для создания гибридного подхода на предприятиях

БЮ – Бюджий (бюджет (БДР, БДДС)

Фаза реакции: фаза планирования

Область реакции: административная функция

Валентность (уровень вовлеченности): малая группа

Периодичность: раз в месяц

БДР (бюджет доходов и расходов) обычно используется для планирования и итоговых отчетов как всего проекта, так и по итогам каждой итерации. Это достаточно статическая тема, где мы видим просто план-факт по месяцам.

Различия между статическим и динамическим документами – БДР и БДДС

А вот БДДС (бюджет движения денежных средств) представляет собой динамическое отражение статуса наших денежных средств в проекте, направленность денежных потоков, чётко распределенных по статьям расхода. Здесь мы видим не доходы, расходы и прибыль, а обороты денежных средств. Остаток денежных средств в кассе и на счетах на конкретные даты очень важен для планирования дальнейшей деятельности.

Основные статьи расходов связаны с областями управления внутри проекта – это люди, производство продуктов, процессы и обеспечение операционной деятельности, материалы, сырье и оборудование, используемое для достижения целей (для производства продукта и создания услуги). В качестве примера посмотрите на структуру БДР и создайте свою иерархическую структуру расходов.

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

расходы по коммерческой службе;

расходы по аппарату управления;

заработная плата персоналу;

страховые взносы;

подбор и найм персонала;

обеспечение электронного оборота с подрядчиками;

издержки, связанные с увольнением персонала;

участие в имиджевых мероприятиях;

услуги консультантов;

принятие решений (тоже стоит денег);

управление рисками (в среднем закладываем 25%, в зависимости от направления деятельности проектов) и т. д.

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

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

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

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

3. Финансовые расходы: проценты по кредитам (выплаты по займам и кредитам, привлеченным для финансирования проекта); комиссии и сборы.

4. Маркетинговые и сбытовые расходы: реклама и продвижение; продажи и дистрибуция: (расходы на организацию продаж, транспортировку и дистрибуцию продукции или услуг).

5. Непредвиденные расходы: резерв на непредвиденные расходы.

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

7. Налоги и сборы: все виды налогов, которые проект должен уплатить, включая НДС, налог на прибыль и другие.

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

Из значимых финансовых показателей:

прибыль;

вычеты налога;

рентабельность производства;

налог на прибыль;

прибыль после вычета налога;

прибыль после вычета налогов амортизации;

прибыль до возврата инвестиций;

сумма выплат инвестиций с учетом ставки дисконтирования;

баланс на конец периода.

Есть также экономические показатели эффективности проекта. Например, некоторые из них: ROI (от англ. Return on Investment) – возврат инвестиций и NPV (Net Present Value) – чистая приведенная стоимость денег, чистый дисконтированный доход, стоимость денег с учетом времени и ставки дисконтирования.

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

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

Несколько иллюстраций по теме из моего тренинга по проектам:

Срок окупаемости инвестиций – сумма инвестиций деленная на среднюю прибыль в период

Коэффициент рентабельности инвестиций – хорошо, когда больше 100%

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

Чистый дисконтированный доход – хорошо, когда больше 0

Формула определения индекса рентабельности инвестиций

Индекс рентабельности инвестиций – хорошо, когда больше 100%

Выбор в пользу проекта с суммарно лучшими показателями

ГА – Диагантий (диаграмма Гантта)

Фаза реакции: фаза планирования

Область реакции: административная функция

Валентность (уровень вовлеченности): все стейкхолдеры

Периодичность: раз в месяц

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

Диаграмма Гантта

На диаграмме Гантта мы не будем долго останавливаться, потому что она вам хорошо знакома. Выделю несколько моментов в её построении и использовании:

1. Декомпозиция. Помните, что декомпозиция работ очень важна для того, чтобы диаграмма Гантта имела свой эффект при чтении. Соответственно, более тщательно и внимательно относитесь к уровню декомпозиции. Помните, что есть верхний уровень работ, а далее идут уровни -1, -2, -3 и т. д. до неделимого пакета работ. Помните о принципе 8 на 80. Без фанатизма декомпозируйте, но не забывайте, что неделимые пакеты работ не должны превышать 80 человеко-часов по объему.

2. Связи между задачами. При построении диаграммы Гантта не забывайте о связях между задачами. Да, не всегда удобно и комфортно выстраивать эти связи в формате «старт-финиш», «финиш-финиш» и так далее. Однако для себя вы точно должны понимать, что последовательность работ на графике должна отражать действительную зависимость.

Что это значит? Часто руководители произносят мне прекрасную фразу: «Лучше я запланирую работу раньше, но буду иметь временной буфер». Так вот, хорошо бы планировать работы так, чтобы они шли друг за другом. Это позволит более грамотно распределить ресурсы. Также не забывайте закон Паркинсона: сколько на задачу выделено времени – столько она и будет делаться. Поэтому чем раньше вы её запланируете, тем дольше будете её делать. Для определения временного буфера используйте метод критического пути. Если вы неадекватно определите старт и финиш работ, то не сможете в диаграмме Гантта увидеть критический путь и загруженность доступных ресурсов.

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

Что можно сделать с диаграммой Гантта и как её читать?

1. Использовать для управления сроками в рамках линейного управления. Ознакомиться с тем, как именно работать с диаграммой, можно в стандарте PMBoK. Здесь останавливаться не буду, скажу только, что это один из самых удобных форматов для того, чтобы проконтролировать сроки, увидеть загрузку и предупредить факапы, связанные с провалами срочных задач.

2. Проведение анализа. Диаграмма Гантта важна при анализе «план-факт» анализе, когда сравниваем то, что планировали, и то, что получили.

3. В гибких подходах диаграмма Гантта важна для руководителя проекта или администратора – для тех, кто держит в руках сроки и принимает решения по перераспределению ресурсов.

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

В каком бы виде вы не использовали Диаграмму Гантта (Microsoft Project, Excel или колбаски маркером на флипчарте), сам процесс построения диаграммы – хороший способ диагностики вашего расписания. Даже если ваша команда не использует диаграмму Гантта для управления, используйте её самостоятельно при планировании работ каждого нового спринта.

ИВ – Исикавий (диаграмма Исикавы)

Фаза реакции: фаза реализации

Область реакции: административная функция

Валентность (уровень вовлеченности): руководитель или специалист

Периодичность: раз в три месяца

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

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

Структура диаграммы Исикавы

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

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

1. Оборудование и все, что связано с физическим оборудованием. В эту область также включаются причины, связанные с ПО.

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

3. Люди – персонал и всё, что связано с человеческим фактором, включая состояние выгорания, сопротивления и уровень лояльности.

4. Система управления включает в себя наличие стандартов, подходов и уровень квалификации руководителей.

5. Окружающая, или рабочая, среда – окружающие внешние факторы или буквально рабочее место сотрудников.

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

Пример диаграммы Исикавы

Алгоритм разработки диаграммы:

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

2. Начертить горизонтальную линию по всему листу, а на её конце справа обозначить проблему. Это «голова» рыбного скелета.

3. Определить все факторы, из-за которых могут возникать проблемы, обозначить их на схеме как ответвления от основной линии. Чаще всего среди этих факторов указывают: оборудование, сырье, люди (персонал), управление (система управления, подходы и методы, используемые на производстве), внешняя среда (рабочие условия сотрудников, законодательство и т.д.), процессы. Факторы могут отличаться в зависимости от конкретной ситуации.

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

5. Определить причины или факторы, которые часто встречаются, повторяются или очевидно составляют основу проблемы. С этим необходимо работать в первую очередь.

6. Определить самое простое и быстрое решение, которое позволит устранить причину или минимизировать её влияние.

7. Реализовать планы по устранению или снижению влияния причины, мониторить результаты.

Основа диаграммы

Пример заполненной диаграммы

Альтернативная структура диаграммы

СГ – Сгораний (диаграмма сгорания спринта)

Фаза реакции: фаза реализации

Область реакции: административная функция

Валентность (уровень вовлеченности): проектная команда

Периодичность: раз в неделю

Bundown Chart – диаграмма сгорания задач. Такая диаграмма отображает процесс работы над проектом.

Виды диаграмм, PMIPMBoK6th

По горизонтали «откладывается» время: остаток дней до конца спринта. По вертикали – количество подзадач, человеко-часов или Story Points – единиц измерения работы. Отдельным цветом на графике показывается план выполнения работ, который в какой-то степени идеален и недостижим – такой план, при котором работы выполняются в одинаковом объеме каждый день, что гипотетически позволило бы равномерно распределять загрузку. Я не сталкивалась с идеалом, но стремиться к нему полезно. Есть с чем сравнить. Можно сделать прикольные выводы – бывают ситуации, когда в рамках спринта команда завершила все задачи намного раньше. Это тоже так себе результат.

Диаграмма сгорания спринта – это один из инструментов Scrum. Подробнее об этом можно почитать в стандарте подхода и кейсах scrum-команд.

Пример диаграммы сгорания спринта

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

Здесь отражается фактический и запланированный объем работ. Например: спринт длится 20 дней, максимальный объем работ – 450 человеко-часов или юнитов. Мы предполагаем, что объем работ постепенно будет таять и к двадцатому дню достигнет нуля. Мы можем увидеть на графике, что где-то выполняется больше запланированного объема, где-то – меньше, но в итоге мы либо приходим к нулю, либо нет. Объем работ может остаться, например, на уровне 150 часов, а спринт уже закончился.

Диаграмма выстраивается в Excel, и задача администратора проекта – подготовить шаблон, где будет указан список задач. Высчитывается прямая по равномерному сгоранию. Если у нас есть 400 юнитов на 20 дней, мы делим и понимаем, что в день должно сгорать 20 юнитов. Соответственно, выставляем планируемое сгорание спринта – 20 юнитов в день. Дальше, в конце дня, загружаем данные, фиксируя выполненный объем работ за сегодня. Например, сегодня отработано 16 часов, и диаграмма сгорания спринта показывает несоответствие, когда мы видим, что вышли за пределы по объему. Другая ситуация – мы всегда выполняли объем больше, чем нужно. В таком случае мы анализируем, что пошло не так – наше планирование было неверным, берём эти выводы в следующий спринт, выясняем, почему запланировали неправильно и почему работали больше, чем нужно, и так далее.

В портфеле проектов диаграмма сгорания спринта может быть полезна для нескольких целей:

1. Мониторинг прогресса по каждому проекту.

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

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

2. Управление ресурсами.

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

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

3. Прогнозирование и планирование.

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

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

4. Коммуникация с заинтересованными сторонами.

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

Отчетность: регулярное обновление диаграмм сгорания помогает в подготовке отчетов о состоянии проектов.

5. Улучшение процессов.

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

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

6. Сравнение и бенчмаркинг.

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

Бенчмаркинг: использование диаграмм сгорания для создания бенчмарков и стандартов производительности.

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

Дж – Дорожний (дорожная карта)

Фаза реакции: фаза планирования

Область реакции: продукт

Валентность (уровень вовлеченности): основные стейкхолдеры

Периодичность: раз в месяц

Дорожная карта – это общее видение плана, в котором указаны промежуточные результаты. Мы описываем в крупном плане не действия, которые выполняем, а промежуточные результаты, которые хотим получить.

Пример заполнения дорожной карты

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

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

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

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

Шаблон дорожной карты

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

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

Есть строка «Риски/сроки/ответственные». Здесь мы вписываем риски итерации, события, которые могут повлиять на промежуточный результат. Фиксируем владельцев рисков – тех, кто будет ответственен за события и мероприятия по работе с ними.

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

Скачать Дорожную карту

ЖТ – Требований (журнал требований)

Фаза реакции: фаза планирования

Область реакции: продукт

Валентность (уровень вовлеченности): основные стейкхолдеры

Периодичность: раз в 3 месяца

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

4 сущности требований

Напомню вам, что в домене требований есть 4 сущности:

Требования – хотелки заказчика и его команды (будущих пользователей продуктов системы).

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

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

Исключения – то, чего не должно быть в проекте или в продукте.

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

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

свод верхнеуровневых требований на первичном этапе, на этапе планирования;

свод ограничений, исключений, допущений;

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

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

1. Обращайте внимание на формулировки и уровни требований: они могут быть верхнеуровневыми, а могут быть конкретными. Не путайте техническое задание с техническим проектом, потому что чем детальнее требования, чем они более техничные (имеют отношение к технологии выполнения работ), тем больше в них от технического проекта, чем от технического задания. Это значит, что они должны быть выверены исполнителем и подтверждены: «Да, так можно выполнить работы и так это делать целесообразно». Чаще всего под требованиями мы подразумеваем именно хотелки – формулировки «я хочу». Чтобы требования были максимально понятны и конкретны, используйте структуру пользовательской истории: «Я как роль… хочу…, чтобы сделать…».

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

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

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

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

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