Масштабируемые процессы гибкой ИТ-разработки

Виктор Павлович Коноплев
Выпускник группы MBA CIO-69
Школы IT-менеджмента Института ЭМИТ
РАНХиГС при Президенте РФ

В наше время ИТ неотъемлемо связано с бизнесом. Связанно не только как поддерживающая функция, но и как двигатель развития, который помогает не только меньше тратить, но и больше зарабатывать. При этом бизнес живёт в очень высоком темпе и с большой степенью неопределенности. Это накладывает на ИТ подразделение необходимость быть изменчивым и уметь масштабироваться.
I. В первой главе мы рассмотрели, как под давлением бизнеса, могут формироваться не масштабируемые процессы в ИТ подразделении.
Мы выяснили, что существует много вариантов формирования команд. Рассмотрели какие есть стили управления и какие типы структур существуют. Разобрали принципы, по которым формируются команды. И выяснили, что есть множество вариантов, в которых может оказаться компания.
Мы рассмотрели классические процессы разработки. Рассмотрели стандартные роли в командах разработки. Выяснили что для общения с бизнесом на его языке, в команде должен быть специально обученный человек
Разобрались, что для бизнеса, который работает с пользователями, не так страшно запустить проект с нерабочим функционалом, но есть риск что продукт не найдёт product market fit
Поняли, что, когда продукт только запустился, не стоит ожидать от него SLA 99,9%. Но это не значит, что про качество надо забывать.
II. Во второй главе мы рассмотрели новые подходы к выстраиванию ИТ подразделений. Сначала мы выделили основные трудности, с которыми сталкивается ИТ подразделение. Затем мы начали перекладывать решения этих проблем на изменения. Детально разобрали scaled agile framework и переложили его на простые и рабочие инструменты.
Мы ввели новые роли. Детально описали обязанности каждой роли и артефакты, которые ожидаются на выходе той или иной роли. Рассмотрели принципы формирования стратегии как безнеса, так и технологической. Разобрались с тем, что главный вопрос, на который должен отвечать продукт или проект — «Зачем?».
Затем мы объединили инструменты из фреймворка с новыми ролями что бы зафиксировать процесс. Процесс, который мы предложили оказался довольно гибким и способным выдержать запросы бизнеса. Ну а в конце, мы рассмотрели классический подход к запуску процесса по улучшению процессов в компании.
III. В последней главе мы детально рассмотрели переход на предложенный процесс в ИТ подразделении. Выделили трудности, с которыми столкнулись, больше всего запомнилась работа с командой. Поиск и подбор людей, особенно трудно было искать архитекторов. Также на пути к достижению задачи, мы потеряли часть людей, но все изменения того стоили.
Мы начали с выбора экспериментальной группы, которая должна была первой взять на себя задачу по изменению процессов в ИТ департаменте. Рассмотрели то, как важно работать с энергией команды и следить за выгоранием сотрудников. Затем мы начали развивать руководителей, что бы те развивали команды. Взяв на вооружение модель Брюса Такмана.
Затем было проведено стратегическое планирование для донесения миссии до команды. Это было сделано для того, чтобы на её основании были сформированы техническая и бизнес стратегии. В качестве инструмента для стратегического планирования, мы выбрали Objectives and Key Results «цели и ключевые результаты».
После того как мы получили ответы на вопросы «Зачем?» и «Куда мы идём?» начали разбираться в том, как правильно выстроить систему контроля и какие показатели использовать. Выяснили как важно защищать ИТ команды от внештатных задач от бизнеса и как важно бизнесу вовлекаться в процесс разработки.
Финалом стало подведение результатов, которых удалось достигнуть при перестроении процессов в ИТ подразделении. Мы смогли масштабировать результат с нескольких команд на десятки команд с несколькими сотнями человек в них. Мы рассмотрели на сколько сильно уменьшились сроки и повысилась точность в прогнозировании результата. Пронаблюдали за тем, как изменение процессов ИТ подразделения позволило бизнесу меняться и масштабироваться.