В условиях быстрой цифровой трансформации и постоянно меняющегося мира бизнеса с точки зрения портфелей проектов также возникает потребность в гибких и интерактивных методах управления. Планирование на уровне портфеля является сложным и трудно прогнозируемым, поскольку, помимо прочего, оно подвержено воздействию многих внешних факторов.
Вспоминая недавнее обсуждение цифровой трансформации, в котором участвовал, Рой Аткинсон в небольшой заметке «Инструменты, дураки и трансформация» («Tools, Fools, and Transformation») приводит пару ярких образов, которые могут помочь осознать, как странно мы иногда подходим к решению ответственных задач. Собственно, название его заметки основывается на известной фразе «A fool with a tool is still a fool». Дословно: «дурак, у которого есть инструмент, всё ещё дурак» (смысл: «инструмент [в широком смысле этого слова] не поможет, если…»). В рамках обсуждения цифровой трансформации, поскольку она цифровая, разговор о технологиях нередко затмевает все прочие аспекты. Хотя технологии в решении данной задачи не первичны. О чём...
Тема цифровой трансформации интересует многих, но не многие до конца понимают в чем суть этого понятия, как и когда ее лучше проводить, зачем, что для этого потребуется, сколько это стоит… И главный вопрос – а стоит ли ее Вам проводить?
27 октября в 11:00 (МСК) Cleverics проведет открытый онлайн-урок «Продуктовый подход в ИТ в традиционных компаниях». Приглашаем всех желающих на это бесплатное мероприятие, регистрация обязательна.
То новое, что мы обсуждали на учебных курсах ещё несколько лет назад, теперь стало привычным и общепринятым. Видимо, то, что мы обсуждаем сегодня, имеет шансы стать новой нормой через несколько лет.
Реальность такова, что переход к мышлению, ориентированному на продукт, часто требует полной трансформации компании. Все в организации должны ориентироваться на общее понимание того, что является ценностью для бизнеса и ваших клиентов. Но есть одна группа, которая отвечает за продвижение всего вперёд — сплочённая команда разработчиков.
Работа над дефектами — известная область разработки ПО, вызывающая вечные и непримиримые споры. Заметьте, что я использовал именно слова «работа над», а не «управление» — из того, что я вижу вокруг, управления дефектами почти ни в одной команде разработки нет.
Когда я впервые услышал термин DevOps, от своих коллег я понял примерно следующее: «Процесс развёртывания приложения в любой среде (dev/QA/prod) называется DevOps. Просто ещё один синоним эксплуатации». Как начинающий программист, я подумал: "Ок, здорово! Ещё одно модное словечко, поразившее в ИТ-индустрию». Люди, которые имеют некоторое представление о DevOps, знают, как я ошибался!
Недавно меня пригласили помочь команде, с которой я уже работала два года назад. Это отличная зрелая команда с хорошо отстроенным рабочим процессом. Но в последнее время поставка заметно замедлилась и начали возникать сбои.
Я была сильно удивлена, когда обнаружила несколько простых дисфункций, которые зрелой команде ничего не стоило выловить самостоятельно. Это заставило меня поразмышлять, почему так происходит? Почему команда с отлаженным рабочим процессом и прекрасными профессиональными навыками может деградировать, вместо того чтобы непрерывно улучшать свои показатели?
Сейчас часто можно услышать о магии дофаминовой системы вознаграждения мозга. Разработчики, ИТ-специалисты и особенно бизнес-лидеры бесконечно гоняются за секретной формулой неуловимого и желанного «состояния потока».
Далее мы поговорим о трёх главных мотиваторах для разработчиков и ИТ-специалистов, но сначала давайте исследуем важность денежной мотивации людей к выполнению механических и когнитивных задач.
CustDev, CJM, USM, MAU/DAU, продуктовые команды, настоящие дорожные карты, ускорение в разы — это всё не про Enterprise. Или нет?