То "уникальная возможность" получить новый навык и расширить знания придет именно к тому моменту, когда этот навык уже вовсю нужен, и времени на тренировку на кошечках просто нет. То новое-старое знание прилетит в голову в тот момент, когда об него споткнутся коллеги, как о грабли, заботливо разложенные у входа известно куда.
Вот и заезженная и потасканная в общем-то тема управления изменения в проектах всплывает в подобный момент. Вообще этот пост должен был появиться на пару месяцев раньше, потому что тема управления изменения в управлении проектами появилась как предмет обсуждения с заинтересованными коллегами именно тогда. Тогда (в далеком, докризисном октябре 2014го..) вопрос звучал буквально так: как управлять изменениями требований к системе так, чтобы это можно было отслеживать и подтверждать в дальнейшем при сдаче системы. Задача в целом важная, потому что на практике при проведении испытаний на соответствие системы ТЗ очень часто (если не сказать - всегда) игнорируются изменения требований, произошедшие на этапах проектирования и согласования решений с заказчиком. В итоге формальное соответствие не достигается. В тот "далекий" день я пришел домой и освежил свои знания об управлении изменениями в PMBoK. Стоит отметить, что всерьез такой процесс воспринимать я и тогда не решался, потому что, несмотря на широкую практическую пользу, которую приносит этот стандарт, с тех пор, как я с ним познакомился в 2011ом году, он остается для меня порождением дьявола, феноменально избыточным и наполненным всевозможными управленческими дисциплинами (управление рисками, управление коммуникациями, управление персоналом, управление качеством и т.д.). Может быть отчасти в таком отношении виноваты люди, демонстрирующие разнообразные регалии "адептов учения PMI" и вместе с тем - абсолютную безграмотность в применении этой информации на практике. Одной из особенностей этого и подобных ему стандартов, к примеру, является любовь авторов к всевозможным коллегиям и комитетам, собираемым для решения различных вопросов, когда казалось бы можно обойтись одним ответственным лицом.
И вот недавно появился интересный кейс, который демонстрирует практическую состоятельность некоторых, казалось бы, избыточных процедур в процессе.
Одно из подразделений, с которым я работаю, давно использует подход к разработке и поддержке ИТ-систем, реализующих сервисы (ITIL v2 Service Provide, Service Support). Это даже можно назвать грамотно поставленным ИТ-процессом, несмотря на всю его сложность и отсутствие так называемых emergency-механизмов (по крайней мере, официальных). Доработки функционирующих систем (ITIL's Service Support) и модификации разрабатываемых (PMBoK's Change Management) - хотя тут в общем-то тонкая грань, которая порой стирается - осуществляются через механизмы внесения изменений. То есть, сперва появляются изменения на уровне требований, потом на уровне конфигурационных единиц, затем управление релизами и тестирование, все по-взрослому! Анализ изменений и разработку решений по реализации изменения в виде модификаций, образующих релизы, в этой цепочке выполняют консультанты с компетенциями архитекторов базового приложения, что в общем-то логично, так как они представляют себе функционал приложения на уровне связанных функциональных блоков и подсистем, а не просто набора функций и кода. Налаженная система дала сбой, когда на горизонте появилась система, в которой есть конфигурационные единицы, разработанные на внешних, по отношению к базовому приложению технологиях, и когда знаний архитектора базового приложения оказалось недостаточно для оценки влияния изменения(change impact analysis).
Рецепт излечения данной проблемы достаточно простое - передать функции анализа влияния на архитектора более высокого уровня, имеющего компетенции в отношении всех компонентов и технологий, используемых в системе (архитектора решения???). Но проблема в том, что ввиду специфики разработки системы, ее поддержания и функционирования, такого архитектора/консультанта не существует. А существующие (например, я), обладающие пониманием всего комплексного решения, не обладают достаточными компетенциями (да и полномочиями, что уж там скромничать) в части базового приложения.
Еще один рецепт излечения данной проблемы состоит в том, чтобы максимально детально расписать связи между конфигурационными единицами во всей системе (включая дополнительные, неизвестные архитектору приложения компоненты) для хотя бы частичной автоматизации анализа влияния. Однако, под пристальным взглядом оказалось, что конфигурационные единицы, которые учитывались для базового приложения, недостаточно детализированы и не позволяют пока вести соответствующий учет связей даже между ними.
В итоге сложилась достаточно странная, хоть и порой типичная в интеграционных проектах ситуация. Единого центра архитектурных компетенций нет. Какой-либо задокументированной, структурированной, а поэтому годной к использованию в автоматическом режиме информации тоже нет. Итоговым решением, к которому следовало бы прийти в этом случае с учетом всех описанных факторов, и является создание некого подобия Change Board или Комитета по изменениям. В ITIL он описан как коллегиальный орган, совместно анализирующий вносимые изменения и формирующий решение по его реализации. Сам процесс анализа влияния в этом случае несколько разрастается, зато он не требует изменения базовой осведомленности ответственных лиц и существенных доработок процесса управления конфигурациями.
Итоговое решение, кстати, пока не найдено. Подозреваю, что сказанные мной слова "комитет по изменениям" и "анализ влияния" несколько напугали коллег, так как уровень зрелости этих процессов с учетом их осознания исполнителями (1 или 2 уровень по модели CMM, если не ошибаюсь) оставляет желать лучшего. Однако, самое главное для меня уже произошло - я увидел практический смысл в исключительно теоретических, как мне казалось, вещах.
Комментариев нет:
Отправить комментарий