В условиях быстрой цифровой трансформации и постоянно меняющегося мира бизнеса с точки зрения портфелей проектов также возникает потребность в гибких и интерактивных методах управления. Планирование на уровне портфеля является сложным и трудно прогнозируемым, поскольку, помимо прочего, оно подвержено воздействию многих внешних факторов.
В недавней статье «Сдвиг влево: создание ценности в Scrum» («Shift Left: Value Creation in Scrum») Стефан Волперс, обращает внимание на то, что формирование ценности в Scrum не такая уж простая штука. Как замечает автор, какими бы ни были эффективны в Scrum-команде разработчики (developers), если на вход в производственную систему поступает ерунда, то эффективность всей системы не будет максимальной («Garbage in, garbage out»). {здесь люди, привыкшие к конструкции уровней «стратегический – тактический – операционный», возможно, вздрогнули; но, на самом деле, в данном случае это несущественно} Основная идея автора в том, что большая часть описания фреймворка Scrum посвящена описанию устройства производственной системы:…
То новое, что мы обсуждали на учебных курсах ещё несколько лет назад, теперь стало привычным и общепринятым. Видимо, то, что мы обсуждаем сегодня, имеет шансы стать новой нормой через несколько лет.
Реальность такова, что переход к мышлению, ориентированному на продукт, часто требует полной трансформации компании. Все в организации должны ориентироваться на общее понимание того, что является ценностью для бизнеса и ваших клиентов. Но есть одна группа, которая отвечает за продвижение всего вперёд — сплочённая команда разработчиков.
Работа над дефектами – известная область разработки ПО, вызывающая вечные и непримиримые споры. Заметьте, что я использовал именно слова “работа над”, а не “управление” – из того, что я вижу вокруг, управления дефектами почти ни в одной команде разработки нет.
Недавно меня пригласили помочь команде, с которой я уже работала два года назад. Это отличная зрелая команда с хорошо отстроенным рабочим процессом. Но в последнее время поставка заметно замедлилась и начали возникать сбои.
Я была сильно удивлена, когда обнаружила несколько простых дисфункций, которые зрелой команде ничего не стоило выловить самостоятельно. Это заставило меня поразмышлять, почему так происходит? Почему команда с отлаженным рабочим процессом и прекрасными профессиональными навыками может деградировать, вместо того чтобы непрерывно улучшать свои показатели?
Сегодня я хочу рассказать о буднях менеджера проекта. Когда я управляю проектом, то придерживаюсь определенного списка деятельности на каждую неделю. Эта комплексная деятельность требует встреч или обсуждений, но наличие четкого представления о том, чем необходимо заниматься каждую неделю помогает сделать более ясным, на чем следует сфокусироваться.
Сейчас часто можно услышать о магии дофаминовой системы вознаграждения мозга. Разработчики, ИТ-специалисты и особенно бизнес-лидеры бесконечно гоняются за секретной формулой неуловимого и желанного «состояния потока».
Далее мы поговорим о трёх главных мотиваторах для разработчиков и ИТ-специалистов, но сначала давайте исследуем важность денежной мотивации людей к выполнению механических и когнитивных задач.
Быстрая разработка часто завязана на использование ПО с открытым кодом. Это увеличивает сложность цепочек зависимостей. Нужно что-то делать, чтобы снизить риски. Потребуется действительно беспрецедентный уровень контроля не только над тем, что разрабатываем сами, но и над тем, что мы используем.
В этой статье показана важность трансляции ценности ИТ для руководителей с использованием подхода, ориентированного на результат, и даны советы по выполнению.
CustDev, CJM, USM, MAU/DAU, продуктовые команды, настоящие дорожные карты, ускорение в разы – это всё не про Enterprise. Или нет?