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

Согласно ITIL 4, SLA (Service Level Agreement) — это документированное соглашение между поставщиком и заказчиком, которое определяет требования к услуге и ожидаемый уровень предоставления этой услуги. SLA фиксирует договоренности между двумя субъектами сервисных отношений, где заказчик должен определить свои требования и ожидания относительно потребляемой услуги, а также требования других стейкхолдеров, таких как регуляторы.

Для определения участия менеджеров ИТ-услуг при выполнении изменений инфраструктуры необходимы данные о взаимосвязях между элементами инфраструктуры и ИТ-услугами. Если имеется система управления базой данных конфигурации (CMDB), можно использовать информацию о связях между конфигурационными элементами и услугами. При отсутствии CMDB возможно вести специальные «паспорта» элементов инфраструктуры, включающие перечень ИТ-услуг, на которые влияет конкретный элемент.

В статье подробно описан эксперимент Дэна Ариели, проведённый в 2005 году и опубликованный в 2008 году. Участникам предлагалось собирать роботов LEGO Bionicle за деньги, причём оплата за каждого следующего робота снижалась на $0,11 после первого, за который платили $2. Каждого участника относили к одной из двух групп: «Работа со смыслом» и «Сизифов труд». В первой группе участники ставили собранных роботов на стол перед собой, формируя отряд, а во второй группе ведущий сразу разбирал только что собранных роботов, объясняя это нехваткой материалов. В результате участники первой группы в среднем собрали 10,6 роботов, а второй — только 7,2. Когда оплата опускалась ниже доллара, 65% участников первой группы продолжали работу, тогда как во второй группе продолжали только 20%. Этот эксперимент показывает, что осознание значения своей работы значительно повышает мотивацию и трудовую отдачу.

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

Наличие дефектов негативно влияет как на бизнес, так и на процесс разработки. Со временем дефекты приводят к экспоненциальному росту потерь - в примере из деловой игры 'Проект Феникс' потери составили 2 000 долларов в первом раунде, 26 000 во втором и 39 000 в третьем. Наличие дефектов замедляет разработку новых функций, так как разработчики вынуждены тратить время на исправление ошибок, и создает технический долг, который становится все дороже в исправлении. Для бизнеса это трансформируется в прямые финансовые потери и ухудшение качества продукта, что отражается на удовлетворенности клиентов.

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

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

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

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