Портал №1 по управлению цифровыми
и информационными технологиями

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Практика и опыт

Примеры реальных задач, истории успеха и решения из жизни

Работает ли приоритизация изменений?

Одним из важнейших вопросов, которым следует задаться, решая задачу по запуску любого процесса – это по каким признакам должно стать понятно, что процесс действительно заработал. Недавно мне довелось снова принять участие в подобном обсуждении, и по итогам возникла идея поделиться на страницах портала REALITSM некоторыми выводами. Как известно, хорошей практикой при проектировании ключевых показателей эффективности, помимо оценки результативности процесса, является измерение уровня реализации ключевых видов деятельности. В данном контексте одним из ключевых признаков функционирования процесса управления изменениями является корректная работа системы приоритизации изменений. Как мы знаем (в том числе из ITIL), определение приоритета, то есть определение последовательности реализации изменений, основано…

ITSM в госсекторе

В редакцию портала поступил вопрос: Приветствую коллеги. Волею судеб из корпоративного ИТ-сектора попал в государственный. Многое в новинку, многое в диковинку, пока втягиваюсь. Однако тяжелое ITSM-прошлое не дает сидеть на месте. Куда не глянь, вижу область для улучшения и так и хочется засунуть свои ручонки для нанесения всеобщего блага))) С другой стороны, объемы работ и отсутствие опыта преобразований в государственном ИТ слегка пугает. Отсюда родился вопрос и тема для обсуждения. Знаете ли вы успешные (и не очень) кейсы внедрения ITSM-инициатив в отечественном ИТ гос. сектора? Может есть личный опыт участия, и вы сможете поделиться на какие грабли наступали. Вопрос конечно…

Как неудачи и эксперименты приводят к успеху

Создание нового программного продукта – это инновационный и творческий процесс. Не всегда всё идет по плану, провалы и неудачи на этом пути неизбежны. Однако, важно то, как команда справляется с ними. Ведь каждая неудача – это возможность сделать переоценку, внести изменения и попробовать иные подходы. Для того, чтобы добиться успеха, команды должны быть устойчивы к неудачам и уметь их использовать для обучения, приобретения и расширения опыта. Эйдан Кейси (Aidan Casey), один из авторов портала DZone, считает, что если ваша команда не сталкивается с неудачами в ходе работы над продуктом, то и шансы на успех тоже невелики. Когда мы чувствуем, что неудача…

Не пора ли прекращать делать обзоры спринтов?

Для многих команд разработчиков такое периодическое мероприятие как спринт ревью, или обзор спринта, морально устарел и уже изжил себя. И, похоже, пора перестать этим заниматься. Так считает Майк Кон (Mike Cohn), один из соавторов и основателей Scrum и Scrum Alliance. Звучит еретически? Отнюдь. Назначение обзоров спринтов Назначение обзоров спринтов заключается в том, чтобы команда разработчиков получила обратную связь. В результате в бэклоге могут появиться задачи, отражающие родившиеся новые мысли относительно имеющихся функций, либо доработки, направленные на доведение их “до ума”. Обзоры традиционно проводятся в конце спринтов. Для большинства команд – непосредственно перед ретроспективой. Но для многих команд проводить обзоры в конце…

Работа 2.0: Ренессанс

Многие сейчас чувствуют и осознают, насколько масштабные изменения происходят в нашем понимании подходов к работе и управлению. Agile перерос ИТ и выплеснулся на предприятия. Теория сложных систем оказывает влияние на наше мышление. Культура безопасности раскрывает ценность неудач и провалов. Менее известная (пока ещё) культура открытости переворачивает представления об иерархии. Помимо этого, есть и такие идеи как менеджер по обслуживанию, трансформационный лидер, открытое пространство, лидерство по приглашению, теория обещаний, устойчивость и многое другое. Все они нацелены на то, чтобы получить больше ценности скорее, безопаснее и сделать людей счастливее. Роб Ингланд, известный как IT Skeptik, называет их “Новые методы работы”, или “Гибкость…

Agile RBAC?

Когда мы слышим или употребляем выражение RBAC (Role-Based Access Control, ролевая модель управления доступом), какой смысл мы вкладываем в него в первую очередь? Конечно, использование ролей. Это центральный элемент данной модели управления доступом. Как показывает практика, модель, действительно, хороша. Используется сейчас очень широко, по большей части заменяя альтернативные модели – DAC (Discretionary Access Control, избирательное управление доступом), MAC (Mandatory Access Control, мандатное управление доступом). Про достоинства RBAC мы немало рассказывали на конференциях, на наших вебинарах, в заметках на портале. При всех своих преимуществах, удобстве и плюсах использования RBAC критически зависит от важной аналитической работы – проектирования или формирования ролей. Что…

Как поощрять Agile-команды?

Организации, стремящиеся стать гибкими, должны также обратить внимание и на формирование новой системы бонусов и стимулов, нацеленных на обеспечение и поддержку Agile-подходов. Независимо от того, насколько хорошо был спроектирован и осуществлён переход на новые методы работы, если будут продолжать действовать стимулы из “прошлой жизни”, способствующие прежнему же поведению, то сотрудники организации будут склонны вести себя “по-старому”. Автор заметки, Майк Кон (Mike Cohn), один из соавторов и основателей Scrum и Scrum Alliance,  называет это организационной гравитацией. Если культура организации не изменится в достаточной степени, чтобы стать другой – гибкой – организационная гравитация вернёт её в то состояние, в котором она пребывала…

Вопрос из зала: внедрение CMDB на практике

В редакцию портала поступил вопрос: Уважаемые коллеги, Внедрение CMDB — тема уже изъезженная, но практической информации крайне мало. Помогите, пожалуйста, не наступить на «те самые» грабли. Мы понимаем, где мы сейчас — осуществлена оценка текущего состояния. ИТ и заказчики видят и понимают проблематику, ограничивающую предоставление услуг с более высоким качеством из-за отсутствия CMDB. Мы знаем, что мы хотим — были собраны бизнес-потребности, при сборе отталкивались в первую очередь от задач, которые необходимо решить. Задачи: 1. Выстроить процесс управления ИТ-активами и конфигурациями (данные об активах содержаться в разных источниках и постоянно устаревают, пользовательское и серверное оборудование регулярно не обновляется, зачастую не удовлетворяет требованиям) 2….

Три причины растущей популярности DevOps

Первые упоминания о DevOps появились где-то в 2010 году. Примерно с этого момента времени энтузиасты начали активно интересоваться новой темой. Если заглянуть в Google Trends, то можно увидеть вот такой график популярности термина “DevOps” за последние 5 лет: А вот график за последние 15 лет: Как вы можете заметить, интерес к DevOps, стартовавший примерно в 2010 году, неуклонно рос и продолжает расти. При этом в начале 2019 года можно отметить резкий его всплеск . Конечно, стоит учитывать, что Google Trends – это не точные данные плюс закрытый исходный код самой платформы. И интерес к DevOps, измеряемый средствами Google, не является…

Сфера ответственности координатора релизов

Сразу уточним – в ITIL роль “Координатор релизов” не описана. Вопрос про сферу ответственности возник у слушателей курса ITIL RCV при обсуждении соответствующего раздела. Почему такой вопрос возник, в целом понятно. По аналогии с процессами управления изменениями или управления инцидентами при управлении релизами напрашивается необходимость фиксации так называемой “сквозной” ответственности за релиз. То есть выделения роли, отвечающей за координацию деятельности в рамках релиза на всём протяжении его жизненного цикла – от планирования до закрытия. По аналогии с “Координатором изменений” хочется назвать её “Координатор релизов”. Однако в ITIL V3 подобная роль не выделена. Справедливости ради следует отметить, что роли “Координатор изменений”,…

Кто отвечает за конвейер развёртывания?

Нужно очень сильно отстать от жизни (примерно лет на 5-7, что по нынешним временам приравнивается к вечности), либо иметь крайне веские аргументы, чтобы не использовать для доставки готового кода до среды эксплуатации конвейер развёртывания (в народе часто именуемый конвейером CI/CD, что в данном случае непринципиально). Техническая сторона вопроса – как построить конвейер – в большинстве случаев понятна, если не очевидна. Инструментов море, идеология ясна, собрать конвейер можно в простых случаях за час, в сложных – за пару недель. Организационная же сторона вопроса не так проста, как кажется. Кто должен/может его создать? Кто обеспечит функционирование? Кто починит, когда сломается? Кто будет…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM