скачать книгу бесплатно
Область реакции: административная функция
Валентность (уровень вовлеченности): руководитель или специалист
Периодичность: раз в три месяца
Диаграмма Исикавы помогает выявить скрытые причины несоответствий, проблем, брака в производственных и управленческих процессах, в стратегическом планировании.
Этот инструмент на сегодняшний день является универсальным: его можно применять в различных рабочих и жизненных ситуациях. Кроме того, метод помогает раскрыть творческий потенциал руководителя и команды, поскольку основывается на принципах мозгового штурма.
Структура диаграммы Исикавы
В основании диаграммы указывается проблема, процесс или проект, который подлежит анализу и рассмотрению. В нашем примере это задержки поставщиков.
Далее рассматриваются причины в шести областях. В классическом инструменте диаграммы есть шесть областей, которые могут подсказать первопричину проблемы:
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. Допущение, или реестр допущений, разрабатывается на старте проекта. Это те условия, с которыми мы работаем на протяжении всего жизненного цикла проекта, и они не меняются до самого конца. Допущения меняются лишь в форс-мажорных обстоятельствах. Например, допущением может считаться наличие у команды офиса, а форс-мажором в данном случае – пандемия, которая лишила ее этого офиса, и все стали работать из дома. Это существенно меняет процедуру коммуникации, отчетность и т. д.
В большинстве подходов – в гибридном, в предиктивном – журнал требований статичный и не меняется до конца проекта. В гибких подходах верхний уровень требований остается неизменным, а вот все, что касается декомпозиции требований или зоны технического проекта, – динамическая история, поскольку в процессе разработки системы мы получаем обратную связь от заказчика, меняется стратегия, меняются внешние условия рынка, и мы можем менять как технологию выполнения работы, так и какой-то вид системы. При этом основной запрос заказчика остается в силе. Если ему нужна система, которая будет обрабатывать входящие платежи, то мы эту систему и будем делать. Другой вопрос – какая логистика данных будет внутри или какого цвета будут формы для заполнения?
С журналом требований работает вся команда. По большей части, конечно, работают исполнители, и журнал требований – основа для коммуникаций заказчика с командой или руководителя проекта с заказчиком. Не забывайте о том, что журнал требований – это не только основа для завершения проекта, для формирования закрывающих документов, но еще и основа для принятия управленческих решений.
