Заявки на доклады

В программе более 20 докладов по темам:

  • Управление командой
  • Бизнес-процессы
  • Трансформационные изменения в людях и командах
  • Коммуникация
  • Работа над собой
  • Личное развитие
  • Развитие осознанности
  • Инструментарий тимлида
  • Работа с командой: делегирование, мотивация и т.д.
  • Новая культура в организации: бирюза, холократия, agile, remote
  • Выход из карантина
Информация для докладчиков
Поиск по тегам:

Новая культура в организации

1) Горизонтальные связи, здоровая коммуникация, ценностные процессы - в каких компаниях важны и какую долгосрочную повестку развития команды формируют.
2) Как развивать среду в компании, оптимальную для проявления творчества, изобретательства, работы на стыке разных департаментов и кросс-функциональных задач? Какие виды внутренней мотивации человека мы поддерживаем через те или иные инструменты внешних "систем мотиваций"?
3) Как мотивировать сотрудников, если у них всегда и так все хорошо? Как создать ту гравитацию в компании, которая будет "увлекать" даже "выросших" и сильных.

Доклад принят в программу конференции

Личное развитие

Максимально практический мастер-класс, на котором вы
* Научитесь упражнениям на правильное звукоизвлечение и дыхание, постановке голоса на опору
* Попробуете быстро находить аргументы и контраргументы для разных точек зрения
* Сделаете задание на работу в команде и попробуете применить актерское мастерство для преодоления стеснительности

Доклад принят в программу конференции

Смежные области для тимлида

Поиск, адаптация и развитие сотрудников процесс бесконечный, но крайне важный. Поговорим о том, чем HR может быть полезен тимлиду, как эффективно с ним взаимодействовать для достижения целей команды:
1. Как найти сотрудника, который гарантированно впишется в вашу команду
2. Как адаптировать новичка, чтобы максимально быстро получать от него результат в работе
3. Как выстроить процесс развития талантов: работа с HiPo, школа наставничества, кейс-клуб для руководителей
4. Что HR точно сделает лучше, а куда HR лучше не пускать

Доклад принят в программу конференции

В период карантина и самоизоляции пышным цветом расцвело направление Developer Relations (DevRel) – рассказывание профессиональных историй инженерами инженерам. Из каждого утюга стало доноситься по онлайн-митапу или вебинару. Статьи с Хабра, VC и остальных мест пошли непрерывным потоком.

Подкасты, квартирники, телега, фейсбук – с марта по июнь плотность информационного потока зашкалила.

DevRel набрал обороты, но вместе с тем стал доставлять больше дискомфорта. После которой уже по счёту прочитанной статьи, посмотренного митапа, послушанного подкаста – стало пропадать желание читать-смотреть-слушать дальше, а тем более не хотелось писать-докладывать-рассказывать.

Тем удивительнее увидеть, что удалёнка сделала DevRel не только источником раздражения, но и открыла новые возможности инженерам извлекать пользу из DevRel.

Как навести порядок в своём потреблении профессиональной информации, зачем и как добавлять свои артефакты в инфопоток, как вовлекать коллег делиться опытом – об этом расскажу в докладе.

Доклад принят в программу конференции

Психология в управлении

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

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

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

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

Доклад принят в программу конференции

Карьера, рост и развитие

Я была в роли тимлида, от которого уходили крутые ребята, потому что они не видели, как и куда дальше развиваться в компании, а я ничего не могла с этим сделать. Я была в роли сотрудника и тимлида, который думал об уходе по той же причине. Я была в роли сотрудника, которому компания дала возможность выдохнуть и разобраться в себе во время творческого отпуска и который смог в результате передоговориться с компанией и прийти к win-win. Этим опытом и хочу поделиться с двух точек: как практика «творческий отпуск» поможет компании (и тимлиду в роли руководителя), и как — человеку (и тимлиду в роли сотрудника).

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

Доклад принят в программу конференции

- Как управлять отделом, созданным из одних джунов
- Что подойдёт отделу с опытными программистами, но не подойдёт джунам
- Ошибки и способы их решения

Доклад принят в программу конференции

Бизнес-процессы

* Трансформация процесса автоматизации. Сокращение time-to-market от 8 месяцев до 14 дней за год.
* Взаимодействие с Заказчиком (понять Заказчика и успеть за трендами рынка).
* Управление бэклогом.
* Эффективное планирование.
* Безопасное и оперативное масштабирование ресурсов.

- "Перестройка" команд из разделения по тех. стекам в продуктовые.
- Формирование состава команды: кто нужен и в чем его роль.
- Оценка эффекта влияния типа личности на занимаемую роль в команде.
- Изменение процесса взаимодействия внутри команды. Переход на agile: грабли и лайфхаки.

Чек-лист для тимлида, при трансформации процессов автоматизации.

Доклад принят в программу конференции

One-on-ones, code review, P&L, Agile/Scrum, performance review — популярные практики, повышающие эффективность работы. В 2020 году о них слышно из каждого утюга. Но что делать, когда всё очевидное уже изучено и опробовано, а всё подходящее уже внедрено, принесло результаты и поддерживается?

Докладу предшествовало исследование: из практик, которые мы используем в Wargaming Platform, мне помогли выделить полезные, но не самые очевидные и популярные.

Вас ждет список нехайповых, но полезных практик для инженерных лидов:
- с областью применения;
- с описанием сути практики;
- с оценкой ожидаемой пользы;
- с оценкой сложности реализации и будущей поддержки.

Доклад принят в программу конференции

Трансформационные изменения в людях и командах

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

Доклад принят в программу конференции

Работать над аварийным проектом — нередкая задача для тимлида. Техническое состояние и работоспособность системы угнетают, процессы проседают, изначальных авторов уже нет на проекте. И еще тяжелее, если доверие между бизнесом и командой уже подорвано.

Первое, что приходит в голову в такой ситуации — внедрить новые процессы: agile, continuous delivery, devops. Но практика показывает, что в ситуации пожара такие инициативы либо отклоняются руководством, либо начинаются и проваливаются. И это неудивительно. Невозможно одновременно формировать будущее и постоянно тушить пожары. Разом на то и другое не хватит, как минимум, внимания и доверия.

В докладе я расскажу, как вывести проект в стабильное состояние, не сгореть самому и не спалить команду.

Доклад будет полезен тем, кто:
1. тушит пожары и не видит им конца;
2. недавно стал тимлидом и чувствует, что “подгорает”;
3. до сих пор раздумывает: “а может, мне вернуться в разработку?”

Доклад принят в программу конференции

В какой-то момент процессы в вашей команде могут начать стагнировать и определить свой следующий шаг для его развития будет непросто. Вы не сможете поменять все и сразу — даже самые блестящие идеи разобьются о то, что команда, заказчик, QA и др. будут говорить: "Зачем так сложно". Процесс эволюции нужно бить на маленькие понятные шаги. Я покажу, как можно пройти этот путь с минимальными потерями и какие грабли ждут вас за каждым из поворотов.

1. Персональный Канбан. Как научиться не выгорать (WIP-лимит) и понять, что вы готовы идти дальше.
2. Командный Канбан. Как “схлопнуть” персональный Канбан у команды разработчиков в одну систему. С чем вы столкнетесь при таком расширении команды, как бороться с попытками заказчиков впихнуть нам побольше задач и что будет с WIP-лимитами.
3. Агрегированный командный Канбан. Как включить в свои процессы соседнюю команду (QA, аналитики) и какие бонусы это вам даст: разработка может разгрузить тестеров, вы будете “видеть” процесс полностью.
4. Классы обслуживания. Как сделать систему более предсказуемой.

Доклад принят в программу конференции

Хайринг: Формирование ожиданий: скиллы и опыт успешного remote-кандидата. Skills Matrix с секцией про remote working skills.

Мотивация и целеполагание: Почему и как должны отличаться системы мотивации для сотрудников в офисе и на удаленке. Работаем по OKR, MBO или KPI? Прозрачность зон ответственности: методология RACI/RASCI. Personal Development plans.

Remote-эмпатия: Методология HDI; как выбрать эффективный инструмент для совместной работы и коммуникации (Zoom/Skype; Wrike; Bonusly; Shared calendars; Virtual party).

Подводя итог, посмотрим, как много плюсов дает работа в распределенной команде. Особенно, когда это неизбежно :)

Доклад принят в программу конференции

Работа с командой

Не удается создавать крутые команды? Да вы просто не умеете их готовить!

Базовый рецепт прост: Возьмите 5-7 мотивированных профессионалов, добавьте соли, перца и амбициозную цель, тушите на медленном огне мотивации 2 недели — результат вылейте на прод!

Однако, как начнешь готовить, сразу всё идет не так – конфликты, недоверие к лидеру, низкая мотивация, слабые результаты, текучка...
В чем же секретный ингредиент тех самых сплоченных продуктивных команд?

В этом докладе я поделюсь секретами Agile-кулинарии: как создать сильную продуктовую команду, настроить коммуникацию/взаимопомощь и быть в ней настоящим лидером.

Доклад принят в программу конференции

Глупо надеяться, что разработчики будут учиться сами по себе (за редким исключением). Но если выстроить единую отлаженную систему, где обучение будет тесно интегрировано в основную деятельность компании и являться частью работы, можно добиться очень хороших результатов. В данном докладе я хотел бы поделиться нашим опытом в части обучения и развития программистов и затронуть такие темы как:

• Мотивация сотрудников на развитие и обучение
• Как создать благоприятную среду в коллективе, способствующую получению новых навыков
• Где и какие курсы выбирать и как достичь максимальной отдачи от них в условии ограниченного бюджета
• Работа со студентами и выпускниками вузов
• Какие инструменты и средства мы используем для этого
• Как найти баланс между обучением и основной работой
• Также, вкратце расскажу о нашей системе грейдов, встречах 1:1, постановке и контроле выполнения целей и многом другом

В настоящий момент у нас в компании работает более 70 разработчиков, профессионалов своего дела. И очень многие пришли к нам студентами или младшими разработчиками (и я среди них). Надеюсь, что наш опыт поможет вам улучшить (или запустить) свою программу обучения программистов (и не только их).

Доклад принят в программу конференции

Часто получается так, что тимлидом в команде становится самый прокачанный разработчик. Зачастую этот разработчик хорош в hard skill’ах, но менеджментом до этого не занимался. В своем докладе я попробую рассказать о том, как принципы SOLID могут помочь технарю понять базовые правила менеджмента. Мы поговорим про людей и их роли, а также поймем все ли из этих принципов применимы к управлению командой. Кроме мы поразмышляем над организацией процессов разработки и проведем параллели между ними и подходами оркестровки и хореографии в распределенных системах.

Доклад принят в программу конференции

Многие команды сталкиваются с проблемой, когда всё для работы вроде бы есть: люди с амбициями, навыками, силами, а ожидаемого эффекта от командной работы нет. Или ещё хуже — команда разваливается.

Почему так происходит, и можно ли этого избежать?

- Чтобы лучше увидеть причины, нужно сравнивать свою деятельность не с соседями, а с лучшими в стране, в мире, в истории и смотреть, как работали они;
- Даже умные люди делают ошибки, но, в отличие от решений, ошибки хорошо видны и заметны — их запоминают;
- Можно собрать ошибки у лучших команд и посмотреть, где они споткнулись;
- Нам останется всего лишь не повторить их ошибок, чтобы пройти там, где они упали...

Справимся?

Доклад принят в программу конференции

Коммуникация

Детальный доклад о таком средстве коммуникаций в проектной команде как meeting notes (заметки или протокол собрания). Цель доклада - подробно рассмотреть все аспекты работы с заметками с собрания: что это такое, зачем они нужны, какую пользу приносит их написание и чтение как лиду, так и всей его команде. Кроме теории, поговрим также о тонкостях практической работы с заметками - как их правильно составлять, использовать и хранить, и самое главное, как это делать с минимальными затратами сил и времени.

Доклад рассчитан на широкую аудиторию, он будет полезен как практикующим лидам и менеджерам, так и тем, кто собирается ими стать.

Доклад принят в программу конференции

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

За много лет работы с Open Source я нашел много закономерностей: на что стоит обращать внимание при выборе технологии, как правильно участвовать в их развитии, а какие проекты лучше обходить стороной. Обучение разработчиков "в лоб" как правило не приносит ожидаемых результатов. Поэтому я придумал хитрый трюк, которой позволяет моим коллегам получать все лучшее от участия в проектах с открытым исходным кодом, одновременно обучая их выбирать и правильно использовать Open Source на благо компании.

Доклад принят в программу конференции

PM просит срочно взять в спринт “маленькую” задачку, а потом вся команда влетает в овертаймы, потому что “слона-то мы и не приметили”? И вроде сталкиваешься с оценками и планированием чуть ли не каждый день, но при этом раз за разом с оценками что от команды, что со своими собственными (что еще ужаснее) — творится какая-то ерунда.

В этом докладе я не буду пересказывать Википедию. Не буду учить вас “сколько вешать в граммах” помидорами или рубашками и умножать на 3.14. Вместо этого я хочу рассказать про физиологию нашего мозга и как он нас дурит.

Отобранные 5 искажений будут проиллюстрированы историями из жизни разработчиков, кратким экскурсом в физиологию происходящих процессов (не пугайтесь, их будет всего четыре) и набором выверенных кулинарных рецептов борьбы с ними и их превозмогания. Не обещаю, что после рассказа вы сразу станете богом оценки сроков и конкурентного анализа, но в вашем наборе инструментов точно появится один или два приема, способных помочь в трудную минуту.

Доклад принят в программу конференции