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

Почему story points перестают справляться

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

Но у этой метрики есть скрытая предпосылка: основную работу выполняет человек. А в 2026 году это всё реже соответствует реальности.

Сегодня разработчики всё чаще решают задачи не только своими знаниями, но и через постоянное взаимодействие с нейросетями: генерация каркаса сервиса, написание тестов, анализ ошибок, рефакторинг, составление SQL-запросов, помощь в code review и многое другое.

Инженерная работа не исчезает. Но её характер меняется.

Поэтому предлагается идея для обсуждения: что если ввести новую метрику — neuro points?

Не вместо story points, а рядом с ними. Не как догму, а как попытку отразить новую реальность — разработку с участием ИИ.

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

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

Две задачи могут иметь одинаковую оценку — например, 5 story points. Но по факту:

• одна решается за 20 минут с помощью 4–5 удачных промптов;
• вторая требует десятков итераций, постоянной проверки и ручной правки;
• третья вообще плохо поддаётся автоматизации и требует глубокой инженерной проработки.

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

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

А в эпоху ИИ становится важен и другой вопрос:

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

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

Что такое neuro points

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

Проще говоря:

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

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

• постановка контекста;
• уточнение требований;
• генерация решений;
• отладка;
• переписывание кода;
• анализ ошибок;
• доработка результата.

Neuro points — это не оценка общей сложности, а метрика ИИ-опосредованного усилия.

Почему такая метрика нужна

Потому что ИИ уже не эксперимент, а часть реальных процессов в крупных компаниях.

Google сообщает, что 75% нового кода в компании генерируется с помощью ИИ. Microsoft и GitHub позиционируют Copilot как инструмент ускорения разработки. Accenture, Hitachi, Generali и HP уже внедрили ИИ-ассистенты в свои workflow, чтобы сократить рутину и освободить время на осмысленный контроль.

Когда ИИ становится системным элементом, возникает естественный вопрос: а как теперь измерять работу?

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

Это не конкурирующие метрики. Они описывают разные измерения.

Story points отражают:

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

Neuro points показывают:

• количество AI-итераций;
• зависимость от качества промптинга;
• необходимость декомпозиции контекста;
• объём проверки ИИ-результата;
• повторяемость взаимодействия с моделью.

Высокие story points не означают высокие neuro points, и наоборот. Задача может быть сложной, но плохо поддаваться ИИ. Или быть простой, но требовать множества итераций для «дожимания» результата.

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

Можно начать с простой шкалы:

• 1 NP — один-два промпта, результат сразу пригоден;
• 2 NP — несколько уточнений, задача решается линейно;
• 3 NP — заметная итеративность: генерация → проверка → исправление;
• 5 NP — задача зависит от контекста, примеров и структуры запросов;
• 8 NP — много циклов, высокая цена ошибки ИИ;
• 13 NP — сильная вовлечённость ИИ, но без контроля результат разваливается.

Числа можно оставить по Фибоначчи — для привычности.

Варианты использования

1. Оценка заранее: на планировании указывается: «5 story points и 3 neuro points» — чтобы учесть ожидаемый паттерн работы с ИИ.

2. Фиксация постфактум: после задачи разработчик отмечает, сколько значимых итераций с ИИ реально потребовалось. Это даёт эмпирические данные.

3. Комбинированный подход: story points — для планирования, neuro points — для анализа. Это помогает понять:

• где ИИ реально ускоряет;
• где создаёт ложную скорость;
• кто эффективно работает с ИИ;
• где нужны шаблоны промптов и внутренние гайды.

Что это даёт команде

1. Более честная картина производительности. Velocity может оставаться прежним, но способ работы уже изменился. Neuro points помогают это увидеть.

2. Понимание реального эффекта ИИ. Не на уровне лозунгов, а по паттернам: тесты и boilerplate ускоряются хорошо, сложная архитектура — ограниченно, legacy — с осторожностью.

3. Видимость нового навыка. Умение работать с ИИ — это уже отдельная компетенция: формулировать запросы, проверять результат, управлять контекстом.

4. Основа для внутренних практик. Вместо призыва «используйте ИИ» можно перейти к вопросу: «где это реально работает?»

Риски: как не испортить идею

Риск 1. Метрика станет объектом игры. Как только neuro points повлияют на KPI, начнётся симуляция активности: лишние промпты, фиксация шума. Поэтому нельзя использовать их как «дубину».

Риск 2. Количество ≠ ценность. Один сильный промпт может заменить десять слабых. Neuro points зависят не только от задачи, но и от навыка инженера, качества инструмента и зрелости процесса.

Риск 3. Не всё нужно делегировать. Есть задачи, где ИИ опасен или бесполезен. Neuro points не должны подменять инженерное мышление.

Риск 4. Зависимость от быстро меняющихся инструментов. Сегодня вы используете Copilot, завтра — другой агент. Метрика должна быть гибкой.

Как внедрить без фанатизма

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

1. Не отменять story points.
2. На 2–3 спринта добавить необязательное поле «ожидаемые neuro points».
3. После задачи фиксировать фактические neuro points.
4. Сравнить прогноз и реальность: где ИИ помог, где мешал, где оценки расходятся.
5. На ретроспективе обсудить — есть ли сигнал или только шум.

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

В чём ценность идеи

Neuro points важны не сами по себе, а как смена фокуса. Они заставляют задать вопрос:

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

Сегодня инженер — это:

• постановщик задачи;
• редактор контекста;
• оператор ИИ-инструмента;
• верификатор результата;
• архитектор последней ответственности.

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

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

Neuro points — не идеальная модель. Скорее всего, в чистом виде она окажется неполной.

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

Когда Google говорит о 75% кода, генерируемого ИИ, а компании вроде Accenture и HP публично внедряют ИИ в разработку, разговор о новых метриках — это не футуризм. Это нормальная реакция на изменение среды.

Story points — это оценка сложности для команды. Neuro 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

• количество AI-итераций;
• степень зависимости задачи от качества промптинга;
• потребность в декомпозиции контекста для модели;
• объём перепроверки AI-результата;
• повторяемость AI-помощи на пути к результату.

Story points

Neuro points

Добавить новый CRUD-эндпоинт по понятному шаблону

Написать интеграционные тесты на существующий сервис

Разобраться в legacy-модуле, найти race condition и безопасно исправить

Спроектировать новую billing-схему с кучей доменных ограничений

Сгенерировать boilerplate для нового микросервиса, потом допилить

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

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

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

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

• 1 NP— один-два промпта, результат почти сразу пригоден;
• 2 NP— нужно несколько уточнений, но задача решается линейно;
• 3 NP— есть заметная итеративность: генерация → проверка → исправление;
• 5 NP— задача сильно зависит от качества контекста, примеров и декомпозиции;
• 8 NP— много циклов взаимодействия, высокая цена ошибки 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. Основание для внутренних практик

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

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

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

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

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

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

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

• лишние промпты ради “объёма”;
• фиксацию шума вместо полезных итераций;
• симуляцию AI-активности.

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

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

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

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

• природы задачи,
• качества AI-инструмента,
• зрелости процесса,
• навыка самого инженера.

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

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

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

Риск 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, разговор о новых метриках выглядит уже не футуризмом, а нормальной реакцией на изменение среды. Google описывает AI как часть собственной инженерной платформы, Reuters пишет о 75% нового кода в Google, генерируемого AI, а такие компании, как Accenture, Hitachi, Generali и HP, публично описывают внедрение AI-инструментов в работу разработчиков. (Google Research)

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

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

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