Хватит мерить задачи 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-эндпоинт по понятному шаблону | 2 | 1 |
Написать интеграционные тесты на существующий сервис | 3 | 3 |
Разобраться в legacy-модуле, найти race condition и безопасно исправить | 8 | 6 |
Спроектировать новую billing-схему с кучей доменных ограничений | 8 | 2 |
Сгенерировать boilerplate для нового микросервиса, потом допилить | 3 | 4 |
Эти цифры условны, но они показывают главное:
высокие 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.
Не как стандарт индустрии.
Не как “правильную новую истину”.
А как рабочую гипотезу.
Как я бы внедрял это без фанатизма
Если бы команда захотела проверить идею, я бы начал так:
Не отменять story points.
На 2–3 спринта добавить для части задач необязательное поле “ожидаемые neuro points”.
После завершения задач фиксировать фактические neuro points ретроспективно.
Сравнить:
где AI дал реальное ускорение;
где оценка не совпала с реальностью;
где промптинг оказался отдельным трудом;
где story points и neuro points расходятся сильнее всего.
На ретро обсудить, есть ли в этом сигнал или только шум.
Если окажется, что шум — отлично, гипотеза не подтвердилась.
Если окажется, что сигнал есть — можно думать дальше.
Что особенно интересно в этой идее
На мой взгляд, 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-итеративности решения.
Не обязательно заменять одно другим.
Но, возможно, уже пора хотя бы положить их рядом и посмотреть, что из этого выйдет.