Презентация мастер класса в Специалисте по теме.
Приглашаю на мастер класс «Управление серией микропродуктов на примере 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
Как обычно, воспринимаем новые аббревиатуры с долей скепсиса, но не забываем почерпнуть полезное, сделать для себя выводы о трендах и тенденциях
AXELOS, известный вендор ITIL(r), опубликовал большой набор связанных статей по культуре Девопс и инженерным Девопс подходам.
В этой публикации мы разберем фрагмент, относящийся к сложностям внедрения DevOps подхода в современных организациях.
В современном мире весь цикл поставки программного обеспечения требует тесного и прочного партнерства между ИТ командами и заказчиком, потребителями и пользователями для поддержания и постоянного улучшения клиентского опыта. Инновации и улучшения, конечно, важны; однако они не гарантируют улучшения клиентского опыта.
Многие руководители хотят улучшить результаты и ценность разработки и развертывания программного обеспечения для своих компаний. Исследования показывают, что переход к DevOps сложен. Проблемы в равной степени распределены между людьми и организацией, рабочими процессами, технологическими темами и экосистемой партнеров. Препятствия возникают вследствие следующих 4 основных групп факторов:
1· Структурный барьер организации не позволяет командам DevOps процветать: формальные, жесткие барьеры поощряют идею о том, что внедрение изменений — это чужая работа. Эти организационные структурные барьеры включают следующее:
a) чрезмерные слои беспокойного среднего менеджмента, которые стоят между идеями и их реализацией,
b) патологически разрозненные организационные структуры без истории или стимулов для участия в сотрудничестве, и
c) руководители высшего звена, которые не могут, не хотят или не имеют навыков для руководства цифровым прорывом в компании.
Барьеры организационной структуры легко обнаружить, но трудно изменить.
2· Культурные «привычки и традиции» мешают отдельным лицам и командам внедрять инновации: для 25% ИТ структур в глобальных корпорациях изменение культуры является одной из трех главных проблем, с которыми они сталкиваются (Upskilling IT 2023). Культура относится к неформальным моделям организации, которые сигнализируют людям, какое поведение является правильным, а какое поведение определяет вас как сложное. Проблемы можно обобщить следующим образом:
а) непривлечение нужных людей в организацию или отсутствие желания их удерживать и развивать
б) нежелание рисковать и предлагать инновационные идеи, а также существующие привычки видеть прошлые неудачи и успехи препятствуют изменениям. Культура является самым сложным препятствием для обнаружения и изменения.
3· Существующие процессы, бюрократия и процедурные барьеры бросают вызов даже мотивированным сотрудникам и командам: существующие сложные процессы затрудняют возможность вносить изменения, поскольку существует слишком много зависимостей и групп влияния. Для 15% корпоративных ИТ-организаций отсутствие инновационных операционных моделей сдерживает их прогресс. Существующие процессы и процедуры важны, поскольку они полезны для выполнения задач, но они также вызывают проблемы, если слишком много внимания уделяется внутренним процессам и процедурам по сравнению с фокусом на результатах.
4· Технологические тенденции продолжат создавать проблемы — это те, которые будут внедрены или запланированы организациями в течение двух лет. Технологические проблемы неизбежны, но постоянное внедрение технологий продолжает увеличивать технический долг. Для 31% организаций ИТ-предприятий управление техническим долгом и/или предотвращение технического долга является значительной проблемой.
IT Services & Project Management 