На русском языке вышла книга Питера Брукса "Метрики для управления ИТ-услугами" (в оригинале Metrics for IT Service Management). Книга заявлена как "практическое руководство по проектированию, созданию и использованию метрик и KPI в качестве механизма управления ИТ-услугами".
Скажу честно, я не очень понимаю, что именно автор подразумевал под "проектированием" и "созданием". Но пусть будет создание через запятую с проектированием. Книга для российской аудитории свежая, да еще с примерами ИТ-метрик. Нужно прочесть!
Прочел целиком, имею сказать следующее.
Вердикт – покупать и читать можно, но не обязательно.
Кратко, из позитивного:
- неплохо написана вводная, стратегическая часть (как жить в процессном мире);
- в этой же части присутствует ряд дельных советов (к сожалению, советы мне уже были известны до прочтения книги);
- перевод неплохой, явных ляпов замечено не было.
Структурно книга разбита так – примерно треть о создании метрик, две трети отведено на примеры. Задумка хорошая, да подкачало наполнение. О концептуальных вещах автор пишет живенько. Из правильных, жизненных советов: для проектирования метрики необходимы четкие цели, для проектирования метрики соберите всех заинтересованных лиц, сделайте семинар принятия решений, не смотрите на софт – смотрите на потребности, т.е. на цель. Есть интересная, хотя и спорная главка о интеграции метрик. Однако целиком теория весьма пафосно описана. Есть мнение, что автор давно не проектировал метрики сам, ручками. Абсолютно не сделан акцент на процессе проектирования: не показана ясно связь между целями и итоговой метрикой, не описан процесс получения вариантов метрик от цели. Выбору границ метрик уделено всего ничего, а не помешало бы. Т.е. в представлении автора создание метрики выглядит так:
1) Определили цель (верно!)
2) Собрали заинтересованных лиц (аплодисменты!)
3) Черный ящик проектирования, выдающий метрику и стартовые границы (вообще ничего не написано, а на деле – самое интересное, что и должно быть в теории)
4) Передаем метрику в эксплуатацию.
5) Серый ящик эксплуатации (описано фрагментарно, а ведь это – соль!)
Дальше началось проектирование на примерах и тут книга перестала мне нравится. Навскидку совершенно крышесносящий пример метрики управления конфигурациями: "Число инцидентов, связанных с невыполненными изменениями из-за неправильно задокументированных конфигурационных элементов". Я не говорю о формулировке метрики, которую редкий технарь поймет на слух. Я не говорю уже о том, что только в идеальном мире три процесса внедрены и максимально интегрированы. Да любая связка из трех независимых показателей в одной метрике не будет работать никогда! (в реальном мире)
Оттуда же метрика "Число нарушений SLA, вызванных ошибками CMDB". Прямая цитата: "Хотя в большинстве случаев показатель, по видимому, будет равен нулю, его существование подчеркивает значимость SLA…" Как говорится, комментарии излишни. Отличный, отличный пример цели для метрик!
Ну и вполне логично, примеры метрик в приложениях не блещут – метрики из cobit, itil, и крайне небольшое число оригинальных метрик с понятными целями.
Итак, для чего можно читать данную книгу: если хочется получить несколько внятных высокоуровневых советов относительно создания метрик, если хочется еще раз пролистать возможные наборы метрик для процесса, как полезные, так и бесполезные.
И напоследок тем, кто все-таки решится купить и прочесть: будьте осторожны – все примеры границ для метрик эксплуатации взяты для выдуманного кейса некоей организации. Поэтому не удивляйтесь загадочным значениям, они - для идеального мира.
Кратко, из позитивного:
- неплохо написана вводная, стратегическая часть (как жить в процессном мире);
- в этой же части присутствует ряд дельных советов (к сожалению, советы мне уже были известны до прочтения книги);
- перевод неплохой, явных ляпов замечено не было.
Структурно книга разбита так – примерно треть о создании метрик, две трети отведено на примеры. Задумка хорошая, да подкачало наполнение. О концептуальных вещах автор пишет живенько. Из правильных, жизненных советов: для проектирования метрики необходимы четкие цели, для проектирования метрики соберите всех заинтересованных лиц, сделайте семинар принятия решений, не смотрите на софт – смотрите на потребности, т.е. на цель. Есть интересная, хотя и спорная главка о интеграции метрик. Однако целиком теория весьма пафосно описана. Есть мнение, что автор давно не проектировал метрики сам, ручками. Абсолютно не сделан акцент на процессе проектирования: не показана ясно связь между целями и итоговой метрикой, не описан процесс получения вариантов метрик от цели. Выбору границ метрик уделено всего ничего, а не помешало бы. Т.е. в представлении автора создание метрики выглядит так:
1) Определили цель (верно!)
2) Собрали заинтересованных лиц (аплодисменты!)
3) Черный ящик проектирования, выдающий метрику и стартовые границы (вообще ничего не написано, а на деле – самое интересное, что и должно быть в теории)
4) Передаем метрику в эксплуатацию.
5) Серый ящик эксплуатации (описано фрагментарно, а ведь это – соль!)
Дальше началось проектирование на примерах и тут книга перестала мне нравится. Навскидку совершенно крышесносящий пример метрики управления конфигурациями: "Число инцидентов, связанных с невыполненными изменениями из-за неправильно задокументированных конфигурационных элементов". Я не говорю о формулировке метрики, которую редкий технарь поймет на слух. Я не говорю уже о том, что только в идеальном мире три процесса внедрены и максимально интегрированы. Да любая связка из трех независимых показателей в одной метрике не будет работать никогда! (в реальном мире)
Оттуда же метрика "Число нарушений SLA, вызванных ошибками CMDB". Прямая цитата: "Хотя в большинстве случаев показатель, по видимому, будет равен нулю, его существование подчеркивает значимость SLA…" Как говорится, комментарии излишни. Отличный, отличный пример цели для метрик!
Ну и вполне логично, примеры метрик в приложениях не блещут – метрики из cobit, itil, и крайне небольшое число оригинальных метрик с понятными целями.
Итак, для чего можно читать данную книгу: если хочется получить несколько внятных высокоуровневых советов относительно создания метрик, если хочется еще раз пролистать возможные наборы метрик для процесса, как полезные, так и бесполезные.
И напоследок тем, кто все-таки решится купить и прочесть: будьте осторожны – все примеры границ для метрик эксплуатации взяты для выдуманного кейса некоей организации. Поэтому не удивляйтесь загадочным значениям, они - для идеального мира.
3 комментария:
Александр, судя по всему, создание и проектирование, вернее, проектирование и создание, имеет отношение к ITIL V3, где все сначала проектируется на стадии Design, а потом фактически создается на стадии Transition. Как Вам такая мысль?
А черт его знает на самом деле, Павел, что авторы (или пиарщики?) имели ввиду. В любом случае по отношению к метрике оборот не очень удачный - чем отличается проектирование от создания для метрики я не понимаю.
Татьяна, извиняюсь, обознался! 8) Ввело в заблуждение сообщество PaSol.
Отправить комментарий