Проблема деградации CI/CD часто возникает после первоначального внедрения по нескольким причинам, связанным с человеческим фактором. Во-первых, это коллективное бессознательное и взаимная ответственность внутри команды, где решения принимаются сообща, а не одним человеком. Во-вторых, в командах часто существуют авторитеты, которые решают, что можно и нужно делать, вместо самоорганизации. В-третьих, мнение людей в команде может меняться под влиянием различных факторов, даже в течение одного дня, что приводит к нестабильности в подходах. В-четвертых, давление сроков, обязательств и SLA часто заставляет команды идти на компромиссы, временно отключая части конвейера (например, автотесты), ссылаясь на срочность других задач. Эти временные решения часто становятся постоянными, так как 'потом разберёмся' редко превращается в реальные действия. В результате, вся накопленная ранее практика работы может быть утрачена, так как перезапуск конвейера в будущем видится как задача низкого приоритета.

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

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

Человеческие отношения играют ключевую роль в управлении услугами ИТ. Независимо от того, взаимодействует ли организация с внутренними или внешними заказчиками, на первом плане должны быть доверие, взаимная вовлеченность, сотрудничество и общие цели. Формальные договоренности, такие как SLA, важны, но они не заменяют качественных отношений. Успешные сервисные отношения зависят от способности сторон вместе решать проблемы, обсуждать цели и улучшать услуги. Это особенно актуально в случае, когда ИТ является внутренним поставщиком услуг, где отсутствие SLA может привести к недопониманию и недоверию.

Важно учитывать как warranty, так и utility при оценке качества ИТ-услуг, потому что они охватывают разные, но взаимодополняющие аспекты восприятия качества. Utility отвечает за соответствие услуги бизнес-потребностям и функциональным требованиям заказчика, а warranty гарантирует стабильность, доступность и безопасность предоставления услуги. Наличие только одного аспекта недостаточно: даже самая функциональная услуга (высокая utility) будет непригодна, если она ненадежна (низкая warranty), и наоборот – надежная, но ненужная услуга (высокая warranty, низкая utility) не будет удовлетворять потребности заказчика.

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

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

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

Суть метода Management By Objectives (MBO) заключается в регулярном совместном определении целей на следующий период планирования с подчиненными, которые сами являются руководителями разных уровней. Также включает выбор способа измерения прогресса и контроль достижения поставленных целей. Два ключевых аспекта: вовлечение исполнителей в постановку целей для преодоления их отторжения и совместное определение методов измерения для повышения доверия к контролям и оценкам результатов.

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