Да, опыт (experience) может рассматриваться как третья группа характеристик услуги. Опыт заказчика (customer experience, CX) и опыт пользователя (user experience, UX) отражают воспринимаемую заказчиком или пользователем совокупность функционального и эмоционального взаимодействия с услугой и провайдером. В отличие от полезности и гарантии, которые можно измерить объективно, оценка опыта часто требует анализа поведения, мнений и решений потребителей, таких как уровень удовлетворенности, количество обращений за помощью или длительность взаимодействия с услугой.

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

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

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

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

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

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

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

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

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