Важно учитывать как Utility, так и Warranty при создании услуги, потому что только их совокупность определяет, сможет ли услуга создать ценность для пользователя. Utility определяет, решает ли услуга нужную задачу (fit for purpose), а Warranty - насколько удобно и надежно ее можно использовать (fit for use). Услуга может идеально решать задачу (высокая Utility), но быть неудобной в использовании из-за частых сбоев, медленной работы или сложной настройки (низкая Warranty), что снижает ее общую ценность. Аналогично, услуга может быть стабильной и надежной (высокая Warranty), но не решать нужных задач пользователям (низкая Utility). Только сочетание высоких уровней обоих характеристик позволяет услуге эффективно создавать ценность и удовлетворять потребности пользователей.

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

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

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

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

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

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

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

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

Принцип распределения ответственности между группами при обработке просроченного инцидента заключается в том, что степень ответственности каждой группы пропорциональна её доле в общем времени обработки инцидента. То есть, если группа потратила большую часть времени на обработку просроченного инцидента, её доля ответственности будет больше и метрика KPI покажет более низкое значение. Формула учитывает время ti, которое каждая группа затратила на работу с инцидентом, и общее время Ti обработки инцидента. Таким образом, ответственность за просрочку распределяется более справедливо, чем при традиционном подходе, где вся ответственность возлагается на последнюю группу.