Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Два ключевых принципа Agile-манифеста помогают использовать групповые эффекты в управлении командой: «самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд» и «над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им». Эти принципы подчеркивают важность самоорганизации и доверия профессионалам, что позволяет команде использовать синергетический эффект для генерации лучших решений. Создание условий для самоорганизации помогает балансировать социальную лень и синергию идей, используя групповые эффекты для достижения более высоких результатов через взаимодействие и распределение ролей в команде.
Процесс «Управление проблемами» участвует в улучшении качества ИТ-услуг через постоянное выявление и устранение корневых причин инцидентов, что ведет к снижению их количества и повторяемости. Системный подход к устранению причин проблем вместо реагирования на их симптомы способствует повышению общей стабильности и надежности ИТ-инфраструктуры. Проактивный анализ позволяет выявлять и устранять потенциальные проблемы до их проявления в виде инцидентов. Кроме того, накопленные данные об известных ошибках и решениях используются для улучшения процессов проектирования и внедрения новых услуг, что в свою очередь повышает качество ИТ-услуг в долгосрочной перспективе.
Момент объявления инцидента значительным определяется на основании заранее согласованного и задокументированного определения, утвержденного поставщиком услуг совместно с заказчиком. Любой участник процесса (сотрудник аварийной службы или подразделения поддержки) может объявить инцидент значительным, если ситуация соответствует заранее определенным критериям. После объявления значительного инцидента должна быть активирована специальная процедура, включающая уведомление топ-менеджмента, назначение ответственного лица, организацию совместной работы команд и внедрение специальных мер реагирования. Даже если некоторые службы не видят признаков значительного инцидента, они обязаны следовать установленной процедуре реагирования.
Чтобы минимизировать искажение данных, необходимо сначала четко обозначить цели учета и не использовать систему как основной инструмент контроля и наказания. Важно обучить сотрудников правилам заполнения, объяснив им, как данные будут использоваться для улучшения процессов. Также следует избегать излишней детализации, которая может привести к формальному отношению к учету. Регулярный анализ и обратная связь по собранным данным повышают значимость системы для сотрудников и повышают ее достоверность.
Процесс управления конфигурациями в современных условиях должен использовать все имеющиеся инструменты, включая системы контроля версий для управления версиями серверов, настроек, документов, тестов и приложений. Он также может использовать средства автоматизации для сбора, анализа и предоставления информации о сервисных активах. Процесс адаптируется к современным методологиям разработки и поддержки приложений, интегрируясь с инструментами для работы с микросервисами, виртуальными машинами и контейнерами, что позволяет эффективно управлять динамически изменяющимися конфигурациями в условиях Agile-методологий.
Релизные циклы часто становятся источником задержек в поставке ценности, потому что они формируют длительную очередь из элементов работы, которые уже завершены, но не могут быть поставлены конечным пользователям. Эта очередь формируется из-за ручного регресс-тестирования, необходимости согласований на выходе, длительной проверки на тестовых группах и других процедур, тормозящих финальную стадию. Это создает ситуацию, когда работа над созданием ценности уже завершена, но ее поставка откладывается, что противоречит принципам непрерывной поставки и снижает ценность продукта для конечных пользователей.
Задача подходит для гибкого подхода, если она характеризуется высокой степенью неопределенности, требует творческого подхода и не может быть полностью описана на начальном этапе. Такие задачи часто требуют постоянной адаптации к новой информации, активного взаимодействия с заказчиком и готовности менять направление развития проекта. Если же задачу можно разбить на небольшие понятные части с четким результатом для каждой, и она не требует инноваций, то гибкий подход может создать избыточную нагрузку. Критерием является необходимость постоянного снижения неопределенности и обсуждения неочевидных аспектов задачи — если это важно для успешного завершения проекта, то гибкий подход оправдан.
Ошибка «делать правильно, но не то, что нужно» заключается в том, что ИТ-специалисты технически корректно выполняют задачи, но эти задачи не связаны с реальными бизнес-потребностями и не приносят ценности. Например, разработчики могут внедрить «крутой» API с высокой производительностью, но если он не интегрирован с CRM, бизнес не увидит роста продаж. Или сервис-деск может похвастаться 1000 закрытыми заявками, игнорируя 40% повторных обращений. В таких случаях работа выполняется технически грамотно, но не решает реальные проблемы бизнеса и клиентов, приводя к потраченным впустую ресурсам и неэффективности.
Современный процесс управления изменениями должен обладать следующими характеристиками: работать быстро, не замедляя скорость преобразований; быть качественным на каждом этапе для решения сложных кросс-системных проблем; иметь четкие границы, чтобы не тратить ресурсы на ненужное; быть естественным образом встроенным в коммуникации и конвейер команд, работающих с разной скоростью и разными инструментами; быть обеспеченным информацией и инструментами для оценки влияния системных преобразований. Только такой зрелый процесс может эффективно функционировать в современных условиях.
Проектная деятельность фокусируется на краткосрочных целях и конечном результате, после чего команда обычно переходит к новым задачам. Однако без постоянной поддержки и развития процессов, которые были созданы в рамках проекта, их эффект может со временем исчезнуть. Даже успешные проекты требуют долгосрочного сопровождения, иначе достигнутые результаты не укоренятся в организации.