Почему сильных инженеров недостаточно
Когда я только начинал работу в ИТ, мне казалось, что 90% успеха составляют сильные инженеры и хороший технологический стек. Но, поработав больше 20 лет в разных компаниях, я пришел к пониманию, что даже команды, состоящие из талантливых инженеров, очень часто испытывают проблемы. Они отстают от сроков, не справляются с поставленными перед ними задачами и нередко делают не очень хороший продукт. К сожалению, дело здесь не в людях.
Тему организационного дизайна я хотел бы раскрыть через одну историю. Но прежде чем к ней перейти, определимся, что вообще такое организационный дизайн.
Организационный дизайн – это процесс проектирования организационной структуры, процессов, а также распределения людей, ролей и полномочий таким образом, чтобы все это отвечало стратегическим целям компании.
Моя история основана на реальных событиях, но имена героев в ней изменены. Иногда это просто собирательные образы.
Небольшая команда: скорость, гибкость и первые риски
Представим 2010 год. Двое друзей, Максим и Денис, решают открыть свой бизнес по продаже мобильных телефонов. Буквально в течение первого года они открывают несколько торговых точек, а к концу второго года их компания уже состоит из нескольких подразделений.
Полномочия распределяются следующим образом: Максим берет на себя продажи и маркетинг, а Денис – закупки, персонал, финансы и, конечно же, ИТ.
ИТ-подразделение к концу второго года работы компании состоит из двух команд. Одна занимается инфраструктурой, серверами и администрированием, вторая – разработкой и внедрением решений на платформе 1С.
Команду 1С возглавляет тимлид по имени Степан. В ней шесть человек, включая самого Степана. Он практик, играющий тренер и сам вместе со своей командой занимается разработкой.
Что хорошо в такой модели?
-
Высокая гибкость и скорость реакции,
-
Тесная коммуникация,
-
Взаимозаменяемость,
-
Легкая управляемость,
-
Мало бюрократии, решения принимаются быстро,
-
Все находятся в едином информационном поле и одном контексте.
Но какие проблемы и риски здесь заложены? Первый – риск потери экспертизы. В такой маленькой компании и команде даже один уходящий человек уносит с собой довольно весомую часть общей экспертизы.
Второй риск – выгорание как обратная сторона взаимозаменяемости, когда тебе нужно делать все и желательно сразу. Кроме того, это приводит к ухудшению качества документации и ревью, росту техдолга и строительству монолитов.
Тезис о строительстве монолитов может быть неочевидным, поэтому поясню его с помощью закона Мелвина Конвея. Он говорит о том, что организации проектируют системы, которые копируют структуру коммуникаций этих организаций.
Системы на платформе 1С зачастую изначально являются монолитными. Когда ими занимается одна небольшая команда, она естественным образом продолжает развивать этот монолит, еще сильнее его усложняя.
Первый кризис роста
Что происходит дальше? Начинается рост. Компания открывает новые торговые точки, запускает B2B-сегмент, появляются первые корпоративные клиенты. Вместе с этим возникает новый кризис.
Для команды Степана он выглядит так: команда перегружена, постоянно переключается между задачами, качество ухудшается, а сроки срываются.
Причина достаточно очевидна – задач стало больше. Розничное направление требует новых фичей, запускаются маркетинговые акции. Бэк-офис хочет стабильности: закрытия месяца без срыва сроков и достоверной управленческой отчетности.
Руководство компании требует от Максима и Степана что-то придумать, чтобы команда вернула прежнюю скорость и справлялась с возросшим объемом поступающих задач.
Степан изучает эту тему через теорию и приходит к достаточно известному закону Литтла из теории массового обслуживания. Он устанавливает взаимосвязь между средним количеством задач в работе, пропускной способностью команды и средним временем цикла одной задачи – cycle time.
Степану кажется достаточно очевидным решением нанять больше людей, чтобы быстрее выпускать фичи в прод. При этом не увеличивать количество задач, одновременно находящихся в работе.
Именно такое решение он предлагает руководству. Оно кажется довольно убедительным. Идею принимают, нанимают новых людей, и через некоторое время команда Степана вырастает. Но внезапно все становится не лучше, а хуже.
Почему увеличение команды не увеличило скорость
Прежде всего размывается ответственность. В психологии существует эффект диффузии ответственности: чем больше людей вовлечено в работу, тем слабее каждый отдельно взятый человек чувствует личную ответственность за результат.
Возникают конфликты – не только межличностные, но и конфликты за ресурсы. Те, кто занимается разработкой на 1С, наверняка сталкивались с тем, что при выполнении разных задач разработчики часто конкурируют за доступ к одним и тем же объектам метаданных.
В результате рост команды приводит не к увеличению, а к снижению скорости и к управленческой перегрузке.
Здесь стоит вспомнить закон Брукса: добавление рабочей силы в проект, который уже отстает от сроков, приводит к еще большему отставанию.
Это хорошо демонстрирует формула, показывающая, как количество каналов коммуникации связано с числом участников команды. Формула очень простая, но, когда подставляешь в нее значения, иной раз приходишь в ужас.
В команде из 12 человек – именно столько сотрудников стало у Степана после расширения – количество каналов коммуникации составляет 66. Это 66 возможных вариантов взаимодействия между всеми людьми.
Также стоит упомянуть закон Миллера. Он говорит о том, что кратковременная человеческая память, как правило, может удержать семь плюс-минус два элемента, то есть от пяти до девяти.
Казалось бы, какое отношение это имеет к командам? Самое прямое. Когда команда из такого количества человек собирается на дейли митинги и каждый рассказывает, чем занимается, отдельный участник к концу встречи вряд ли вспомнит, о чем вообще шла речь. И вряд ли сможет кому-то чем-то помочь.
Переход от функциональной модели к доменной
К чему в итоге приходит компания Максима и Дениса? К тому, что необходима реорганизация. Наконец они приходят к этому важному пониманию и переходят от функциональной модели управления к доменной.
Происходит деление одной большой монолитной команды на три доменные команды, в каждой из которых внедряется Agile-фреймворк Scrum. Это не просто организационное изменение, а фундаментальная смена парадигмы.
Она требует от каждого участника команды, в том числе от Степана, нового взгляда и нового мышления. Теперь Степану необходимо не просто управлять командой, а координировать работу целой экосистемы доменных команд.
Сами доменные команды становятся мини-стартапами. Каждая несет свою миссию, отвечает за определенную доменную область и приносит бизнес-ценность.
В новой картине мира Степан становится руководителем подразделения из трех команд. Такая перестройка требует от него и от всех сотрудников серьезных усилий, вложений и инвестиций. Она не дается даром, и некоторое время команда действительно испытывает проблемы.
Но спустя примерно год становятся заметны эффекты изменений. Во-первых, яснее зоны ответственности. Во-вторых, становится меньше переключений и выше предсказуемость. И, как вишенка на торте, происходит естественный уход от монолитов.
Почему происходит этот уход? Возвращаемся к закону Конвея. Становясь автономными, команды стремятся закрепить эту автономию в архитектуре. Они уходят от монолита как минимум к модульному монолиту, а в некоторых случаях – к отдельным сервисам.
Обратная сторона автономии
Однако и здесь не обходится без проблем. Через некоторое время Степан снова берется за голову: возникают новые сложности.
Во-первых, необходимо синхронизировать три новые команды.
Технические задачи «гуляют» между командами, и каждая отвечает: «Это не мое, это не мой домен».
Экспертиза распределяется неравномерно: в одной команде инженеры сильнее, в другой – слабее.
Обособленность и дублирование. Возникает и побочный эффект автономии: команды начинают каждая по-своему изобретать велосипеды.
Размышляя о том, как решить вопрос синхронизации, Степан вместе с командой и руководством рассматривает три фреймворка масштабирования Scrum: SAFe, Nexus и LeSS.
Но ни один из них внезапно не подходит. SAFe и Nexus рассчитаны на очень большие масштабы, а LeSS – на общий бэклог, которого в случае команды Степана нет.
В итоге принимается решение применять достаточно простой фреймворк Scrum of Scrums, в котором команды синхронизируют свои планы и заранее разрешают зависимости. Кроме того, решают выделить одного архитектора на три команды.
Архитектор как связующее звено и единая точка отказа
На сцену выходит Семен – архитектор, который должен помогать с интеграциями, определять технические стандарты и решать сложные задачи, которыми не могут заниматься доменные команды.
Через некоторое время становится заметен эффект таких изменений. Во-первых, появляются единые стандарты. Во-вторых, улучшается кросс-командная координация, потому что архитектор выступает связующим звеном и помогает довести сквозные инициативы от начала до конца через несколько команд.
Снижается архитектурный долг и уменьшаются операционные риски. Что здесь имеется в виду? Доменные команды часто не думают о том, что нужно заниматься бэкапами и инфраструктурой. Архитектор уделяет этому внимание. В том числе он занимается вопросами безопасности и регуляторными рисками, например защитой персональных данных.
Но спустя время снова возникают проблемы. Команды ждут консультации архитектора, а сам архитектор становится единой точкой отказа.
Происходит частичная потеря ответственности доменных команд. Они все чаще говорят: «Это не ко мне, это к архитектору. Это слишком сложно».
Возникает риск выгорания и у самого архитектора, который превратился в бутылочное горлышко, и у инженеров в командах. Они хотят быть сопричастны к чему-то важному, интересному и сложному, но им остаются менее интересные задачи.
Здесь вспоминается Голдратт Элияху и его теория ограничений. Она говорит о том, что производительность любой системы ограничена одним или несколькими бутылочными горлышками, а не суммой возможностей всех ее частей.
В данном случае архитектор невольно становится одним из таких бутылочных горлышек, хотя, конечно, не единственным.
Технические лидеры и распределение экспертизы
Спустя время команда Степана и руководство приходят к следующему решению. Как минимум, необходимо заранее учитывать эту особенность и синхронизировать планы.
Кроме того, во всех командах нужно ввести технических лидеров, чтобы внутри каждой команды появилась ответственность за техническую часть.
Когда проектируются какие-то решения, техлиды должны участвовать в этом процессе и оформлять архитектурные решения – ADR.
Примерно через полгода становится заметен эффект: меньше простоев, выше предсказуемость, команды лучше попадают в цели.
Происходит распределение и накопление экспертизы. Теперь она сосредоточена не только в одном человеке – архитекторе.
Team Topologies и появление платформенной команды
Спустя некоторое время компания Максима и Дениса проходит очередной виток роста, ставит перед собой новые амбициозные цели и понимает, что даже эта новая, казалось бы, зрелая модель перестает работать.
Тогда организация рассматривает свою работу через призму фреймворка организационного дизайна Team Topologies.
Этот фреймворк говорит о том, что ускорения поставки ценности необходимо добиваться через снижение когнитивной нагрузки, улучшение организационных взаимодействий и распределение зон ответственности.
Как это предлагается делать? Фреймворк выделяет несколько типов команд. Нужно посмотреть, какие из них уже существуют в организации, и подумать, какие команды необходимо добавить.
Это потоковые команды, команды сложных подсистем, платформенные и поддерживающие, или фасилитирующие, команды.
Потоковые команды создают ценность для бизнеса. Назначение команд сложных подсистем понятно из названия. Платформенные команды создают инструменты для потоковых команд, чтобы упростить их работу и снизить когнитивную нагрузку. Поддерживающие, или фасилитирующие, команды помогают другим командам внедрять процессы, например Agile.
В итоге принимается решение создать платформенную команду, в которую переходит архитектор, а также инженеры, интересующиеся DevOps-процессами и SRE.
Функционал этой команды состоит в том, чтобы реализовывать библиотеки, инструменты, CI/CD-пайплайны, системы мониторинга и заниматься стандартами разработки.
Спустя некоторое время снова становится заметен эффект от появления такой команды. Другие команды начинают переиспользовать готовые решения и перестают изобретать велосипеды, как это было раньше.
Сокращается cycle time – время цикла, время выполнения задач. У потоковых команд появляется больше фокуса на ценности: их основной задачей становится доставка бизнес-ценности своему стейкхолдеру.
Чтобы немного резюмировать все вышесказанное, можно использовать небольшой фреймворк самодиагностики и задать себе вопросы о текущем состоянии организации.
Если хотя бы на несколько из них, даже на пару-тройку, ответ будет «да», скорее всего, стоит задуматься, не пора ли что-то сделать с организационным дизайном.
Организационный дизайн должен соответствовать этапу роста
В завершение хотелось бы сказать, что организации, как правило, не разрушаются от плохого кода или какой-то кривой архитектуры.
Они разрушаются из-за того, что используют устаревшие подходы и не меняются тогда, когда это необходимо.
Каждый этап роста организации требует пересмотра организационного дизайна. И вопрос даже не в том, насколько хороша или идеальна ваша текущая организационная структура.
Не существует единственной идеальной организационной структуры и единственного идеального организационного дизайна.
Вопрос в другом: подходит ли текущий организационный дизайн той компании, которой вы являетесь сегодня? А еще лучше – той компании, которой вы хотите стать завтра?
Книги об организационном дизайне
В завершение хочу порекомендовать несколько книг, которыми я в свое время вдохновлялся, когда сталкивался с вопросами организационного дизайна и не только.
Это «Team Topologies», книга Элияху Голдратта «Цель» и книга по предметно-ориентированному проектированию Влада Хононова.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
