Политики и регламенты. Как писать правила так, чтобы ими реально пользовались

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

В такие моменты ответственность ложится на конкретных людей. Решения принимаются не по инструкции, а на основе устоявшейся практики. Выбор стоит между формальным соответствием процессу и реальными последствиями для пользователей и бизнеса.

Почему политики и регламенты не работают

Часто внутренние правила и процедуры написаны людьми, которые не имеют представления о повседневной работе команды. Это может быть менеджмент, HR, службы безопасности или юристы. Они видят требования, но не видят настоящую последовательность действий, точки напряжения и компромиссы. В результате документ описывает идеальный процесс, который не совпадает с практикой.

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

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

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

Чаще всего к таким правилам возвращаются только во время проверок, чтобы показать, что документ есть, процесс описан и сотрудники ознакомлены. Другой вопрос, работает ли это в реальной жизни.

При этом сама система редко проверяет применимость требований, они живут сами по себе. Из-за отсутствия обратной связи, компании узнают о проблемах слишком поздно. Если за нарушение правил следует наказание или формальная фиксация, то добиться честной обратной связи от сотрудников очень сложно. В результате причины проблем не анализируются, нарушение воспринимается как вина конкретного человека, а не сигнал проблемы в самом правиле. В такой системе важнее не улучшать процессы, а просто их не нарушать. В итоге в отчетах все выглядит хорошо, а реальные проблемы остаются. Со временем сотрудники перестают о них говорить. Формируется культура, в которой важнее научиться жить с нерабочими процессами, чем задавать неудобные вопросы.

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

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

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

Идея выглядит правильно - сделать изменения управляемыми и снизить риски. Для запланированных релизов все действительно работало. Создавали запрос, описывали шаги, согласовывали изменения. Если случался инцидент, например, падал сервис, то ждать согласование изменений было уже невозможно. Решения принимались в чатах и на звонках, инженеры восстанавливали систему и перезапускали компоненты, ориентируясь на текущую ситуацию.

Из-за того, что регламент требовал сначала получить одобрение, а уже потом вносить изменения, оформление запросов и всех необходимых согласований происходило задним числом. Описание подгонялось под уже выполненные действия.

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

Правила работают, если…

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

Читайте также

Государство хочет знать раньше. К чему ведет централизация уведомлений об инцидентах

Государства по всему миру переходят от разовых уведомлений о киберинцидентах к модели непрерывной осведомленности — с быстрыми сигналами, регулярными обновлениями и централизованным сбором данных. Это меняет не только требования регуляторов, но и саму логику работы бизнеса с инцидентами, превращая уведомление в отдельную управленческую функцию. О том, к чему ведет эта трансформация и какие риски она несет, — в материале IT-World.

Но при следующем инциденте все повторяется, по привычке чинят, созваниваются, списываются в чатах. В реальной жизни, когда что-то идет не по плану, решение принимает тот, кто находится ближе к проблеме. А регламент потом пишут, чтобы зафиксировать случившееся и показать, что проблема под контролем. Здесь и появляется разрыв между настоящей работой и документом.

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

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

Документ не обязан отвечать на все возможные вопросы, он должен помогать ориентироваться в ситуации, задавать рамки: что является приоритетом, где возможны отклонения и в каких случаях нужно подключать других.

Хорошее правило начинается с цели, а уже потом описывает порядок действий. Команде важнее видеть, зачем они это делают, чем просто выполнять прописанные шаги. Сотрудники должны видеть цель, понимать границы, в которых можно действовать. Нужно принимать решения исходя из смысла. Важны критерии и приоритеты, а не строгая последовательность шагов.

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

Баланс между формальными требованиями и живыми процессами

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

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

Такой баланс требует доверия к команде. Вместо жесткого контроля появляется ответственность, сотрудники понимают, почему принято то или иное правило. Они чувствуют свое участие в его развитии. Это снижает сопротивление и делает соблюдение требований естественной частью работы, а не навязанной обязанностью.

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

Работающие правила - это не идеальные документы, а отражение реальной работы команды, зафиксированные простым языком, с понятной всем целью и возможностью адаптации. Такие правила не мешают работе, а помогают ориентироваться в сложных ситуациях и принимать решения осознанно.

В моей текущей команде подход к изменениям и инцидентам устроен следующим образом. Формально тоже существует политика управления изменениями, но она построена вокруг приоритетов и ответственности, а не вокруг последовательности согласований. Основная цель - как можно быстрее восстановить работоспособность сервиса и минимизировать влияние на пользователей.

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

• при инциденте приоритет всегда у восстановления сервиса;

• инженер, находящийся ближе всего к проблеме, имеет право принимать технические решения без предварительных согласований;

• формальные процедуры не должны блокировать экстренные действия;

• изменения в рамках инцидента считаются допустимыми, если они направлены на стабилизацию системы.

Вместо длинного описания процесса используется короткий чек-лист:

Читайте также

Николай Городецкий: «Мы выстроили сквозную модель от первого запроса клиента до отгрузки»

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

1. Зафиксировать инцидент в общем канале.

2. Назначить ответственного.

3. Сконцентрироваться на восстановлении сервиса.

4. Параллельной вести краткий лог действий.

5. После завершения оформить изменения и провести разбор.

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

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

Заключение

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