Когда я устроился в СПб ГБУ «Центр транспортного планирования» ещё студентом, процесс рассмотрения документации казался мне чёрным ящиком. Я видел, как опытные коллеги быстро проверяют огромные и очень разные проекты. Тогда мне казалось, что они просто “знают всё наизусть”. Позже я понял: на самом деле они смотрели не на нормы. Они сперва видели проблему на чертеже, понимали, что именно смущает, а уже потом находили нормативный пункт, который это подтверждает.

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

В какой-то момент мне это надоело, и я решил попробовать превратить процесс проверки в систему.

Сначала я проанализировал письма организации за несколько лет — замечания, которые писали эксперты по итогам рассмотрения документации. Я начал выписывать формулировки и быстро заметил закономерность: одни замечания были точными и однозначными, а другие — расплывчатыми и двусмысленными.

Документы чиновников не могут себе позвлить оставлять пространство для трактовки. В итоге я вывел для себя универсальную структуру замечания: — что не так в проекте; — какая норма нарушена с конкретной цитатой; — что фактически показано в проекте. По сути: “норма требует вот это, в проекте сделано вот так”. Без эмоций и без разночтений. Так проверка начала превращаться из “мнения эксперта” в понятную типизированную коммуникацию.

Следующим шагом я решил разобраться не с отдельными нормами, а вообще со всем перечнем требований, которые относится к полномочиям организации. Для этого я: — проанализировал прошлые замечания; — выписал нормативы, на которые ссылались коллеги; — отдельно изучил полномочия нашей организации и смежных ведомств; — прочитал нормативные документы и своды правил целиком, отмечая требования, которые относятся именно к нашей зоне ответственности. В результате появился не абстрактный подход “проверяем транспортную часть”, а конкретный перечень пунктов СП и нормативов, на соответствие которым нужно проверять документацию.

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

После этого появился своего рода технологический чек-лист проверки. Эксперт во время просмотра документации отмечал: — что именно он проверил; — какую норму применял; — есть замечание или требование соблюдено. Если нарушений нет — замечание удалялось и ставилась отметка “соблюдено”. Такая своего рода геймификация процесса проверки проекта.

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

Организация перестала хранить знания только “в головах” отдельных специалистов. Появилась структурированная информация о том: — что именно проверяется; — почему это проверяется; — как предоставлять результат проверки.

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

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

На сколько знаю, организация и по сей дей пользуется этой системой.