# Scorecard трансформации стартапа с AI: ежемесячный отчет основателя

> Создайте scorecard трансформации стартапа с AI, который каждый месяц отслеживает экономию на зарплатах, скорость поставки, доступность, дефекты после релиза и объем проверки.

## Зачем основателю один ежемесячный отчет по AI

Команда может купить AI-инструменты для программирования, создать больше pull request и при этом тратить на разработку столько же. Активность не показывает, получила ли компания реальную пользу. Важные вопросы просты: снизились ли расходы на зарплаты, быстрее ли полезная работа дошла до клиентов и сохранилась ли надежность?

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

Scorecard трансформации стартапа с AI собирает эти компромиссы на одной странице. Он сравнивает экономию на зарплатах, скорость поставки, доступность сервиса, дефекты в production и время на проверку или исправление работы. Основателю не нужно изучать каждый commit или prompt. Нужен стабильный ежемесячный обзор затрат, рисков и результата.

Такой отчет улучшает и рабочий разговор. Вместо вопроса, «достаточно ли команда использует AI», основатели и руководители разработки обсуждают конкретные результаты. Команда могла за месяц выполнить на 30% больше работы, но число дефектов в production выросло с двух до девяти. В этом случае нужны лучшие тесты или правила проверки, а не больший бюджет на AI.

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

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

## Пять показателей для отслеживания

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

### Экономия на зарплатах

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

Если компания тратила $120 000 в месяц на команду из десяти разработчиков, а теперь тратит $72 000, ежемесячная экономия на разработке составляет $48 000. Рядом укажите любые изменения в объеме работы. Меньшая команда, которая делает намного меньше, не дает выигрыша.

### Скорость, надежность, качество и проверка

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

Каждый месяц измеряйте доступность за одинаковый период мониторинга. Считайте дефекты, которые клиенты нашли после релиза, и сравнивайте их с числом релизов или поставленных изменений. Также фиксируйте часы, которые люди тратят на проверку кода, тестов, спецификаций и изменений в production, созданных AI.

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

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

## Как измерять экономию на зарплатах без завышения

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

Включите все расходы на создание и поддержку продукта:

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

Используйте полную ежемесячную стоимость, а не только зарплату. Если подрядчик стоит $12 000 в месяц, а инженер с поддержкой AI требует дополнительных $3 000 на инструменты и сверхурочную работу, экономия составляет $9 000, при условии что объем и качество работы сохранились.

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

Показывайте эти цифры в разных строках: «сокращенные текущие расходы» и «отложенный будущий найм». Так незаполненная должность не будет выглядеть как уже полученная экономия.

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

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

## Как измерять скорость поставки с пользой

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

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

### Сравнивайте похожую работу

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

После внедрения поддержки AI команда может сократить медианное время небольших изменений продукта с 12 до 5 дней. Этот результат имеет смысл только при сравнении похожих изменений и одинаковых правилах приемки.

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

Краткий ежемесячный обзор может включать:

- медианное время поставки по типам работы;
- завершенные релизы или принятые задачи;
- заблокированные дни с указанием причины;
- возвращенную работу и исправления после релиза.

Следите за работой, которая возвращается после релиза: hotfix, повторно открытыми задачами, обращениями в поддержку и незапланированной уборкой. Если срок поставки сократился с 10 до 4 дней, но объем последующей работы удвоился, команда перенесла усилия, а не сэкономила их.

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

## Держите доступность и качество в одном отчете

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

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

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

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

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

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

Команда может сократить срок поставки с 10 до 4 дней, сохранить доступность на уровне обещаний клиентам и снизить число дефектов после релиза с шести до двух. Это здоровый результат. Если срок сократился, но число инцидентов удвоилось, а проверяющие каждый месяц тратят на исправление предотвратимых проблем еще 40 часов, нужно замедлить релизы и изменить процесс работы с AI.

## Показывайте объем проверки людьми

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

Считайте часы инженеров на проверку pull request, тестов, технических заметок и инструкций к релизам, созданных AI. По возможности берите время из инструментов проверки, а затем добавляйте работу вне них: например, проверку предлагаемого изменения базы данных или повторный запуск ненадежного теста.

Отделяйте обычную проверку от работы, вызванной проблемой. Обычная проверка включает чтение pull request, проверку покрытия тестами и одобрение безопасного изменения. Доработка включает исправление сломанных сборок, неверных допущений, откат релиза или переписывание кода, который сначала выглядел приемлемым.

В простом отчете можно показать обычные часы проверки AI-результатов, часы исправления дефектов, связанных с AI, часы проверки тестов и документации, написанных AI, а также результат: закрытые задачи или выпущенные функции.

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

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

Команда из двух человек могла потратить в мае 18 часов на проверку результата AI и закрыть 24 задачи. В июне она закрыла 26 задач, но потратила 34 часа на проверку, включая 12 часов на исправление неудачного изменения платежей. Команде стоит улучшить prompt, добавить проверки для платежного кода и оставить эту область под прямым контролем людей.

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

## Как шаг за шагом собрать отчет

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

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

### Зафиксируйте отчетный период

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

Храните источник каждого показателя. Экономию на зарплатах можно брать из финансовых данных, скорость поставки из закрытых задач, доступность из мониторинга, дефекты после релиза из инцидентов production, а объем проверки из pull request или журналов задач. Это не дает спору перейти на воспоминания.

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

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

### Проводите одну встречу для принятия решений

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

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

## Пример простого ежемесячного scorecard

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

| Показатель | До AI-инструментов | 3-й месяц | Что это значит |
|---|---:|---:|---|
| Зарплаты разработки | $128 000 в месяц | $108 000 в месяц | Две открытые позиции разработчиков остаются незаполненными, что дает экономию $20 000 в месяц. |
| Поставленные задачи | 24 в месяц | 39 в месяц | Команда выполняет примерно на 63% больше задач. |
| Доступность production | 99,95% | 99,94% | Надежность сервиса практически не изменилась. |
| Дефекты после релиза | 3 в месяц | 7 в месяц | После релиза до клиентов доходит больше багов. |
| Часы проверки людьми | 310 в месяц | 365 в месяц | Инженеры тратят больше времени на проверку изменений, созданных AI. |

Стартапу не стоит пока называть все $20 000 постоянной экономией на зарплатах. Эта сумма появилась из-за отложенного найма, а дополнительные 55 часов проверки тоже имеют стоимость. Если часы проверки продолжат расти, команда может просто переносить работу с написания кода на его проверку.

Результат по скорости выглядит многообещающе. Число релизов выросло с 24 до 39 без заметного снижения доступности. Но число дефектов после релиза увеличилось более чем вдвое, поэтому расширять применение AI на все типы изменений было бы неосторожно.

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

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

## Ошибки, которые искажают scorecard

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

### Подсчет несуществующей экономии

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

Команда может сказать, что AI сэкономил 80 инженерных часов в апреле. Если затем инженеры потратили эти 80 часов на ту же очередь поддержки, расходы на зарплаты не снизились. Зафиксируйте перенос времени отдельно. Основатель увидит дополнительную мощность, но ее нельзя помещать в колонку экономии.

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

### Восприятие одного хорошего показателя как доказательства

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

С доступностью нужна такая же осторожность. Доступность 99,99% означает, что production оставался доступным. Это не доказывает, что каждый релиз улучшил продукт или сократил число дефектов. Небольшая ошибка в checkout может навредить сильнее короткого сбоя инфраструктуры, даже если доступность остается высокой.

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

## Быстрые проверки перед ежемесячной встречей

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

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

Перед обсуждением итогов прочитайте заметки об доступности и дефектах. Показатель 99,9% может скрывать серьезный сбой во время запуска продаж. Рост дефектов после релиза может быть связан с большим релизом, спешкой при проверке или пользовательским сценарием, который команда не протестировала.

До завершения встречи назначьте одно конкретное действие на следующий цикл. Например: «Майя добавит обязательное одобрение человеком для созданного AI кода, связанного с платежами, до 15 мая».

Используйте короткий checklist:

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

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

## Выбирайте следующее действие по цифрам

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

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

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

Если скорость выросла на 25%, а часы проверки удвоились, протестируйте меньшее изменение. Введите созданные AI тесты и сводки pull request для одного сервиса, а в следующем месяце сравните время проверки и долю дефектов после релиза с baseline. Сохраняйте изменение только при стабильном качестве и меньшем времени на проверку обычной работы.

Используйте результаты, чтобы выбрать следующий шаг:

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

Team & AI Audit с Олегом Сотниковым дает основателям независимую оценку затрат на разработку, потока поставки и внедрения AI. Это может помочь, когда scorecard показывает проблему, но команда не может договориться о ее причине или следующем шаге.

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