Как улучшать управление проектом по ходу проекта

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

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

Толковать формулу можно так:

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

Руководя программами проектов и проектами, я постоянно думаю, как оптимизировать работу прямо по ходу ее выполнения. Не так давно я руководил программой по разработке и внедрению ERP-системы в одной международной компании.

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

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

Об этом инструменте я и расскажу сегодня.

Обычно на совещаниях обсуждают три вопроса:

• Что у нас работает хорошо?
• Что могло бы работать лучше?
• Что из этого нам необходимо улучшать?

При внедрении ретроспективы мы с командой немного модернизировали вопросы, разбив их на группы:

1. Выполнение задач, поставленных в ретроспективе:

• Какие задачи выполнены?
• Что не удалось выполнить и почему?
• Каковы новые сроки по нереализованным задачам?

2. Обсуждение KPI команды: какие фактические значения KPI получились в рассматриваемом периоде?

3. Что помешало команде получить лучшие значения KPI? Что нужно сделать к следующей ретроспективе, чтобы повысить фактические значения KPI?

4. Затем составлялся список задач на последующую ретроспективу, назначались ответственные сотрудники и сроки.

Примеры проблем, которые обсуждались на ретроспективах:

1. Фактическое значение показателя «Производительность команды» оказалось ниже, чем хотелось бы.

2. Пользователи сталкиваются с одной и той же проблемой несколько раз.

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

Обсуждение этих проблем позволило определить их причины и составить список задач для их устранения. Затем определялись ответственные исполнители и сроки реализации.

Какие KPI были заложены в систему мотивации команды

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

Во время разработки KPI в программе проектов уже выполнялся один из них – промышленная эксплуатация ERP-системы (он длился около года). За это время собралась очередь из более 100 пожеланий пользователей по улучшению нескольких модулей ERP-системы.

Затем составлялся список задач для команды проекта. В него входили:

1. Поддержка пользователей ИТ-системы

2. Доработка пожеланий по новому функционалу

3. Обучение пользователей ИТ-системы

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

Подход к премированию был общим, но показатели у разных ролей в команде отличались.

Начну с описания самого подхода к премированию.

После обсуждения работы с руководством компании, мы решили, что премиальная часть у команды должна составлять примерно 25% от оклада.

При этом 25% – максимальное значение, которое можно было заработать при выполнении всех KPI на 100%.

У каждой роли в проекте было порядка трех KPI. Например, у программистов они были такими:

1. Среднее значение производительности команды (для ее расчета использовался «фокус-фактор», подробнее об этом здесь) по задачам спринтов, завершенных в данном месяце. Вес фактора в премии: 60%.

2. Отсутствие ошибок в работающем релизе. Вес фактора в премии: 20%.

3. % инцидентов, закрытых в нормативное значение. Вес фактора в премии: 20%.

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

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

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

После этого мы собирались на ретроспективное совещание и обсуждали способы улучшения качества работы. Соответственно, и премиальные.

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

Что дает использование ретроспектив

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

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

Остались вопросы? Пишите в комментариях.

Удачи вам в улучшении ваших проектов!