Выявляем скрытые сигналы по всему циклу

  • 01

    Источники требований: доля с прослеживаемым происхождением

    Какая часть формализованных требований связана с источником: заявка или ТЗ заказчика, пункт контракта, дорожная карта продукта, стандарт, замечание аудита, обращение поддержки. Считаем по вашим системам приёма постановки. Серый сигнал — источники есть, но в стеке не связаны с требованиями.
  • 02

    Полнота входа: необработанный поток постановки

    Объём и возраст входящих запросов и изменений без решения (принято, отклонено, отложено) — для продуктового бэклога и для потока изменений по договору. Показывает, не теряется ли постановка на входе SDLC.
  • 03

    Доля требований с понятным статусом согласования

    Какая доля требований в актуальной версии имеет явный статус и ответственного — в том числе согласование с заказчиком или внутренним владельцем продукта. Без статусов в данных процесс проектирования не измерить.
  • 04

    Планирование: связь плана с постановкой и обязательствами

    Доля элементов плана (этапы, вехи, спринты, поставки по договору), связанных с утверждёнными требованиями или пунктами контракта/ТЗ. Если план живёт отдельно от постановки, сроки формально есть, а управлять объёмом нельзя.
  • 05

    Планирование: план / факт по срокам и вехам

    Отклонение фактических дат от базового или рабочего плана: внутренние вехи продукта и контрактные этапы (промежуточная/окончательная приёмка). Берём из ваших систем планирования и учёта проектов. Рост отклонения при «зелёных» задачах — типичный серый/красный сигнал.
  • 06

    Планирование: устойчивость объёма к изменениям

    Доля и влияние согласованных изменений объёма после базовой линии: change request по договору или пересмотр scope продукта. Смотрим, фиксируются ли изменения в стеке вместе с пересчётом сроков и проверок — иначе план и контракт расходятся с реальностью.
  • 07

    Покрытие требований проверками

    Доля утверждённых требований, связанных с достаточными проверками — по вашему контуру. Для заказной разработки особенно важно перед этапами приёмки. Методика — на странице покрытия требований тестами.
  • 08

    Сироты и целостность трассировки

    Объекты без обратной связи и доля обязательных связей по согласованной модели — от источника/контракта до проверки и поставки. Много сирот или битых связей — артефакты SDLC не собраны в наблюдаемый граф. О практике — на странице трассировки требований.
  • 09

    Отставание проверок от изменений требований

    Сколько требований или пунктов объёма изменились, а связанные проверки не пересмотрены. В заказных проектах это частая причина срыва приёмки; в продуктовых — поздних переделок. Если цепочку из стека не собрать, сигнал серый.
  • 010

    Разработка: работы без связи с постановкой и планом

    Доля задач и поставок без привязки к утверждённому требованию, этапу плана или обязательству по договору. Показывает, идёт ли разработка от согласованного объёма или «сама по себе».
  • 011

    Разработка: блокировки и ожидание из‑за постановки

    Время в ожидании уточнений, которые по вашей классификации связаны с неясной или меняющейся постановкой — в том числе ожидание ответа заказчика. Отделяем от общего простоя мощностей и от возвратов из‑за качества исполнения.
  • 012

    Инженерия: простой исполнителей и ресурсов

    Доля времени, когда инженеры, проектировщики или стенды/среды простаивают: нет постановки, нет входных данных, занято оборудование, ждут смежный контур (механика, электроника, ПО). Для ПАК простой часто дороже «пустого» статуса в трекере — считаем по вашему учёту загрузки и простоев.
  • 013

    Инженерия: перегрузка работами

    Фактическая загрузка относительно нормы: число параллельных задач на человека, сверхурочные, срыв внутренних сроков из‑за перегруза, концентрация критичных работ на узком круге специалистов. Смотрим по командам и ролям (разработка, проектирование, расчёты) — как это отражено в вашем стеке планирования и учёта времени.
  • 014

    Инженерия: задачи и артефакты вне системы

    Доля инженерных работ, которые идут мимо учёта в основном контуре: проектирование схем и плат, моделирование, математические и прочностные расчёты, подготовка конструкторской документации, стендовые прогоны. Если результат появляется только «файлом в папке», сигнал серый или красный: для ПАК это часто основная часть цикла, а не обочина.
  • 015

    Инженерия: связь схем, моделей и расчётов с постановкой

    Какая часть схем, моделей, расчётов и конструкторских артефактов связана с требованиями, изменениями и этапами плана/договора. Без связи нельзя оценить влияние изменения ТЗ на железо и математику — типичный разрыв именно на ПАК, даже когда код учтён хорошо.
  • 016

    Качество работы: процент возвратов

    Доля работ, возвращённых на доработку с ревью, тестирования или приёмки (в том числе приёмки заказчиком и конструкторского/схемотехнического контроля), в разрезе команд и ролей. Высокий процент возвратов при стабильной постановке — сигнал о качестве исполнения и критериях «готово».
  • 017

    Качество работы: ошибки и дефекты исполнения

    Плотность и доля дефектов реализации (не постановки): код, схемы, модели, расчёты — найденных на ревью, в тестах, на стенде, на приёмке и после передачи. Смотрим по командам/авторам в том виде, в каком учёт уже ведётся. Повторные ошибки одного типа — признак системного разрыва в практиках.
  • 018

    Качество работы: продуктивность по поставке

    Темп полезной поставки: завершённые задачи и изменения за период, частота успешных слияний или выпусков комплектов документации/прошивок, объём принятых результатов — в связке с долей переделок. Не гонимся за «строками ради строк»: важна ценность для продукта или этапа договора.
  • 019

    Качество работы: ревью кода и инженерных артефактов

    Срок до первого ревью, длительность цикла, число кругов доработки, плотность замечаний и доля принятых с первого раза — для кода, схем, моделей, расчётов и тестовой документации, как это устроено у вас. Показывает нагрузку на ревьюеров и зрелость подготовки изменений.
  • 020

    Развёртывание и передача: готовность к выпуску или приёмке

    Доля объёма поставки, закрытая проверками с приемлемым результатом, плюс открытые критичные дефекты на момент выкладки, прошивки, стендовой сдачи или передачи заказчику. Для продукта — релиз; для заказа и ПАК — этап/окончательная приёмка. Считаем по вашему контуру.
  • 021

    Развёртывание: сбои выпуска и дефекты после передачи

    Откаты, срочные исправления после выкладки или поставки комплекта, дефекты, впервые найденные в эксплуатации, на стенде у заказчика или после приёмки этапа. Связываем с поставками в стеке — насколько выпуск и передача предсказуемы.
  • 022

    Бизнес и контракт: срок вывода на рынок и срок по договору

    Для продукта — время от потребности или утверждённой постановки до доступности пользователю (Time to Market). Для заказной разработки и ПАК — соблюдение контрактных сроков этапов и окончательной поставки. Точки старта и финиша — как заданы у вас в процессах и системах.
  • 023

    Бизнес и контракт: доля обязательств вовремя

    Доля вех, релизов и этапов договора, выполненных к согласованной дате, плюс срок поставки изменения (от взятия в работу до выпуска или передачи). Классическая предсказуемость — на ваших данных о плане, приёмках и поставках.
  • 024

    Бизнес: доля усилий на переделки и видимость ИИ

    Оценка доли трудозатрат на повторные работы (код, схемы, модели, расчёты) и доля материалов с ИИ, привязанных к согласованной постановке и рецензии. Вместе с простоем, перегрузкой и возвратами показывают: идёте ли к сроку или к невидимым потерям. Эффект — на странице оценки процесса разработки.

Зачем индикаторы и как их считаем

На технологическом стеке клиента по всему циклу: каналы постановки и условия договора, требования и тестирование, планы и вехи, трекеры, учёт загрузки и простоев, контур ревью, хранилища схем/моделей/расчётов — если есть доступ, дефекты и возвраты, сборка, стенды, приёмка. Индикаторы — смысл сигналов; дашборд — как мы их показываем руководству и команде на ваших данных.

Обычный дашборд часто рисует занятость и статусы задач. Мы собираем дашборд здоровья процесса: что измеримо в стеке, что серое «не достать», где скрыты простой, перегрузка, работы вне системы и разрывы постановки. Цель — увидеть проблемы, а не украсить отчёт.

Да. В заказных проектах точки контроля часто заданы контрактом: ТЗ, этапы, сроки, приёмка. Для ПАК рядом с кодом критичны схемы, модели, расчёты, стенды и смежные контуры — поэтому в наборе есть простой, перегрузка и работы вне системы. Для продукта акцент смещается на бэклог, релизы и срок вывода на рынок — логика набора та же.

Без связи плана с постановкой и обязательствами сроки существуют «на бумаге»: задачи зелёные, а веха или этап договора сдвигается. План/факт и учёт изменений объёма показывают, управляете ли вы сроком или только фиксируете опоздание задним числом.

В инженерии ПО и особенно ПАК срок часто съедают не «красные» задачи, а простой (ждут данные, стенд, смежников), перегруз узких специалистов и работа мимо учёта — схемы, модели, мат. расчёты «в папках». Если этого не видеть, картина SDLC выглядит как чистая разработка кода и врёт по загрузке и рискам.

Чтобы отделить проблемы постановки от проблем исполнения. Процент возвратов, ошибки (включая схемы и расчёты), темп поставки и метрики ревью — по вашему учёту, в разрезе команд и ролей. Цель — узкие места процесса, а не «рейтинг наказаний»; серый сигнал часто значит, что возвраты и причины дефектов не классифицируются.

Что по вашему стеку метрику нельзя посчитать устойчиво: нет связей с контрактом, базовой линии плана, учёта простоев, статусов согласования, дат приёмки или выгрузки по схемам/моделям. Это факт о наблюдаемости, а не приговор инструменту.

Нет. На экспресс-срезе берём доступные данные по цепочке SDLC — с учётом того, продукт у вас или заказные проекты, — и честно помечаем остальное серым. Дальше набор уточняют под договорную модель, отрасль и связи.

Фиксируем картину и влияние на сроки, приёмку, качество и аудиты. При необходимости — оценка процесса и варианты усиления контура. Компоненты Devprom — только там, где закрывают конкретный разрыв; срез не требует смены стека.

Индикаторы — общий язык на вашем стеке для продуктовых команд и проектных контуров. Повторяем срез раз в квартал: было / стало по постановке, плану, разработке, выпуску и срокам — без обязательства сразу менять инструменты.

Запросите экспресс-срез. Уточним, какой у вас микс продуктовой и заказной разработки, перечислим источники в стеке по этапам SDLC (включая план и договорные вехи), покажем зелёное / красное / серое и согласуем следующий шаг.