
Когда говорят про составляющие системы управления качеством, многие сразу представляют себе гору документов: политики, процедуры, инструкции. И в этом кроется главная ошибка. На деле, если эта система — живой организм, то документы это скелет, но без мышц, нервов и кровообращения он просто рассыплется. В ООО Хэнань Цзюйхэ Текнолоджи мы через это прошли, когда начинали внедрять процессы для проектов цифровой трансформации. Сначала сделали красивый мануал, а потом оказалось, что команда его просто не чувствует. Вот с этого, пожалуй, и начну.
Итак, первая и самая очевидная составляющая — документационная база. Но здесь важно не количество, а связность. Раньше мы, как и многие, считали, что главное — прописать все до мелочей. Получился том, который никто не открывал. Ошибка была в подходе: мы описывали идеальный мир, а не реальные процессы команды разработки и внедрения.
Потом пришло понимание: ключевые документы — это те, которые ?работают? ежедневно. Не политика качества на три страницы, а чек-лист приемки этапа проекта или шаблон фиксации требований заказчика. Именно они становятся точками касания системы с реальностью. Мы переработали все, оставив только оперативные документы. Остальное перевели в справочные разделы на внутреннем портале. Резко упало сопротивление сотрудников.
Кстати, наш сайт — https://www.hnjhkjjt.ru — это тоже часть внешней документации системы. Информация для клиентов о наших подходах должна быть прозрачной и соответствовать внутренним правилам. Но это уже следующий уровень — коммуникация.
Вторая группа составляющих — это процессы. И вот здесь без личного опыта не разберешься. Можно взять за основу ISO или любую другую модель, но если не адаптировать ее под специфику компании, толку не будет. В ООО Хэнань Цзюйхэ Текнолоджи, как у поставщика услуг цифровой трансформации, критически важны процессы управления требованиями и изменениями.
Поначалу мы пытались разделить ответственность строго по отделам: аналитики собирают требования, разработчики делают, тестировщики проверяют. На практике это создавало ?слепые зоны?. Качество проседало на стыках. Пришлось вводить сквозные процессные владельцев для ключевых потоков, например, для потока ?Разработка нового модуля интеграции?. Это не менеджер проекта в классическом смысле, а человек, отвечающий за целостность процесса от идеи до передачи заказчику.
Это было болезненно. Люди привыкли к вертикали. Но когда владелец процесса из отдела разработки сам начал инициировать встречи с аналитиками на ранних этапах, чтобы обсудить технические ограничения, количество доработок на поздних стадиях упало заметно. Вот это и есть живая система управления качеством — не когда контролер проверяет, а когда каждый участник понимает свою роль в общем результате.
Третий блок — метрики. Измерять все подряд — путь в никуда. Мы наступали на эти грабли. Собирали десятки показателей: количество багов, время на исправление, удовлетворенность заказчика по пятибалльной шкале... Анализировать это стало неподъемной задачей, а решения по улучшению принимались наобум.
Сейчас мы используем всего несколько ключевых метрик, но зато они действительно влияют на решения. Например, для нас как для компании, фокусирующейся на цифровой трансформации, критичен ?цикл времени от идеи до рабочего прототипа?. Это не просто скорость, это показатель слаженности всех составляющих системы: насколько четко сформулированы требования, как быстро они доходят до разработки, как настроены процедуры тестирования.
Еще одна важная метрика — процент повторных обращений заказчика по одной и той же проблеме. Она говорит не об работе техподдержки, а о качестве первоначального решения и документации. Если этот процент растет в каком-то направлении, мы не штрафуем сотрудников, а идем разбираться в процесс. Часто оказывается, что где-то потеряна важная информация или не проведено обучение клиента.
Можно иметь идеальные процессы и метрики, но если в компании культура ?сдать и забыть?, система будет буксовать. Это, пожалуй, самая сложная для формализации составляющая. В ООО Хэнань Цзюйхэ Текнолоджи мы долго не могли понять, почему после успешных проектов случаются провалы на, казалось бы, простых задачах.
Оказалось, все упирается в внутреннее обучение и обмен знаниями. Система качества должна не контролировать, а учить. Мы внедрили регулярные короткие разборы (не совещания!) по завершенным задачам: что прошло хорошо, где споткнулись, что можно взять на вооружение. Без поиска виноватых. Это сработало лучше любого мотивационного письма от руководства.
Еще один момент — вовлеченность рядовых специалистов в улучшение процессов. Например, наш ведущий интегратор как-то предложил изменить шаблон технического задания для определенного типа заказчиков. Он, исходя из своего опыта, видел, что мы постоянно упускаем один и тот же нюанс. Его предложение внесли в стандарт. Когда люди видят, что их практический опыт меняет правила к лучшему, система становится своей, а не навязанной.
Наконец, техническая база. Без адекватных инструментов даже самая продуманная система превратится в кошмар ручного труда. Речь не о покупке самого дорогого ПО для управления качеством. Речь о выборе того, что ляжет на ваши процессы.
У нас был этап, когда мы использовали три разных системы: для трекинга задач, для документооборота и для сбора обратной связи от клиентов. Информация терялась, дублировалась, контекст распадался. Сейчас мы движемся к унификации на одной-двух платформах, которые позволяют связать требование заказчика, задачу разработчику, тестовый сценарий и финальный отчет для клиента в одну цепочку.
Важный урок: инструмент должен быть гибким. Процессы в digital-трансформации меняются быстро, и ваша Jira или Bitrix24 должна позволять адаптировать workflow без месячных доработок от программистов. Иногда проще отказаться от какой-то ?крутой? автоматизации в пользу простого, но понятного всем ручного шага, который гарантированно будет выполнен.
Так что, если подводить неформальный итог, составляющие системы управления качеством — это не пункты в учебнике. Это взаимосвязанные элементы, которые имеют вес только в работе друг с другом. Документы без людей — мертвы. Процессы без метрик — слепы. Люди без инструментов — неэффективны.
Для компании ООО Хэнань Цзюйхэ Текнолоджи, которая строит цифровые решения для других, наша внутренняя система качества — это по сути наш продукт. Если мы не можем отладить процессы у себя, как мы можем предлагать трансформацию клиентам? Это не про сертификаты на стену, это про ежедневную практику.
Система никогда не бывает законченной. Сегодня мы пересматриваем подход к метрикам, завтра может появиться новый инструмент, который потребует изменить процесс. И это нормально. Главный признак того, что система живая — это не ее стабильность, а ее способность меняться без полного разрушения. Вот над этим мы и работаем, иногда методом проб и ошибок. Но это уже другая история.