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

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

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

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

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

Definition of Done (DoD) - это четкое определение критериев, которые должны быть выполнены, чтобы работа над элементом (историей, задачей) могла считаться завершенной. DoD важен для командной работы потому, что объекты в бэклоге должны иметь строгие границы, чтобы команда могла их осознать и работать с ними эффективно. Без четкого DoD команда не сможет точно определить, когда элемент работы завершен, что приведет к неопределенности, пересечениям в работе и задержкам. Для эпиков и инициатив отдельный DoD обычно не определяется, так как они представляют собой компиляции дочерних требований, а вот для пользовательских историй и задач DoD критически важен для обеспечения стабильности процесса разработки.

Оценка успеха внутренних inhouse продуктов сложнее по нескольким причинам: во-первых, пользовательская база значительно уже, что затрудняет сбор репрезентативной обратной связи; во-вторых, между покупателем (спонсором) и непосредственным пользователем часто существует разрыв интересов и потребностей; в-третьих, цикл адаптации и внедрения продукта занимает значительное время (обычно 3+ месяцев); в-четвертых, отсутствует возможность многократного предложения продукта в случае неудачи; в-пятых, финансовая успешность продукта может не напрямую коррелировать с его функциональными характеристиками из-за дискретности продаж и специфики корпоративных решений. Также возникают сложности с получением данных об использовании продукта из-за организационных и технических ограничений внутри компании. Для объективной оценки успеха таких продуктов требуется создание отдельных каналов коммуникации с покупателем и пользователями, измерение TTV (Time-To-Value) - времени достижения ценности продуктом для заказчика, и учет специфики требований разных клиентов.

Современные средства ITSM-автоматизации отличаются от простых систем обработки заявок гораздо большей сложностью и функциональностью. Они включают в себя поддержку интеграции с другими ИТ-процессами, работу с конфигурационной базой данных (CMDB), инструменты для планирования и учета трудозатрат, а также учитывают сложные организационные структуры и схемы привлечения подрядчиков. Простые системы обработки заявок, как правило, ориентированы на базовую обработку запросов без учета таких специфических ИТ-аспектов, что делает ITSM-инструменты значительно более продвинутыми и сложными.

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

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