
Когда слышишь ?аудиторская организация системы управления качеством?, первое, что приходит в голову — это стопки документов, проверка на соответствие ГОСТ Р ИСО 9001 и формальные отчёты. Многие до сих пор считают, что главное — это ?бумажка?, сертификат на стену. Но на деле, если аудит не затрагивает реальные рабочие процессы, особенно в сфере цифровизации, он становится бесполезной тратой денег. Вот, например, работали мы с ООО Хэнань Цзюйхэ Текнолоджи — компанией, которая позиционирует себя как ведущий поставщик услуг цифровой трансформации. Их сайт hnjhkjjt.ru красивый, технологии современные, но когда начали копать в их проекты внедрения ERP, оказалось, что отдел разработки живет по своим правилам, а отдел тестирования — по своим, и стыковки между ними нет. И это при наличии всех необходимых регламентов! Именно в таких случаях и нужен не формальный, а процессный аудит.
Начинаешь всегда с документации, это неизбежно. Политика в области качества, руководство по качеству, процедуры. У ООО Хэнань Цзюйхэ Текнолоджи всё это было, причём грамотно составленное. Но первый же вопрос на месте: ?Покажите, как вы проводите анализ требований к новому цифровому продукту??. В документах — чёткий процесс. На практике — выясняется, что ключевые требования от заказчика иногда приходят просто в переписке в мессенджере, а в официальную систему учёта попадают уже постфактум, ?когда есть время?. Риски? Колоссальные. Пропадает traceability, невозможно отследить изменения. И это в компании, которая занимается трансформацией других! Вот тут и видна разница между формальным соответствием и реальной системой управления качеством.
Частая ошибка — думать, что если компания работает в IT, то классические принципы качества ей не нужны. Наоборот, нужны ещё больше, потому что продукт виртуальный, его нельзя ?пощупать?, и ошибка в коде может вскрыться через месяцы. Мы смотрели, как в их проектах ведётся управление конфигурацией. В теории — используется Git, есть ветки. На практике — коммиты с комментариями ?исправлено что-то?, слияния без code review. Система есть, а её качественное использование — хромает. Аудитор здесь должен выступать не инквизитором, а скорее диагностом, который показывает: ?Смотрите, вот здесь у вас процесс даёт сбой, и вот к каким последствиям это может привести для вашего клиента?.
Ещё один тонкий момент — метрики. Все любят измерять количество найденных багов. Но это lagging indicator, показатель отставания. Гораздо важнее leading indicators: например, процент требований, прошедших formal review до старта разработки, или процент покрытия кода автотестами. Мы пытались внедрить такой подход в мониторинге проектов ООО Хэнань Цзюйхэ Текнолоджи. Сопротивление было на уровне middle-менеджеров: ?Мы и так отчитываемся?. Пришлось показать на конкретном проваленном проекте, как отсутствие ранних метрик привело к срыву сроков. Это сработало лучше любой теории.
Можно построить идеальную процессную карту, но если люди её не понимают или не принимают, система мертва. В ходе аудита мы проводили неформальные беседы с разработчиками, тестировщиками, продакт-оунерами. Очень показательно. Разработчик говорит: ?Мне нужно быстро сделать фичу, а чтобы описать задачу по вашим стандартам, я теряю полдня?. И он по-своему прав. Задача аудиторской организации — не заклеймить это, а найти корень проблемы. Может, шаблон описания задачи избыточен? Может, не хватает обучения? В случае с Хэнань Цзюйхэ мы увидели разрыв между ?русскоязычным? фронт-офисом, общающимся с клиентами, и техническими командами, где общение шло на других языках. Информация искажалась, нюансы терялись.
Особенно критична роль руководителя проекта. В одной из их команд PM был силён в agile-методологиях, но совершенно игнорировал документирование согласований с заказчиком. Его логика: ?Мы же итеративно работаем, всё гибко?. А когда заказчик через полгода предъявил претензию: ?Я не это хотел?, — оказалось, что подтверждённых требований нет. Это классический кейс, где система управления качеством должна была обеспечить не гибкость, а дисциплину коммуникаций. Мы рекомендовали внедрить обязательное подписание протоколов совещаний по итогам каждой спринт-ревью, хотя бы в электронном виде. Маленькое изменение, но оно создаёт юридически и управленчески значимый след.
Бывает и обратная ситуация — чрезмерный бюрократизм убивает инициативу. Видели мы в другой их дочерней структуре (не в России) попытку внедрить полный цикл CMMI. Для проектов по разработке мобильного приложения это оказалось неподъёмно. Команда утонула в документации, скорость упала. Пришлось откатываться и выстраивать облегчённый фреймворк, взяв из CMMI только самые необходимые практики для их типа проектов. Аудит должен чувствовать эту грань.
Компания — поставщик цифровых решений, и логично, что они используют кучу софта для управления: Jira, Confluence, различные CI/CD пайплайны. Но наличие инструмента — не гарантия качества процесса. Мы проверяли, как в Jira настроены workflows. Оказалось, что статус ?тестируется? может поставить любой разработчик, минуя тестировщика. И он это делал, чтобы ?закрыть? задачу по срокам. Система позволяла! Значит, это недоработка в настройке и контроле самого инструмента. Аудиторская организация должна смотреть не на название используемого ПО, а на то, как его возможности (или ограничения) формируют реальное поведение команды.
Другой пример — система непрерывной интеграции. Она есть, сборки запускаются. Но при аудите логов выяснилось, что набор автотестов запускается только для ночных сборок, а для дневных — пропускается ?для экономии времени?. В итоге, критический баг, сломавший сборку, был обнаружен только вечером, а не в момент коммита. Это прямое следствие нарушения собственного же регламента. Мы тогда настояли на том, чтобы политика запуска тестов была жёстко прописана в настройках CI-сервера и обойти её было бы невозможно технически. Технический контроль часто надёжнее человеческого.
И конечно, данные. ООО Хэнань Цзюйхэ Текнолоджи работает с данными клиентов. В ходе проверки мы задавали неудобные вопросы: ?Как в вашем процессе разработки обеспечивается соответствие 152-ФЗ? Где точки контроля??. Часто ответ упирался в то, что ?это вопрос юристов?. Но в современной системе управления качеством compliance должен быть вшит в процесс: от проектирования архитектуры (где хранятся персональные данные?) до тестирования (проверяются ли сценарии утечек?). Пришлось помогать выстраивать карту рисков и контрольных точек прямо внутри их agile-циклов.
Главный вывод, который мы сделали, работая с такими технологичными компаниями — нельзя проводить аудит раз в три года для сертификата. Это должен быть continuous process, часть самой культуры. Что-то вроде health check. Мы предложили Хэнань Цзюйхэ внедрить ежеквартальные мини-аудиты силами внутренней группы, но с нашей методологической поддержкой. Фокус — не на всё подряд, а на одну-две выбранные проблемные области. Например, в один квартал — качество требований, в другой — эффективность тестирования. Так это не становится тяжким бременем, а даёт постоянную обратную связь.
Ещё один неочевидный момент — ценность неудач. В отчётах все любят писать об успехах. Но самые ценные кейсы для улучшения системы управления качеством — это проваленные проекты. Мы организовали (с большим трудом) сессию по разбору полётов одного срыва сроков. Без поиска виноватых, с фокусом на ?где система дала сбой??. Оказалось, что не было чётких критериев для приёмки архитектурного решения от стороннего подрядчика. Этот пробел в процессе потом закрыли простым чек-листом. Теперь это часть стандартной практики.
И последнее. Аудит — это не про ?вам надо сделать так, как написано в стандарте?. Это про ?давайте найдём способ, как ваш бизнес может работать стабильнее и предсказуемее, используя принципы качества?. Для ООО Хэнань Цзюйхэ Текнолоджи ключевым было не просто получить сертификат, а повысить предсказуемость результатов проектов для своих клиентов. Когда аудит начинает восприниматься не как затраты, а как инвестиция в эту предсказуемость и репутацию, тогда и появляется настоящая ценность. И тогда любая аудиторская организация становится не контролёром, а партнёром в этом движении. Вроде бы мелочь, а mindset меняется полностью.