Story points — прошлый век?

Хватит мерить задачи story points. Пора хотя бы обсудить neuro points

Мнение. Предложение к обсуждению, а не новая догма.

В разработке есть старый и понятный инструмент — story points. Он помогает команде примерно оценить задачу по сложности, неопределённости и объёму усилий.

Но у story points есть важная скрытая предпосылка: основную работу по решению задачи делает человек.

И вот здесь, как мне кажется, в 2026 году начинается расхождение с реальностью.

Сегодня всё больше задач в разработке решаются не только головой инженера и документацией, но и через постоянное взаимодействие с нейросетями:
мы просим LLM сгенерировать каркас сервиса, написать тесты, предложить SQL, разобрать stack trace, сделать рефакторинг, подсветить архитектурные варианты, оформить документацию, составить regex, придумать миграцию и даже помочь с review.

Всё это не отменяет инженерную работу. Но меняет её характер.

Поэтому у меня есть предложение для обсуждения:
а что если рядом со story points ввести ещё одну сущность — neuro points?

Не как замену здравому смыслу.
Не как попытку “оцифровать всё подряд”.
А как новую метрику, которая лучше отражает реальность AI-assisted разработки.

В чём проблема story points сегодня

Story points исторически удобны, потому что они оценивают задачу относительно:
не в часах, а в сравнении с другими задачами.

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

Две задачи могут выглядеть одинаково по story points, но на практике:

• первая решается за 20 минут с помощью 4–5 хороших промптов;

• вторая требует десятков итераций с нейросетью, постоянной перепроверки и ручной доработки;

• третья вообще плохо делегируется модели и требует классической глубокой инженерной работы.

Снаружи это всё может быть “5 SP”.
Но по факту это уже разные типы труда.

Story points отвечают на вопрос:

Насколько задача сложна для команды?

А в AI-эпоху всё чаще нужен ещё один вопрос:

Насколько задача решаема через нейросетевой контур работы?

И это уже другая ось оценки.

Что такое neuro points

Neuro points — это моя предлагаемая метрика, которая оценивает задачу через объём и характер взаимодействия с нейросетью при её решении.

В самой простой формулировке:

Neuro points = условная оценка того, сколько осмысленных AI-итераций требуется, чтобы довести задачу до рабочего результата.

Важно: речь не о тупом подсчёте любых сообщений в чат.

Не “сколько раз открыл ChatGPT”.
Не “сколько токенов сжёг”.
Не “кто больше напромптил”.

Речь про полезные, рабочие, значимые итерации, которые реально двигают задачу:

• постановка контекста;

• уточнение требований;

• генерация вариантов решения;

• отладка;

• переписывание кода;

• генерация тестов;

• анализ ошибок;

• доработка результата после проверки.

То есть neuro points — это не метрика “сложности задачи вообще”, а метрика AI-опосредованного усилия.

Почему такая метрика вообще имеет смысл

Потому что крупные компании уже не просто “интересуются AI”, а встраивают его в реальные инженерные процессы.

Google прямо пишет о трансформации собственных внутренних инструментов разработки с AI-поддержкой, включая IDE, code review, поиск по коду, bug management и planning. Это особенно важно для нашей темы: AI там встроен не только в “написание кода”, но и в соседние инженерные контуры. (Google Research ^[1])

По данным Reuters от 22 апреля 2026 года, Sundar Pichai заявил, что 75% нового кода в Google генерируется AI, а Google одновременно делает ставку на AI-агентов как на производственную enterprise-инфраструктуру. Это уже не эксперимент на уровне хакатона, а часть стратегии большой компании. (Reuters ^[2])

Microsoft и GitHub давно продают Copilot не как игрушку, а как инструмент ускорения разработки; в документации GitHub прямо говорится, что Copilot помогает писать код быстрее и с меньшими усилиями, а исследования GitHub связывают его использование с ускорением выполнения задач и более высоким субъективным ощущением продуктивности. (GitHub Docs ^[3])

У Microsoft есть и конкретные кейсы крупных организаций.
Accenture развернула тысячи лицензий GitHub Copilot по всему миру и сопровождала внедрение обучением ^[4] и геймификацией, чтобы повысить реальное использование инструмента. (Microsoft ^[5])

Hitachi внедрила GitHub Copilot как часть инициатив по продвижению AI внутри компании и повышению продуктивности разработки; компания отдельно подчёркивает, что интеграция с существующими фреймворками разработки дала полезные знания, которые они масштабируют через внутреннее сообщество практиков генеративного ИИ. (Microsoft ^[6])

Generali описывает цель ещё прямее: использовать AI по всему SDLC, чтобы часть работы выполнялась автоматически, а у людей оставалось больше времени на review и осмысленный контроль результата. (Microsoft ^[7])

HP тоже прямо говорит, что встроила GitHub Copilot в workflow, после чего разработчики стали быстрее писать код и быстрее решать проблемы, не застревая на рутинном каркасе и синтаксисе. (Microsoft ^[8])

То есть тезис “нейросети становятся частью нормального процесса разработки” уже не выглядит спорным. Он подтверждается и внутренними блогами платформ, и кейсами крупных компаний, и новостным фоном. (Google Research ^[1])

А если инструмент становится системным, то рано или поздно команда начинает задаваться вопросом:
а как теперь это измерять?

Чем neuro points отличаются от story points

Story points и neuro points не обязаны конкурировать. Скорее они описывают разные плоскости.

Story points отвечают за:

• сложность;

• неопределённость;

• архитектурный риск;

• объём ручного инженерного труда.

Neuro points могут отвечать за:

• количество AI-итераций;

• степень зависимости задачи от качества промптинга;

• потребность ^[9] в декомпозиции контекста для модели;

• объём перепроверки AI-результата;

• повторяемость AI-помощи на пути к результату.

Условно:

Эти цифры условны, но они показывают главное:
высокие story points не всегда означают высокие neuro points, и наоборот.

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

Как можно считать neuro points на практике

Я бы не начинал со сложной формулы.
Лучше с простой, понятной и грубой шкалы.

Например:

• 1 NP — один-два промпта, результат почти сразу пригоден;

• 2 NP — нужно несколько уточнений, но задача решается линейно;

• 3 NP — есть заметная итеративность: генерация → проверка → исправление;

• 5 NP — задача сильно зависит от качества контекста, примеров и декомпозиции;

• 8 NP — много циклов взаимодействия, высокая цена ошибки ^[10] AI-ответа;

• 13 NP — нейросеть участвует много, но без глубокого человеческого контроля задача разваливается.

Да, числа можно оставить фибоначчиевыми, чтобы модель была ближе к привычному agile-мышлению.

Важно, что считать можно по-разному:

Вариант 1. Оценивать заранее

На планировании команда говорит:
“Эта задача на 5 story points и примерно на 3 neuro points”.

То есть оценивается не только сложность, но и ожидаемый AI-паттерн работы.

Вариант 2. Фиксировать постфактум

После закрытия задачи разработчик или команда отмечает фактические neuro points:
сколько значимых AI-итераций реально понадобилось.

Этот вариант даже интереснее, потому что даёт эмпирику.

Вариант 3. Считать комбинированно

Например:

Story points — для прогноза спринта.
Neuro points — для анализа фактического способа выполнения задач.

Так можно увидеть:

• какие типы задач лучше всего ускоряются AI;

• где нейросети реально экономят время;

• где они, наоборот, создают ложную скорость;

• какие разработчики умеют эффективнее работать в AI-контуре;

• где нужны шаблоны промптов, внутренние гайды и общие практики.

Что это даёт команде и менеджменту

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

1. Более честную картину производительности

Сейчас velocity в story points может оставаться прежней, хотя фактический способ производства результата уже изменился.

Команда вроде бы “та же”, спринт вроде бы “тот же”, а внутренняя механика работы уже другая.

Neuro points позволяют хотя бы начать это замечать.

2. Понимание, где AI реально ускоряет работу

Не на уровне лозунга “мы используем ИИ”, а на уровне паттернов:

• тесты — хорошо ускоряются;

• boilerplate — отлично ускоряется;

• документация — ускоряется;

• сложная архитектура — ускоряется ограниченно;

• dangerous legacy — требует осторожности.

3. Видимость нового навыка

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

Теперь добавляется ещё один слой:
умение эффективно взаимодействовать с AI-инструментами.

И это уже похоже на отдельную профессиональную компетенцию.

4. Основание для внутренних практик

Если руководство, как в моей компании, уже сознательно интегрирует нейросети в рабочие процессы ради ускорения, то логично ^[11] однажды перейти от призыва “используйте AI” к вопросу:
“а как мы понимаем, где это реально работает?”

Neuro points можно использовать хотя бы как исследовательский инструмент внутри команды.

Но здесь очень важно не испортить идею

Сразу скажу: у такого подхода куча рисков.

Риск 1. Метрика станет объектом игры

Как только любая метрика начинает влиять на KPI, люди начинают оптимизироваться под метрику.

Если привязать neuro points к эффективности разработчика, можно быстро получить абсурд:

• лишние промпты ради “объёма”;

• фиксацию шума вместо полезных итераций;

• симуляцию AI-активности.

Поэтому neuro points нельзя вводить как дубину.

Риск 2. Количество промптов не равно ценности

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

То есть neuro points измеряют не “сложность мира”, а смесь из:

• природы задачи,

• качества AI-инструмента,

• зрелости процесса,

• навыка самого инженера.

Риск 3. Не всё надо делегировать модели

Есть задачи, где AI помогает только локально.
Есть задачи, где он опасен.
Есть задачи, где основная ценность — не генерация кода, а корректность, ответственность и понимание домена.

И это значит, что neuro points не должны подменять инженерное мышление ^[12].

Риск 4. Сильная зависимость от инструмента

Сегодня команда сидит на одной модели, завтра — на другой.
Сегодня IDE умеет одно, завтра — другое.
Сегодня у вас Copilot, Cursor, Claude Code, Gemini или внутренний агент, а через полгода ландшафт меняется.

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

Поэтому моя позиция простая

Я не предлагаю выбросить story points.
И тем более не предлагаю срочно переписать весь Scrum под нейросети.

Я предлагаю признать простую вещь:

В AI-assisted разработке появляется ещё один тип усилия, которого story points не описывают достаточно хорошо.

И вот это усилие можно попробовать назвать neuro points.

Не как стандарт индустрии.
Не как “правильную новую истину”.
А как рабочую гипотезу.

Как я бы внедрял это без фанатизма

Если бы команда захотела проверить идею, я бы начал так:

1. Не отменять story points.

2. На 2–3 спринта добавить для части задач необязательное поле “ожидаемые neuro points”.

3. После завершения задач фиксировать фактические neuro points ретроспективно.

4. Сравнить:

   • где AI дал реальное ускорение;

   • где оценка не совпала с реальностью;

   • где промптинг оказался отдельным трудом;

   • где story points и neuro points расходятся сильнее всего.

5. На ретро обсудить, есть ли в этом сигнал или только шум.

Если окажется, что шум — отлично, гипотеза не подтвердилась.
Если окажется, что сигнал есть — можно думать дальше.

Что особенно интересно в этой идее

На мой взгляд, neuro points ценны даже не сами по себе.
Их ценность — в смене фокуса.

Они заставляют задать неудобный, но своевременный вопрос:

Если разработка всё чаще идёт через нейросетевой контур, то не пора ли нам обновить язык, которым мы описываем труд инженера?

Когда-то было нормально оценивать только человеческое усилие.
Теперь инженер всё чаще работает как:

• постановщик задачи,

• редактор контекста,

• оператор AI-инструмента,

• верификатор результата,

• архитектор последней ответственности.

И, возможно, именно это и должно начать отражаться в метриках.

Вместо вывода

Я не утверждаю, что neuro points — идеальная модель.

Более того, почти уверен, что в чистом виде она тоже окажется несовершенной.

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

Пока крупные компании массово внедряют AI в разработку, внутренние инструменты, code review и инженерный workflow, разговор о новых метриках выглядит уже не футуризмом, а нормальной реакцией ^[13] на изменение среды. Google описывает AI как часть собственной инженерной платформы, Reuters пишет о 75% нового кода в Google, генерируемого AI, а такие компании, как Accenture, Hitachi, Generali и HP, публично описывают внедрение AI-инструментов в работу разработчиков. (Google Research ^[1])

Так что мой тезис очень простой:

story points — это оценка сложности задачи для команды.
neuro points — это возможная оценка AI-итеративности решения.

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