В своей недавней статье Paul Wilkinson делится рядом интересных наблюдений, сделанных во время деловой игры MarsLander, в которой приняли участие две “идеологические группы”. В статье они называются “DevOps and ITIL stakeholders”. Как развивалась игра и какими рекомендациями сопровождает описание автор, вы можете познакомиться в первоисточнике. Мы же хотели бы познакомить вас с основными “результатами на вынос” – то есть с выводами, которые сделали сами участники тренинга, выводами, которые участники “взяли с собой”, чтобы постараться применить в своей повседневной работе.
Важный акцент в деловой игре MarsLander сделан на выстраивании эффективного сотрудничества. Именно поэтому тон рассуждениям участников, когда они обсуждали целевой характер взаимодействия при решении поставленных задач, задавал почти лозунг “Не кричите друг на друга!”, написанный на доске. И именно он, по всей видимости, (не только он, конечно) помог команде прийти к перечисленным ниже выводам.
Итак, в качестве ответа на вопрос “что из того, что вы попробовали сделать сегодня, вы возьмёте с собой и попробуете применить в своей организации” участники сформировали следующий список.
- Если вы действительно хотите получить преимущества, вам нужно принять “краткосрочную боль” для долгосрочной выгоды, при этом признавая, что некоторая краткосрочная боль необходима, чтобы дать время экспериментировать, учиться и совершенствоваться, чтобы расширить способность приносить больше пользы в долгосрочной перспективе… кто готов принять боль?
- Определение приоритетов изменений следует выполнять путём сопоставления следующих аспектов: получаемая ценность, теряемая ценность, ценность улучшения. Необходимо обеспечить баланс приоритетов.
- Определение приоритетов инцидентов должно быть связано с воздействием на бизнес. Необходимо вовлекать заказчиков (“Engage” в ITIL4 – для тех, кто уже с ним познакомился) для получения сведений о реальном воздействии.
- Бизнес-кейсы, формируемые в рамках инициатив по улучшению, должны содержать описание препятствующих факторов, неэффективных потерь, избыточной сложности, потери ценности, а также возможности для создания новой ценности в результате улучшений.
- Поддержка инициатив по улучшению и задач по решению проблем должна опираться на факты и их “оцифровку”.
- Коммуникация и сотрудничество имеют решающее значение. Общайтесь в деловых терминах, сотрудничайте на основе принятых всеми участниками поведенческих соглашений (например, мы слушаем, мы уважаем). Используйте стендапы, ретроспективы и семинары по постоянному совершенствованию для развития сотрудничества, понимания и построения доверительных отношений.
- Владельцы услуг обязательно должны участвовать в стендапах и ретроспективных встречах для выявления и приоритизации инициатив по улучшению услуг.
- Определите типы требований и возможностей и начните сопоставлять потоки создания ценности с ответственными ролями. Используйте это для определения (выявления) ценности, устранения неэффективных потерь и согласования приоритетных улучшений.
- Улучшайте прозрачность всех видов работ, а также распределения ресурсов и текущих задач (work-in-progress). Кто над чем работает и каковы приоритеты? Резервируйте время для работы по улучшению.
- Переместите фокус с DevOps (от кода до внедрения) на BizDevOpsBiz (от идеи к ценности) и переместите “фокус ITIL” с процессов на сквозные потоки ценности.
- У одного потока создания ценности должен быть один владелец продукта (product owner). Избегайте конкуренции нескольких владельцев продуктов за ресурсы и приоритизации своих собственных КПЭ за счет других владельцев продуктов. Владелец продукта должен владеть сквозным потоком создания ценности, то есть отвечать не только за функции, но и за качество обслуживания и получение ценности.
- Выстраивайте отношения с коллегами по бизнесу. Используйте метрики, дашборды, взаимодействуйте с бизнесом и конечными пользователями.
- Необходимо обеспечить чёткость понимания всеми ролей и обязанностей, особенно в определении приоритетов и принятии решений.
- Команды нуждаются в тренерах (коучах), чтобы проводить стендапы, ретроспективы или сессии выявления мер по улучшению. Коуч должен быть встроен в команду. Важно, что именно коуч, а не менеджер должен выполнять описанную работу.
- Донесите важность создания бизнес-кейсов до владельцев продуктов. Если мы хотим, чтобы владелец продукта верно расставил приоритеты в области улучшения, управления проблемами, дефектами или техническим долгом, мы должны сформировать бизнес-кейс с фактами и цифрами, относящимися к ценности и влиянию.
- Общая задача в рамках деятельности по управлению услугами – получать обратную связь из первых рук, анализировать работу исполнителей на местах. Только так можно действительно выявить неэффективность, избыточную сложность и возможности для совершенствования.
- Команды нуждаются в коучинге для развития соответствующих навыков сотрудничества и коммуникации и для стимулирования постоянного обучения и совершенствования.
Полный текст статьи доступен по ссылке.
