Менеджмент «Про бизнес» 14 сентября 2020

Не платите «налог на управление»! Почему ИТ-компании заваливают сроки, раздувают штаты и как с этим справиться

Срыв сроков и медленный запуск продуктов, попытка уместить в одном человеке управленца и технического эксперта или, наоборот, раздутый штат менеджеров — типичные проблемы, с которыми сталкиваются отделы разработки (delivery organisation) в ИТ-компаниях. Вместо того чтобы эффективно развиваться, бизнес тратит много времени и денег на «латание дыр». В чем причины и как, наконец, решить эти проблемы? Собственным комплексным подходом делится Виктория Бутич, эксперт в сфере ИТ с многолетним опытом работы Delivery Director, автор блога для менеджеров.

— Более 10 лет я занимаюсь стабилизацией и выведением на новый уровень delivery-подразделений в уже работающих и зарабатывающих деньги ИТ-компаниях.

Анализируя важные проблемы, связанные с производством продукта в сфере ИT, я часто вижу одну из самых острых — она связана с эффективным распределением ресурсов. Вместо того чтобы думать про развитие, компания тратит много времени и средств на «залатывание дыр». Как этого избежать? Хочу поделиться своей системой из 5 шагов, которая поможет ИТ-компаниям улучшить, наконец, результаты и производительность работы.

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

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

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

Почему важно решать проблемы в деливери

Деливери — это основной генератор выручки в ИT-компаниях, эффективное управление этим подразделением является ключом к стабильному развитию и долгосрочной конкурентоспособности на своем рынке.

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

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

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

В чем причины проблем

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

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

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

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

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

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

Вообще, качественно проанализировать текущее положение дел можно только поработав некоторое время внутри компании и завоевав доверие людей (у меня на это обычно уходит 2−3 месяца). Без доверия и симпатии невозможно получить честную обратную связь о происходящем снизу. Самые сильные и мотивированные на хорошую работу люди редко бывают открытыми с чужаками.На этом этапе очень важно правильно оценить менеджеров и ключевых сотрудников, которые находятся внутри подразделения, чтобы понять, как строить организационную структуру, на кого опираться.

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

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

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

Шаг 2. Формирование оптимальной оргструктуры и управленческой команды

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

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

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

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

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

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

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

Я, например, дважды делала такие трансферы, в одном случае очень успешно, а в другом — человек не справлялся.

Еще один пример. Со сменой структуры в компании отказались от роли девелопмент-лидера (менеджера команды разработки), разделив эти функции между деливери-менеджером и техническим лидером. Освободился очень активный технарь, который умеет хорошо анализировать информацию и доносить ее до разных людей простым и понятным языком. Мы посмотрели, где этот талант может нам помочь. Оказалось, что в компании есть немало проблем во взаимопонимании между разработкой и другими отделами, что тормозит работу, а иногда приводит к глупым ситуациям с клиентами. А заодно раскрутили ворох «ничейных» зон ответственности, где нужны и технические знания, и умение общаться и договариваться. В итоге получили отдельную роль, на которой человек отлично раскрылся.

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

Чтобы построить команду из собранной группы менеджеров, нужно создать атмосферу сотрудничества вместо конкуренции, обеспечить «химию» между людьми. Руководитель может делать это через:

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

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

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

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

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

Например, цель команды — реализовать запланированную продуктовым менеджером функциональность. Ключевые результаты: а) план сделан на 80% и выше; б) количество критических ошибок после выпуска равно 0.

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

Шаг 4. Трансформация, описание и стандартизация бизнес-процессов

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

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

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

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

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

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

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

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

Этот этап не имеет завершения, он должен превратиться в процесс постоянного совершенствования (модный нынче «кайдзен»).

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

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

1. Внедрение и распространение менторства, обучения и системы управления знаниями.

2. Определение и распространение культурного кода — набора простых правил, основанных на ценностях. Они должны давать ответ на вопросы:

Какие действия мы поощряем в компании и как можно убедиться, что мы их замечаем?
Какие действия мы наказываем в компании и как убедиться, что мы их не пропускаем?
За какие действия мы точно увольняем?
Что нужно обязательно проверять при найме и как?

3. Создание и поддержание атмосферы доверия.

4. Построение системы обратной связи.

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

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