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

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

От бумаги к процессу: где обычно ломается внедрение

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

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

Пришлось пересмотреть подход к документации. Вместо объемных мануалов, которые никто не читал, стали использовать чек-листы и визуальные схемы процессов прямо в Trello и Jira. Ключевое — привязать каждый пункт чек-листа к конкретному выходному результату этапа. Не ?проверить код?, а ?проверить код на соответствие стандарту безопасности PSD2, пункт 3.2?. Это сразу добавило осмысленности. Кстати, наш сайт https://www.hnjhkjjt.ru в разделе методологии частично отражает этот подход — мы вынесли туда не сухие принципы, а именно схемы взаимодействия, которые родились из этих самых разборов.

Роль цифровых инструментов: не автоматизация ради автоматизации

Многие коллеги из сферы digital ошибочно полагают, что система управления качеством в IT — это в первую очередь набор софта для баг-трекинга и CI/CD. Инструменты важны, но они вторичны. Сначала должен быть консенсус по процессу. У нас был опыт внедрения дорогой системы управления тестированием, которая в итоге простаивала, потому что тестировщики продолжали работать в привычных Excel-таблицах — новый инструмент не решал их главных проблем, а лишь добавлял отчетности.

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

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

Люди и культура: самая ненадежная и самая важная основа

Вот что точно не купишь и не скачаешь — это культура качества. Ее не внедрить приказом. В ООО Хэнань Цзюйхэ Текнолоджи, как в компании, оказывающей услуги трансформации, мы поняли, что должны демонстрировать тот же подход к качеству, который проповедуем клиентам. Иначе это лицемерие. Начинается все с малого — с того, как проходит внутреннее совещание. Если на нем можно открыто сказать руководителю проекта, что сроки нереальны без ущерба для качества, — система работает. Если нет — это профанация.

Мы пробовали вводить KPI, привязанные к качеству, но это slippery slope. Сотрудники начинают оптимизировать метрики, а не реальный результат. Гораздо лучше сработало публичное признание за найденные ?процессные? ошибки, которые предотвратили потенциальный сбой у клиента. Это сместило фокус с наказания за ошибки на поощрение за их раннее выявление. Создало атмосферу, где не страшно сообщить о проблеме.

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

Интеграция с клиентом: где заканчивается наша система и начинается общая

Это, пожалуй, самый сложный пласт. Можно выстроить идеальную внутреннюю систему управления качеством, но если клиент не интегрирован в процесс, результат будет хромым. Мы для себя сформулировали правило: ключевые контрольные точки (gate reviews) должны быть совместными. Не мы присылаем отчет, а проводим сессию с представителями заказчика, где вместе сверяем выходные артефакты с изначальными требованиями.

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

На сайте https://www.hnjhkjjt.ru мы сознательно не выпячиваем фразы вроде ?гарантия качества?, потому что это пустой звук. Вместо этого в описании кейсов стараемся показать, как именно было организовано взаимодействие, как проходила приемка. Это честнее. Клиент, который читает это, понимает, что имеет дело не с продавцом софта, а с партнером, который думает о процессе в целом.

Постоянная переоценка: система не монолит, а живой организм

Главный вывод за годы работы: если ваша система управления качеством не менялась два года — она мертва. Технологии, рынок, ожидания клиентов меняются слишком быстро. Мы раз в полгода проводим аудит не на соответствие стандартам (это само собой), а на полезность. Собираем обратную связь от всех команд: что из процедур стало рутиной, что реально помогает, чего не хватает.

Например, с приходом agile-методологий в большие промышленные проекты пришлось перекраивать процессы контроля качества. Жесткие gate reviews на каждом этапе стали тормозить. Пришлось разработать гибридную модель, где есть обязательные контрольные точки по вехам контракта, но внутри спринтов действуют облегченные процедуры проверки. Это был болезненный переход, но необходимый.

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