January 12, 2024

Оценка качества планирования

Я писал пару раз, как можно оценить компетенции и результативность СТО. Одна из этих веще - это систематическое расхождение плана по реализации проекта/релиза/спринта и так далее. Есть несколько подходов к решению такой задачи. Постараюсь описать те, которые знаю я.
Для начала надо отметить, что хоть планирование по "гибким методологиям" и сильно методологически отличается от "водопадного", но есть и общие сущности: задачи, сроки и т.д. Если один технический директор ведет проекты по двум методологиям, то мы либо должны привести оценку к сравнимым величинам, либо ставить ему два КПЭ.

Контрольный пример

Очень удобно теоретизировать о том как можно было бы что-то оценивать, но я не фанат теоретических упражнений. Поэтому сделал Гугл-табличку с демонстрационными примерами.
Вот она - https://docs.google.com/spreadsheets/d/1KOwudvite88ODkF7ehXcgEuEwIEGQk-RNqqf_ZmI5vw/edit?usp=sharing

Для большего их понимания и для того, чтобы понимать контекст - я чуть подробнее опишу примеры:
1. Проект "Альфа" - Типичный водопад по разработке информационной системы для большого сложного заказчика. Отмечу сразу - "водопад" не формируется сразу. Детализация фиксируется поэтапно, по мере реализации проекта, но после фиксации этапа, плановые сроки уже не смещаются.
2. Проект "Бета" - Проект на этапе технической поддержки, которым занимается выделенная команда релизы выпускаются раз в две недели, технический директор отдает план на две недели.
3. Проект "Гамма" - Проект по развитию продукта в соответствие с дорожной картой, утвержденной CEO, CPO, CTO. Релизы выпускаются раз в три месяца.
4. Проект "Дельта" - Проект со стандартным циклом спринтов - один месяц. Бэклог пополняется продуктовой командой и приоритезируется ежемесячно.

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

Оценка точности плана

Я обычно применяю одну из трех оценок точности.

  1. Оценка через отклонение срока достижения цели от общей протяженности проекта
  2. Оценка через накопленное отклонение по задачам от их общей протяженности
  3. Оценка через оценку прогнозируемости отклонений

Каждую из оценок разберем в примерах

Проект "Альфа"

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

Любые относительные показатели в пределах 10 процентов на таком горизонте являются приемлемыми. Выход за пределы 20 процентов - это мрак.

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

Проект "Бетта"

Отличное относительное отклонение. Задачи решаются в совокупности в пределах сроков, но плохой коэффициент вариации. В данном примере это связано с тем, что для оценки выбрана методика "Фиббоначи". В ней есть нелинейность оценки, что при ошибки может приводит к кратному росту сложности. Хотите оценить прогнозируемость ошибок - выбирайте другой метод


Проект "Гамма"

Плохое относительное отклонение. Выбивается за 20%, на горизонте планирования в три месяца - это значит, что "планирование" было слепым. Тут любой уважающий себя СТО придумает 1000 отмазок, что при планировании дорожной карты был ужасный уровень технической неопределенности, не было функциональных описаний или может какие-то задачи сносились в низкий приоритет. Это, конечно, легко проверяется на выборочной проверке самых слетевших задач, "НО" если СТО заранее не обозначал рисков и не говорил о необходимости в корректировке дор. карты, то это его косяк.
Вариация дельты тут тоже не показательна, т.к.

Проект "Дельта"

Специально подогнал пример, чтобы отловить другой тип СТО. Смотрите, вроде все круто, показатели в хороших зонах. "НО" вариация дельты говорит о том, что отклонения достаточно прогнозируемые. Можно было бы подумать, что опять "недозаклад" по сложности, но провалившись в цифры видим, что ситуация зеркальна. Везде "перезаложены" риски. Что это значит? Что 16% трудовых ресурсов вы просрали из-за перестраховки СТО

Вывод

Наличие оценки качества технического планирования может позволить Вам управлять результативностью СТО. Конечно, каждый техдир придумает кучу причин, почему так произошло и какой он молодец, что все не упало (для этого, кстати есть КПЭ по устойчивости в прошлой статье) и вы вообще еще в продуктиве. Но так у вас будут числа, чтобы дискутировать и будет почва для принятия решений. Всем добра!

The CTO