Реальность такова, что переход к мышлению, ориентированному на продукт, часто требует полной трансформации компании. Все в организации должны ориентироваться на общее понимание того, что является ценностью для бизнеса и ваших клиентов. Но есть одна группа, которая отвечает за продвижение всего вперёд — сплочённая команда разработчиков.
Работа над дефектами – известная область разработки ПО, вызывающая вечные и непримиримые споры. Заметьте, что я использовал именно слова “работа над”, а не “управление” – из того, что я вижу вокруг, управления дефектами почти ни в одной команде разработки нет.
Недавно меня пригласили помочь команде, с которой я уже работала два года назад. Это отличная зрелая команда с хорошо отстроенным рабочим процессом. Но в последнее время поставка заметно замедлилась и начали возникать сбои.
Я была сильно удивлена, когда обнаружила несколько простых дисфункций, которые зрелой команде ничего не стоило выловить самостоятельно. Это заставило меня поразмышлять, почему так происходит? Почему команда с отлаженным рабочим процессом и прекрасными профессиональными навыками может деградировать, вместо того чтобы непрерывно улучшать свои показатели?
Сегодня я хочу рассказать о буднях менеджера проекта. Когда я управляю проектом, то придерживаюсь определенного списка деятельности на каждую неделю. Эта комплексная деятельность требует встреч или обсуждений, но наличие четкого представления о том, чем необходимо заниматься каждую неделю помогает сделать более ясным, на чем следует сфокусироваться.
Сейчас часто можно услышать о магии дофаминовой системы вознаграждения мозга. Разработчики, ИТ-специалисты и особенно бизнес-лидеры бесконечно гоняются за секретной формулой неуловимого и желанного «состояния потока».
Далее мы поговорим о трёх главных мотиваторах для разработчиков и ИТ-специалистов, но сначала давайте исследуем важность денежной мотивации людей к выполнению механических и когнитивных задач.
Быстрая разработка часто завязана на использование ПО с открытым кодом. Это увеличивает сложность цепочек зависимостей. Нужно что-то делать, чтобы снизить риски. Потребуется действительно беспрецедентный уровень контроля не только над тем, что разрабатываем сами, но и над тем, что мы используем.
В этой статье показана важность трансляции ценности ИТ для руководителей с использованием подхода, ориентированного на результат, и даны советы по выполнению.
CustDev, CJM, USM, MAU/DAU, продуктовые команды, настоящие дорожные карты, ускорение в разы – это всё не про Enterprise. Или нет?
Обычно, когда в компании возникает потребность в организационных изменениях, сотрудники проходят соответствующее обучение, но часто на этом всё и заканчивается. Никакой магии не происходит, работа не перестраивается, потому что теоретической базы недостаточно, чтобы изменения случились.
Помимо усвоения новой информации нужны реальная практика,
понимание того, какую последовательность шагов надо предпринять, чтобы всё это заработало в конкретной организации и мотивация сотрудников.
Чем тут могут помочь деловые игры?
Разговоры про ускорение разработки программного обеспечения ведутся уже много лет. Насколько ожидания оправданы? Можно ли ускориться, и как сильно? И главное – что для этого нужно?
В Agile наша вера в то, что сплочённость и состояние команды в порядке, может зависеть от положительных сигналов, которые мы подсознательно предпочитаем.