Бизнес-бенефиты (раздел Business benefits в нижнем левом квадранте) должны отвечать на вопрос, как результаты проекта будут полезны бизнесу в целом. Нужно указать, на какие вопросы руководства компании позволит ответить внедрение проекта, какие проблемы бизнеса будут решены. Например, можно указать: «Численные KPI для оценки качества операционной деятельности ИТ-подразделения», «Сокращение времени простоя системы за счет улучшенного управления инцидентами», «Повышение удовлетворенности клиентов за счет быстрого реагирования на запросы». Важно показать конкретную пользу для бизнеса, а не только для ИТ-отдела.

Для оценки удовлетворенности заказчика ИТ-услугами можно использовать опрос, содержащий ключевые вопросы, задаваемые заказчикам на регулярной основе. Например, вопросы о степени удовлетворенности достигаемойutility услуг, степени удовлетворенности достигаемой warranty услуг, и степени соответствия показателей warranty реальным потребностям заказчика. Ответы даются по шкале 0-1 (0 – полное несоответствие, 1 – полное соответствие), а для определения итогового показателя можно использовать взвешенное арифметическое усреднение. Такой подход обеспечивает прямое получение обратной связи от заказчика.

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

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

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

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

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

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

Да, кратное ускорение возможно без смены персонала, включая программистов, аналитиков, тимлидов и руководителей. Ключевым является фокус на изменении системных аспектов работы, а не на замене людей. Необходимо сосредоточиться на четырёх направлениях: перестроить организацию ресурсов от иерархии к более самостоятельным командам; провести архитектурные изменения для поддержки быстрого цикла разработки; наладить приоритизацию входящих задач с фокусом на бизнес-ценные инициативы; внедрить систему организации производства с управлением потоком создания ценности и ограничениями на текущую работу. Пример деловой игры 'Проект Феникс' показывает, что те же люди, изменив подход к работе, могут ускориться в 15-25 раз без изменения состава команды.

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