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

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

Постоянное улучшение

Непрерывное совершенствование, управление качеством, метрики, CSI

Дорожная карта развития продукта vs диаграмма Ганта

Диаграммы Ганта теряют свою популярность. Особенно среди энтузиастов Agile, которые полагают, что даты и зависимости подавляют креативность и инновации. Это может быть правдой, если команда работает очень линейно и каждую фазу не может начинать пока не будет завершена предыдущая. Несмотря на то, что сегодня большинство команд таким образом не работают, я понимаю, откуда исходит скептицизм. Диаграммы Ганта считаются пережитком очень медленных и негибких стилей работы. У процесса развития продукта нет чёткой даты начала и окончания. И нужно действовать быстро, чтобы идти в ногу с потребностями клиентов. Поэтому логично отдавать предпочтение гибкости, а не структурированности. Создание успешного продукта требует рабочей среды,…

Шаг “Отложено” в потоке создания ценности

Рассмотрим простейший поток создания ценности: На ваш взгляд, что в этом потоке не так? Подумайте, и когда будете готовы – листайте ниже.                     Ответ бросается в глаза – один из шагов отличается от других. Опциональный шаг “Отложено” подразумевает, что задача, двигающаяся по потоку, может встать на паузу после этапа “В работе”, но до этапа “Проверка”. Причины этой паузы из схемы не ясны, но шаг “Отложено” даже визуально, из-за подписи “(опционально)”, уже выглядит инородным. Однако проблема не в инородности. Проблема в том, что на схеме изображён не поток создания ценности, а что-то…

Цель не понял, задачу выполнил!

Гибкие методологии управления ИТ-разработкой изначально несли в себе посыл становится клиентоориентированными, фокусироваться на бизнес-ценности, чтобы создавать результат, максимально удовлетворяющий заказчика. Двадцать лет назад мысль о том, что ответственность ИТ-разработчиков заключается не просто в создании новой функциональности, а в поставке ценности была действительно революционной. Фокусировка на ценности позволяет найти лучшее техническое решение из множества доступных разработчикам, когда они выбирают способ реализации требование бизнеса. В итоге результат соответствует ожиданиям заказчиков и созданную функциональность не приходится дорабатывать или переделывать. Что экономит время разработки и повышает качество продукта. Однако, с течением времени стало понятно, что фокусировка разработчиков на бизнес-ценности задач штука совершенно необходимая, но…

Менеджер продукта vs Владелец продукта

Некоторые говорят, что лучше никогда не читать комментарии. Но я обычно читаю столько, сколько могу, даже если не получается ответить на каждый. Среди свежих комментариев я нашёл рассуждение, в котором проводилась аналогия между разработчиками и производителями одежды. Идея в том, что разработчики похожи на портных, поскольку они фактически сшивают код. Но есть много другой работы, связанной с созданием одежды. Например, разработка выкройки, подбор материалов и координация с дистрибьюторами. При этом, независимо от того, что конкретно вы создаёте, нужны специалисты, которые смогут с этим помочь. Здесь на помощь приходят менеджер продукта и владелец продукта. Каждый из них применяет свои навыки, чтобы…

Новая эпоха в управлении услугами

Поскольку мы готовимся жить дальше с тем, что было названо “новой нормой”, сейчас самое время подумать о влиянии глобальной пандемии на ваш бизнес и о том, как в будущем обосновать свою стратегию управления услугами. Многие из нас чувствовали себя комфортно до кризиса, но пандемия вытолкнула нас из этих зон комфорта, охватив лихорадочным темпом цифровой трансформации, продемонстрировав нам постоянно растущее значение DevOps и возросшие темпы внедрения. Сейчас больше, чем когда-либо, основное внимание в управлении услугами уделяется тому, чтобы способствовать созданию ценности для бизнеса. Второй фокус направлен на то, чтобы обеспечить успешный и, что ещё более важно, целостный опыт заказчика. Следовательно, стратегия…

Как ускорить поток создания ценности?

Работая над созданием ценности, команда ИТ-разработки живёт в привычных для неё организационных процессах. Непредвзято взглянуть на свой поток и разобраться, где в нём существуют проблемные зоны, требующие улучшения, бывает очень не просто. Задачки ставятся и двигаются от этапа к этапу по сложившемуся маршруту. И кажется, что все логично, что ускорить этот процесс нельзя без увеличения количества исполнителей. Но так ли это на самом деле? Внутри потока создания ценности могут существовать процессы, существенно замедляющие его течение, делающие его непредсказуемым и неравномерным. Давайте рассмотрим причины, которые препятствуют движению элементов работы в потоке. Недостаточно информации для решения задачи Для того чтобы элементы работы…

Как эффективное слушание может сделать вас лучшим лидером

Подумайте о лидере, который постоянно даёт вам советы и задаёт вопросы только для того, чтобы затем высказать своё собственное мнение, не давая вам возможности высказать своё, постоянно прерывает вас, не давая закончить мысль, при этом делает вид, что слушает, кивая головой или издавая звуки вроде «ага… хм…». Или о лидере, который только озвучивает своё мнение, не удосуживаясь задать ни одного вопроса, и оставляет вас в недоумении относительно того, какие выводы сделать после такого одностороннего разговора. Разве такие лидеры не сводят вас с ума, притворяясь слишком занятыми и заставляя вас чувствовать, что ваши идеи и мнения не имеют значения. Будете ли…

Поток создания ценности – поток создания чего?

Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а что же такое ценность? Много говорится о потоке создания ценности, о том, какие организационные шаги необходимо предпринять, чтобы сделать его сбалансированным и управляемым, но зачастую команды разработки плохо представляют, что лежит за самим этим понятием. Кажется, что вся работа продуктовой команды направлена на создание ценности. Люди живут в привычном рабочем процессе и считают, что все их действия строго необходимы для развития продукта. Очень сложно заходит мысль, что часть этих рабочих процессов с точки зрения…

Если вы уложились во все сроки в дорожной карте развития продукта, значит что-то идет не так!

Представьте себе продуктовую команду, которая радостно празднует крупную победу! Менеджер по продукту, команда разработчиков, владелец продукта, может быть даже парочка руководителей компании совместно отмечают успех. Должно быть, они достигли чего-то значительного, верно? Что это может быть: новый уровень прибыли? Важные вехи в прохождении дорожной карты? Достижение целевых показателей в расширении клиентской аудитории? Положительный отзыв о продукте в крупном отраслевом издании? А что, если команда празднует тот факт, что они выпустили новую версию продукта за день до крайнего срока, обозначенного в дорожной карте? Это, конечно, может быть поводом для радости. А может и нет. Поставка новой функциональности или продукта вовремя –…

Управление потоком создания ценности: следующий эволюционный шаг в разработке программных продуктов

Поставка программного обеспечения сложна, мало кто будет спорить с этим утверждением. Тем не менее, каким бы трудоемким не был этот процесс, он жизненно важен для всех организаций, независимо от того, в какой отрасли они работают или какой продукт создают. Сегодня каждая компания нуждается в разработке программных продуктов. Но недостаточно просто создавать программное обеспечение – необходима высокая производительность. В сегодняшних условиях ИТ-директоры постоянно думают об улучшении этого процесса, поскольку перед ними стоит задача создавать больше бизнес-ценности с меньшими затратами ресурсов. К сожалению, во многих случаях стремление к повышению производительности при поставке программного обеспечения сводится к благим намерениям, которые не достигают поставленных…

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM