Большинство ИТ-департаментов известных мне компаний постоянно находятся под стрессом входящего потока изменений. Общее время, требуемое для реализации изменений, ожидающих обработки, с учетом имеющихся ресурсов и трудоемкости задач, как правило, составляет 6+ месяцев, а нередко – и более года. «Взять все и поделить выполнить» не получается – на входе прибывает быстрее, чем ИТ-специалисты успевают разгребать. Значит нужно расставлять приоритеты. Но как это сделать на практике?

Мы поднимали эту тему уже не раз. И в формате вебинаров, и в заметках на данном портале. Но больше делали акцент на том, какие факторы лежат в основе принятия решения – оценка сроков и стоимости реализации, ущерб от отказа в реализации (или реализации позже заданного срока). Все это верно, но в итоге кто-то на основании входных данных должен все-таки принять решение. Кто – ясное дело, бизнес-заказчик. А вот как будет приниматься решение, учитывая конкуренцию за одни и те же ресурсы представителей различных бизнес-подразделений? Принципиально мне известно два подхода.

Первый – совместное обсуждение, где подразделения договариваются между собой. Трудный метод, поскольку каждое подразделение в первую очередь понимает свои задачи и осознает именно их, как наиболее важные (во всяком случае, как наиболее важные с точки зрения своих KPI). Выполнить объективное сравнение известными методами оценки инвестиционных проектов (NPV, IRR, …) не всегда возможно – недостаточно входных данных. А, кроме того, многим «бизнесменам» эти методы понятны еще менее чем ИТ-руководителям. В итоге «кто громче кричит, тот больше прав», а остаться крайним больше всех рискует ИТ-руководитель, ведь это он не успел сделать счастливыми всех.

Второй метод – выделение подразделениям компании квот на ресурсы разработчиков. Величина этих квот устанавливается на среднесрочной основе с учетом бизнес-планов и степени ответственности подразделений за их реализацию. Здесь самый трудный момент – договориться в начале. Не каждый ИТ-директор возьмет на себя смелость, не каждый рискнувший сумеет убедить, что данный подход оправдан. Не в каждой компании есть руководящий орган, компетентный принимать такие решения.

Конечно, заманчива перспектива переложить ответственность за организацию принятия соответствующих решений с ИТ-руководителя на кого-нибудь в бизнесе. Например, большие инициативы вынести на проектный комитет, а по небольшим пусть решает операционный директор или директор по развитию (кто чем богат). Особенно логичным такой подход становится в компаниях, где этот «внешний» человек является руководителем ИТ-директора.

Все эти подходы используются на практике. Многие компании перепробовали несколько. Кто может поделиться историей успеха? У кого в итоге получилось сделать так, чтобы одна из этих или какая-либо иная система определения приоритетов заработала на практике, не вызывая значимых конфликтов?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

Повысить долю успешных изменений, снизить риски, знать всё про конфигурации