отдел управление системы качества

Когда слышишь ?отдел управления системами качества?, многие сразу представляют себе людей, которые только и делают, что пишут инструкции и требуют их соблюдения. Это, пожалуй, самый живучий миф. На самом деле, если такой отдел работает правильно, он должен быть встроен в саму ткань бизнес-процессов, а не висеть где-то сбоку как надзиратель. У нас, в ООО Хэнань Цзюйхэ Текнолоджи, к этому пришли не сразу. Были и попытки просто ?получить сертификат?, и периоды, когда документация жила своей жизнью, а проекты — своей. Сейчас я понимаю, что настоящая роль такого отдела — это быть связующим звеном между стратегией цифровой трансформации, которую мы предлагаем клиентам, и тем, как эта трансформация реализуется на практике в каждом конкретном проекте. Это не контроль ради контроля, а создание предсказуемой среды, в которой даже сложные IT-решения рождаются с изначально заложенным качеством.

От формального соответствия к интеграции в процессы

Начиналось всё довольно стандартно. Руководство поставило задачу: внедрить систему менеджмента качества, скажем, по ISO 9001. Создали отдел управления системами качества, написали гору документов, провели аудит, получили красивый сертификат. И на этом всё затихло. Документы пылились на полке, а в оперативной работе о них вспоминали только когда ?проверяющие едут?. Разрыв был колоссальный. Особенно это било по проектам цифровой трансформации, где гибкость и скорость — ключевые факторы. Наши разработчики и архитекторы видели в процедурах отдела только бюрократические препоны, замедляющие работу.

Переломный момент наступил, когда мы начали крупный проект по цифровизации логистической цепочки для одного из наших заказчиков. Проект был сложный, с множеством интеграций. И в самый разгар работ выяснилось, что требования к API одного из внутренних модулей были задокументированы… неточно. Вернее, их задокументировал один инженер в своём блокноте, а команда работала по устным договорённостям. В итоге — сбой, переделки, сорванные сроки. Именно тогда стало ясно, что управление качеством — это не про отчётность перед руководством, а про обеспечение надёжности самого продукта на всех этапах. Наш отдел из ?карающего меча? должен был превратиться в ?инструмент поддержки?.

Мы начали перестраивать работу. Вместо того чтобы требовать от проектных команд заполнять формы постфактум, мы буквально ?вживили? своих специалистов в эти команды. Сейчас, например, аналитик из нашего отдела участвует в старте каждого нового проекта на стороне ООО Хэнань Цзюйхэ Текнолоджи. Его задача — не читать нотации, а помочь сразу структурировать требования, выделить критические точки качества (performance, безопасность, удобство интерфейса) и заложить процедуры их проверки прямо в план разработки. Это уже не контроль, а совместное проектирование качества.

Цифровая трансформация как объект управления качеством

Здесь кроется специфика нашей компании. Мы не производим станки, мы оказываем услуги по цифровой трансформации. А значит, наш ?продукт? — это зачастую нечто нематериальное: новый процесс, программный комплекс, модель данных. Как применить к этому классические принципы системы качества? Пришлось много думать и адаптировать.

Возьмём, к примеру, этап сбора требований. Раньше это могло быть просто многостраничное техническое задание. Сейчас мы настаиваем на создании ?живых? спецификаций — например, в виде набора пользовательских сценариев (user stories) с четкими критериями приемки (acceptance criteria). И наш отдел следит не за тем, красиво ли оформлен документ, а за тем, насколько эти критерии измеримы и тестируемы. Потому что если критерий звучит как ?система должна работать быстро? — это не критерий, это предмет для спора. А если ?отклик интерфейса на действие пользователя не должен превышать 2 секунд при 1000 одновременных подключений? — это уже конкретика, которую можно проверить и на которую можно ориентироваться.

Ещё один важный аспект — управление знаниями. В проектах трансформации часто создаются уникальные решения. Раньше после сдачи проекта ключевые разработчики уходили на другие задачи, а тонкости архитектуры оставались только в их головах. Сейчас одна из функций отдела управления системами качества — обеспечить, чтобы архитектурные решения, причины выбора тех или иных технологий, описание ключевых интеграций обязательно документировались в процессе работы. Мы используем для этого не громоздкие отчеты, а внутренние wiki-страницы и репозитории кода с комментариями. Это не для галочки, а для того, чтобы через полгода можно было безболезненно доработать систему или исправить ошибку.

Провалы, которые учат больше, чем успехи

Не всё, конечно, получалось гладко. Был у нас опыт внедрения одного модуля для управления тестированием. Выбрали, казалось бы, мощный и популярный инструмент, настроили сложные workflows, обязали все команды его использовать. Итог? Провал. Команды саботировали, работу выполняли в обход системы, данные были неактуальны. Мы проанализировали ошибку и поняли: мы навязали процесс, который не решал их реальных проблем, а лишь создавал дополнительную нагрузку. Мы действовали как ?полиция качества?, а не как партнёры.

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

Другой пример — попытка стандартизировать абсолютно все процессы под одну гребёнку. У нас есть команды, которые занимаются долгосрочными проектами трансформации ERP-систем, и есть команды, которые делают быстрые POC (Proof of Concept) для стартапов. Требовать от вторых такого же объёма документации и формальных согласований, как от первых — убить саму идею быстрого прототипирования. Пришлось разрабатывать гибкую модель, где уровень формализации процессов качества зависит от сложности, рисков и длительности проекта. Это сложнее, чем одна инструкция на всех, но зато это работает.

Как это выглядит в реальном проекте

Расскажу на примере недавнего проекта, информацию о котором можно найти на нашем сайте hnjhkjjt.ru. Мы разрабатывали платформу для анализа данных в ритейле. С самого начала, вместе с архитектором и проджект-менеджером, мы определили, что ключевыми атрибутами качества для этого продукта будут: точность расчётных алгоритмов (это основа), скорость обработки больших объёмов данных в near-real-time режиме и интуитивность визуализаций для бизнес-пользователей.

Для каждого атрибута мы определили метрики и способы проверки. Точность алгоритмов проверялась не только unit-тестами, но и регулярным прогоном на эталонных наборах данных с известным результатом. За это отвечала автоматизация, выстроенная при нашем участии. По скорости мы с самого начала заложили нагрузочное тестирование на каждом крупном этапе интеграции, а не в самом конце. Это позволило вовремя обнаружить и устранить ?узкое горлышко? в одном из микросервисов. По интерфейсу — мы организовали регулярные сессии с привлечением реальных представителей заказчика (не топ-менеджеров, а именно будущих пользователей-аналитиков) для сбора обратной связи на ранних прототипах.

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

Взгляд в будущее: качество как часть ДНК

Сейчас я вижу эволюцию роли нашего отдела. Мы постепенно уходим от понятия ?отдел? как некоего изолированного подразделения. Принципы управления качеством должны стать частью культуры каждой команды в ООО Хэнань Цзюйхэ Текнолоджи. Наша цель — чтобы каждый разработчик, каждый аналитик думал о качестве не потому, что его заставили, а потому что он понимает, как это влияет на успех проекта и удовлетворённость клиента.

Мы активно развиваем внутренние обучающие сессии, где не мы читаем лекции, а лучшие команды делятся своими кейсами: как они организовали код-ревью, как настроили CI/CD пайплайн с автоматическим тестированием, как работают с инцидентами. Это работает лучше любых приказов.

Ключевой вызов на будущее — это масштабирование такого подхода. Компания растёт, проектов становится больше, они усложняются. Как сохранить этот неформальный, но системный подход к качеству? Думаю, ответ лежит в правильном балансе между чёткими, но минимально достаточными, правилами игры (те самые ?системы?) и предоставлением командам автономии в их реализации. Наша задача — быть гарантом этого баланса, архитекторами процессов, а не их надсмотрщиками. В конце концов, конечная цель всего этого — чтобы клиенты, заходя на hnjhkjjt.ru, видели не просто список услуг, а могли быть уверены в надёжности и продуманности каждого нашего решения, от идеи до внедрения. И это та уверенность, которая строится не на словах, а на ежедневной, порой невидимой со стороны, работе по управлению качеством.