Что делать, когда единые правила не работают? Когда разные группы участников одного процесса работают по своим правилам? Причём, не из прихоти, а в силу определённой специфики своей деятельности?
В качестве примера рассмотрим знаменитую историю про трёх товарищей, которые не смогли сдвинуть с места воз с поклажей. Ведь золотые слова написал Иван Андреевич! Но можно взглянуть на проблему и чуть с другой стороны. Все трое ведь банально РАЗНЫЕ! И по-другому не могут! Значит, надо их правильно организовать. Менеджера процесса на них нет, да с регламентом! Только вот ведь незадача: смотри пункт 1 – они все разные. Ну нельзя им всем просто сказать: "Тащи вперёд". Надо лебедю объяснить, чтобы вдоль берега летел, да на одной высоте. Щуке вменить роль подводного буксира, движущегося вдоль камыша. Раку – назад ползти, видимо. Причём, регламент-то напрашивается общий. Например: загружаем-впрягаемся-тянем-выгружаем. А дальше пошла специфика… Например, первым действием лебедя на этапе "Тянем" будет "взлететь на высоту не более Х", а у щуки – "нырнуть на глубину не более Y". То есть получается, что есть некий высокоуровневый процесс, состоящий из обязательных шагов. А внутри каждого этапа все действуют с учётом своих особенностей.
Департаменту ИТ ведь тоже надо общий воз вести, а на нём… не буду перечислять бренды производителей различных информационных систем, но вы понимаете. Какого только добра нет! И проприетарные, и самопальные, и ещё порталы с сайтами. Порядок согласования функционального задания разный, разработки разный, и публикуются изменения по некоторым сразу по готовности, а по некоторым – по релизной схеме. А ещё бывают комплексные изменения – это когда все вместе реально в одну телегу впрягаются и несколько систем переделывают, да ещё должны одновременно этот воз на продуктив выгрузить.
То есть, говоря формальным языком, нужно обеспечить, казалось бы, несовместимое:
- внедрить единый процесс управления изменениями, охватывающий все информационные системы заказчика;
- при этом учесть специфику выполнения изменений по отдельным ИТ-системам.
Выполнить такую задачу очень помогает подход с применением моделей изменений. Схематично всё выглядит примерно так:
Как уже было сказано выше, нужно описать высокоуровневый процесс, состоящий из обязательных этапов. А в моделях изменений описать детализацию этапов. И много чего ещё полезного, что не удаётся внести в общий регламент и распространить на изменения всех информационных систем.
На самом деле подход достаточно универсальный и может применяться не только для управления изменениями. Но сейчас я хочу предложить вам, уважаемые читатели портала REALITSM, немного поговорить именно про модели изменений. И поговорить в следующем формате:
- вы зададите в комментариях вопросы, которые у вас возникли по указанной теме до, во время или после прочтения данной заметки;
- ваш покорный слуга постарается ответить на присланные вами вопросы во время вебинара, запланированного на весеннюю CleverTALK-сессию.
Если для вас эта тема интересна, озвученная проблема актуальна, с нетерпением жду ваши вопросы, а также рассказы об опыте применения данного подхода.
Я сейчас работаю по такой схеме, основная проблема с которой я сталкиваюсь – синхронизация и скорость релизов по разным ИТ-решениям. Запросы на изменения идут комплексные, переносить в продуктив их надо одновременно, а вот релизы выстроить одновременно очень сложно. Бизнес заказчик у разных систем разный, в разные время дает окна под релизы и синхронизовать окна очень сложно (часто невозможно). Вообще в нынешних реалиях (читай Грефа) бизнес ожидает, что переносить будем день в день, а в релизы так не построишь.
Внимание – вопрос, что делать ?