Дефектовка должна управлять работами

Плохая дефектная ведомость выглядит как список раздражающих замечаний: 'не работает', 'проверить', 'нет связи'. Хорошая ведомость показывает, что именно не работает, где, почему это важно для сдачи и каким действием закрывается.

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

Какие графы нужны

Минимальный набор: корпус, секция, этаж, помещение, система, оборудование, описание дефекта, вероятная причина, риск, приоритет, ответственный, срок, способ проверки устранения.

Если дефект находится на границе со смежной системой, это нужно писать отдельно. Иначе все замечания автоматически начинают возвращаться в сторону АПС и СОУЭ.

  • тип замечания: монтаж, питание, линия, конфигурация, АРМ, смежная система
  • влияние на сдачу: блокирует, критично, важно, второстепенно
  • контрольная точка проверки
  • что должно измениться после устранения

Практический прием

Формулировка должна позволять проверить устранение без автора ведомости. Вместо 'проверить СОУЭ в секции 2' лучше писать: 'Секция 2, этаж 12, зона оповещения 2.4: при пожарном событии от ИПР не запускается речевой канал. Проверить выход модуля, линию усилителя и событие в АРМ'.

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

Практический чеклист

  1. Разделить замечания по типам и приоритетам.
  2. Указывать место, систему, оборудование и проверяемый результат.
  3. Отдельно помечать границы со смежными системами.
  4. После устранения фиксировать способ проверки, а не только факт выполнения.