IT лидер / Руководитель проекта — популярное

В этом году я решил попробовать нестандартные методы для обучения: интенсивы, игры и другие подходы.

Вашему вниманию представлена деловая ролевая игра «Оценка задач», которая готовит проджект-менеджеров ко всем возможным ситуациям в процессе оценки. Рефлексия после каждого «раунда» помогает закрепить материал.

Концепция игры

Что такое «оценка» — это процесс демонстрации продуктом идеи для команды с подготовленными артефактами: прототип и описание того, как идея решает проблему пользователя.

Для кого: для команд разработки и проджектов.

Роли участников: - РО — продукт-оунер, рассказывает идею команде, отвечает на вопросы, хочет получить объективную оценку. - ПМ — руководитель проекта, руководит процессом оценки. - Аналитик — проводит поверхностный анализ задачи и варианты наложения на текущую архитектуру системы. - Дизайнер — отвечает за визуальную реализацию, должен обращать внимание на прототипы, важно обсуждать с фронтендером возможные решения. - Бэкендер — проектирует решение, должен полностью понять, что хочет продукт. - Фронтендер — проектирует реализацию UI, должен ограничивать полёт фантазии дизайнера. - Тестировщик — оценивает объём тестирования, возможные риски решения и подводные камни.

Концепция игры: 1. Создание ситуации оценки задач продукта. 2. Участники должны быть в неестественных ролях, например, разработчик получает роль аналитика или тестировщика. 3. У каждой роли есть антипаттерны поведения, которые участник разыгрывает в ситуации. 4. Задача участника с ролью руководителя проекта — преодолеть все антипаттерны поведения, выдержать встречу в рамках и добиться результата.

Итоги игры: ПМ сделал всё хорошо, если: 1. Встреча прошла структурно. 2. Конфликты удалось погасить или избежать. 3. Задача была декомпозирована и оценена. 4. РП справился с антипаттернами поведения. 5. Оценка задачи имеет обоснование на своё существование. 6. Встреча прошла в заложенный тайминг.

Процесс проведения

Начинается сама игра: 1. Ведущий рассказывает правила: 3 оценки, каждый будет в роли ПМа и в роли одного из участников оценки: аналитика, разработчика, тестировщика. 2. Назначается первый ПМ, раздаются роли индивидуально остальным. Даются пояснения. 3. Когда все готовы — объявляется старт первого раунда. Засекается таймер на 15 минут. 4. Руководитель QA, он же играет роль Product Owner, запускает демонстрацию экрана с первой продуктовой задачей. 5. Модерация встречи полностью переходит к играющему ПМу. 6. Оценка проходит согласно нашему процессу разработки. 7. Оценка заканчивается. Объявляется стоп-игра. 8. Проджект-менеджер пытается угадать, с кем он только что оценивал задачи. 9. Дальше рефлексия всех участников первой итерации. 10. Повторяется для ещё 2 сценариев. 11. В конце рефлексия по всей игре: начинает приглашённый на роль Product Owner, дальше остальные участники. В конце ведущий проговаривает важные нюансы и основные ошибки, которые были допущены. Обсуждается, как их в дальнейшем не допускать и исправлять.

Как прошла игра

Игра была проведена между всеми проджект-менеджерами нашей компании, всего их трое. Был приглашён руководитель тестирования на роль Product Owner. Я был ведущим, но при этом отыгрывал одну из ролей из списка, следил за выполнением условий игры и подмечал моменты, которые нужно было вынести на обсуждение.

3 ситуации, при которых каждый проджект примерил на себя роль ПМа и провёл встречу по оценке задач, а также ещё одну из ролей: аналитик, разработчик, тестировщик.

Так как нас было 5 человек, мы сократили разработчиков до одного и убрали дизайнера из возможных ролей. Если будете проводить на продуктовую команду, нужно использовать весь набор.

Выводы после игры

1. Всем понравилось.

2. Каждый испытал на себе разные роли, что позволило подойти к заданию творчески.

3. Прошло нескучно.

4. Много кейсов было решено правильно.

5. Во время рефлексии многие вспомнили похожие ситуации, а также проанализировали во время игры, что не получилось.

6. Были подсвечены проблемные места и что нельзя ПМам делать на такой встрече.

Видео с конференции

[embed]https://youtu.be/_GJuwesBCgc[/embed]

О чём рассказывает докладчик

В своём выступлении на TeamLeadConf 2021 спикер подробно разбирает 9 кругов Канбана. Эта система помогает командам визуализировать рабочий процесс, выявлять узкие места и повышать эффективность.

Ключевые моменты методологии

• Первый круг — входные задачи и их приоритизация.

• Второй круг — анализ и декомпозиция крупных задач.

• Третий круг — планирование спринтов и распределение ресурсов.

• Четвёртый круг — непосредственно выполнение работы.

• Пятый круг — тестирование и контроль качества.

• Шестой круг — ревью и финальные правки.

• Седьмой круг — готовность к релизу.

• Восьмой круг — развёртывание и выпуск продукта.

• Девятый круг — сбор обратной связи и ретроспектива.

Практическая польза для команд

Использование 9 кругов Канбана позволяет командам не просто двигаться от задачи к задаче, а постоянно улучшать процессы. Важно отслеживать метрики на каждом этапе, чтобы вовремя вносить коррективы.

Внедрение этой методологии требует времени и вовлечённости всей команды, но результаты — более предсказуемые сроки и высокое качество продукта — того стоят.

Рекомендую к просмотру тем, кто работает над выстраиванием процессов в команде или компании.

Почему стоит посмотреть

Потому что в фильме главные герои берут на вооружение сомнительную систему, в которую верят только они. Преимущество данного подхода: метрики, расчеты, по сути — данные. Основываясь на данных, они принимают решения.

Основные моменты системы

Система долгое время не работает по различным причинам, хочу выделить основные для себя:

• Сопротивление со стороны скаутов и тренеров — в вашей работе это ваши коллеги и начальство.

• Переходный этап очень сложный сам по себе и в основном тянется на энтузиастах и их энергии.

• Очень важный момент, лично для меня: система системой, но вот без личного участия главного героя, без его личного общения ничего не вышло бы. Он нашел лидера раздевалки, опытного игрока, и теперь появился союзник среди коллектива, лидер изменений, который подхватывает их. Билли начал проводить то, что мы называем 1х1 встречи с сотрудниками, что очень полезно сыграло и позволило быстрее прийти к результату. И даже не потребовалась смена тренера, который остался в итоге в команде.

• Умение вести переговоры и торг — сцена, где происходит торг с 2 командами и владельцем клуба — высший пилотаж переговоров, когда ты хочешь получить необходимые тебе элементы системы для победы (результата). В моей карьере при формировании команды часто приходится вести такие переговоры.

Дополнительные уроки

• Напарник очень важен — даже обсуждать идеи вслух с кем-то, а не только с собой, даёт другое мнение либо подтверждение вашего.

• Ограниченный бюджет — все стартапы проходят через это, когда хочется "выиграть лигу", а у тебя денег на команду. "Есть богатые команды, есть бедные, потом 50 м г...а, а затем мы." (с) по сравнению с другими.

Спойлерить, чем закончится фильм, я не буду, приятного просмотра :)

https://youtu.be/N7NOcxG0Ekg

В видео рассматривается применение системного мышления в инженерных и управленческих задачах.

Основные принципы

Системное мышление помогает анализировать сложные взаимосвязи и процессы, а не отдельные компоненты. Это особенно важно в современных проектах, где инженеры и менеджеры сталкиваются с многокомпонентными системами.

Практическое применение

• Для инженеров: подход позволяет проектировать более надёжные и эффективные решения, учитывая влияние изменений в одной части системы на другие.

• Для менеджеров: инструмент помогает в планировании ресурсов, управлении рисками и координации команд, видя проект как целостную систему.

Использование системного мышления способствует снижению ошибок и повышению результативности в работе.

В видео Алексей Пименов (RealResult) делится своим взглядом на рабочий процесс как на процесс накопления знаний, а не просто выполнение задач.

Суть подхода

Он предлагает рассматривать каждую рабочую задачу как возможность узнать что-то новое и систематизировать опыт. Это позволяет не только выполнять текущие обязанности, но и постоянно развивать свои компетенции.

Практические аспекты

• Фиксация результатов: важно документировать не только итоги работы, но и ключевые инсайты и методы, которые привели к успеху.

• Анализ ошибок: неудачи стоит рассматривать как ценный источник информации для будущих улучшений.

• Создание базы знаний: накопленный опыт следует структурировать в доступные материалы, которые можно использовать повторно.

Такой подход помогает снизить когнитивную нагрузку, так как не нужно каждый раз "изобретать велосипед", и увеличить эффективность в долгосрочной перспективе.

Значение для специалистов

Для менеджеров и разработчиков это означает переход от реактивного режима "тушения пожаров" к проактивному построению систем, которые предотвращают проблемы. Видео доступно по ссылке: https://youtu.be/ux4Gl234qMk

IT-лидер команды разработки — это опытный разработчик или инженер, который руководит и управляет командой, занимающейся созданием программного обеспечения или IT-проектами.

Основные задачи

1. Руководить и координировать работу команды разработчиков — отвечает за распределение задач, ресурсов и контроль выполнения работ.

1. Предоставлять техническое руководство и консультации — обладает глубокими знаниями и опытом в области разработки ПО и помогает членам команды в решении сложных технических задач.

1. Планировать проект и управлять ресурсами — отвечает за планирование работы команды, определение сроков и приоритетов проекта, а также за управление ресурсами для достижения поставленных целей.

1. Разрешать проблемы и конфликты — урегулирует проблемы внутри команды, конфликты и обеспечивает эффективную командную работу.

1. Общаться с заказчиком или заинтересованными сторонами — может быть ответственным за коммуникацию, чтобы понять требования и обеспечить их успешную реализацию в проекте.

Роль и требования

IT-лидер команды разработки играет важную роль в создании и управлении высокоэффективной командой. Для этого ему необходимо обладать хорошими навыками управления, коммуникации и технического руководства, а также быть хорошо информированным о последних технологических трендах и методологиях разработки программного обеспечения.