Практика постоянного улучшения требует определённой технологии. С чего начать? Как управлять улучшениями? Своим опытом и наработками в этом направлении решил поделиться уже знакомый нам Стюарт Рэнс. Автор выделил четыре области, которые подробно рассматривает в своей заметке.

Во-первых, для начала нужно составить реестр, наполнив его записями об улучшениях. Где их взять? Помимо результатов вашего собственного исследования и наблюдения, есть множество других источников: жалобы заказчиков и обратная связь с ними, пожелания ИТ-команд — как со стороны эксплуатации, так и со стороны развития, реестры рисков, процессные KPI и оценки процессов, зарегистрированные проблемы, регулярные обзоры по управлению ИТ-услугами.

Во-вторых, нужно структурировать реестр, снабдив каждую запись об улучшении необходимой информацией. Не нужно превращать реестр в сложную штуковину — вести его можно и в Excel, используя следующие (но и не только) поля:

• "id" — уникальный номер каждой записи в реестре.
• "Описание" — что это за улучшение.
• "Польза" — почему это улучшение необходимо. Имеет смысл выставлять признак для каждого улучшения по простой шкале: "Большая / Средняя / Маленькая".
• "Срочность" — к какому сроку улучшение необходимо. Это может быть привязка к какому-либо конкретному ожидающемуся событию. В других случаях — определяться размером денежных потерь. Аналогично используем шкалу "Высокая / Средняя / Низкая".
• "Длительность" — сколько займёт реализация улучшения. Грубой оценки здесь достаточно, ведь главный вопрос — это потребует недели, месяца или года?
• "Стоимость" — насколько улучшение дорого. Достаточно оценить её по уже принятой шкале: "Высокая / Средняя / Низкая".
• "Владелец" — на ком будет лежать ответственность за последующий анализ и принятие решений по данному улучшению.
• "Дата регистрации" — можно увидеть, с какого момента запись находится в реестре.
• "Статус" — для отслеживания, что происходит с улучшением.
• "Доля выполнения" — для улучшений, требующих большого количества времени.

В-третьих, нужно выработать практику отбора реализуемых улучшений. После того, как вы заполните реестр — внезапно! — станет ясно, с каких улучшений стоит начать в первую очередь. Можно, конечно, создать правила отбора, но, кажется, всё понятно и так:

• улучшения с признаками "большая польза", "высокая срочность", "низкая стоимость" сразу отправляются в разработку;
• на улучшения с "большой пользой", "высокой срочностью", но при этом "средней" или "высокой" стоимостью нужно посмотреть более внимательно, возможно, создать бизнес-кейс, защитить бюджет на его реализацию;
• улучшения с "маленькой пользой" и "высокой стоимостью", обычно, сразу исключаются из дальнейшего рассмотрения — в корзину;
• оставшиеся можно проранжировать по "пользе", "срочности" и "стоимости" и отобрать самые ценные.

В-четвёртых, нужно управлять улучшениями. Единственно верного пути здесь нет. Важно, чтобы улучшение, которое было затеяно и реализовано, принесло пользу. Какой бы подход (Agile, управление проектами и пр.) вы не использовали, необходимо сделать итоговый обзор по завершении улучшения. Обзор должен не просто констатировать факт реализации, но и давать количественную оценку той пользы, что была принесена улучшением.

ОБУЧЕНИЕ

Учебные курсы и сертификация на русском языке

специалистов по ИТ-менеджменту