Показатель CPI (Cost Performance Index) из методики EVM имеет несколько преимуществ по сравнению с показателем SPI. CPI эффективно оценивает соответствие проекта бюджету на всех этапах, включая завершённые проекты, поскольку он рассчитывается как отношение запланированной стоимости выполненных работ к фактическим затратам. В отличие от SPI, CPI не искажается к концу проекта и продолжает отражать финансовые отклонения, позволяя менеджерам объективно оценивать эффективность использования бюджета как в процессе выполнения, так и после завершения проекта.

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

Новый подход стимулирует не только быстрое устранение инцидентов, но и профилактику их возникновения. Поскольку инциденты, влияющие на бизнес (te > Tmin), снижают общий рейтинг даже при соблюдении Tmax, поставщикам услуг становится невыгодно допускать сбои. Это приводит к повышению общей надежности ИТ-инфраструктуры и снижению количества инцидентов, что напрямую улучшает доступность сервисов и минимизирует риски для бизнес-операций.

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

В тексте упомянуты четыре основные проблемы управления рабочим временем: 1. Объем работы: задач поступает больше, чем есть времени на их выполнение. После перехода из клиентской компании в консалтинг и запуска собственного бизнеса рабочая загрузка возросла до 120-160%, что создало острую нехватку времени. 2. Противоречие интересов: существует разница между тем, что хочется делать (интересная работа) и тем, что необходимо выполнять (обязательные задачи, например, бухгалтерский и налоговый учёт). 3. Приоритизация: рутинные оперативные вопросы занимают всё рабочее время, в то время как на стратегическое развитие компании и личностный рост времени не хватает. 4. Размытость границ: в современных условиях сложно отделить рабочее время от личной жизни. Гибкий график и постоянное погружение в работу приводят к тому, что приходится успевать и профессиональные, и семейные обязанности.

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

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

Интеграция ITIL и Agile требует понимания того, что эти подходы дополняют друг друга, а не противоречат. ITIL фокусируется на стабильности и качестве ИТ-услуг, а Agile - на скорости и гибкости разработки. Для успешной интеграции: во-первых, определите зоны ответственности - ITIL для управления эксплуатацией и поддержкой услуг, Agile для разработки и внедрения новых функциональных возможностей. Создайте совместные процессы для перехода разработки в эксплуатацию (DevOps-практики). Адаптируйте процесс управления изменениями ITIL, чтобы учитывать частые релизы Agile-команд, внедрив стратегию мелких, низкорисковых изменений. Синхронизируйте циклы планирования - совмещайте ритм ITIL (ежеквартальное планирование услуг) с спринтами Agile (2-4 недели). Используйте общий инструмент управления работой, поддерживающий как ITIL-процессы, так и Agile-методологии. Проведите обучение для обеих команд, чтобы они понимали принципы и ограничения друг друга. Внедрите общие метрики, оценивающие как стабильность, так и скорость внедрения изменений. Создайте мостовые роли, например, менеджер по внедрению, который будет координировать работу между Agile-командами и службой поддержки.

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

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