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

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

Цифровая трансформация

Проблемные зоны цифровой трансформации

Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их необходимо создавать и развивать. При этом, если ваша организация – это не недавно созданный стартап, то скорее всего она жила и функционировала уже какое-то время. А значит гибкий команды, по сути, будут состоять из тех же самых людей, что поддерживали развитие бизнеса через внутреннюю разработку ИТ-продуктов всё время существования компании. Изменения не всегда могут приветствоваться людьми, которых они затрагивают. Есть устоявшиеся процессы, в которых сотрудники чувствуют себя комфортно. Им может казаться, что организовать работу другим способом просто невозможно. Часто…

Простые уловки, как ускорить процесс разработки программного обеспечения

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

Что люди не понимают в управлении потоком создания стоимости

Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.

6 тенденций в ИТ, за которыми нужно следить

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

Воля и разум

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

Действительно ли управление ИТ-продуктами – это управление продуктами?

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

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

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

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

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

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM