Практика и опыт Archives – Страница 11 из 53

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

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

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

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

Взаимодействие между суперпользователями, поддержкой и бизнесом

В редакцию портала поступил вопрос: Добрый день! Для меня очень актуальна проблема по выстраиванию взаимодействия между суперпользователями, поддержкой и бизнесом. Есть примеры реализации такого взаимодействия? Как поступают заявки от конечных пользователей к суперпользователям? На каких условиях бизнес согласился их выделить? Как суперпользователи получают задачи от консультантов с тестированием доработок? Участвуют ли они в согласовании доработок? В общем хотелось бы узнать как это работает в компаниях?

Вопрос из зала, 1 июля 2019, последний комментарий 8 июля 2019

Как организовать работу с нестандартными запросами?

В редакцию портала поступил вопрос: Добрый день, Хотелось бы узнать опыт участников форума, по теме организации работы с нестандартными запросами пользователей. То есть у нас имеются выделенные запросы на обслуживание (стандартизированные запросы), они в какой то мере регламентированы. Но существует хаос с внутренними ИТ-проектами, особенно с небольшими проектами, которые не подпадают под изменения. Часто не совсем ясно, как провести грань между проектом и изменением (не всегда очевиден объем и масштаб работ). Поделитесь опытом, как у вас организовано формирование очереди работ, как прогнозируются сроки решения. Как “вклиниваются” срочные задачи. Спасибо.

Вопрос из зала, 1 июля 2019, последний комментарий 5 июля 2019

Проверяем дорожную карту продукта на гибкость

Небольшой чеклист для проверки на гибкость вашей дорожной карты продукта от Матиаса Скарина

Не кричите друг на друга (пожалуйста), или как подружить DevOps и ITIL

В своей недавней статье Paul Wilkinson делится рядом интересных наблюдений, сделанных во время деловой игры MarsLander, в которой приняли участие две “идеологические группы”. В статье они называются “DevOps and ITIL stakeholders”. Как развивалась игра и какими рекомендациями сопровождает описание автор, вы можете познакомиться в первоисточнике. Мы же хотели бы познакомить вас с основными “результатами на вынос” – то есть с выводами, которые сделали сами участники тренинга, выводами, которые участники “взяли с собой”, чтобы постараться применить в своей повседневной работе. Важный акцент в деловой игре MarsLander сделан на выстраивании эффективного сотрудничества. Именно поэтому тон рассуждениям участников, когда они обсуждали целевой характер…

Постоянное улучшение. 10 советов по организации самообслуживания

Организация самообслуживания сотрудников компаний обычно рассматривается как ключевая инициатива для перегруженных ServiceDesk’ов ИТ-подразделений. Цели “классические”: снижение затрат, ускорение обработки запросов на обслуживание, обеспечение лучшего клиентского опыта. Согласно исследованиям, проведённым как в Северной Америке (HDI), так и в Великобритании (SDI), порядка 80% ИТ-организаций уже инвестировали в ту или иную форму самообслуживания. Пока что всё идёт, вроде, неплохо – ITSM-отрасль рассматривает идеи самообслуживания как способ стать “лучше, быстрее, дешевле”. Однако, есть одно большое “но”. Исследование того же SDI за 2017 г. демонстрирует, что только 12% ИТ-организаций получили ожидаемую отдачу от внедрения технологий самообслуживания. Бесценный опыт, сын ошибок трудных, был получен по результатам…

Новостной поток, 26 мая 2019, последний комментарий 12 июля 2019

Подходы к учёту простоя услуг

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

Вопрос из зала, 17 мая 2019, последний комментарий 3 июня 2019

Повышение приоритета как (неработающий) способ ускорения работ

Мы это видим довольно регулярно. Не только видим, но и принимаем участие в обсуждении или принятии решения: “смотрите, задача АВС уже очень долго находится в работе, давайте повысим её приоритет, чтобы, наконец-то, устранить проблему”. Согласитесь, это вполне привычный способ управления. Беда в том, что он очень деструктивен и зачастую приносит больше вреда, чем пользы. Для дальнейших рассуждений необходимо сделать два предположения: Задача, приоритет которой повышается, не единственная в очереди. Работы много; точно больше, чем ресурсов в данный момент. В большинстве случаев оба предположения верны и дела обстоят именно так. Эти два пункта позволяют нам смотреть на ситуацию как на систему,…

Олег Скрынник, 28 апреля 2019, последний комментарий 14 мая 2019

Вопрос из зала: как вы учитываете изменения?

В редакцию портала поступил вопрос: Разрабатываю документ с описанием процесса управления изменениями и попутно разрабатываю сам процесс. Вопрос: у кого-нибудь в компании есть учет изменений кроме как в системе управления заявками и проводятся ли их одобрения CAB или чем-то подобным? Если есть описания этого процесса, то просьба, хотя бы кратко, привести в ответах. Спасибо!

Вопрос из зала, 15 апреля 2019, последний комментарий 18 апреля 2019

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

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