Разговоры о компенсации при использовании ИИ: объём, владение и риск

Почему количество коммитов перестаёт рассказывать всю историю

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

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

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

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

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

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

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

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

Что означают объём, владение и риск

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

Объём — это область, которой человек управляет

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

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

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

Владение и риск несут реальный вес

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

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

Именно поэтому сырая производительность так часто вводит менеджеров в заблуждение. ИИ может позволить двум инженерам закончить одну и ту же фичу быстрее. Но если один всё ещё отвечает за доступность, проверку безопасности, планы отката и окончательное решение «пускать/не пускать», то ответственность не уменьшилась только потому, что печатать стало быстрее.

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

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

Какие доказательства стоит приносить на встречу

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

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

Ведите запись за квартал

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

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

Хорошие доказательства конкретны. Укажите решение, контекст и результат. Отметьте проекты, которыми человек владел от начала до конца. Запишите инциденты, эскалации и компромиссы, которые он сделал. Отметьте, как он ревьюил код, наставлял коллег или помог teammate избежать повторения ошибки. Главное — смотрите на паттерн за несколько месяцев, а не на одну насыщенную неделю.

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

Используйте артефакты, а не память

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

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

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

Как проводить разговор

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

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

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

Объём — первый пункт, потому что его проще увидеть. Работал ли человек над одной фичей, целой системой или над сложной кросс‑командной задачей с неочевидными границами? Широкий объём обычно означает больше контекста, больше компромиссов и больше давления.

Далее говорите о владении. Замечал ли он проблемы на раннем этапе, принимал решения и доводил работу до конца? Или ему требовалось постоянное руководство? ИИ может помочь выдать много кода, но не сможет подменить устойчивое владение надолго.

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

Используйте недавние примеры, а не общие впечатления. Выберите два–три момента из последнего квартала. Один яркий пример лучше расплывчатой фразы «он сильно вырос». Менеджер может сказать: «Вы взяли на себя неудавшийся релиз, сократили количество инцидентов и координировали поддержку, QA и инженеров две недели». Это даёт человеку основу для реакции.

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

Заканчивайте простым ответом. Скажите, что решили сейчас, что мешает следующему шагу по оплате и когда вы пересмотрите вопрос снова. Если ответ «не сейчас», назовите недостающие доказательства в одну‑две строки и запланируйте следующую проверку до конца встречи.

Простой пример из продуктовой команды

Представьте маленькую продуктовую команду с двумя инженерами, Майей и Беном. Оба ежедневно используют ИИ‑инструменты. За квартал они выпустили почти одинаковый видимый объём: похожее количество пулл‑реквестов, фиксов, тестов и небольших обновлений.

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

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

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

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

Если Бен хочет вырасти до следующего уровня оплаты, путь должен быть конкретным. Он может взять одну фичу от планирования до релиза, стать главным on‑call для ограниченной области с поддержкой рядом, принимать и документировать компромиссы или управлять чек‑листом релиза без постоянной помощи. Это работает лучше, чем расплывчатая похвала или «делай больше». У Бена появляется реальная цель, и Майя не чувствует, что невидимая работа не учитывается.

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

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

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

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

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

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

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

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

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

Быстрая проверка перед решением

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

Начните с одной простой фразы об объёме человека. Если вы не можете описать это без жаргона, роль всё ещё расплывчата. «Отвечает за поток биллинга для web и mobile» — ясно. «Поддерживает доставку продукта по платежам» — неясно.

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

Риск — там, где многие решения по оплате слабеют. Спросите, что ложится на этого человека, когда что‑то ломается. Его тянут на инциденты в 2:00 ночи? Он принимает компромиссы, которые могут повредить доходу, безопасности или доверию клиентов, если ошибиться? Более высокая оплата обычно идёт за более высокую цену ошибки, а не за большее количество сообщений.

Короткий чек‑лист помогает:

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

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

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

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

Если вы не можете честно ответить на все пять пунктов фактами, подождите. Отложенное решение лучше, чем принятое на шумных данных.

Следующие шаги для менеджеров и основателей

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

Хорошая заметка по роли звучит просто. Она говорит, что человек отвечает за качество релизов в области продукта, принимает архитектурные решения без постоянного утверждения или управляет рисками для пользовательского потока. Это гораздо полезнее, чем считать pull‑requestы, закрытые тикеты или часы в сети.

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

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

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

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

Если титулы и уровни оплаты перестали соответствовать реальной работе, полезен взгляд со стороны. Олег Сотников на oleg.is работает с основателями как внештатный CTO и стартап‑советник; его опыт охватывает роли инженера, CTO, CEO и основателя. Эта перспектива полезна, когда ИИ меняет работу команды быстрее, чем успевает система компенсаций.

Сделано правильно, это не делает разговоры об оплате мягче. Оно делает их понятнее, потому что все видят, чем на самом деле является роль.