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

«Известная ошибка» (Known Error) в рамках ITIL - это документально зафиксированная проблема, корневая причина которой уже выявлена, но для которой пока не разработано постоянное решение. Вместо постоянного решения может использоваться временный обходной путь (workaround) для минимизации влияния на бизнес. Известные ошибки документируются в базе данных известных ошибок (KEDB - Known Error Database), чтобы обеспечить информацию для быстрого реагирования на аналогичные инциденты в будущем.

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

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

Есть несколько вариантов отображения задач с необходимостью переделки на канбан-доске. 1) Оставить задачу в текущем состоянии (напр., на этапе тестирования) с пометкой "блокер" для привлечения внимания к необходимости переделки. Сигнал о блокере обрабатывается на ежедневных собраниях. 2) Вернуть задачу на этап, где требуется переделка с явной отметкой возврата для анализа системы. В этом случае нарушается плавное течение потока и возникают сложности с WIP-лимитами. 3) Оставить основную задачу на месте, создать дочернюю задачу на переделку и отправить её на соответствующий этап. Такой вариант сочетает преимущества и недостатки первых двух подходов, но добавляет сложность контроля связи между задачами. Д. Андерсон и Т. Божева считают, что передача дочерней задачи вместе с родительской характерна для более высоких уровней зрелости канбан-системы (4-й или 5-й уровень).

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

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

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

Основными факторами определяющими возможность привлечения внешних специалистов в данных областях являются: специфичность и критичность задач для продукта, необходимость постоянного вовлечения, а также возможность стандартизации и автоматизации процессов. Для Compliance и Security, которые требуют глубокой экспертизы и тесной интеграции с текущими процессами, внешние специалисты могут быть эффективны только при наличии четких SLA и понимания требований. В случае с UX, если продукт не требует постоянного взаимодействия с пользовательским интерфейсом, можно воспользоваться услугами фрилансеров или узко-специализированных компаний для отдельных проектов. Что касается CI/CD, автоматизированные процессы и использование облачных сервисов позволяют минимизировать прямое участие разработчиков, но требуют от команды базовой компетенции в настройке и поддержании pipeline.

Независимо от сегмента (B2C, B2B, государственные или внутренние), к продуктам применимы следующие общие принципы измерения успеха: продукт должен решать конкретную проблему или удовлетворять определенную потребность; важно измерять весь жизненный цикл взаимодействия с продуктом от первоначального интереса до постоянного использования; необходимо фокусироваться как на интересе к продукту, так и на его удержании; метрики должны быть связаны с показателями ценности, которую продукт приносит пользователям или заказчикам; важно учитывать как количественные, так и качественные аспекты взаимодействия с продуктом. Даже для самых сложных случаев, таких как инфраструктурные решения или внутренние корпоративные системы, остаются актуальными вопросы удовлетворения потребностей, удержания пользователей и измерения положительного влияния на бизнес-процессы. Ключевым различием остается только то, какие именно данные доступны и как их собирать для конкретного типа продукта.