Плоская структура для центров компетенций в ИТ: зачем и как не разбиться
Классический центр компетенций устроен как иерархия: специалисты сгруппированы в отделы, над каждым — руководитель, над всеми — директор. Заявка от заказчика проходит длинную цепочку согласований, а нестандартный вопрос рискует «упасть между стульями», пока его директивно не закрепят за кем-то. Плоская структура предлагает другое: убрать средний управленческий слой и построить работу вокруг экспертизы, а не вокруг подчинения.
Почему ИТ — идеальная среда для плоской модели Центр компетенций по своей природе — уже не силос, а пул экспертов, которых собирают под задачи. ИТ-специалисты привычны к таск-трекерам, самоорганизации и асинхронной коммуникации — в отличие, скажем, от бухгалтерии, где плоская модель ляжет тяжело. Профессия сама требует самостоятельности и глубокого погружения в задачу, а плотность талантов в ИТ традиционно выше, чем в большинстве функций.
Как это выглядит на практике
Вместо отделов — круги. Backend, интеграция, Data, DevOps — не отделы с начальниками, а сообщества экспертов вокруг компетенции. Специалист может состоять в двух-трёх кругах сразу; состав и набор кругов пересматриваются под новые технологии и вызовы.
Задачи — через систему, а не через руководителя. Заказчик создаёт заявку, видит, кто взял её в работу, и оценивает результат. Критично: систему управления задачами нужно внедрить до перехода, чтобы она стала привычным ритуалом. Без такого инструмента плоская структура — не модель, а хаос.
Лидеры вместо руководителей. Лидер круга — эксперт, который развивает компетенцию и распределяет задачи, но не подписывает отпускные и не проводит встречи один на один как начальник. Административные функции уходят директору центра или в общий сервис.
Партнёры в бизнесе. Выделенные ИТ-партнёры, «сидящие» в продуктовых командах и на ключевых совещаниях заказчиков, — своего рода «head of IT» направления без прямых подчинённых. Это решает главную боль любого ЦК: дистанцию от заказчика.
Наставники. У каждого нового сотрудника — наставник из числа старших специалистов: он не руководит коллегами, но несёт функцию передачи экспертизы и поддержания стандартов.
Что придётся честно признать У модели есть цена. Во-первых, карьера: привычный путь от джуниора к тимлиду и руководителю отдела исчезает, амбициозных сотрудников удерживать сложнее — нужна альтернатива в виде грейдов, технического трека, роли архитектора. Во-вторых, бывшие тимлиды почти всегда воспринимают потерю административной власти как понижение — это самая болезненная часть любого перехода. В-третьих, модель требует зрелости команды: если в центре много джуниоров, нагрузку и качество придётся балансировать принудительно — а это возврат иерархии через заднюю дверь.
Кому и когда стоит Плоская структура проваливается, когда её тиражируют сверху на всю компанию одним регламентом. Рабочий формат — пилот: одна функция, 30–100 человек, зрелая команда и настроенная система управления задачами до старта, а не после. Полностью от вертикали отказываться не нужно — остаётся компактный «скелет»: директор функции, партнёры, старшие специалисты. Итог простой: плоский центр компетенций — это не «отмена руководителей», а перенос управления из людей в систему. ИТ — та среда, где для этого уже есть всё, кроме, пожалуй, готовности руководителей остаться экспертами.
#ит #оргструктура #центркомпетенций #управление #agile #менеджмент #организация #плоскаяструктура
· вчера
Характер IT-проектов и специфика их реализации напрямую определяет оргструктуру компании. Масштаб, сложность, сроки и гибкость процессов задают выбор типа матричной структуры: слабой, сбалансированной или сильной. Для небольших типовых задач подходит слабая матрица, а для крупных комплексных продуктов — сильная. Однако бывают исключения: например, перспективную продуктовую разработку эффективнее централизовать.
В начале 2010-х, в Техносерве, сильная матрица обеспечивала 80% выручки на крупных комплексных проектах. Организационная структура проекта строилась на пересечении векторов. Границы горизонталей регламентировал продуктовый каталог, где были зафиксированы ФИО. Вертикали делились по стадиям: на пресейл (MVP), проектирование, реализацию, поддержку. Каждую вертикаль возглавлял директор департамента с замом. За конкретный этап проекта отвечал тандем: директор (или зам) и ключевой специалист (ФИО), чья доля работ или бюджета на этапе была максимальной, но его кандидатуру утверждали директор департамента и KAM проекта. Выбранный специалист полностью отвечал за проект на этапе, ставил задачи остальным участникам, лично принимал результаты с предыдущей стадии и сдавал проект на следующую.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· вчера
Вертикали с директорами на каждый этап выглядят избыточно. Конфликты между «колодцами» этапов неизбежны: требования уплыли, непонятно, кто виноват и кто переделывает. Самый перегруженный колодец — реализация: на неё приходится основная доля бюджета и людей, она копит все долги ошибок предыдущих стадий, а ключевые специалисты становятся узким местом всей компании. И самое узкое место — передачи между этапами: на стыках встречаются два директора с двумя разными KPI, и там, где проектировщики сдали «как поняли», реализация принимает «как написано». Ответственность за результат в этом моменте размывается, а решения по расхождениям всё равно замыкаются на вертикаль — то есть главный источник задержек остаётся на месте.
2
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· вчера
Георгий, Вы правы про риски «колодцев» в Agile, но эта избыточность — защита от убытков. Структура гарантирует глубокий фокус на контроле рисков каждой стадии. Профильные лидеры: Директор по пресейлу — главный по MVP, директор по проектированию — главный ГИП, по реализации — главный РП, по поддержке — Service Management Lead. Руководители экспертны в своих областях и не распыляются.
По качеству выстраиваются четкие границы и фильтры. Фильтр приемки защищает этап, принцип простой: «Не принял этап — обоснуй, а принял — делай». Проектировщики не сдадут сырую работу, ведь реализация её не примет, защищая свой KPI. Вся переделка и затраты остаются на предыдущем колодце, в его бюджете и сроках. Но и самое важное, сдача/приемка заставляет команды предметно спорить и расти. Профессионализм проявляется именно в деталях на стыках и защищает от хаоса.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён