Операционная эффективность в IT: как сделать процессы прозрачными и предсказуемыми.

Привет, VC! На связи Александр Сельдемиров — CEO ITQuick, сооснователь Jumse. Сегодня — о том, что многие собственники и инвесторы формулируют одним предложением: «Мы не понимаем, что происходит внутри IT!” Они вкладывают огромные деньги, сроки плывут, а прогнозов нет. Ниже — как мы делаем IT абсолютно прозрачным.

Мы начинаем ряд публикаций, подготовленных совместно с Денисом Демчиком — ведущим проектным менеджером ITQuick с более чем 15-летним опытом, который работает над повышением операционной эффективности в крупных IT-проектах, таких как “Транзит”, “GetChips” и “БИС”.

Задачу повышения прозрачности и эффективности IT-процессов особенно остро чувствуют бизнес, инвесторы и собственники. Ключевой запрос сводится к пониманию того, что происходит внутри IT и как сделать процессы действительно эффективными и понятными для всех уровней, от владельцев до непосредственных исполнителей.

Внутренние заказчики часто недовольны результатами: компании-подрядчики обещают одну картину, а в реальности возникают непредвиденные ошибки, влекущие за собой дорогостоящие исправления и затягивание сроков.

Операционная эффективность — это не что иное, как комплекс характеристик, позволяющих компании работать быстрее, качественнее и гибче при минимальных затратах. Мы сегментировали весь процесс на следующие ключевые элементы:

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

Например, если мы будем говорить о прозрачности конкретно для компании БИС, то доступность и актуальность информации — это необходимое условие эффективности бизнеса. Но как оно будет реализовано для конкретной компании, мы смотрим, исходя из ситуации. И здесь в детализации мы уже видим: создание dashboard-метрик, отчеты по заявкам, определение загруженности сотрудников и т.д.

Прозрачность можно сравнить с состоянием автомобиля во время поездки из точки А в точку Б. Когда все системы работают, есть навигатор и четкий маршрут, путь быстр и управляем — это высокий уровень прозрачности. Если же приборы не работают, дороги незнакомы, а решения принимают «на ощупь», эффективность падает, и риски возрастают.

Оптимизированный поток. Здесь мы обращаем внимание на то, что все идет гладко, с минимальными потерями, нет узких горлышек. В самом общем виде оптимизированность потока можно разбить на контроль метрик, таких как Time to Market, Cycle Time, Work in Progress (WIP), Flow Efficiency и потери (waste). Цель — создать плавный поток и сократить общее время выполнения задач, что напрямую влияет на удовлетворённость заказчиков и предсказуемость работы системы.

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

Качество — это не только отсутствие дефектов, отражаемое техническими метриками, такими как test coverage, defect rate и escaped defects, но и удовлетворение всех заинтересованных сторон, включая и инвесторов, и бизнес, и саму команду, которая работает над проектом. Баланс интересов — ключевой для сохранения мотивации.

Адаптивность и гибкость — способность команды быстро меняться под нужды бизнеса и внешнюю среду. В нашем бэкграунде есть не одна история, когда внезапно уходит ключевой заказчик, а компания оказывается к этому совершенно не готова и испытывает болевой шок.

Вовлечённость команды подразумевает не только денежную мотивацию. На финансах не выстроить инициативу и самоорганизацию. Людям должно быть интересно работать, а когда это так, команда постепенно начинает работать без жесткого управления, самостоятельно предлагая улучшения.

Ориентация на ценность означает, что задачи понимаются через призму пользы для проекта. В идеале, каждый разработчик должен понимать, для чего он решает ту или иную задачу, над какой фичей он работает. А не так, что “работает, потому что она в плане стоит”.

Итак, мы наметили общую картину того, как добиться ясности в функционировании бизнеса, и какими метриками её можно измерить.

Этот подход применим в большинстве технологических и IT-компаний, занимающихся продуктовой разработкой. Он основан на богатом опыте и проверенных методологиях, составляющих золотой стандарт операционной эффективности в IT.

Приходилось ли вам пересматривать основные процессы в вашем бизнесе? Разбирали ли вы, в чем кроется эффективность вашего IT? Предлагаю обсудить в комментариях.