В управленческой среде есть древняя скрижаль, на которой время оставило базовую мудрость: нельзя управлять тем, что нельзя измерить. Почти любую деталь сложного проекта можно разложить на исчисляемые параметры. Однако измерения ради измерений не обязательно облегчают управление. Они хороши настолько, насколько хороша рассказываемая ими история.
Для истории важно – был ли проект успешен или нет. Алексей Ким, руководитель проектов «Рексофт», делится своим видением ключевых параметров, влияющих на успех ИТ-проекта. В этом посте мы поговорим, по каким метрикам оценивать проект РП, чтобы соблюсти статус-кво по задачам со стороны заказчика и команды, и дадим примеры из практики, чтобы показать, что к чему, и как мы сами эти показатели мерим.
Считается, что хорошие ИТ-метрики берут факты в истории развития проекта и на их основе устанавливают методологию измерения прогресса в достижении бизнес-целей. Когда измеряемые параметры актуальны, они направляют процесс принятия решений, помогающих компаниям достичь стратегических целей, и поддерживают дисциплину и объективность при измерении влияния технологий на бизнес.
Эффективные проектные метрики:
На что обратить внимание: Ключевой вопрос при оценке Scope creep — насколько влияют на ход проекта изменяющиеся требования? Как изменения влияют на количество новых задач? Регулярное отслеживание данного параметра поможет оставаться на плаву и не взваливать на команду больше необходимого.
В качестве примера — типичная статистика по релизу. 2 промежуточных статуса (Approved, Committed) – не актуальны в контексте Scope creep. А вот то, что входит в статус New – это и есть иллюстрация разрастания. Из этой статистики видно, что 71 из 329 – это больше 21%, в данном случае, приходится на новые задачи (то, что было заведено как новые требования).
Возьмем типичный Burndown chart проекта, в котором новые требования учитываются под осью «Время». Это позволяет получить наглядную картину роста scope creep. Если бы его не было, то дата окончания работ была бы в точке Т1, а текущий тренд говорит, что вероятная дата окончания будет значительно позже – в Т2.
На что обратить внимание: Важно одинаково критически подходить к любому несовпадению оценки. То есть, рассматривать не только слишком оптимистичные разночтения — когда заложено меньше ресурсов, чем потребовала задача — но и чересчур пессимистичные, когда в плане стоит куда больше, чем оказалось в итоге. Однако куда важнее своевременно рефлексировать над повышением качества оценок и делать верные выводы из разногласий.
В современных реалиях, в Agile проектах, практически нереально застраховаться от ошибки в оценке задач. И чем дальше мы находимся от этапа разработки, тем менее точной будет наша оценка (тут актуальна концепция Конуса Неопределенности). Можно попробовать улучшить качество оценки с помощью PERT (Project Evaluation Review Technique). Суть в том, чтобы дать оптимистичную (To), пессимистичную (Tp) и наиболее вероятную (Tm) оценки на задачу. И по фoрмуле (То + 4*Tm + Tp)/6 получить ожидаемую оценку по задаче.
С точки зрения контроля графика выполнения проекта, можно отойти от «Критического пути» проекта к несколько модифицированному подходу предложенному Голдраттом – метод «Критической цепи». Он дает больше гибкости за счет использования буферов при оценке задач. Что, в свою очередь, должно снизить риски разломать план-график проекта.
На что обратить внимание: статус здоровья является скорее эмоциональной проектной метрикой, и лучше обращать внимание не на скорость команды или количество закрытых сторипоинтов в спринте, а на автономность и вовлеченность сотрудников. Высокие уровни вовлеченности говорят об интересе членов команды, а автономность — в соответствии их проектным требованиям и правильном подборе компетенций.
Статус здоровья команды — это одна из ключевых метрик успешности проекта. Понятно, что она напрямую связана как с качеством коммуникаций в команде, так и с рисками потери сотрудника, его экспертизы и опыта из-за того что он решил покинуть проект/компанию. Причины могут быть различными: от конкурентного уровня оплаты до семейных обстоятельств, но, в данном случае, говорим о вовлеченности и компетенциях. Очень эффективный фреймворк был предложен Синтией Максвелл (на тот момент Director of Engineering at Yahoo). Она предлагает отслеживать сложность задач и рост экспертизы, знаний сотрудников, по ходу проекта.
Две оси (Challenge – сложность задач, Skills – уровень знаний и экспертизы). Нужно периодически отслеживать текущий статус сотрудников в проектной команде. Задачи, которые они выполняют, должны быть достаточно амбициозными и сложными. При этом, в ходе их выполнения должны приобретаться новые знания.
Если задачи слишком сложные для сотрудника, то велик риск того, что он с ними не справится и, как следствие – сомнения, дискомфорт и т.д. Слишком легкие задачи – другая крайность, которая может привести к тому, что сотруднику на проекте будет скучно. Для IT-профессионалов очень важно понимать, что вместе с новыми задачами они получают нужный им новый опыт и знания (технологии, фреймворки и т.п.). Соответственно, если на этой плоскости получаются сильные отклонения от медианы, то это сигнал о значительном росте рисков, влияющих на статус здоровья команды.
На что обратить внимание: необходимо найти критические зависимости и работать над их разрешением. Возможно, привычный фреймворк через несколько лет потребует переработки или ключевой проектный эксперт решит заняться чем-то другим — угроз масштабированию больше, чем кажется.
В качестве положительного примера могу привести проект «Рексофт», на котором после 4 последовательно реализованных этапов с все большим и большим масштабом заказчик просто забронировал ресурсы команды из 7 инженеров, 3 тестировщиков и двух менеджеров на год вперед — то есть, он пока еще не был уверен, что конкретно предстоит делать, но был готов к обеспечению потенциальных задач исполнителями.
Мое мнение — этому проекту не хватило счастья. Разумеется, измерить его не представляется возможным — оно лежит глубоко в эмоциональной плоскости — но следствия наличия или нехватки счастья проявляются как в четырех вышеописанных метриках, так и в деталях общения между сторонами и командами. Сложно насыпать в проект щепотку счастья, но можно отследить его нехватку и усилить производительную сторону.
На что обратить внимание: одним из следствий удовлетворенности заказчика (и успешности проекта) является то, готов ли он перейти от фиксированных затрат на проект к модели «time & material». Как правило, это говорит о высоком уровне доверия исполнителю. Члены команды могут выражать счастье в трех плоскостях: вовлеченностью в проект, ростом их компетенций и материального вознаграждения. Возможно, своевременные опросы удовлетворенности обеих сторон помогут отследить параметры счастья. Но это не точно.
Измерение счастья проектов — это субъективная и достаточно интуитивная процедура, которая может вдохновить на новые идеи или напротив, разочаровать в своей эфемерности. Однако если ваш заказчик не спешит говорить о масштабировании или расширении команды, подумайте, может быть, корень его колебаний можно найти в пяти составляющих выше.
Источник статьи: https://habr.com/ru/company/reksoft/blog/568930/
Для истории важно – был ли проект успешен или нет. Алексей Ким, руководитель проектов «Рексофт», делится своим видением ключевых параметров, влияющих на успех ИТ-проекта. В этом посте мы поговорим, по каким метрикам оценивать проект РП, чтобы соблюсти статус-кво по задачам со стороны заказчика и команды, и дадим примеры из практики, чтобы показать, что к чему, и как мы сами эти показатели мерим.
Считается, что хорошие ИТ-метрики берут факты в истории развития проекта и на их основе устанавливают методологию измерения прогресса в достижении бизнес-целей. Когда измеряемые параметры актуальны, они направляют процесс принятия решений, помогающих компаниям достичь стратегических целей, и поддерживают дисциплину и объективность при измерении влияния технологий на бизнес.
Эффективные проектные метрики:
- фокусируют внимание сотрудников на приоритетах внутри проекта
- передают данные в бизнес-терминах
- улучшают процесс принятия решений
- сообщают о необходимости выполнения определенного действия
- развиваются по мере взросления проекта
1. Разрастание масштаба или Scope creep
Говоря об удовлетворенности проектом с обеих сторон, нельзя не сказать об основном параметре измерения внутрипроектной энтропии. Насколько бы очевидным ни являлся данный параметр, разрастание масштабов сильнее всех влияет на общее настроение как со стороны заказчика, так и в команде исполнителей. Любой проект так или иначе подвержен изменению требований, поэтому критически важно учитывать уровень разрастания — это поможет адекватной оценке ресурсов и снизит потенциальный хаос.На что обратить внимание: Ключевой вопрос при оценке Scope creep — насколько влияют на ход проекта изменяющиеся требования? Как изменения влияют на количество новых задач? Регулярное отслеживание данного параметра поможет оставаться на плаву и не взваливать на команду больше необходимого.
В качестве примера — типичная статистика по релизу. 2 промежуточных статуса (Approved, Committed) – не актуальны в контексте Scope creep. А вот то, что входит в статус New – это и есть иллюстрация разрастания. Из этой статистики видно, что 71 из 329 – это больше 21%, в данном случае, приходится на новые задачи (то, что было заведено как новые требования).
Возьмем типичный Burndown chart проекта, в котором новые требования учитываются под осью «Время». Это позволяет получить наглядную картину роста scope creep. Если бы его не было, то дата окончания работ была бы в точке Т1, а текущий тренд говорит, что вероятная дата окончания будет значительно позже – в Т2.
2. Качество наших проектных оценок
Данная метрика говорит о масштабе несовпадения плоскостей «ожидание-реальность» проекта. Неправильная оценка задачи в рамках проекта потенциально нарушает план разработки и ведет к разрастанию масштабов. В основе неправильной оценки же лежит непонятное или непонятое требование, что сообщает о расхождениях на более фундаментальном уровне восприятия проекта. Напротив, более верное измерение задач ведет к более оптимальному распределению приоритетов, ресурсов и сил на их решение, что снижает неопределенность и экономит деньги и нервы.На что обратить внимание: Важно одинаково критически подходить к любому несовпадению оценки. То есть, рассматривать не только слишком оптимистичные разночтения — когда заложено меньше ресурсов, чем потребовала задача — но и чересчур пессимистичные, когда в плане стоит куда больше, чем оказалось в итоге. Однако куда важнее своевременно рефлексировать над повышением качества оценок и делать верные выводы из разногласий.
В современных реалиях, в Agile проектах, практически нереально застраховаться от ошибки в оценке задач. И чем дальше мы находимся от этапа разработки, тем менее точной будет наша оценка (тут актуальна концепция Конуса Неопределенности). Можно попробовать улучшить качество оценки с помощью PERT (Project Evaluation Review Technique). Суть в том, чтобы дать оптимистичную (To), пессимистичную (Tp) и наиболее вероятную (Tm) оценки на задачу. И по фoрмуле (То + 4*Tm + Tp)/6 получить ожидаемую оценку по задаче.
С точки зрения контроля графика выполнения проекта, можно отойти от «Критического пути» проекта к несколько модифицированному подходу предложенному Голдраттом – метод «Критической цепи». Он дает больше гибкости за счет использования буферов при оценке задач. Что, в свою очередь, должно снизить риски разломать план-график проекта.
3. Статус здоровья команды
Классическая и практически аксиомальная проектная метрика вбирает в себя множество подпараметров и методов оценки. При этом, распространенной ошибкой в оценке производительности команды является излишняя полагаемость на измерения. Как известно, введение наблюдателя в систему меняет поведение системы, и ИТ-команда точно так же соответствует этому тезису. При попытках объективно измерить эффективность сотрудников страдают либо сами механизмы измерений, либо сотрудники, пытающиеся подстроить свою работу под параметры оценки.На что обратить внимание: статус здоровья является скорее эмоциональной проектной метрикой, и лучше обращать внимание не на скорость команды или количество закрытых сторипоинтов в спринте, а на автономность и вовлеченность сотрудников. Высокие уровни вовлеченности говорят об интересе членов команды, а автономность — в соответствии их проектным требованиям и правильном подборе компетенций.
Статус здоровья команды — это одна из ключевых метрик успешности проекта. Понятно, что она напрямую связана как с качеством коммуникаций в команде, так и с рисками потери сотрудника, его экспертизы и опыта из-за того что он решил покинуть проект/компанию. Причины могут быть различными: от конкурентного уровня оплаты до семейных обстоятельств, но, в данном случае, говорим о вовлеченности и компетенциях. Очень эффективный фреймворк был предложен Синтией Максвелл (на тот момент Director of Engineering at Yahoo). Она предлагает отслеживать сложность задач и рост экспертизы, знаний сотрудников, по ходу проекта.
Две оси (Challenge – сложность задач, Skills – уровень знаний и экспертизы). Нужно периодически отслеживать текущий статус сотрудников в проектной команде. Задачи, которые они выполняют, должны быть достаточно амбициозными и сложными. При этом, в ходе их выполнения должны приобретаться новые знания.
Если задачи слишком сложные для сотрудника, то велик риск того, что он с ними не справится и, как следствие – сомнения, дискомфорт и т.д. Слишком легкие задачи – другая крайность, которая может привести к тому, что сотруднику на проекте будет скучно. Для IT-профессионалов очень важно понимать, что вместе с новыми задачами они получают нужный им новый опыт и знания (технологии, фреймворки и т.п.). Соответственно, если на этой плоскости получаются сильные отклонения от медианы, то это сигнал о значительном росте рисков, влияющих на статус здоровья команды.
4. Легкость масштабирования проекта
Этот параметр учитывает готовность обеих сторон к увеличению масштабов и важен, скорее, на более поздних этапах проекта. В идеальных ситуациях заказчик видит дальнейшие стратегические точки развития проекта, а исполнитель готов обеспечить связанные с ними расширения требований ресурсами и инструментами. Часто происходит так, что в пост-проектной фазе исполнитель предоставляет поддержку сотрудникам или пользователям заказчика. Важно понять, мешает ли объем оказываемой поддержки готовности к масштабированию, и почему.На что обратить внимание: необходимо найти критические зависимости и работать над их разрешением. Возможно, привычный фреймворк через несколько лет потребует переработки или ключевой проектный эксперт решит заняться чем-то другим — угроз масштабированию больше, чем кажется.
В качестве положительного примера могу привести проект «Рексофт», на котором после 4 последовательно реализованных этапов с все большим и большим масштабом заказчик просто забронировал ресурсы команды из 7 инженеров, 3 тестировщиков и двух менеджеров на год вперед — то есть, он пока еще не был уверен, что конкретно предстоит делать, но был готов к обеспечению потенциальных задач исполнителями.
5. Всеобщее счастье
Максимально абстрактный параметр, который часто является чуть ли не единственным определяющим долгосрочность сотрудничества. Часто происходит так, что проект завершен, все требования заказчика выполнены, команда выложилась по полной, но никакой магии не происходит. Проект передается заказчику и начинает жить сам по себе, а команда просто переключается на следующий.Мое мнение — этому проекту не хватило счастья. Разумеется, измерить его не представляется возможным — оно лежит глубоко в эмоциональной плоскости — но следствия наличия или нехватки счастья проявляются как в четырех вышеописанных метриках, так и в деталях общения между сторонами и командами. Сложно насыпать в проект щепотку счастья, но можно отследить его нехватку и усилить производительную сторону.
На что обратить внимание: одним из следствий удовлетворенности заказчика (и успешности проекта) является то, готов ли он перейти от фиксированных затрат на проект к модели «time & material». Как правило, это говорит о высоком уровне доверия исполнителю. Члены команды могут выражать счастье в трех плоскостях: вовлеченностью в проект, ростом их компетенций и материального вознаграждения. Возможно, своевременные опросы удовлетворенности обеих сторон помогут отследить параметры счастья. Но это не точно.
Измерение счастья проектов — это субъективная и достаточно интуитивная процедура, которая может вдохновить на новые идеи или напротив, разочаровать в своей эфемерности. Однако если ваш заказчик не спешит говорить о масштабировании или расширении команды, подумайте, может быть, корень его колебаний можно найти в пяти составляющих выше.
Источник статьи: https://habr.com/ru/company/reksoft/blog/568930/