Редакторский аудит rnd-project-cost.md

Дата аудита: 2026-08-23.

Исходная статья: C:\bshop26\docs\ru\rnd-project-cost.md.

Назначение этого файла — передать другой сессии не просто список опечаток, а восстановленную смысловую карту проекта. Исходную статью во время аудита не редактировали.

Итог в одном абзаце

Статья хорошо читается, имеет сильный голос и использует много реальных фактов, но отвечает преимущественно на вопрос «почему последние RF-дефекты оказались трудными». Заголовок обещает объяснить стоимость всей разработки за месяцы. Сейчас это скорее постмортем M3/CTS/868 МГц с приложенной оценкой стоимости. Нужна не косметическая правка, а перестройка центра тяжести: сократить часть поздних RF-подробностей и добавить происхождение проекта, работу с легаси, создание испытательного стенда, продуктовые контуры, производственный пульт, аппаратную работу и цену доказательства результата.

Главная смысловая проблема

Текущий текст описывает автоматизированный стенд как уже существующий третий элемент связки «человек + Codex + стенд». Но стенд не был готовым прибором или купленной программой. Его пришлось придумать, физически собрать, связать с оборудованием, многократно переписать и отдельно проверить. Поэтому статья показывает выгоду от автоматизации, но почти не показывает цену её создания.

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

Как реально развивался проект

Для новой версии статьи нужна короткая понятная хронология.

1. Наследованный прототип

• сначала существовало устройство на 433 МГц;
• идеи и код переносились на 868 МГц;
• ранняя передача работала через обычный FIFO;
• затем нашли и начали использовать тестовый PN9;
• первоначально генерация существовала для одного диапазона, второй добавлялся простым переключением;
• короткие защитные таймеры ранней лабораторной разработки позднее превратились в распределённое легаси;
• проект переносился с STM32F030 на STM32G431;
• старые RF-таблицы и конфигурации имели не до конца известное происхождение, местами содержали следы 433-МГц проекта.

Это важно: проект не был greenfield-разработкой по готовой спецификации.

2. Превращение функции в продукт

После первой работающей генерации пришлось создать:

• нормальное управление тремя RF-модулями;
• Scan и детектор;
• физическую кнопку с большим набором жестов;
• LED- и виброиндикацию;
• батарейную логику, ADC, Stop0, безопасное засыпание и пробуждение;
• хранение настроек и восстановление после перезапуска;
• ESP-прошивку, Wi-Fi, Web UI, UART-протокол и единое фактическое состояние;
• OTA приложения и файловой системы с recovery;
• формат пакета конфигурации;
• Studio для создания, проверки, сохранения и загрузки пакетов;
• производственный пульт для отдельных и полных операций с новыми изделиями.

Фраза «написали прошивку и нарисовали кнопки» скрывает почти весь этот объём.

3. Распутывание STM

В STM пришлось последовательно разбирать и переделывать Control, Generation, Scan, RF, Storage, UI, Platform и Diagnostics. Это не была одна уборка. Выполнялись отдельные карты архитектуры, ТЗ, реализации, аппаратные проверки и повторные аудиты.

Показательные числа:

• ранний STM-срез содержал 65 .c и 73 .h, а main.c занимал 4925 строк;
• текущий основной STM-контур состоит из 19 .c/.h;
• Scan уменьшился с 4319 до 902 строк — примерно на 79%;
• музейная Diagnostics на 1327 строк была доказанно удалена;
• полезный TX3 при этом сохранили, отделив его от мёртвой лабораторной оболочки.

Финальный размер кода не отражает объём работы: большой её результат — именно удалённый, объединённый или переписанный код.

4. ESP, Web и Studio

ESP — не «ещё одна страница управления». Она владеет Wi-Fi, Web/API, WebSocket, UART/Wire V3, фактическим состоянием STM, пакетом, NVS, OTA, LittleFS и восстановлением после ошибок.

Studio — не просто форма с частотами. Она является компилятором и редактором канонического пакета, проверяет ограничения, поддерживает нестандартные наборы Generation/Scan и участвует в безопасной записи каталога в устройство.

Из рабочего каталога Studio было архивировано 334 исторических файла общим размером около 108,8 МБ. Это хороший наглядный пример пути от экспериментов к одному current owner.

5. Стенд как отдельная разработка

Стенд возник потому, что ручными проверками было невозможно надёжно различать:

• дефект изделия;
• потерю HTTP-ответа после уже выполненного действия;
• ошибку ридера;
• занятый прибор;
• неверную геометрию;
• повреждённую форму RF при полностью «зелёной» цифровой телеметрии.

Для этого стенд научили работать с:

• STM и ST-Link;
• физической кнопкой через ST-Link helper;
• USB-GND helper;
• TP-Link лабораторным адаптером;
• Logic16;
• SDR;
• Urovo;
• CipherLab;
• тремя FM505;
• STM/ESP builds и flashing;
• NVM preservation;
• package restore;
• resource locks, timeout, postcondition и unconditional cleanup.

Старый стенд представлял собой набор разрозненных CLI, WebGUI, helper и скриптов. При clean rewrite Bench V2 в исторический архив вывели 1282 файла общим размером около 45 МБ. Новый публичный runtime на момент cutover состоял из восьми файлов и 2731 строки, после чего продолжил развиваться.

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

6. Производственный пульт

Это отдельный инструмент, а не одна кнопка Bench. Его назначение:

• отдельно прошивать STM;
• отдельно прошивать ESP;
• отдельно загружать пакет;
• выполнять полный производственный цикл;
• правильно выбирать подключённое изделие среди других USB-устройств;
• работать без лабораторного стенда — только с ST-Link, его кнопкой и USB ESP;
• оставлять понятный результат каждой операции.

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

7. Product acceptance и дальнейшие RF-исследования

Полная приёмка проверяла не только happy path:

• разные размеры пакета: P1/P3/P5/P_MAX;
• отрицательные пакеты;
• листаемость кнопкой при разном количестве режимов;
• все пять режимов Generation и все направленные переходы;
• Scan masks и разные ридеры;
• Studio transaction и recovery;
• Web state и reconnect;
• app/UI OTA и recovery;
• сон, питание, ADC, физические жесты и финальное безопасное состояние.

Только после уже полученного product PASS исследования продолжились в область редких CTS-зависаний, M3, 868/910 МГц, мощности, airtime и тихой потери модуляции. Эти эпизоды важны, но они являются финальной частью истории, а не всей историей.

Почему работа с легаси особенно дорога

Легаси здесь нельзя описывать только словами «старый плохой код».

В нём одновременно находились:

• две ветви исполнения Generation;
• параметры, протащенные Studio → package → ESP → STM без продуктовой необходимости;
• старые per-mode timeout;
• legacy NVM и встроенные режимы;
• несколько владельцев одного состояния;
• diagnostics и experimental paths;
• конфигурации, пережившие несколько аппаратных ревизий;
• защитные задержки, происхождение которых было неизвестно, но удалять их без A/B было опасно.

Правильный цикл выглядел так:

1. прочитать весь затронутый owner и соседние связи;
2. восстановить фактическое поведение по коду, документации, Logic и SDR;
3. записать контракт до изменения;
4. изменить минимально или написать новый узкий контур;
5. собрать exact image и сохранить NVM;
6. проверить на физическом устройстве;
7. вернуть production baseline, если новая архитектура оказалась хуже.

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

Что автоматизация не могла сделать вместо человека

Для честной оценки нельзя создать впечатление, что Codex и Bench автоматически разработали изделие.

Человек всё равно:

• формулировал физические гипотезы;
• выбирал, какой результат считать полезным;
• перепаивал питание, делители, UART, PB11 и линии RF-модулей;
• переставлял Logic-каналы;
• менял геометрию антенн, ридеров и меток;
• смотрел на SDR и замечал изменение формы сигнала;
• диагностировал отдельные экземпляры плат;
• принимал продуктовые компромиссы;
• решал, когда эксперимент прекращать и к какому резерву возвращаться.

Автоматизация сократила механическую и аналитическую работу, но не отменила физическую лабораторию и инженерное решение.

Конкретные фактические правки исходной статьи

1. Смешены два разных RF-дефекта

Исходник, строка 84:

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

Перед этим описана тихая потеря PN9-модуляции, при которой CTS и команды остаются штатными. Bounded recovery переживало другой класс событий — CTS-зависание. Тихую потерю модуляции при валидном CTS оно само не обнаруживало.

Нужно явно разделить:

• CTS stall, который можно обнаружить и восстановить;
• silent modulation collapse, который цифровая телеметрия не видит.

2. PA=0x50 описано как текущая сохранённая точка

Строки 129–131 утверждают, что снижение мощности улучшило устойчивость и было сохранено как рабочая настройка.

Доказано только:

• 0x50 находилось на 0,531 дБ ниже измеренного плато 0x60;
• это соответствует примерно 88,5% принятой мощности;
• дальнейшее снижение давало более заметную потерю.

Устранение первопричины не доказано. Кроме того, current RF init сейчас снова содержит PA level 0x7F в D:\868_3_431\firmware\stm32g431\rf\rf.c.

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

3. Устойчивость 910 МГц сформулирована слишком категорично

Повторные наблюдения действительно показывали различие 868 и 910 МГц, но полностью matched-прогон с идентичной геометрией и сохранённым внешним воздействием не был оформлен.

Безопасная формулировка:

В проведённых повторных физических проверках сетка около 910 МГц срывов не показала, тогда как около 868 МГц проблема воспроизводилась.

4. STOP0 назван глубоким сном

В строке 143 лучше написать «в используемом режиме сна STOP0».

Пятнадцатичасовой опыт доказал отсутствие заметного падения напряжения с разрешением 0,001 В. Он не является точным автоматизированным измерением тока в микроамперах.

5. Число программ противоречит заявленному полному контуру

53–54 тыс. строк — защищаемая оценка четырёх основных кодовых контуров при конкретной методике подсчёта. Но производственный пульт ниже тоже назван частью системы, хотя в эти четыре продукта и в число строк он не входит.

Рекомендуемая формулировка:

Четыре основных кодовых контура — STM, ESP/Web, Studio и Bench — плюс отдельный производственный пульт.

Если число строк останется в hero, рядом нужно указать дату среза, включённые корни и факт исключения vendor/build/archive. Иначе метрика непроверяема.

6. 83 датированных этапа — неточное название

Это 83 датированных каталога работы за 2026-07-19..2026-08-22. Среди них есть 23 подготовки/стратегии/ТЗ, 17 execution/implementation и отдельные аудиты. Некоторые пары описывают один большой этап.

Лучше:

83 датированных рабочих каталога и контрольных точки за последний интенсивный период.

До этого существует ещё 75 отобранных исторических отчётов за май–июль. Это не нужно складывать в искусственные «158 задач», но ранний пласт необходимо упомянуть.

7. Человеко-месяцы делятся слишком линейно

Фраза «12 человеко-месяцев — примерно три месяца команды из четырёх» верна только арифметически. Реальный RF/embedded-проект имеет последовательные зависимости, один стенд и общий аппаратный экземпляр.

Добавить:

Арифметическое деление не равно календарному плану: физические эксперименты, интеграция и приёмка выполняются последовательно и не распараллеливаются пропорционально размеру команды.

8. Финальная цена запрета инструментов не следует из таблицы

Строка 290 говорит, что запрет «добавляет 15–30 млн ₽». Но 15–30 млн ₽ выше указано как полная стоимость фактического пути внутри компании, а не как дельта.

Разница между сценариями 8–15 и 15–30 находится примерно в диапазоне 7–15 млн ₽, но даже это сравнение смешивает «повторить известный результат» и «пройти неизвестный исследовательский путь».

Защищаемая формулировка:

Без сопоставимой автоматизации и сохранения полного контекста такой объём оценивается в 25–40 человеко-месяцев, или примерно 15–30 млн рублей внутри компании; внешний R&D-контракт мог бы стоить 25–50 млн рублей.

9. Коэффициенты ускорения выглядят измеренными

10–30×, 5–10×, 4–7× нужно пометить как экспертную оценку порядка величины по наблюдавшимся циклам, а не как результат отдельного хронометражного исследования.

10. Зарплатные источники имеют разную выборку

Общая медиана 183 333 ₽ взята из исследования Хабр Карьеры на 52 123 зарплатах. Senior/lead 370–380/540–570 тыс. ₽ взяты из отдельного исследования Grades всего на 660 записях. Числа процитированы правильно, но вторую оценку нужно назвать меньшей ориентировочной выборкой.

Стоимость 0,5–0,8 млн ₽/месяц — собственный расчёт loaded cost, а не число из этих источников. Стоит одной фразой раскрыть переход от зарплаты на руки к стоимости для компании.

11. «Несколько компьютеров» звучит рекламно

В hero точнее и сильнее написать:

два микроконтроллера, три радиомодуля и несколько независимых программных контуров.

Что сохранить из текущей статьи

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

Что сократить или переместить

• семь точек остановки сейчас почти все относятся к нескольким последним RF дням;
• подробности 0x50, guard, 868/910, FIFO reset и WDS не должны занимать половину смыслового веса статьи;
• внутренние имена резервов и файлов лучше держать в <details> либо сносках;
• повторения мысли «интерфейс зелёный, а физика сломана» можно объединить;
• словарь на 13 терминов появляется после того, как термины уже использованы.

Как перестроить раздел «где обычный бизнес остановился бы»

Сейчас почти все остановки относятся к августовскому RF-расследованию. Лучше распределить их по всей хронологии:

1. заработала первая генерация и два режима — можно было оставить прототип;
2. заработал лабораторный Scan — можно было не оптимизировать acquisition и detector;
3. закончилась миграция на G431 — можно было сохранить старую архитектуру;
4. появились Studio/package/ESP UI — можно было не заниматься единым owner и атомарностью;
5. финальная product acceptance 12 августа дала формальный PASS;
6. bounded recovery практически обработало внешний CTS stall;
7. clean-room и тихий M3 показали границу дальнейшего экономического смысла.

Тогда раздел действительно покажет, сколько раз продукт был «достаточно готов», а не только сколько раз можно было прекратить один RF-аудит.

Предлагаемая новая структура статьи

1. Короткий ответ: это не прошивка, а продуктовая экосистема.
2. С чего начинали: 433 → 868 → PN9 → F030/G431 и накопившееся легаси.
3. Что пришлось построить: STM, ESP/Web, Studio, Bench и производственный пульт.
4. Почему стенд не был бесплатным: его создание, оборудование и эволюция.
5. Почему легаси съедает месяцы: восстановление скрытых контрактов и цена безопасного удаления.
6. От демонстрации до продукта: сон, питание, NVM, OTA, пакет, UI и приёмка.
7. Один подробный RF-кейс: M3 как доказательство необходимости физического стенда.
8. Работа, которой нет в финальном коде: удалённые подсистемы, архивы и неудачные ветки.
9. Человек, автоматизация и физическая лаборатория: кто что реально делал.
10. Прозрачная оценка трудозатрат и денег.
11. Вывод: цена не количества строк, а восстановления знания и доказательства результата.

Предлагаемый центральный тезис

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

Как обосновать оценку стоимости

Оценку 25–40 человеко-месяцев лучше показать как engineering judgement по непересекающимся блокам, а не как число, появившееся из воздуха. Возможная структура без ложной точности:

Блок работы	Ориентир
STM, RF, Scan, power и legacy-археология	8–12 чел.-мес.
ESP, Web, protocol, package storage и OTA	4–6 чел.-мес.
Studio и compiler/package workflows	3–5 чел.-мес.
Bench, интеграция приборов и производственный пульт	5–8 чел.-мес.
Аппаратные эксперименты, сквозная интеграция, приёмка и документация	5–9 чел.-мес.

Категории частично связаны, поэтому это не бухгалтерский timesheet, а проверяемое объяснение диапазона 25–40 человеко-месяцев.

При loaded cost 0,5–0,8 млн ₽/месяц арифметический диапазон составляет 12,5–32 млн ₽; округление до 15–30 млн ₽ выглядит разумным как оценка порядка величины. Подрядная цена 25–50 млн ₽ может включать риск, управление, маржу и ответственность за конечный результат.

Важная редакторская оговорка про NDA

Конфиденциальность сама по себе не запрещает современные инструменты. Их запрещает конкретная политика, если компания не допускает согласованные enterprise/private/on-prem решения.

Поэтому лучше писать не «NDA делает проект дорогим», а:

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

Так вывод остаётся сильным, но не превращается в легко опровергаемый тезис «любой NDA запрещает AI».

Финальная оценка исходного материала

Текущая статья не плохая и не выдуманная. Её фактическая база в основном реальна, а отдельные RF-примеры сильны. Проблема — неверный масштаб повествования. Она подробно описывает последние тяжёлые дни, но почти не показывает месяцы превращения прототипа в продукт и создания инфраструктуры, которая вообще позволила провести эти последние исследования.

Правильная переработка должна:

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

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