13 ноября, суббота
Эффективное управление проектами. Взгляд в глубину.
Организатор секции:
16:30-18:30
О чём будет секция?
Кейсы эффективного управления проектами в эпоху COVID
Работающие инструменты и подходы в новых условиях
Практики успешной адаптации к новым условиям в управлении проектами
Цель
обсудить современные практики, используемые в проектном управлении в профессиональном сообществе
Задачи
- Разобрать различные практические кейсы, с которыми сталкиваемся в управлении проектами
- Найти полезные инструменты, помогающие в управлении проектами, и показать их пользу и успешные варианты применения
- Вовлечь аудиторию на каждом выступлении, чтобы аудитория активно работала во время секции
Описание секции
Секция управления проектами собирает опытных и начинающих руководителей проектов, чтобы разобрать успешные практики, подходы и инструменты, которые позволяют управлять проектами эффективно в постоянно изменяющихся условиях.
Формат секции:
Экспертная часть с докладами (3-4 доклада), ответы на вопросы, интерактив для взаимодействия с аудиторией
Для кого
1
руководители проектов
2
менеджмент ИТ компаний
3
начинающие специалисты в области управления проектами
4
ИТ-директора
Купить билет на Город IT
В первый день конференции (12 ноября) мы собираем профессионалов IT-рынка для участия в воркшопах и обмена опытом (БОНУСОМ вы бесплатно получаете возможность посетить конференцию во второй день).

Покупая билет на секции, вы получаете право принять участие во всех секциях Город ИТ Pro (12 и 13 ноября). На секции мы приглашаем всех, кто интересуется IT выступлениями спикеров и мощнейшим нетворкингом.
Билет на воркшоп 12 ноября
Билет включает в себя оплату воркшопа 12 ноября и БОНУСОМ вы получаете входной билет на профессиональный день 13 ноября.

Программу конференции вы сможете посмотреть тут.

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

14 000
Билет на воркшоп 12 ноября
14 000 ₽
Билет включает в себя оплату воркшопа 12 ноября и БОНУСОМ вы получаете входной билет на профессиональный день 13 ноября. Программу конференции вы сможете посмотреть тут.Если вы хотите приобрести несколько билетов, то Вам необходимо после покупки связаться с менеджером конференции и предоставить информацию о каждом участнике. Мы распечатаем индивидуальные бейджи и подготовим пакеты участника.
Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности
Билет на секции
Билет включает в себя посещение секций Город IT Pro 12 и 13 ноября.
Место проведения Город IT Pro: РК "Факел", г. Томск, Красноармейская, 120

Программу конференции вы сможете посмотреть тут.

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

2500 ₽ 4 000
Билет на участие 13 ноября
2 500 ₽ 4 000 ₽
Данный билет дает возможность участвовать в конференции только 13 ноября. Программу конференции вы сможете посмотреть тут. Если вы хотите приобрести несколько билетов, то Вам необходимо после покупки связаться с менеджером конференции и предоставить информацию о каждом участнике.Мы распечатаем индивидуальные бейджи и подготовим пакеты участника.
Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности
Иван Селиховкин
«Полиморфизм в ИТ-менеджменте 2021».

Тезисы:

В управлении проектами, продуктами, сервисами, как и в объектно-ориентированном программировании важна способность к полиморфизму.
В зависимости от ситуации "на входе" команда и менеджер должны быть способны продемонстрировать разное поведение (применение разных управленческих подходов).
Рассмотрим несколько сквозных примеров на примере работы команд в ИТ-компании (штат несколько тысяч человек).
С какими методологиями (подходами, фреймворками) работают команды в зависимости от ситуации и как это выглядит на высоком уровне (глазами проектного офиса).
Кристина Рейзенбук (Sibedge)
«Управление изменениями в команде»

Тезисы:

Команда, процессы – это уже сложившаяся система, убрав один элемент системы, ее нужно перестраивать. Необходимо максимально подготовить систему к изменениям, чтобы сохранить эффективность и качество.
Рассмотрим на примерах, как руководителю проектов готовить команду к изменения и управлять этим процессом.
Анна Артенян (Sibedge)
«Управление изменениями в команде»

Тезисы:

Команда, процессы – это уже сложившаяся система, убрав один элемент системы, ее нужно перестраивать. Необходимо максимально подготовить систему к изменениям, чтобы сохранить эффективность и качество.
Рассмотрим на примерах, как руководителю проектов готовить команду к изменения и управлять этим процессом.
Сергей Дорофеев (Rubius)
«Как таймлайны и визуализация облегчают планирование и контроль».

Тезисы:

- Таймлайны и как отслеживать выполнение задач в соответствии с дедлайнами
- Как объединить все проекты в одну борду и не запутаться
- Как правильно спланировать загрузку команды
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.

У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.

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

В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.

У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.

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

В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.

У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.

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

В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.