6 декабря
Международный конкурс «Выбор года» представляет победителей 2024 года!
3 | 1 |
Наш эксперт Максим Якубович рассказывает о ретроспективных совещаниях – хорошем способе улучшить реализацию проекта, когда он уже запущен.
– Одна из самых интересных идей оптимизации любой деятельности встретилась мне в теории решения изобретательских задач (ТРИЗ). В частности, в описании закона повышения идеальности системы. Закон рассматривает развитие технической системы как процесс увеличения степени ее идеальности. Все это можно представить такой формулой:
Толковать формулу можно так:
«Техническая система тем идеальнее, чем больше она выполняет полезных функций, и чем меньше факторов расплаты сопровождает выполнение этих функций. Из этого вытекает парадоксальное, на первый взгляд, следствие: идеальная система – это система, которой нет, но ее функция выполняется».
Руководя программами проектов и проектами, я постоянно думаю, как оптимизировать работу прямо по ходу ее выполнения. Не так давно я руководил программой по разработке и внедрению ERP-системы в одной международной компании.
Одной из самых полезных вещей, который мне удалось внедрить, был подход к управлению проектами под названием scrum. О том, как мы его внедряли, я рассказал в этой статье.
В этом подходе есть один интересный инструмент, позволяющий непрерывно улучшать рабочие процессы, – ретроспективные совещания.
Об этом инструменте я и расскажу сегодня.
Обычно на совещаниях обсуждают три вопроса:
При внедрении ретроспективы мы с командой немного модернизировали вопросы, разбив их на группы:
1. Выполнение задач, поставленных в ретроспективе:
2. Обсуждение KPI команды: какие фактические значения KPI получились в рассматриваемом периоде?
3. Что помешало команде получить лучшие значения KPI? Что нужно сделать к следующей ретроспективе, чтобы повысить фактические значения KPI?
4. Затем составлялся список задач на последующую ретроспективу, назначались ответственные сотрудники и сроки.
Примеры проблем, которые обсуждались на ретроспективах:
1. Фактическое значение показателя «Производительность команды» оказалось ниже, чем хотелось бы.
2. Пользователи сталкиваются с одной и той же проблемой несколько раз.
3. Один из членов команды потратил на задачу в 2 раза больше времени, чем планировалось.
Обсуждение этих проблем позволило определить их причины и составить список задач для их устранения. Затем определялись ответственные исполнители и сроки реализации.
Чтобы понять, почему были выбраны конкретные KPI, нужно уточнить какие задачи стояли перед командой и на каком этапе находилось внедрение ERP-системы.
Во время разработки KPI в программе проектов уже выполнялся один из них – промышленная эксплуатация ERP-системы (он длился около года). За это время собралась очередь из более 100 пожеланий пользователей по улучшению нескольких модулей ERP-системы.
Затем составлялся список задач для команды проекта. В него входили:
1. Поддержка пользователей ИТ-системы
2. Доработка пожеланий по новому функционалу
3. Обучение пользователей ИТ-системы
Чтобы команда была мотивирована ответственно выполнять свои задачи, было решено ввести систему премирования в зависимости от KPI.
Подход к премированию был общим, но показатели у разных ролей в команде отличались.
Начну с описания самого подхода к премированию.
После обсуждения работы с руководством компании, мы решили, что премиальная часть у команды должна составлять примерно 25% от оклада.
При этом 25% – максимальное значение, которое можно было заработать при выполнении всех KPI на 100%.
У каждой роли в проекте было порядка трех KPI. Например, у программистов они были такими:
1. Среднее значение производительности команды (для ее расчета использовался «фокус-фактор», подробнее об этом здесь) по задачам спринтов, завершенных в данном месяце. Вес фактора в премии: 60%.
2. Отсутствие ошибок в работающем релизе. Вес фактора в премии: 20%.
3. % инцидентов, закрытых в нормативное значение. Вес фактора в премии: 20%.
По каждому показателю была разработана шкала премирования. Например, по показателю «Среднее значение производительности команды по задачам спринтов, завершенных в данном месяце»:
Показатель «Отсутствие ошибок в работающем релизе» не имел никакой градации. Если обнаруживалась ошибка, ее последствия были несущественными и команде удавалось устранить ее за 5-10 минут, то она не считалась критической. В противном случае – премию за этот показатель не получал никто из команды проекта.
В конце месяца я получал отчет по всем показателям команды и рассчитывал премиальные сотрудников.
После этого мы собирались на ретроспективное совещание и обсуждали способы улучшения качества работы. Соответственно, и премиальные.
На задачи, поставленные на ретроспективах, сотрудникам выделяли столько времени, сколько прогнозировали они сами (сроки согласовывали со мной). Это время учитывалось при планировании работ команд на 2 недели вперед.
На мой взгляд, это отличный инструмент улучшения процессов при работе над проектом. Он позволяет повышать идеальность системы управления проектом.
Ретроспектива – по сути, инструмент для внесения корректирующих действий в проект. И если использовать его постоянно, команда проекта может наблюдать динамику улучшений проекта прямо по ходу его реализации.
Остались вопросы? Пишите в комментариях.
Удачи вам в улучшении ваших проектов!
6 декабря
Международный конкурс «Выбор года» представляет победителей 2024 года!
5 декабря
Форум «Инновационный шторм»: платформа для идей, технологий и предпринимательства
5 декабря
Импровизированный LOVE REPUBLIC HOTEL открыл свои двери, чтобы вместе с гостями отпраздновать официальное открытие в Беларуси
5 декабря
В Минске прошел Форум по управлению интернетом
3 декабря
Будущее глазами бэкенд-разработчиков. Регистрируйтесь на мероприятие о технологиях в электронной коммерции
2 декабря
РКО от Белагропромбанка – широкие возможности для бизнеса
2 декабря
5 топовых советов от спикеров бизнес-конференции «RACE. Кейсы, результаты, инсайты»
1 декабря
Путь к победе длиною в девять месяцев: Белагропромбанк подвел итоги Стартап-марафона 2024