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

Метрика эффективности потока, похоже, совершенно бесполезна

Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику Flow Efficiency. Действительно, ещё со времён увлечения Lean нам известно, что далеко не всё время, которое заготовка проводит в нашей производственной системе, над ней кто-то работает. Существенную часть времени она находится в очередях, в ожидании, перемещаясь между участками работы и так далее. Потери, одним словом. Плохо. И Lean, и Канбан-метод, и даже ребята из DevOps советуют измерять эффективность потока путём деления времени, потраченного на собственно работу по созданию ценности, на общее время, которое задача провела в потоке. К примеру, вот что написано в словаре книжки “Essential Kanban Condensed”…

Олег Скрынник, 21 февраля 2021, последний комментарий 20 июля 2021

Минимизация когнитивной нагрузки команды для улучшения потока

Команды являются средоточием производства в организациях. Они создают программный продукт и обеспечивают его поставку. Как и любое средство производства, команда требует внимания и своевременного ухода. Компаниям необходимо следить за тем, чтобы когнитивная нагрузка на команду не была чрезмерной (о том, что такое “когнитивная нагрузка“, мы рассказывали в одной из наших предыдущих заметок), поскольку работа в условиях слишком высокой когнитивной нагрузки не позволит эффективно и надёжно создавать и улучшать разрабатываемое программное обеспечение. В своей заметке на IT Revolutions Мэтью Скелтон (Matthew Skelton) и Мануэль Пайс (Manuel Pais) продолжают рассматривать тему и рассказывают об обнаружении и ограничении когнитивной нагрузки для того, чтобы…

Вопрос одновременного внедрения нескольких базовых процессов

В редакцию портала поступил вопрос: Коллеги, доброго дня, поделитесь пожалуйста опытом. Есть ли у вас УСПЕШНЫЕ кейсы одновременного внедрения нескольких базовых процессов (инциденты\обращения\изменения\конфиг\проблем)? Какие дополнительные «грабли» были при таком внедрении и как удалось избежать эффекта паралича работы ИТ-службы (когда специалисты вместо обычных 10 заявок в периоде — начинают обрабатывать 4-5 а остальное время «тупят» в новом ServiceDesk-е с новыми окошками и привыкают указывать связи, типы, статусы и т.д. по инструкциям)? Заранее благодарю, Сергей.

Вопрос из зала, 11 февраля 2021, последний комментарий 18 февраля 2021

Сели и пишем, или что можно сделать с коварством эффекта Даннинга-Крюгера

Сегодня среди компаний, чей бизнес плотно завязан на ИТ, наверное, только ленивый не слышал про трансформацию, «agile-изацию» и прочие процессы повышения прозрачности и эффективности разработки. Многие попробовали различные методологии на себе – и что-то из этого получили, с тем или иным выхлопом. Давайте оставим за рамками обсуждения позитивный сценарий и поговорим о ситуации, когда вроде и ребят умненьких наняли, и продакта-проджекта им привели, и методологии все «по канону», а всё равно ИТ-отдел выдаёт не то, не с тем качеством, не в те сроки, и вообще всячески доводит бизнес до предынфарктного состояния. Появляется ощущение, что проблема глубже, чем казалось изначально, но…

Я знаю три слова…

Есть довольно ощутимые вещи, которые вы можете сделать, чтобы прокачать свои знания в ITSM: посетить учебные курсы, мастер-классы, деловые игры, семинары и тренинги. Что выбрать в этом многообразии и как учесть тенденции быстро меняющегося мира? Да, мир не стоит на месте и вслед за официальным объявлением AXELOS об отмене сертификации ITILv3, о котором мы уже писали, набирает обороты новая линейка курсов и сертификации ITIL4. Но что делать тем, которым нужны знания в области ITSM, при этом вопросы сдачи англоязычных экзаменов не так актуальны? А если еще учесть то, что материалов в публикациях «ITIL® 4 Practice Guide» намного больше, чем требуется…

Как регистрировать дополнительные независимые заявки в тех поддержку, возникающие во время решения основной?

В редакцию портала поступил вопрос: Добрый день! От инженеров, использующих систему регистрации заявок (СРЗ) для выполнения нарядов, поступил кейс, верное решение которого не получается определить однозначно. Часто специалисты выезжающие на места, приходя по одной заявке, делают еще 10. Это происходит потому что другие сотрудники, узнав о том, что специалист тех. поддержки где-то рядом, вспоминают, что у них тоже давно тормозит компьютер или не хватает какого-то ПО (т.е. услуги могут быть самыми разными). Инженеры попросили разработчиков СРЗ дать им возможность самостоятельно заводить себе наряды на такие вот случаи. Это, с одной стороны, позволит не просить заявителя «оставить заявочку», а с другой,…

Вопрос из зала, 3 февраля 2021, последний комментарий 8 февраля 2021

Когнитивная нагрузка команды

Когда мы говорим об умственной нагрузке, то понимаем, что у любого человека есть предел того, сколько информации он может хранить в своём мозге в определённый момент. То же самое касается и команд, где суммируются когнитивные возможности всех членов. Чем чревато превышение допустимой когнитивной нагрузки, и какие могут быть рекомендации по недопущению её превышения, делятся в своей заметке на IT Revolution Мэтью Скелтон (Matthew Skelton) и Мануэль Пайс (Manuel Pais), авторы книги “Team Topologies: Organizing Business and Technology Teams for Fast Flow”. Что такое когнитивная нагрузка В 1988 году психолог Джон Свеллер (John Sweller) охарактеризовал когнитивную нагрузку как «общее количество умственных…

Переклассификация обращения после начала выполнения работ по нему

В редакцию портала поступил вопрос: Добрый день! Интересна тема переклассификации обращения после начала выполнения работ по нему. Обращение классифицируется диспетчером на первой линии, он вносит услугу, определяющую SLA. Заявителю отправляется уведомление о регистрации обращения с указанием услуги и срока решения заявки согласно SLA этой услуги. У нас необходимость переклассификации обращения в плане изменения изначально определенной услуги, возникает в следующих случаях: После поступления наряда по обращению на рабочую группу выясняется, что диспетчер неверно выбрал услугу. Выбор корректной услуги может удлинить срок оказания услуги если у нее, согласно договору, больше SLA . После эскалации работ по обращению одной рабочей группой на другую…

Новостной поток, 25 января 2021, последний комментарий 26 января 2021

Насколько детальным должно быть меню регистрации запросов пользователей?

В редакцию портала поступил вопрос: Добрый день. Вопрос наверное не новый и проблема общая. Поступает куча запросов, неправильно зарегистрированных пользователем: неправильная привязка сервиса, типа запроса и т.п. Вопрос в следующем, насколько глубоко меню регистрации запроса должно быть категоризировано. Грубо говоря первая крайность – меню совсем без полей выбора привязки к сервису, к типу и т.д., пользователь просто описывает проблему своими словами, а далее все привязки делает специалист СТП при регистрации запроса. Вторая крайность – меню содержит кучу зависимых полей выбора (Сервис – Вид обращения – Тип запроса и т.д.), в которых пользователь обычно путается и регистрирует запрос неверно. Хотелось бы…

Вопрос из зала, 20 января 2021, последний комментарий 11 февраля 2021

Не зрелость

Запись вебинара “Не зрелость”, посвященного оценке процессов управления ИТ в интересах руководителя, опубликована на канале YouTube Cleverics. Программа вебинара: Что такое зрелость системы управления Что даёт оценка зрелости Чего оценка зрелости дать не может Оценка эффективности Целевые аудитории для разных видов оценки Ведущий: Дмитрий Исайченко, управляющий партнёр Cleverics. Практикующий консультант с пятнадцатилетним стажем, преподаватель. Имеет опыт обследования и реорганизации работы подразделений ИТ ряда средних и крупных компаний: ВТБ24, Raiffeisenbank, UniCredit Bank, Банк «Санкт-Петербург», М.видео, Спортмастер и других. ITIL Expert, ITIL 4 Managing Professional, соавтор и рецензент материалов ITIL 4. Автор публикаций и программных продуктов по управлению ИТ.

Дистанционные итоги

Вот уже почти год… Поначалу никто не верил, что это быстро не закончится. Ждали очный формат. Плюс мешала привычка к вебинарам – не верили, что дистанционный формат может быть реальной альтернативой. Но потом ситуация изменилась. Полученный за прошедшее время опыт позволяет поделиться наблюдениям и сделать некоторые выводы. И начну, пожалуй, с “ложки дёгтя”. Что мешает? Факторы места пребывания. Например, нет подходящего места, где можно разместиться. Возможен шум, например, от ремонта у соседей. Существенная разница в часовом поясе тоже создаёт неудобства. [Кстати, уже скоро будут доступны другие варианты графика. Пишите в комментариях, если у вас есть интерес к определённому графику.] Возможности…

Артём Мукосеев, 21 декабря 2020, последний комментарий 31 декабря 2020

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

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

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