Почему оргструктура AI-компании ломается на росте
Пока в команде пять-восемь человек, оргструктура AI-компании существует только на словах: решения принимает основатель, задачи расходятся по знакомым, и такая схема даёт максимальную скорость. Отказ начинается позже — когда появляется вторая продуктовая линия, отдельный контур данных и первые клиенты с требованиями к качеству.
Первым ломается разделение зон ответственности. Подготовка данных, обучение модели, оценка качества и внедрение — четыре разные компетенции, но границы между ними не прочерчены. Вопрос «кто отвечает за падение качества модели в продукте» не имеет адресата — деградацию замечает клиент, а не команда.
Второе узкое место — согласования. Доступ к данным, смена приоритета, выпуск в продукт, найм: всё сходится к одному человеку. Очередь решений растёт до нескольких дней, инженеры либо простаивают, либо обходят процесс и договариваются напрямую, теряя общую картину.
Дальше — перегрузка руководителя. Он одновременно ведущий инженер, владелец продукта и владелец найма: контекст переключается каждый час, стратегические задачи вытесняются срочными, и качество решений падает там, где цена ошибки максимальна.
Наконец, конфликт приоритетов. Команда исследований и команда внедрения делят одни ресурсы — доступ к разметке, вычислительные мощности, время сильных инженеров. Без формального арбитра спор выигрывает тот, кто громче.
Разбираем, как это закрывается: какие роли вводить на каждом этапе роста, где проходит граница ответственности и как устроена эскалация, не возвращающая всё к основателю.
Что меняется после перестройки модели управления
Первое, что становится заметно, — срок согласования решения. Пока вопрос проходит несколько уровней, он живёт в переписке и ждёт чужого окна в календаре. После перестройки у каждого класса решений появляется один владелец и заранее записанные границы полномочий, поэтому типовое решение закрывается не за дни, а за часы.
Второй измеримый эффект — доля решений на уровне команды. Когда границы ответственности описаны, семь из десяти вопросов не выходят за пределы команды: их не нужно ни с кем согласовывать, достаточно зафиксировать в журнале решений. Наверх уходят только те, что меняют архитектуру продукта или обязательства перед заказчиком.
Из этого вырастает скорость вывода продукта: цикл выпуска сокращается с кварталов до недель при том же объёме проверок. Самая длинная часть работы — ожидание согласований — перестаёт быть узким местом, и команда тратит время на продукт, а не на переписку.
Отдельная метрика — повторные эскалации, то есть доля задач, которые возвращаются наверх с тем же вопросом второй раз. Она падает почти до нуля, когда у эскалации есть один адресат и правило, по которому решение принимается. Раньше один и тот же вопрос поднимали по кругу, потому что ответ нигде не фиксировался.
И последнее: уходит целый класс отказов — решения, зависшие без владельца. Такое решение просто не принималось, а выяснялось это уже на этапе выпуска. Теперь у каждого шага есть имя и срок, поэтому «повисших» пунктов в плане развития не остаётся.
Сравнение моделей управления и режимов эскалации
Выбор схемы управления определяет не то, как рисуется иерархия на схеме, а то, куда уходит спор о приоритетах и кто держит финальное решение по инциденту. На старте, когда продукт один, любая из моделей работает — расхождения начинаются на втором-третьем направлении, когда общие данные, платформа и разметка нужны сразу нескольким командам.
| Схема | Когда подходит | Где начинает тормозить |
|---|---|---|
| Функциональная модель | Один продукт, общий конвейер данных, команды собраны по компетенциям: модели, данные, инфраструктура | Появляется второе направление — задачи встают в очередь между функциями, продукт ждёт в чужих приоритетах |
| Продуктовая модель | Два-три продукта с разными пользователями, нужна скорость решений внутри команды | Дублирование компетенций, расхождение стандартов разметки и оценки качества между командами |
| Матричная структура | Продукты разные, но платформа, данные и инфраструктура общие | Двойное подчинение размывает ответственность, конфликт руководителей решается в переписке |
| Гибридная схема управления | Продуктовые команды плюс общая платформа и совет по стандартам | Работает только при прописанных владельцах решений и сроках эскалации |
Эскалация: что фиксируем в регламенте
В любой из схем эскалация должна иметь тайм-аут: если владелец решения не ответил в оговорённое время, вопрос автоматически поднимается на уровень выше, а не ждёт его возвращения. Отдельно фиксируем, кто владеет качеством данных, кто — релизом модели, кто — приоритетом доработок: без этого матрица превращается в переписку, а продуктовая модель — в параллельные правки одного и того же конвейера.
Схему выбирают по числу продуктов и объёму общих ресурсов, а переходят между ними поэтапно — переносим одну команду, смотрим на время принятия решений и число незакрытых эскалаций, и только потом двигаем остальные. Так смена модели управления не останавливает разработку.
Этапы перестройки управления и правил эскалации
Перестройка управления начинается не с новой схемы подчинения, а с картины того, кто реально принимает решения. Мы собираем её из интервью с участниками и разбора закрытых задач и инцидентов: важна фактическая практика, а не то, как роли описаны в документах. Дальше последовательность повторяется от проекта к проекту, меняется только глубина проработки.
- Аудит ролей. Фиксируем классы решений — от выбора данных до приёмки результата — и отмечаем фактического владельца каждого. На выходе список решений без владельца и решений, где владельцев двое.
- Схема потоков решений. Рисуем путь решения от постановки до выпуска: где оно останавливается на согласовании и сколько ждёт. Обычно находится 2-3 точки простоя без причины.
- Матрица ответственности. Для каждого класса решений фиксируем, кто решает, кого спрашивают и кого только информируют. Один класс решений — один решающий, иначе спор возвращает задачу в начало.
- Карта эскалации. Задаём уровни, сроки реакции и правило: нет ответа дольше срока — решение поднимается выше автоматически. Задачи перестают ждать неделями.
- Регламент передачи задач. Определяем, что переходит вместе с задачей: контекст, критерии готовности, владелец, точки эскалации. Передача перестаёт зависеть от памяти конкретного человека.
- Проверка на живой задаче. Прогоняем реальную задачу по новым правилам и замеряем время прохождения решения, число касаний и эскалаций. Правки вносим сразу, а не после запуска.
- Передача. Отдаём схемы, матрицу и регламент команде, назначаем владельца процесса и точку, куда смотреть при отклонениях.
После передачи правила живут в документации и в разборе задач, а не в голове руководителя — поэтому структура не откатывается к прежней через месяц.
Матрица ответственности и регламенты эскалации
Отдаём не презентацию про ценности, а рабочий комплект, по которому команда живёт без нас. Каждый документ закрывает конкретный вопрос: кто решает, к кому идти, когда решение застряло. Проверяем на живых спорных ситуациях и правим формулировки, пока они не станут однозначными.
- Матрица ответственности — по каждому процессу, от постановки задачи на модель до вывода результата в продукт, видно: кто исполняет, кто согласует, кто отвечает за итог и кого держат в курсе. Заполняется по фактическим ролям, а не по должностям из штатного расписания.
- Описание роли — зона ответственности, границы полномочий, что роль принимает на вход и что отдаёт дальше, по каким метрикам её работу оценивают. Отдельным блоком — что роль не делает, чтобы не возникало двойного подчинения.
- Регламент эскалации — уровни обращения, срок реакции на каждом, что считается поводом поднять вопрос выше и к кому идти, если владелец решения недоступен.
- Схема принятия решений — дерево от типа вопроса (качество модели, изменение продукта, инфраструктура, приоритеты) до уровня, где решение закрывается, плюс условие, при котором оно возвращается на пересмотр.
- План перехода — по этапам: кто дублирует роль на переходном периоде, в какой момент дублирование снимается и где стоят точки контроля.
- Шаблоны и правило пересмотра — карточка решения, протокол разбора сбоя и триггеры, по которым структуру пересматривают: рост обращений выше уровня, задержки на согласовании, появление нового направления.
Кейс: перестройка управления в продуктовой команде
До: очередь решений на одном человеке
Продуктовая команда из 40 человек, три направления — модели, данные, аналитика. Роли формально были, но решения стекались к руководителю: приоритеты, релизы, доступы, найм. В Jira висело в среднем 26 задач в неделю с пометкой «нужно решение владельца», среднее время согласования — 9 дней. Почти каждый третий вопрос возвращался на второй круг: зона ответственности не закреплена.
Дублирование ролей добивало картину — две пары «владельцев модели», аналитик и дата-инженер делили один отчёт. Люди не понимали, кого слушать, и текучесть в командах доходила до 28% в год: уходили сильные инженеры, которым надоело ждать.
После: три уровня эскалации
Развели три уровня решений: технические — на владельце направления, продуктовые — на владельце продукта, межкомандные — на архитектурном совете раз в неделю. На руководителя эскалировалось только то, что меняет состав команд или бюджет. Пересечения ролей убрали: каждую зону закрепили за одним человеком, спорную — за владельцем с правом вето. Регламент эскалации уместился на одну страницу.
Очередь на руководителе — с 26 до 6 задач в неделю, время согласования — с 9 дней до 2. Дублирующих ролей не осталось, текучесть в командах упала с 28% до 11% за год, доля вопросов, вернувшихся на второй круг, — с 30% до 7%.
Что делать, если оргструктура уже есть, но эскалация буксует?
Если эскалация буксует, формальная схема почти всегда описывает не то, что происходит в работе. Спорные решения по модели, данным и приоритетам стекаются к одному человеку, а очередь на согласование растёт независимо от числа уровней на схеме. Первый шаг — снять фактическую карту решений: кто принимает, кто может остановить, к кому идут, когда формальный владелец молчит.
Дальше почти всегда находятся теневые роли. Человек без полномочий фактически решает судьбу выпуска, потому что он единственный понимает модель или владеет доступом к данным. Пока эти роли не названы явно, любая перестановка обходит их стороной, и через месяц очередь возвращается на прежнее место. Перегруженный руководитель здесь не причина, а индикатор: он держит решение, потому что стык между зонами никому не отдан.
Пересборка без остановки работы идёт по одному правилу: сначала фиксируются маршруты решений, потом меняется схема подчинения. Для каждого класса решений назначается владелец, критерий «решаю сам» и точка эскалации с явным сроком. Пока новый маршрут не проверен на реальных задачах, старый продолжает действовать — параллельно, с датой переключения.
Переходный период — самая рискованная часть. Две роли могут временно сосуществовать у одного человека, но у каждой свой набор полномочий и признак завершения: доля вопросов, уходящих наверх, падает, типовые решения закрываются на уровне владельца. Когда признак держится несколько циклов планирования, схему можно считать рабочей, а не нарисованной.
Частые вопросы о ролях, эскалации и перегрузке
Переход к новой оргструктуре ломается не на схеме, а на людях: у руководителей меняются зоны ответственности, у команд появляется второй канал эскалации. Ниже — сомнения, которые чаще всего звучат до старта, и как мы закрываем их на практике.
Команды сопротивляются новой структуре — что делать?
Сопротивление идёт не от самой роли, а от неясности: кто принимает решение и куда эскалировать. Начинаем с матрицы решений — по каждому классу задач фиксируем владельца и тех, кого информируют. Когда границы становятся явными, разговор переходит с «зачем это» на настройку переходного периода.
Как не получить дублирование функций?
Дублирование появляется там, где роль описана через активность, а не через результат. Разводим функции по артефактам: у каждой свой выход и свой критерий готовности. Если два подразделения претендуют на одну задачу, спор решает владелец процесса, а не эскалация наверх. Карту ролей пересматриваем раз в квартал.
Можно ли внедрять структуру постепенно?
Сначала оцениваем зрелость управления: есть ли владельцы процессов, работает ли регламент эскалации, собираются ли метрики по факту, а не по отчётам. Дальше берём одно подразделение, переводим его целиком, стабилизируем несколько недель — и только потом тиражируем на остальные. Так ошибки проектирования остаются в одном контуре и не расходятся по всей компании.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы вернуться с планом, а не с общими словами, нам нужен короткий срез вашей ситуации: сколько людей в команде, как сейчас распределены роли — от исследований и подготовки данных до внедрения и поддержки, где решения застревают и на каком уровне чаще всего останавливается задача. Достаточно описать текущую схему и главную проблему: параллельные мандаты, отсутствие владельца результата, эскалация «через знакомых» или очередь из согласований перед каждым запуском.
В ответ вы получаете состав работ, порядок этапов и ожидаемый эффект по срокам и качеству решений — без абстрактных обещаний.
- карта ролей и зон ответственности: кто принимает решения, кто исполняет, где мандаты пересекаются;
- план перехода: последовательность этапов от фиксации ответственности до работающей эскалации;
- состав работ по каждому этапу с разделением, что делаем мы, а что остаётся на вашей стороне;
- регламент эскалации: уровни, сроки реакции и пороги, при которых вопрос поднимается выше;
- требования к ролям: какие компетенции закрываем перераспределением людей, какие — наймом;
- критерии проверки: время принятия решения, доля вопросов, закрытых на первом уровне, срок вывода решения в работу.
Опишите задачу в двух-трёх абзацах — вернёмся с оценкой, порядком этапов и планом перехода, который можно запускать без остановки текущих проектов.
