Алгоритм решения проблем в управлении разработкой в ИТ.

Delivery organisation (или engineering organisation или отдел разработки)- это часть IT компании, которая отвечает за производство того, что хочет продавать бизнес: услуг по разработке (проектов), продуктов, сервисов. Под этим понятием обычно объединяют программистов, тестировщиков, руководителей проектов и бизнес-аналитиков (но не продакт оунеров, которые отвечают за развитие продуктов: правильно, когда они входят в отдельную структуру). Дизайнеры и UX специалисты могут быть как частью Delivery, так и самостоятельным подразделением, в зависимости от бизнес-модели, по которой они работают и от размера компании. То же самое касается и сервис-инженеров (которых мы называем IT Ops или Dev Ops).

Посколько в IT мире слово Delivery не переводят на русский язык, дальше я буду писать его кириллицей.

Основные проблемы c деливери, которые бывают у компаний :

• Постоянный перенос сроков поставки продуктов
• Непредсказуемость, отсутствие возможности планировать с горизонтом в квартал и больше
• Большие издержки на поддержку (проблемы с качеством)
• Большой «налог на управление» (необходимо нанимать много менеджеров разного уровня, которые ничего «руками» не производят)
• Скорость поставки продуктов ниже, чем у конкурентов, и тенденции к улучшению нет
• Очень высокая стоимость разработки в целом.

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

Все проблемы с деливери чаще всего связаны с одним или несколькими из факторов:

• Неверно выбранная организационная структура внутри подразделения, например, объединение ролей проектного, продуктового и ресурсного менеджмента в одном человеке или отсутствие менеджмента как такового, внедрение «самоорганизующихся команд» без учета контекста
• Неверно выбранная методология управления проектами; скажем, сейчас модно использовать Скрам или Канбан даже там, где эти методологии не подходят, поэтому в результате получается процесс ради процесса, люди (включая руководителей) не понимают ни логики, ни смысла ритуалов и артефактов, методология из помощника превращается в тормоз и вредит эффективности
• Хаотичные и несистематизированные бизнес-процессы (часто — их отсутствие)
• Неверная постановка и описание задач, которые мешают разработчикам и тестерам адекватно оценивать время на их реализацию
• Страх людей перед ошибками — проблемы с ответственностью, мотивацией и культурой в целом
• Экспертиза, сконцентрированная в одних или в нескольких головах конкретных людей (отсутствие системы передачи знаний), что ведет к зависимости от этих людей
• Высокая текучесть кадров или, наоборот, слишком низкая
• Отсутствие системных базовых знаний по планированию и контролю у линейных менеджеров
• Отсутствие ясных целей и KPI
• Отсутствие управленческой команды (нет синхронизации между отделами)
• Отсутствие стратегии по привлечению и управлению персоналом.

Я много лет занимаюсь стабилизацией и выведением на новый уровень деливери подразделений в уже работающих и зарабатывающих деньги компаниях, у меня есть своя система из 5 шагов, которую я применяю для быстрого устранения проблемных факторов.

1. Анализ текущей ситуации.

Задачи на этом этапе — поиск проблемных факторов, подготовка и проверка гипотез.

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

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

Я выделяю четыре критерия при поиске точек опоры:

• компетентность и уважение коллег
• гибкость (готов к переменам, стремится к знаниям)
• независимость (человек не боится потерять работу, то есть находится на своем месте не от безысходности, а потому что ему тут нравится)
• позитивное отношение, активность

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

2. Создание оптимальной организационной структуры и формирование управленческой команды.

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

Структура должна быть одна, общая для всех команд. При ее построении важно отталкиваться от точек опоры, определенных на предыдущем этапе.

Самые распространенные ошибки при создании организационной структуры, которые замечаю я:

• слишком большое количество линейных руководителей (проблемы с процессами пытаются решить за счет ручного управления);
• игнорирование особенностей культуры и менталитета в погоне за модными тенденциями Запада;
• убежденность, что специалистами одной области могут руководить только выходцы из этой области (например: программистам нужен dev lead, а тестировщикам — QA lead);
• желание объединить роль технического эксперта и управленца в одном лице;
• желание объединить продуктовый и проектный менеджмент в одном лице.

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

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

3. Сверка целей и KPI (или ОКР).

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

В ИT при работе с целями сейчас модно использовать фреймворк ОКР (Objectives & Key Results — цели и ключевые результаты). Чаще всего это так называемая двухсторонняя модель: когда руководство компании спускает ключевую цель на квартал сверху, а команды снизу ставят для себя поддерживающие верхнюю 3−5 целей и определяют ключевые результаты — измеримые показатели, определяющие достижение каждой цели.

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

Косвенный признак проблем с пониманием целей — отсутствие мотивации и инициативы снизу.

4. Трансформация, описание и стандартизация текущих бизнес-процессов (включая методологию управления проектами).

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

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

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

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

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

• описание ролей и позиций (оно обязательно должно быть!)
• процесс перфоменс ревью
• процессы, связанные с управлением проектами, различные шаблоны
• другие процессы, которые лежат в основе теории управления

Этот этап не имеет завершения, он должен превратить в процесс постоянного совершенствования.

5. Решение типичных проблем с персоналом.

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

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

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

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

Вам будет интересно почитать: Как решать проблемы с планированием в ИТ.

ВИКТОРИЯ БУТИЧ

Консультант, директор по разработке.

Умею делать эффективных менеджеров из инженеров и решать любые проблемы в области управления разработкой.

P.S. Я верю в то, что абсолютно любую проблему можно решить, а работа менеджера — это поиск возможностей для решения. С интересом разберу понравившиеся мне кейсы вместе с вами в качестве ментора бесплатно. Запрос с кратким описанием кейса можно присылать на victoria.butsich@gmail.com