16 октября
Компания МиСофт объявляет о проведении масштабной конференции о цифровизации бизнеса в Минске
2 | 1 | 1 | 1 |
Срыв сроков и медленный запуск продуктов, попытка уместить в одном человеке управленца и технического эксперта или, наоборот, раздутый штат менеджеров — типичные проблемы, с которыми сталкиваются отделы разработки (delivery organisation) в ИТ-компаниях. Вместо того чтобы эффективно развиваться, бизнес тратит много времени и денег на «латание дыр». В чем причины и как, наконец, решить эти проблемы? Собственным комплексным подходом делится Виктория Бутич, эксперт в сфере ИТ с многолетним опытом работы Delivery Director, автор блога для менеджеров.
— Более 10 лет я занимаюсь стабилизацией и выведением на новый уровень delivery-подразделений в уже работающих и зарабатывающих деньги ИТ-компаниях.
Анализируя важные проблемы, связанные с производством продукта в сфере ИT, я часто вижу одну из самых острых — она связана с эффективным распределением ресурсов. Вместо того чтобы думать про развитие, компания тратит много времени и средств на «залатывание дыр». Как этого избежать? Хочу поделиться своей системой из 5 шагов, которая поможет ИТ-компаниям улучшить, наконец, результаты и производительность работы.
Delivery organisation (или engineering organisation или отдел разработки) — это подразделение, которое отвечает за производство всего, что ИТ-компания продает: услуги по разработке (проектов), продуктов, сервисов. Под этим понятием обычно объединяют программистов, тестировщиков, руководителей проектов и бизнес-аналитиков (но не продакт-оунеров, которые отвечают за развитие продуктов: правильно, когда они входят в отдельную структуру).
Дизайнеры и UX-специалисты могут быть как частью delivery, так и самостоятельным подразделением, в зависимости от бизнес-модели, по которой они работают, и от размера компании. То же самое касается и сервис-инженеров (которых мы называем IT Ops или Dev Ops).
Поскольку в ИT-мире слово Delivery не переводят на русский язык, дальше я буду писать его кириллицей.
Деливери — это основной генератор выручки в ИT-компаниях, эффективное управление этим подразделением является ключом к стабильному развитию и долгосрочной конкурентоспособности на своем рынке.
Проблемы в деливери имеют свойство нарастать как снежный ком, вынуждая постоянно тушить пожары и чинить то, что сделано в прошлом, вместо того чтобы фокусироваться на будущем.
Основные проблемы c деливери, которые бывают у компаний:
Обычно эти проблемы начинают возникать и накапливаться при переходе от стадий стартапа и быстрого роста в стадию стабилизации, когда у компании появляется больше крупных и более требовательных клиентов. Вдобавок возникают амбиции и появляются деньги для того, чтобы делать все более сложные и дорогие продукты и решения с упором на долгосрочную перспективу.
Все проблемы с деливери чаще всего связаны с одним или несколькими из факторов:
Отсутствие стратегии по привлечению и управлению персоналом.
Предлагаю алгоритм для решения всех этих проблем, который я разработала, опираясь на свой опыт.
Задачи на этом этапе — поиск проблемных факторов, подготовка и проверка гипотез о необходимых изменениях и их влиянии на систему.
Вообще, качественно проанализировать текущее положение дел можно только поработав некоторое время внутри компании и завоевав доверие людей (у меня на это обычно уходит 2−3 месяца). Без доверия и симпатии невозможно получить честную обратную связь о происходящем снизу. Самые сильные и мотивированные на хорошую работу люди редко бывают открытыми с чужаками.На этом этапе очень важно правильно оценить менеджеров и ключевых сотрудников, которые находятся внутри подразделения, чтобы понять, как строить организационную структуру, на кого опираться.
Я выделяю четыре критерия при поиске таких точек опоры:
На этапе анализа можно и нужно чинить мелкие проблемы, которые, как правило, мешают людям выполнять работу или вызывают у них стресс и беспокойство. Часто это очень банальные вещи, до которых вечно не доходят руки: разрешить людям работать из дома при признаках простуды, проводить регулярные общие собрания с целью делиться новостями компании, убрать лишние элементы бюрократии, защитить команду от наездов со стороны и так далее.
Структура должна сложиться, исходя из реального положения дел в этой конкретной компании, а не из теории. Она должна требовать минимальных изменений по сравнению с тем, как было раньше.Базовое правило, которое я для себя вывела: лучше, если абсолютное большинство руководителей в команде будут выходцами изнутри. Использовать имеющийся потенциал очень важно не только для мотивации, но и потому, что слишком большое число новых лиц — это лишний стресс для сотрудников. Я думаю, что это правило применимо не только в ИT-сфере.
Структура должна быть одна, общая для всех команд. При ее построении важно отталкиваться от точек опоры, определенных на предыдущем этапе.
Самые распространенные ошибки при создании организационной структуры, которые я замечаю:
Пример. Топ-менеджер привык углубляться в детали всего, что происходит «внизу». С ростом компании это удается делать все хуже: приходится постоянно переключаться с проблемы на проблему, соответственно, каждой команде внимание уделяется урывками. При этом все знают, что он может в любой момент вклиниться и отменить любое принятое локально решение, поэтому, чтобы не бегать туда-сюда, люди предпочитают не брать на себя ответственность, а ждать, пока «само разрешится».
Спустя некоторое время топ-менеджер видит, что его подходы не работают. И принимает решение назначить несколько локальных руководителей из числа «технарей», которые будут представлять команды в коммуникации с ним, чтобы он мог держать руку на пульсе. Но от этого проблема с принятием решений не исчезает, потому что вместо процессов работает его личное ручное управление, просто теперь уже через новых менеджеров, которые, как бывшие технари, не имеющие опыта управления, не знают, что предложить взамен. Спустя какое-то время топ-менеджер решает, что нужно поделить зоны ответственности, и назначает дополнительных руководителей и так далее. Положение лучше не становится, а «налог на управление» растет.
Важно отметить, что любые перемены в организационной структуре высвободят хороших и компетентных людей, которым желательно найти другое интересное им применение. Иногда можно даже создать для таких сотрудников специальные должности. Например, со сменой структуры некоторые ИТ-компании отказываются от роли руководителя отдела тестирования, перенеся все функции в команды. При этом руководителю предложили попробовать себя в деливери-менеджменте с сохранением зарплаты.
Я, например, дважды делала такие трансферы, в одном случае очень успешно, а в другом — человек не справлялся.
Еще один пример. Со сменой структуры в компании отказались от роли девелопмент-лидера (менеджера команды разработки), разделив эти функции между деливери-менеджером и техническим лидером. Освободился очень активный технарь, который умеет хорошо анализировать информацию и доносить ее до разных людей простым и понятным языком. Мы посмотрели, где этот талант может нам помочь. Оказалось, что в компании есть немало проблем во взаимопонимании между разработкой и другими отделами, что тормозит работу, а иногда приводит к глупым ситуациям с клиентами. А заодно раскрутили ворох «ничейных» зон ответственности, где нужны и технические знания, и умение общаться и договариваться. В итоге получили отдельную роль, на которой человек отлично раскрылся.
После принятия решения об изменениях лучше открыто его озвучить и сразу же начать внедрять: последовательно, уверенно и, насколько это позволяет ситуация, быстро. Люди гораздо лучше переносят единовременный стресс от больших перемен, чем долгое и мучительное привыкание к растянутым во времени постепенным изменениям, которым не видно конца.
Чтобы построить команду из собранной группы менеджеров, нужно создать атмосферу сотрудничества вместо конкуренции, обеспечить «химию» между людьми. Руководитель может делать это через:
Когда у вас есть команда, люди сами находят взаимозависимости и сами договариваются, как их решить, не происходит эскалаций в сторону руководителя, а потому все задачи выполняются максимально эффективно.
Прежде чем переходить к дальнейшей работе, нужно убедиться, что все команды знают, что они делают, для чего они это делают и каковы критерии успеха.
В ИT при работе с целями сейчас модно использовать фреймворк ОКР (Objectives & Key Results — цели и ключевые результаты). Чаще всего это так называемая двухсторонняя модель: когда руководство компании спускает ключевую цель на квартал сверху, а команды снизу ставят для себя поддерживающие верхнюю 3−5 целей и определяют ключевые результаты — измеримые показатели, определяющие достижение каждой цели.
Например, цель команды — реализовать запланированную продуктовым менеджером функциональность. Ключевые результаты: а) план сделан на 80% и выше; б) количество критических ошибок после выпуска равно 0.
Важно проверить, что команды участвовали в постановке целей, понимают их связь с тем, куда двигается компания, принимают их как первоочередные и важные и разделяют. Это можно сделать, например, через выборочные опросы (часто их проводят HR). Косвенный признак проблем с пониманием целей — отсутствие мотивации и инициативы снизу.
Это включает и работу с методологией управления проектами. На этом этапе у нас уже должна быть управленческая команда, в которой нет явных конфликтов, а есть базовая симпатия людей друг к другу.
Обычно все решения, которые принимаются и спускаются сверху, вызывают у людей сопротивление. Поэтому при пересмотре и стандартизации процессов важно максимально использовать влияние, личный авторитет, а не власть. Власть — это то, на что мы формально имеем право. А влияние — это когда люди за нами идут, потому что верят в то, что руководители — профессионалы и знают, что делают, что с ними сотрудникам лучше, чем без них.
Задача руководителя — не только подсветить проблему и показать ее важность, но и сделать ее понятной и достаточно очерченной, ограниченной рамками. Тогда люди с удовольствием сами ее решат.
Пример. Руководитель компании придумал свой процесс ведения проектов, не посоветовавшись с локальными менеджерами. Сверху пришло распоряжение, что отныне нужно делать вот так, и это не обсуждается. Процесс был очень сложным и трудоемким, люди в командах стали возмущаться, потому что он требовал от них большой работы по документации мелких активностей, к тому же важно было правильно вносить в систему множество данных, что постоянно вызывало путаницу. Это отнимало много времени от написания кода.
Локальные менеджеры выяснили, что цель нового процесса — необходимость точно считать время, потраченное на разработку и тестирование на каждом из этапов производства продукта. Тогда они предложили свой вариант решения проблемы, учитывающий особенности команд и возможности по перераспределению ответственности, о которых руководитель не знал.
В результате получилось считать не только нужные бизнесу цифры, но и собирать еще много полезной дополнительной информации, благодаря которой команды смогли улучшить производительность и эффективность. Люди следовали новому процессу даже там, где это требовало некоторых усилий, потому что они сами его придумали и понимали четко, зачем.
В случаях, когда не нужно изобретать велосипед и задача является стандартной, решенной другими уже множество раз, стоит действовать наоборот: сначала предложить процесс, а потом попросить на него обратную связь и скорректировать. К таким случаям, например, относятся:
Этот этап не имеет завершения, он должен превратиться в процесс постоянного совершенствования (модный нынче «кайдзен»).
Как правило, все вопросы, связанные с текучкой кадров, с концентрацией экспертизы в руках ограниченного круга людей, с мотивацией и страхом перед ошибками и т.п. решаются через:
1. Внедрение и распространение менторства, обучения и системы управления знаниями.
2. Определение и распространение культурного кода — набора простых правил, основанных на ценностях. Они должны давать ответ на вопросы:
3. Создание и поддержание атмосферы доверия.
4. Построение системы обратной связи.
5. Системную работу на всех уровнях управления с ответственностью, делегированием, оценкой и вовлеченностью.
Ну и, наконец, я считаю, что любой руководитель с самого начала должен готовить себе замену так, чтобы в случае его выхода из компании все, что было построено, продолжало работать без сбоев.
16 октября
Компания МиСофт объявляет о проведении масштабной конференции о цифровизации бизнеса в Минске
15 октября
Расширяйте свой бизнес с «ШиреКруг» от Белагропромбанка
14 октября
Проверьте свой сайт: SOC hoster.by раскрыл цепочку взломов интернет-магазинов
8 октября
КАК НАЛАДИТЬ НЕТВОРКИНГ И УВЕРЕННО ЗАЯВЛЯТЬ О СЕБЕ: воркшоп по самопрезентации от команды "Про бизнес", 25 октября
7 октября
Суперакция на размещение рекламы на Про бизнес до 31 октября — не пропустите!
4 октября
Сотрудники банка пришли на работу вместе с животными, а клиенты поддержали благотворительную акцию Pet friendly
3 октября
«Айгенис» представляет интересы «Активлизинг» как эмитента облигаций на фондовом рынке Беларуси
2 октября
Банковское кредитование и альтернативные инструменты: все возможности финансовой поддержки бизнеса на одной площадке Ярмарки Финансирования