Мы не будем говорить про игры, направленные только на сплочение команды, целеполагание, управление временем и другие soft skills. Эти навыки, безусловно, полезны и необходимы.
Мы же будем говорить про другую категорию игр, направленных на приобретение фундаментальных знаний и навыков, подкрепленных современной мощной теоретической базой ИТ-менеджмента, лучшими ИТ и бизнес-практиками. Игры про которые мы будем говорить формируют системную картину не только мира ИТ, но и бизнеса в целом, участие в них позволит получить максимальную отдачу от ваших проектов.
Очень часто участники игр не понимают, не чувствуют в чём заключается работа менеджера. Они ошибочно полагают, что менеджер должен непосредственно и постоянно участвовать в рабочем процессе, быть одним из исполнителей. Например: раздавать задачи, приоритизировать инциденты, выискивать зависшие и потерянные работы…
На примере деловой игры «Apollo-13 – ITSM на практике» я покажу, к чему может привести такое заблуждение и расскажу, как мы помогаем командам его увидеть, избежать в игре и устранить в реальной жизни.
Все современные организации работают в условиях нехватки ресурсов, это особенно заметно в ИТ. Нам часто и довольно сильно не хватает персонала, финансирования, времени…
В деловой игре «Grab@Pizza – ИТ и основной бизнес» специально предусмотрено очень жёсткое ограничение, которое невозможно устранить – календарь изменений. Можно нанять больше людей, работать в три смены, получить доп.бюджет, но календарь есть календарь, в неделе будет ровно 7 дней.
Такое ограничение подводит команду к сложным вопросам: как понять что важно, а что нет? Какой бизнес-проект более приоритетен? Как быть, если нужно и проекты делать, и апгрейды ИТ-инфраструктуры? Почему невозможно получить сквозную приоритизацию всех задач? И как, в конце концов, помочь бизнесу заработать, даже если календарь нас так жёстко ограничивает?
В реализации любого проекта (особенно сложного) требуется не только уложится в срок и в бюджет, но и сделать то, что нужно – как бы это не казалось очевидным. Получить тот результат, ради которого проект задумывался. Что без постоянного взаимодействия с заказчиком и управления требованиями невозможно. Однако есть большая разница между «у нас есть техническое задание — мы пошли работать» и «на протяжении всего проекта мы знаем, что нужно получить и как это проверить».
На примере деловой игры «The Challenge of Egypt — управление проектами» я покажу, как увидеть насколько эффективно команда управляет требованиями и ожиданиями заказчика.
Гибкие методологии управления разработкой ПО призывают уходить от директивного менеджмента в сторону совместного принятия решений и самоорганизации сотрудников. Хороший лозунг, но насколько это реально?
В игре «Проект Феникс – DevOps на практике» мы даём команде возможность провести эксперимент в безопасной среде. Однако частенько бывает так, что команда всё равно переходит на ручное управление: кто-то берёт на себя функцию главного, начальника, координатора… К чему это приводит? Чему учится команда на таком примере?
Создание ИТ-продуктов происходит исключительно совместными усилиями разных специалистов, при этом и сама деятельность, и её результат – нематериальны. Мы не можем потрогать аналитику, взвесить код или посчитать тестирование. Как понять, что происходит с задачами в работе? Кто чем занят? Когда будет сделано? Какие проблемы мешают завершить работу и донести результат до потребителя?
На примере игры «Проект Феникс – DevOps на практике» я покажу, как команды проходят эволюционный путь от хаотичной организации рабочего процесса к управляемому движению задач и сопровождающей информации.