План компенсации для AI-команды, который вознаграждает настоящую ответственность

Почему оплата за объём не работает

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

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

Количество черновиков — слабая замена здравому смыслу. Один человек может попросить AI-инструмент сделать двадцать версий одной функции и не выпустить ни одной. Другой может проверить один вариант, заметить ошибочное предположение, сократить объём и предотвратить неделю исправлений. Второй человек сделал больше настоящей работы, даже если дашборд показывает обратное.

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

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

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

Хороший план оплаты вознаграждает ответственность за результат, а не груду черновиков, которую может сгенерировать AI.

Сначала назовите роли, потом назначайте цену

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

Справедливый план начинается с понятных обязанностей, а не с подсчёта объёма. Составьте список реальной работы, которую команда делает в обычную неделю. Включите решения о релизах, code review, реакцию на инциденты, разбор багов, настройку промптов, правки документации и ту тихую уборку, которая поддерживает стабильность продакшена.

Потом разложите работу по понятным корзинам:

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

Это разделение важно, потому что AI создаёт много движения. Человек может за день сгенерировать двадцать черновиков и всё равно избегать более сложной работы: решать, что действительно должно выйти, ловить скрытые ошибки или чинить проблему в два часа ночи. Если оплата зависит только от объёма, выигрывает самый шумный труд.

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

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

Маленькая команда может сделать это за полчаса в общем документе. Многие стартапы думают, что все четыре человека «отвечают за delivery». Но как только они честно разбирают неделю, обычно выясняется, что один человек утверждает релизы, один ведёт большую часть ревью, а двое несут основную нагрузку дежурств. Когда роли названы, обсуждать оплату становится намного проще.

Соберите план по шагам

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

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

Хорошо работает простой порядок сборки. Сначала перечислите результаты, которые команда должна выдавать в обычный месяц, и оставьте список достаточно коротким, чтобы его помнил каждый. Затем назначьте на каждый результат одного владельца, который отвечает за качество и сроки, даже если в черновиках помогают AI или коллеги. После этого оцените, сколько времени на ревью нужно команде каждую неделю. Посчитайте pull request’ы, дизайн-ревью, проверки тестов и время на утверждение релизов. Оплату дежурств отделите от работы по поставке. Платите за саму ротацию, а потом добавляйте фиксированную сумму за вызовы, которые рвут вечер или выходные. Сначала протестируйте план месяц, и только потом считайте его окончательным.

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

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

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

Назначьте отдельную оплату за ответственность за результат

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

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

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

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

Привязывайте релизную выплату к результатам, которые вы согласовали до начала работы. Не привязывайте её к количеству тикетов, количеству коммитов или объёму текста, который сгенерировал AI. Эти цифры вознаграждают активность, а не здравый смысл.

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

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

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

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

Оплачивайте ревью как настоящую работу

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

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

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

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

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

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

Простая модель работает хорошо: платите фиксированную надбавку за ревью тому, кто дежурит по проверкам на этой неделе, а затем добавляйте доплату за особенно рискованные ревью, где нужны более глубокие проверки. На маленькой команде, которая поддерживает продакшен-системы, одно сильное ревью может сэкономить дни восстановления и защитить uptime. В журнале активности это может не выглядеть шумно, но это важно.

Дежурства нужно выделять отдельно

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

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

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

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

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

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

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

Команды, которые хорошо работают на lean-инфраструктуре, делают это осознанно. Понятные runbook’и, разумные алерты и отдельная оплата превращают дежурства из скрытого налога в определённую работу.

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

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

Возьмём небольшую SaaS-компанию: один основатель, два разработчика и один человек, отвечающий за product ops. Все они используют AI для черновиков кода, заметок к релизам, ответов поддержки и внутренней документации. AI экономит время, но не владеет результатом. Люди — владеют.

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

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

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

Человек, отвечающий за product ops, ведёт координацию релизов, заметки по инцидентам и разбор клиентских проблем. Он тоже может участвовать в ротации дежурств, если для системы и продукта это реалистично.

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

Этого достаточно для большинства маленьких команд. Получать оповещения в два часа ночи — это труд, даже если AI помогает составить сообщение об инциденте.

Ошибки, которые портят план

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

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

Помогает простой тест: кто отвечает за результат после релиза? Если на этот вопрос никто не может ответить, правило оплаты, скорее всего, вознаграждает объём, а не результат.

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

Плохие планы также игнорируют обслуживание. Исправление багов, обновление зависимостей, настройка алертов, постобработка инцидентов и трудные рефакторинги редко выглядят эффектно в дашборде. Но именно они защищают uptime и уменьшают будущий стресс. Oleg Sotnikov часто работает с командами над lean-операциями и delivery в формате AI-first, и закономерность довольно стабильна: почти идеальный uptime появляется только тогда, когда команды считают обслуживание настоящим трудом, а не невидимой работой.

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

Изменения правил тоже могут тихо навредить. Когда основатели меняют формулы выплат каждые несколько недель, команда перестаёт доверять плану и начинает играть в последнюю версию. Держите правила стабильными достаточно долго, чтобы люди успели в них поверить.

Ещё один тревожный сигнал — использовать объём AI-выдачи как показатель эффективности. Больше промптов, больше черновиков и больше сгенерированного кода могут означать меньше здравого смысла, а не больший вклад. Считайте выпущенные результаты, аккуратные ревью, меньше повторных инцидентов и стабильные системы. Эти сигналы куда труднее подделать.

Быстрая проверка перед запуском

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

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

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

Короткий стресс-тест быстро выявляет плохие планы:

• Если завтра объём AI-выдачи удвоится, останется ли оплата почти прежней для авторов черновиков и вырастет только тогда, когда реально увеличатся ответственность, нагрузка на ревью или время дежурств?
• Можно ли назвать одного человека, который утверждает каждый релиз?
• Понимает ли каждый ревьюер, за что полагается доплата и что считается обычной поддержкой команды?
• Покрывает ли оплата дежурств и плановую смену, и тяжёлые инциденты?
• Прогоняли ли вы один пробный цикл до того, как зафиксировали цифры?

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

Что делать дальше вашей команде

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

Запишите направления простым языком: кто отвечает за поставку, кто проверяет работу и кто несёт дежурства. Поставьте рядом с каждым направлением правило оплаты. Формулировки должны быть скучными и точными. «Отвечает за результат релиза» лучше, чем «поддерживает delivery». «Проверяет pull request’ы в течение одного рабочего дня» лучше, чем «помогает с качеством».

Большинству планов на одну страницу нужны только четыре части:

• Базовая зарплата за роль.
• Оплата за ответственность, привязанная к выпущенной работе и доведению до конца.
• Оплата за ревью за время, потраченное на проверку, исправление и утверждение.
• Оплата за дежурства за покрытие, прерывания и реакцию на инциденты.

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

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

Очень помогает одна практичная привычка: храните короткую заметку о релизе всего с тремя именами — владелец, ревьюер и дежурный. Такой记录 сильно упрощает решения по оплате, когда память уже подводит.

Если вашей команде нужен внешний разбор перед запуском, Oleg Sotnikov на oleg.is может посмотреть на зоны ответственности, привычки ревью и покрытие дежурств в рамках своего Fractional CTO advisory. Такая внешняя проверка особенно полезна, когда маленькая команда быстро движется и одно неясное правило способно раздражать всех месяцами.