27 октября в 11:00 (МСК) Cleverics проведет открытый онлайн-урок «Продуктовый подход в ИТ в традиционных компаниях». Приглашаем всех желающих на это бесплатное мероприятие, регистрация обязательна.
То новое, что мы обсуждали на учебных курсах ещё несколько лет назад, теперь стало привычным и общепринятым. Видимо, то, что мы обсуждаем сегодня, имеет шансы стать новой нормой через несколько лет.
Реальность такова, что переход к мышлению, ориентированному на продукт, часто требует полной трансформации компании. Все в организации должны ориентироваться на общее понимание того, что является ценностью для бизнеса и ваших клиентов. Но есть одна группа, которая отвечает за продвижение всего вперёд — сплочённая команда разработчиков.
Работа над дефектами — известная область разработки ПО, вызывающая вечные и непримиримые споры. Заметьте, что я использовал именно слова «работа над», а не «управление» — из того, что я вижу вокруг, управления дефектами почти ни в одной команде разработки нет.
Когда я впервые услышал термин DevOps, от своих коллег я понял примерно следующее: «Процесс развёртывания приложения в любой среде (dev/QA/prod) называется DevOps. Просто ещё один синоним эксплуатации». Как начинающий программист, я подумал: "Ок, здорово! Ещё одно модное словечко, поразившее в ИТ-индустрию». Люди, которые имеют некоторое представление о DevOps, знают, как я ошибался!
Недавно меня пригласили помочь команде, с которой я уже работала два года назад. Это отличная зрелая команда с хорошо отстроенным рабочим процессом. Но в последнее время поставка заметно замедлилась и начали возникать сбои.
Я была сильно удивлена, когда обнаружила несколько простых дисфункций, которые зрелой команде ничего не стоило выловить самостоятельно. Это заставило меня поразмышлять, почему так происходит? Почему команда с отлаженным рабочим процессом и прекрасными профессиональными навыками может деградировать, вместо того чтобы непрерывно улучшать свои показатели?
Сейчас часто можно услышать о магии дофаминовой системы вознаграждения мозга. Разработчики, ИТ-специалисты и особенно бизнес-лидеры бесконечно гоняются за секретной формулой неуловимого и желанного «состояния потока».
Далее мы поговорим о трёх главных мотиваторах для разработчиков и ИТ-специалистов, но сначала давайте исследуем важность денежной мотивации людей к выполнению механических и когнитивных задач.
CustDev, CJM, USM, MAU/DAU, продуктовые команды, настоящие дорожные карты, ускорение в разы — это всё не про Enterprise. Или нет?
Новое исследование Forrester показывает, что компании, достигшие более высокой производительности, трансформируют свои операционные модели ИТ и непрерывно совершенствуются.
Заканчивая серию обзорных публикаций о сертификационной линейке ITIL4 (CDS, DSV, HVIT, DPI), сегодня речь пойдет о книге, курсе и экзамене ITIL 4 Digital and IT Strategy (DITS).
Обычно, когда в компании возникает потребность в организационных изменениях, сотрудники проходят соответствующее обучение, но часто на этом всё и заканчивается. Никакой магии не происходит, работа не перестраивается, потому что теоретической базы недостаточно, чтобы изменения случились.
Помимо усвоения новой информации нужны реальная практика,
понимание того, какую последовательность шагов надо предпринять, чтобы всё это заработало в конкретной организации и мотивация сотрудников.
Чем тут могут помочь деловые игры?