Прошел тренинг по применению ИИ в бизнесе и ИТ услугах от AXELOS/Peoplecert — вендора ITIL(r).
Структурировал опыт, заработал бейдж 🙂
На тренингах и в проектах ИИ активно применяем. Приходите, заказывайте!
Кстати, 17.04.2025 17-30 будет онлайн мастер класс «ИИ для Датасаенс специалистов». Подключайтесь!
Полный курс доступен в Специалисте по ссылке
Рекомендую гибридные форматы обучения для глубокой проработки обтвенных кейсов
Презентация мастер класса в Специалисте по теме.
Приглашаю на мастер класс «Управление серией микропродуктов на примере b2c мобильных приложений»
Разберем одну из ключевых задач CPO (Chief Product Owner) — координацию межпродуктовой разработки, избежание дублирования работ и конфликта между продуктами и командами.
Краткая презентация для непроектных — как организовать приоритезацию и выстраивание очередности задач для непроектных сотрудников
Некоторое время назад был опубликован драфт PMBOK8, и появились первые комментарии на него, вызвавшие бурное обсуждение в профессиональном сообществе.
Одно из бросающихся в глаза отличий возвращение непосредственно в структуру свода знаний PMBOK8 процессной модели. Напомню, что в версии 7, основанной на принципах, процессы были вынесены из собственно PMBOK в отдельный материал на сайте.
Вокруг этого изменения разгорелась нешуточная дискуссия, которая мне лично представляется избыточной, т.к. проектное управление в современном мире настолько разнообразно, что «загнать» все варианты в рамки предопределенных процессов вряд ли возможно. Поэтому модель принципов (которые, кстати также остаются в версии 8) представляется лично мне вполне целесообразной. Количество принципов сокращается с 12 в версии 7 до 6 в версии 8. Посмотрим.
При этом ценность процессов как повторяющейся деятельности, никто не принижает. Процесс фиксирует лучшие практики, но уже на уровне более локальном. Так что эта дискуссия, на мой взгляд, изтшне методологична. Даже и при включении процессов непосредственно в PMBOK, все равно каждое предприятие будет адаптировать модель «под себя», что собственно всегда и было.
Понятие «Ценности» (Value) по-прежнему в центре внимания. Однако, фокус смещается на более прикладное понимание — Выгоды превалируют над затратами — классические «весы».
В определении ключевых характеристик проекта введено очень, на мой взгляд, полезное понятие уникального контекста. Как и было очевидно много лет, не каждый проект (точнее большинство их) полностью уникален, но уникальны (или отличны) условия реализации. Так что такое определение более точно.
В версии 8 развивается разделение ролей продуктового и проектного управления. По сути реализуется классический анализ (сначала разделить) и синтез. Как много лет говорят практики (и я в том числе, буду нескромен), проект — способ реалзации и развития продукта. Владелец продукта можеи выступать заказчиком проекта по соданию/развитию продукта.
Из PMBOK 8 предполагается убрать гдаву «Методы, модели и артефакты», что на мой взгляд, существенно снизит полезность самого PMBOK. Хотя авторы и пишут в своих блогах, что это позитивно, т.к. глава не вписывалась в контекст, но — опять же на мой взгляд — контекст здесь и не обязателен, эта глава фактически представляет собой в версии 7 справочник, из которого по мере необходимости можно почерпнуть нужную конкретную информацию. Шаг назад. Возможно, опубликуют отдельно, но пока неизвестно.
В проектное управление добавлены функциональные элементы — 7 базовых функций —
Из доменов произвоительности убраны коммуникации, качество и поставки. Если с поставками все понятно, уже давно эта область по сути вынесена за рамки проекта, и РП выступал как внутренний заказчик, то удаление коммуникаций и качества выглядит странно.
Ожидаем продолжения дискуссии, доступ к самому драфту можно получить в режиме рецензента (комментировать не обязательно 🙂 )
Готовимся к февральскому Инфостарту. Планирую участвовать в секции ИТ менеджмент и управление ИТ услугами.
Примерные тезисы моего выступлания (Если тема интересна, проголосовать за нее можно по ссылке)
Команды разработки и поддержки ИТ услуг обычно сопротивляются ведению и актуализации базы знаний. Обычный аргумент — не лишенный оснований — нет времени, много задач.
Как сподвигнуть на создание, наполнение — и самое главное — регулярное обновления базы знаний.
Обычный подход — должно приносить пользу самим сотрудникам, быть удобным в каждодневном применении.
1. Выявить потери от дублирования, ошибок, затраты времени на поиск и исследования очевидных вопросов.
2. Выявить неудачный опыт
3. Совместно с опытными сотрудниками выработать максимально простую процедуру обновления базы знаний
4. Развернуть простейшее ПО. Давайте посмотрим примеры такого ПО.
5. Минимальные требования к ПО ведения базы знаний.
6. Первичное наполнение — используем ТЗ, бэклоги комментарии
7. Варианты структурирования информации в БЗ, чтобы не превратить ее в «свалку».
8. Вводим KPI на пополнение и проверку статей в базе знаний при выполнении регулярных задач — решение инцидентов, проблем, обновления, изменения.
9. Демо — период. KPI считается, сотрудники информируются, но KPI не применяется.
10. Применяем KPI — элементы принуждения.
11. Теперь мы работаем эффективней! База накоплена, сотрудники сами ощущают пользу — минимизируются ошибки, рутина, выше производительность.
12. Некоторые трюки и «фишки».
Если тема интересна, проголосовать за нее можно по ссылке —
Публикую презентацию с открытой онлайн конференции по развитию ITIL и DevOps подходов. В презентации достаточно наглядно показан соотнесение Lean — Agile — DevOps c ITIL и дальнейшее развитие в новую область SRE — Service Reliability Practices
Как обычно, воспринимаем новые аббревиатуры с долей скепсиса, но не забываем почерпнуть полезное, сделать для себя выводы о трендах и тенденциях
IT Services & Project Management 