Мы часто затрагиваем тему повышения прозрачности и измерений. Есть отдельный курс по разработке систем измерения и оценки «VAP: Разработка сбалансированной системы KPI». Есть тренажёр «Flow Metrics: управление потоковым производством на основе данных». На портале есть большое количество заметок на эту тему. Вышло уже втрое издание книги «Управление услугами на основе измерений».
Один из принципов ITIL® 4 так и сформулирован «Сотрудничайте и повышайте прозрачность» («Collaborate and promote visibility»). Но всегда любопытно взглянуть на свежие реальны данные, полученные в результате следования этому принципу.
В опубликованной несколько дней назад заметке «Как прозрачность помогает разработчикам сфокусироваться на инновациях» («How Visibility Helps Devs Focus on Innovation») Эндрю Ло ссылается на исследование компании Jellyfish, которая проанализировала работу более 23 000 инженеров и опросила сотни ведущих инженеров.
Кроме всего прочего приводится диаграмма усредненного распределения ресурсов инженеров (см. картинку ниже).
Автор заметки обращает внимание на следующее помимо 24%, идущих на поддержку, и 19,3%, идущих на работу с инфраструктурой и (как говорит известный на этом портале человек) на поддержание огня в печи, почти 22% ресурсов, идущих на незапланированные работы (что, кстати, больше на 15% (!!!) чем в предыдущем году) и есть источник, использование которого может увеличить долю ресурсов, затрачиваемых на рост и инновации (сейчас менее 35%). Вполне очевидная мысль: «Запланируйте и придерживайтесь планов. И будет вам счастье» Если ваши планы были планами инновационными, то вы получите больше возможности для роста. Всё более-менее понятно.
Конечно, кого-то может поразить огромная доля утилизации на внеплановую работу. Кому-то может показаться, что это слишком мало. Но, кажется, любопытным здесь является и то, как измеряли долю незапланированной работы.
Ведь вопрос не только в выборе единицы измерения. Считать в потраченных часах (видимо, отнормированных) или в задачах (штуках, видимо, тоже нормированных на какую-то условную единицу) — это, как говорится, две большие разницы. Примеры, основанные на реальных кейсах, можно посмотреть в т.ч. в наборе уже упомянутого тренажёра (см., например, диаграмму Done By Type).
Не меньший разброс может дать расхождение в понимании того, что такое «плановое».
Например, когда сотруднику прилетает задача, о которой сотрудник до этого момента не знал(а). Это внеплановая задача? Может быть она плановая, но определена на другом уровне планирования. Или задача, которая была в планах, но поехала по срокам (в любую сторону). Она всё ещё плановая? Почему? Потому, что мы её когда-то такой назвали?
Получается, что доля плановой (и, соответственно, внеплановой) работы очень сильно зависит от качества планирования. Не только от корректности планов в смысле точности, достижимости и пр. Но и в смысле поддержания планов в актуальном состоянии.
Разумеется, сильно влияет и точность учёта. Собственно, в оригинальном отчёте об исследовании, на который ссылается автор упомянутой заметки («State of Engineering Management») речь идёт о незапланированной/неучтённой трате ресурсов (Unplanned/Unallocated).
В общем, как обычно, хоть и идея автора понятна, и метрика, кажется, довольно простая, на самом деле, есть над чем поработать, чтобы получить рабочий инструмент, который позволит оценить то насколько мы отвлекаемся в работе от плана. Интересно!
