Как выстраивать архитектуру ролей: от стратегии к людям

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

Настоящая работа начинается с проектирования. Причём не людей — а логики.

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

Вот как она выглядит:

🔹 Шаг 1. Зачем?
Фиксируем стратегическую цель. Не абстрактно — конкретно: что меняется в системе? Куда она направлена, и что ей нужно обеспечить?
Пример: компания выходит на новые рынки.

🔹 Шаг 2. Что создаёт ценность?
Что конкретно будет давать результат в этой стратегии? Не функции, а механизм ценности.
В примере с выходом на рынок: способность масштабироваться быстро, без перегрузки центральной системы, с минимальной фрагментацией.

🔹 Шаг 3. Как?
Через какие процессы создаётся эта ценность? Какие связи, ритмы, потоки нужно обеспечить, чтобы всё заработало?

🔹 Шаг 4. Где?
Где в структуре должна находиться ответственность? Не просто «у кого в должностной инструкции», а в какой точке система удерживает это усилие. Кто сопрягает с другими функциями? Кто ведёт?

🔹 Шаг 5. Кто?
Вот теперь можно говорить о ролях. Какие именно динамики должны поддерживать эти процессы? Какие паттерны мышления, поведения, навыки и тип связи с другими нужны? Кто может это держать?

🔹 Шаг 6. Сколько?
Какие метрики показывают, что роль работает? Что мы считаем результатом: скорость, стабильность, отказоустойчивость, clarity?

Этот порядок кажется очевидным — но на практике его почти никто не соблюдает.
Чаще — наоборот: у нас есть Вася, Вася что-то делает, давайте оформим это в табличку.

📌 А потом оказывается, что мы строим компанию не от цели, а от имеющихся людей. И когда стратегия меняется, вся архитектура осыпается — потому что её не было.

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

Крупный бизнес мы разберем отдельно и посмотрим, где важны становятся детали.

А в следующем посте я покажу, как по этой логике проверить системные дыры («все подумали, что это делает кто-то другой»). Где нет сопряжения между функциями. Где система не держит ответственность. И закрываем ли мы эти дыры наймом или объединением ролей в одной должности.