Оргструктура lean-software-компании для команд до десяти человек

Зачем маленьким командам всё равно нужна оргструктура

Со стороны команда из шести или девяти человек выглядит простой. Но внутри всё быстро становится запутанным. Одни и те же люди переключаются между продуктовой работой, поддержкой, продажами, багфиксом и AI-экспериментами, поэтому одна и та же проблема может попасть сразу на три стола и всё равно закончиться без понятного решения.

И вот тут начинается проблема. Общая работа — это нормально. Общая ответственность — нет. Если никто не принимает окончательное решение, задачи расползаются, сроки сдвигаются, а небольшие разногласия превращаются в зависшие релизы.

Особенно это заметно, когда сразу срабатывает несколько рисков. Меняются правила продукта, AI-процесс даёт неправильный ответ, клиент спрашивает, как хранятся его данные, а в production после деплоя появляются ошибки. В маленькой компании все эти проблемы часто касаются одних и тех же людей. Все помогают. Никто не решает.

Оргструктура для lean software company — это не про уровни менеджеров. Это про одно простое правило: у каждой зоны есть один человек, который отвечает за решение, даже если работают над ней другие.

Представьте SaaS-команду из девяти человек. Фаундер всё ещё участвует в звонках с продажами. Инженер параллельно отвечает за инфраструктуру. Product lead пишет ответы в поддержку, когда это нужно. Это нормально. Важно другое: команда должна сразу ответить на четыре вопроса:

• Кто утверждает правила продукта?
• Кто отвечает за поведение AI и ограничения?
• Кто решает, как обрабатываются данные клиентов?
• Кто принимает решение во время проблем в production?

Если ответы на эти вопросы ясны, команда работает быстрее и тратит меньше энергии. Люди перестают мешать друг другу, а тяжёлые недели становятся управляемыми.

Четыре линии ответственности, которые нужно провести в первую очередь

Маленькая оргструктура становится полезной, как только отвечает на один вопрос: кто принимает решение, когда что-то меняется, ломается или требует утверждения?

В команде до десяти человек вам не нужна сложная схема. Вам нужна понятная ответственность в четырёх местах, где путаница обходится дороже всего.

Начните с правил продукта. Этот человек решает, что должен делать софт, что считается корректным поведением, какие крайние случаи важны и когда запрос выходит за рамки задачи. Инженеры, дизайнеры и support могут высказывать мнение. Но окончательное решение всё равно принимает один человек.

Затем назначьте владельца AI-процессов. Речь не только о том, «кто пользуется ChatGPT». Кто-то должен отвечать за инструменты, промпты, выбор модели, этапы проверки и границу между черновиком и утверждённой работой. Без такого владельца люди копируют промпты куда попало, доверяют слабым ответам и создают беспорядок, который потом сложно проверить.

Данные клиентов тоже должны иметь своего владельца, даже в маленькой SaaS-компании. Этот человек решает, у кого есть доступ, как долго данные остаются в системе, как работают выгрузки и что происходит, если клиент просит удалить свои данные. Юридическая консультация может задать правила, но внутри компании кто-то должен следить, чтобы они обновлялись и соблюдались.

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

Эти линии не обязательно требуют четырёх разных людей. В команде из семи или восьми человек один фаундер может отвечать за правила продукта и AI-процессы, а технический lead — за production-риски и данные клиентов. Совместная работа — это нормально. Проблемы создаёт размытая ответственность.

Назначайте людей на решения, а не на должности

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

Начните не с ролей, а с повторяющихся решений. Выпишите те решения, которые ваша команда принимает каждую неделю или каждый месяц. Какие изменения продукта попадут в следующий релиз? Кто может менять AI-процесс в production? Кто утверждает доступ к данным клиентов? Кто решает, делать ли откат после инцидента? Кто даёт согласие на новый внутренний инструмент?

Для каждого такого решения нужен один владелец. Один, не два. Другие могут давать вводные, и это важно. Но окончательное решение принимает один человек, если команда не согласна или времени мало.

Хорошо работает простой формат: решение, кто даёт вводные и кто принимает окончательное решение. Это сильно снижает повседневное трение. Люди перестают ждать группового одобрения на обычные вопросы и точно понимают, кого подключать перед запуском.

Сначала используйте реальные имена. «Sam решает объём релиза» понятнее, чем «Head of Product решает объём релиза», особенно когда Sam ещё ведёт интервью с клиентами и иногда делает QA. Позже имена можно связать с ролями для найма или передачи дел.

Держите эту схему стабильной, даже когда задачи меняются. В маленькой команде рабочие процессы постоянно сдвигаются. Ответственность за решения должна меняться куда реже. Если она меняется каждый спринт, ей никто не верит.

Назначьте ответственность за продукт без лишних уровней

Маленькие команды начинают путаться, когда правила продукта живут в чатах или только в голове у одного фаундера. Назначьте одного человека, который отвечает за цены, лимиты использования и поведение, видимое пользователям. Ему не нужен громкий титул. Ему нужна власть сказать «да», «нет» или «пока нет».

Отделяйте идеи для roadmap от изменений правил. «Нам стоит добавить командный биллинг в следующем квартале» — это идея для roadmap. «У бесплатных аккаунтов теперь три экспорта вместо десяти» — это уже изменение правила. Когда команды смешивают эти вещи, support даёт неверный ответ, инженеры внедряют неправильный дефолт, а sales обещает то, что никто не утверждал.

Зафиксируйте два уровня контроля: кто может менять дефолты и кто может предлагать изменения. В большинстве команд до десяти человек только один человек должен напрямую менять дефолты, а короткий список других — предлагать правки с обоснованием. Уже это сильно снижает ненужную суету.

Срочные запросы клиентов тоже должны идти коротким путём. Support или sales фиксирует запрос. Владелец правил продукта проверяет влияние. Инженеры подтверждают трудозатраты, если нужно менять код. Один утверждающий человек подписывает любое исключение.

Исключения тоже должны иметь владельца. Если клиент просит кастомный лимит, возврат вне политики или доступ к скрытой функции, назовите человека, который может это одобрить. Не оставляйте это на того, кто ответил первым.

В SaaS-команде из девяти человек настройка может быть очень простой: фаундер отвечает за политику ценообразования, product manager — за дефолты, support предлагает изменения, и только фаундер утверждает исключения для крупных аккаунтов. Этого достаточно. Люди двигаются быстрее, когда правила перестают меняться у них под ногами.

Дайте AI-процессам одного понятного владельца

AI может ускорить работу. Но он так же быстро может распространить путаницу. Если никто не отвечает за процесс, люди меняют промпты, переключают модели и доверяют ответам, которые следовало проверить.

Назначьте одного человека, который может утверждать или отклонять изменения. Этот человек выбирает, какую модель команда использует для каждой задачи, какие инструменты могут получать доступ к данным компании и когда изменение промпта нужно протестировать, прежде чем его начнут использовать в реальной работе. В команде до десяти человек это часто фаундер, CTO или инженер, который уже отвечает за delivery.

Выходы, которые видит клиент, должны проверяться по правилам, а не на глаз. Если AI пишет ответы в поддержку, тексты продукта или release notes, назначьте человека, который проверяет результат перед отправкой. Для кода относитесь к AI как к младшему помощнику. Он может предлагать варианты, но разработчик всё равно проверяет, тестирует и утверждает результат.

Обычно хватает короткого набора правил. AI может сам готовить внутренние заметки, резюме и обновления документации. Он может предлагать код, но разработчики проверяют, тестируют и объединяют его. Он может помогать писать ответы в поддержку, но если в вопросе есть детали аккаунта, финальное сообщение отправляет человек. ИИ не должен менять production-системы, если этот путь не утвердил конкретный владелец.

Владелец также должен обозначить точки передачи. Какие-то задачи AI может делать сам. Другие требуют человека каждый раз. Один раз проведите эту границу и заставьте команду ей следовать.

Ведите логи, даже если они простые. Сохраняйте промпт, модель, результат, решение об одобрении и любой странный случай, из-за которого кто-то остановился и проверил ответ. Командам, которые используют больше одной модели — например, Claude для программирования и GPT для черновиков поддержки, — это нужно ещё сильнее. Короткий лог помогает заметить неудачные правки промптов, рискованные привычки и повторяющиеся ошибки ещё до того, как их увидят клиенты.

Защитите данные клиентов простыми правилами

Данные клиентов в маленькой команде очень быстро превращаются в хаос. Один человек выгружает CSV для support, другой вставляет реальные записи в AI-инструмент, и никто не знает, кто должен всё это привести в порядок. Чёткая оргструктура должна остановить такой дрейф.

Сначала назначьте одного человека, который отвечает за три решения: у кого есть доступ, как долго данные хранятся и когда они удаляются. Это не значит, что он сам делает всю работу. Это значит, что никто не спорит о финальном решении, когда запросов на доступ становится много или клиент просит удалить свои данные.

Пропишите, какие роли могут видеть сырые данные клиентов, а какие нуждаются только в маскированных или примерных данных. Здесь важно быть строгими. Большинству людей не нужны полные записи для работы. Инженеры обычно могут тестировать на фейковых аккаунтах. Support часто решает проблему и с частичными данными. Если команда использует AI-инструменты, не передавайте туда живые данные клиентов, если владелец не одобрил именно такой сценарий.

Простая схема должна отвечать на четыре вопроса: кто утверждает доступ к сырым данным клиентов, какие роли могут делать выгрузки, какие инструменты могут получать данные клиентов вне основного приложения и кто действует первым, если кто-то ошибочно поделился данными.

Последний пункт важнее, чем ожидают многие команды. Если подрядчик загрузил не тот файл или фаундер выгрузил слишком много данных, решают минуты. Назначьте первого реагирующего заранее, ещё до того как что-то пойдёт не так. Обычно это тот же владелец или человек, который ведёт production. Он должен знать, кого предупредить, что отключить и как зафиксировать произошедшее.

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

Держите production-риски в одной цепочке командования

Когда production ломается, команде до десяти человек не нужен комитет. Ей нужна одна цепочка командования, которой все доверяют ещё до того, как что-то пойдёт не так.

Начните с рискованных деплоев. Назначьте одного человека, который говорит «да» или «нет», когда изменение затрагивает биллинг, вход в систему, хранение данных или общую инфраструктуру. Ему не обязательно писать весь код. Ему нужен достаточный контекст, чтобы оценить масштаб удара, и достаточно полномочий, чтобы отложить релиз.

Ответственность за on-call должна быть такой же ясной. Один человек ловит первое уведомление, ведёт тред инцидента и решает, когда подключать помощь. Если два человека думают, что другой смотрит алерты, не смотрит никто.

Схема должна показывать, кто утверждает более рискованные деплои, кто дежурит в on-call на этой неделе, кто может сразу сделать rollback и кто закрывает запись об инциденте после исправления.

Право на rollback важнее, чем думают многие фаундеры. Во время сбоя команда не должна останавливать всё ради совещания, чтобы отменить неудачный релиз. Назначьте человека, который может сам откатить релиз, заново выкатить последнюю стабильную версию или отключить рискованный feature flag.

Та же цепочка должна покрывать и закрытие инцидента. После восстановления сервиса один владелец подтверждает root cause, проверяет, что мониторинг по-прежнему работает, и пишет короткий follow-up. Если за этот последний шаг никто не отвечает, тот же сбой часто возвращается через месяц.

Связывайте каждое изменение сервиса с двумя числами: uptime и стоимостью. Деплой, который держит приложение в сети, но вдвое увеличивает расходы на облако, всё равно создаёт production-риск. Маленькие команды часто упускают это из виду, потому что технически сервис работает. На практике неожиданные счета за инфраструктуру могут ударить почти так же сильно, как простой.

Работает простое правило: один человек утверждает изменение, один человек отвечает на алерт, и один человек может быстро отменить изменение. Иногда это один и тот же человек. Важно лишь, чтобы все знали его имя ещё до того, как production проверит схему на прочность.

Соберите схему за один рабочий сеанс

Такую оргструктуру проще завершить за одну фокусную встречу, чем за неделю переписки. Соберите всю команду, или хотя бы всех, кто принимает ежедневные решения, в одной комнате на 60–90 минут. Начните с чистого листа. Не с должностей.

Выпишите решения, которые повторяются снова и снова. Держите их конкретными. Кто утверждает изменение онбординга? Кто может редактировать AI-промпт, который используется в production? Кто отвечает на запрос доступа к данным клиента? Кто решает, делать ли rollback после сбоя?

Затем сгруппируйте эти решения по четырём блокам: продукт, AI, данные и production. Большинство маленьких команд уже так и работают, даже если не называли это вслух. Когда работа разложена по блокам, легче увидеть пересечения.

Обычно хватает короткого прохода. Составьте список повторяющихся решений, а не задач. Поместите каждое решение в один из четырёх блоков. Напишите рядом с каждым пунктом одного владельца. Добавьте одного резервного человека на случай отпуска, болезни или разницы во времени. Затем сравните черновик с недавними инцидентами и обращениями в поддержку.

Правило одного владельца обязательно. Если один пункт «принадлежит» трём людям, в моменты давления он не принадлежит никому. Резервный человек — это другое. Владелец принимает решение. Резервный помогает, когда владелец спит, болеет или недоступен.

В конце проверьте схему на реальных примерах из последнего месяца. Посмотрите на тикеты поддержки, задержки релизов, неудачные ответы AI, запросы на доступ и алерты production. Если недавняя проблема заставила кого-то спросить: «Кто это решает?», значит, в схеме всё ещё есть дыра. Закройте её прямо в комнате, пока детали свежие.

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

Простой пример для SaaS-команды из девяти человек

SaaS-команде из девяти человек не нужна стопка менеджеров. Ей нужны понятные имена рядом с решениями, которые могут ударить по выручке, доверию или uptime.

Рабочая схема может строиться вокруг пяти ролей ответственности и четырёх individual contributors. Фаундер держит общее направление компании, принимает сложные компромиссы и разруливает спорные ситуации, когда скорость, маржа и качество продукта тянут в разные стороны.

Пять владельцев могут быть такими: фаундер, product lead, AI lead, data lead и ops lead. Оставшиеся четыре человека могут быть тремя инженерами и одним специалистом поддержки. Для маленькой продуктовой команды этого достаточно, если все понимают, куда уходит решение.

Product lead отвечает за правила продукта, логику цен и объём релиза. Если команда спорит, должна ли функция быть бесплатной, платной или отложенной, именно этот человек принимает решение.

AI lead отвечает за промпты, оценку результатов и маршрутизацию моделей. Если support сообщает, что помощник начал выдавать слабые ответы после изменения промпта, AI lead проверяет тесты, сравнивает поведение моделей и решает, делать ли откат или перенаправить трафик на другую модель.

Data lead отвечает за доступ к данным клиентов, выгрузки и запросы на удаление. Когда клиент спрашивает: «Кто может видеть данные моего аккаунта?» или «Пожалуйста, удалите наши записи», команде не нужно гадать.

Ops lead отвечает за деплои, алерты и решения об откате. Когда production идёт наперекосяк в 2 часа ночи, один человек решает, откатывать релиз, чинить или подождать.

Support передаёт реальные проблемы клиентов в каждый из этих блоков. Путаница с ценами идёт к продукту. Неправильные ответы AI — к AI lead. Вопросы по доступу — к data. Паттерны инцидентов — к ops. Схема остаётся маленькой, но перестаёт быть размытой.

Ошибки, которые создают пробелы в ответственности

Большинство проблем с ответственностью начинается тогда, когда маленькая команда слишком долго пытается оставаться «гибкой». Один человек пишет правила функции, другой меняет AI-поток, а третий отвечает на жалобы клиентов, когда результат выглядит неправильно. У каждого есть кусок работы, но за итог не отвечает никто.

Ещё одна плохая привычка — принимать решения «по громкости». Фаундер вмешивается в понедельник, senior engineer решает иначе во вторник, а все остальные подстраиваются на ходу. На неделю или две это кажется быстрым решением. Потом команда перестаёт доверять схеме и ждёт самого громкого человека в комнате.

AI добавляет пробел, который маленькие команды часто не замечают. Они подключают инструменты к тикетам, документам, расшифровкам звонков или данным production ещё до того, как установят базовые правила доступа, тестирования и утверждения. Изменение промпта может поменять поведение для клиентов так же сильно, как изменение кода. Относитесь к этому именно так.

Данные клиентов создают отдельное слепое пятно. Команды часто считают это инженерной задачей, но риск начинается раньше. Продукт решает, что собирать. Sales и support часто первыми видят чувствительные детали. Кому-то нужно чётко отвечать за правила данных, сроки хранения и доступ, даже если системы настраивают инженеры.

Риски production обычно остаются размытыми до первого настоящего сбоя. Тогда уже поздно. Если база данных тормозит в 2 часа ночи, команда должна заранее знать, кто ведёт инцидент, кто обновляет клиентов и кто может сделать rollback.

Одинаковые предупреждающие признаки появляются снова и снова. Два человека считают, что оба могут утверждать одно и то же изменение. Никто не может назвать владельца доступа к AI-инструментам. Вопросы по данным прыгают между продуктом, support и engineering. Обновления по инциденту приходят от нескольких людей с разными ответами.

Хорошая схема убирает все эти серые зоны. Если команда не может ответить на вопрос «Кто решает?» одним предложением, пробел всё ещё есть.

Быстрая проверка перед тем, как делиться схемой

Схема готова, когда она быстро снимает споры. Если люди всё ещё останавливаются и спрашивают, кто решает, кто делает работу или кто подменяет отсутствующего, нужно ещё одно редактирование.

Начните с самых больших решений, которые команда принимает каждую неделю. Изменения цен, запросы на доступ, production-инциденты, правки промпта в живом AI-процессе и клиентские policy-решения должны каждый раз указывать на одного человека. Одного имени достаточно. Два имени обычно означают, что никто не хочет брать финальное решение на себя, когда давление растёт.

Затем проверьте передачи ответственности. Команда должна уметь без догадок сказать, кто утверждает, кто действует и кто подхватывает работу, если этого человека нет. Резервная ответственность важнее, чем думают многие фаундеры. Маленькая команда очень остро чувствует каждый больничный и каждый отпуск.

Быстрый обзор на одной встрече обычно показывает слабые места. Попросите нового сотрудника пять минут читать схему и объяснить её своими словами. Возьмите одну реальную проблему клиента и проследите её через правила продукта, AI-процессы, данные клиентов и production. Уберите одного человека из этого пути и посмотрите, очевиден ли запасной вариант. Измените роль одного участника команды и сразу обновите схему. Если файл становится неудобно поддерживать, он уже слишком сложный.

Используйте реальный сценарий, а не выдуманный. Если клиент говорит, что AI-функция показала не тот аккаунт, схема должна показывать, кто отвечает за правило, кто проверяет процесс, кто решает вопрос с данными и кто ведёт исправление в production.

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

Что делать дальше

Проверьте схему под нагрузкой, прежде чем считать её готовой. Возьмите один запланированный релиз, один сложный тикет поддержки и один production-инцидент как тестовые случаи. Для каждого случая задайте три простых вопроса: кто решает, кто делает работу и кто сообщает клиенту, что произошло.

Если два человека претендуют на одно и то же решение, исправьте это сейчас. Если шагом никто не владеет, исправьте в первую очередь это. Маленькие команды чувствуют себя быстрыми, когда все сразу включаются, но эта привычка становится дорогой, как только AI-процессы начинают работать с данными клиентов или плохой деплой попадает в production.

Сделайте пробу простой. Проведите следующий релиз по схеме и запишите каждую передачу ответственности. Пропустите один реальный запрос поддержки через назначенных владельцев. Проведите один инцидент, даже если это всего лишь 20-минутная tabletop-практика.

После этого превратите схему в короткий операционный документ. Для большинства команд до десяти человек хватит одной страницы. Укажите каждую линию ответственности, человека, который принимает решение, резервного человека и правило первого реагирования для проблем, видимых клиенту.

Сделайте это до того, как добавите новые инструменты или новые роли. Дополнительный софт не исправит размытые зоны ответственности. Большее количество людей обычно только усиливает путаницу.

Если команда всё ещё чувствует себя застрявшей, поможет внешний взгляд. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями именно на стыке продуктовых решений, AI-процессов, инфраструктуры и организационной структуры. Часто одного внешнего взгляда достаточно, чтобы увидеть пробелы в ответственности, которые команда перестала замечать.