Конференция, полностью посвященная инженерным процессам и практикам

Доклады

TechLeadConf: Архитектура (5)

Начинали как OLTP, а закончили...?

PostgreSQL
MSSQL
Базы данных / другое
Архитектура данных, потоки данных, версионирование

Практически в любой самописной информационной системе СУБД сначала выглядит как чисто транзакционная — OLTP. Однако первым же вопросом от бизнеса после релиза становится... создание отчета. С этого момента начинается плавный «дрифт» в сторону от OLTP.

Покажем, куда же этот «дрифт» нас приведет и что с этим можно сделать. Конкретные цифры тоже будут!

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

Единственная ответственность

Роман Хаимов

Рексофт

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

В рамках доклада мы рассмотрим такое определение SRP, которое с наибольшей вероятностью поможет инженеру построить качественную архитектуру в своём проекте.

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

Строим архитектуру стартапа с большой кодовой базой

Роман Силаков

ex Яндекс Такси

Во время мастер-класса спроектируем архитектуру стартапа «Межгород» — сервиса для междугородних поездок. Проанализируем, как на нее влияет обсуждение требований и сроков с бизнесом. Рассмотрим на примерах, как можно переиспользовать существующую инфраструктуру и кодовую базу для более быстрой реализации.

Краешком глаза посмотрим на историю того, как архитектурные решения Яндекс Такси превращались в платформенные. В конце на примере спроектированного решения обсудим, с какими компромиссами приходится сталкиваться при запуске стартапов.

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

Принятие оптимального архитектурного решения по шагам

Методы и техника разработки ПО
Теория

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

В ходе доклада я постараюсь раскрыть скрытые промежуточные шаги. Предлагаю поэтапный алгоритм для принятия решений с применением таких инструментов, как ADD от SEI, SPE, TOC, TRIZ и других.

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

Как рассказывать архитектурные диаграммы

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

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

На примере одного известного архитектурного кейса мы обсудим пять основных затруднений, возникающих при изложении архитектурных решений, и способы с ними справляться. Кроме того, я предложу три рекомендации, позволяющие рассказать архитектуру решения интересно, ясно, ярко и максимально полно; вовлечь в принятие решений необходимых участников, но избежать при этом пустых утомительных обсуждений. Нам помогут выстроить внятный рассказ такие вещи, как шаблоны архитектурных решений ADRs, метод анализа компромиссов ATAM, практики выявления и оценки альтернативных вариантов реализации решения.

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

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

TechLeadConf: Безопасность (2)

Особенности создания внутренних сервисов в крупных компаниях, и как избежать провала

Роман Поборчий

Независимый эксперт

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

Нагрузки выше, сервис тормозит. Пользователи ругаются.

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

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

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

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

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

6 причин заняться безопасной разработкой

Как обеспечить безопасность своего продукта? Как соответствовать требованиям заказчиков и внутренней ИБ-команды?

Кажется, что ответ простой: нужно несколько сканеров кода, два крепких AppSec-инженера и быстро настроенная инфраструктура. Но проходит время, продукт обновляется, и возникают простые Low-уязвимости, которые игнорируются при анализе результатов сканирования, а рекомендуемые сроки исправления растягиваются из-за горящего бэклога.

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

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

TechLeadConf: Масштабирование: инфраструктура, процессы (1)

Как мы не выбрали K8s, остались эффективными и повысили производительность

Часто наши клиенты или друзья спрашивают: «А какую версию: „Кубернетес“ вы используете в продакшн?», и после ответа «Никакую», следует: «Ну, хоть Докер-то у вас есть?». Нет, Докера у нас тоже нет.

Еще 10 лет назад это мало бы кого удивило, но почему же мы так «отстали от жизни» и не внедряем «отраслевые стандарты» и не следуем best practices?

Мы предъявляем к своему ПО ряд требований:
* мониторинг;
* надежность;
* безопасность;
* производительность;
* масштабируемость;
* стандартизация развертывания;
* управление версиями.

Неправда ли, похоже на K8s?

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

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

TechLeadConf: Инженерные практики (7)

Как сделать инженерную культуру в компании однородной

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

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

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

Trunk based development: меняем подход к разработке и забываем о релизах

Мы начинали с монолита, релизов раз в 2 недели с регулярными срывами сроков и хотфиксами, а закончили авторелизами и изменениями сразу в мастер-ветку. За последние 365 дней этот проект деплоился на прод больше тысячи раз.

Расскажу, как мы к этому пришли: сравним Git Flow и Trunk Based Development, вместе преодолеем страх мгновенного попадания изменений на прод сразу после мерджа и насладимся миром, в котором отсутствуют проблемы после релиза.

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

Функциональные тесты: развёртывание, интеграция в CI и сбор покрытия

* Зачем отдавать приоритет функциональным тестам.
* Как мы пришли к этой ценности, зачем отказались от unit-тестов.
* Инструментарий для работы с функциональными тестами, как их готовить в платформе.
* Инфраструктура, как развернуть, интеграция в процесс CI.
* Как собирать статистику внедрения функциональных тестов, оценка качества.
* Как работает интеграция с Allure.
* Как собирается покрытие кода функциональными тестами.

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

Как и зачем централизованно управлять качеством в куче кросс-функциональных команд?

Автоматизация разработки и тестирования
Методологии и процессы разработки ПО; Сроки и приоритеты
Функциональное тестирование
Нагрузочное тестирование
Автоматизация тестирования
QA / другое
Мотивация сотрудников
Управление командой
Трансформационные изменения
Антон Епишин

Росбанк

Когда в 2019 году Банк вступил на тропу IТ-трансформации, и началось масштабное появление Agile-команд, развивающих свою часть продукта самостоятельно, единое «Управление качеством» в Росбанке было полностью расформировано. Специалисты переданы в команды, процессы и обязанности — тоже.

Но как обеспечить функционирование Банка всё же с учётом, что это единый IТ-организм, и падение одной системы влечёт проблемы в другой? Или как закрыть «ресурсный голод», когда какая-то команда может позволить себе выделить бюджет на выделенного инженера по нагрузке, а какая-то — не может нанять даже «ручника»? И как в таких условиях управлять качеством?

Одним из ответов стал подход «Тестирование как сервис», распространяемый подразделением, находящимся в Core IT. И в данном докладе коснёмся следующих тем:
* Вендор внутри? Или почему было просто не нанять 100500 внешних сотрудников.
* Как эволюционировали, какие идеи сработали, какие докрутили, исходя из открывшихся нюансов.
* Как это выглядит внутри и как работает в части 4 основных сервисов — методология тестирования, автоматизация тестирования, нагрузочное тестирование, инструменты тестирования.
* В чём плюсы для сотрудников такого подразделения, и где легко сгореть.
* Какие результаты, куда движемся и какие проблемы ещё только предстоит решить.

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

TDR — процесс технического дизайн-ревью

Базы знаний / wiki
Инструменты
Внутренние митапы

Многие компании в тот или иной момент времени приходят к необходимости валидировать архитектуру. Кто-то пишет пропоузалы, которые никто не читает. Другие пишут RFC, которые никогда не найдешь. Третьи делают архитектурные комитеты.

Мы в Авито пробовали все 3 формата и сделали свой, третий, под названием TDR.

О чем расскажу
* раскрою проблематику: кому когда и зачем нужна такая практика;
* опишу процессы, что были ранее;
* расскажу, при чем тут ТЕХРАДАР;
* опишу новый для нас процесс TDR — как способ провалидировать техническое решение;
* расскажу об итогах его внедрения.

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

Как техлиду выжать максимум из ChatGPT

В докладе мы погрузимся в новейшие, сложные и неочевидные аспекты и техники промптинга для ChatGPT, как для «Chat»-модели, так и при использовании API. Даже если вы уже освоили базовые техники, есть еще много тонкостей, которые могут кардинально изменить качество вашего взаимодействия с моделью. Во время доклада мы подробно рассмотрим тему мультиагентного взаимодействия, заставим модель работать саму с собой в разных амплуа, что позволит выводить качество ответов на совершенно новый уровень.

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

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

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

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

Автоматизация разработки и тестирования
Управление командой
Документация
Инструменты
Команда

Если команду всё устраивает, она не станет менять свои методы работы. Но когда начинает прибавляться пользователей или появляются новые услуги, возникают непредвиденные проблемы, и приходится быстро искать решения.

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

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

TechLeadConf: Резерв (3)

Как мы готовили Mobbing, или Парное программирование на всю команду, или Mobbing, или Экстремальное программирование в кросс-функциональной команде

Базовая идея доклада: поделиться опытом, как мы в Garage Eight привнесли в команду Pair Programming/Swarming/Mobbing. Расскажем, как заинтересовать команду погрузиться в такой подход разработки, какие болячки 100% вылезут, как с ними работать. Поделимся, как в таком формате ресерчить рынок конкурентов, как делать сугубо технические истории и, конечно, как работать над тестированием продуктовых гипотез и разработкой фич на все клиенты (Web, IOS, Android). Затронем утилизацию ресурсов в команде, ни для кого не секрет, что она будет низкой :) Поделимся результатами такой работы.

Приблизительный план доклада:
1. Что такое экстремальное программирование, как оно появилось, рассказать, что корень не «экстрим», а «экстремум».
2. Mobbing и Swarming как масштабирование парного программирования на всю кросс-функциональную команду. Рассказать формальные правила и то, как они работали в наших случаях.
3. Подробнее рассказать про первый опыт, конечно, болезненный.
4. Рассказать про более поздний опыт и про то, как кросс-функциональная команда ресерчила рынок конкурентов на старте нового продукта, как мы искали product-market fit.
5. Рассказать, как оно работает в маленькой команде из хардкорных T-shaper’ов.
6. Подвести итоги.

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

Как упорядочить подходы и покрыть стандартами зоопарк из 100+ микросервисов

Стандарты кодирования
Большие проекты/команды
Совместное планирование и разработка
Дмитрий Куянов

Райффайзен Банк

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

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

Как, а главное, зачем писать SDK для рекомендательной платформы

Методы и техника разработки ПО
Разработка библиотек, включая open source библиотеки
Управление командой
Фиксация знаний

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

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

База (7)

Как не превратиться из хорошего программиста в плохого менеджера

Фёдор Борщёв

Школа Сильных Программистов

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

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

Как наладить коммуникацию там, где все сломалось

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

Все знают, что в крупных корпорациях много бюрократии, которая, с одной стороны, защищает от необдуманных решений, а с другой, — мешает продуктивно работать. Известно также, что люди ко всему привыкают. Даже самые инициативные сотрудники через какое-то время начинают думать и отвечать в стиле: «это не наша проблема», «у нас все работает», «обратитесь к команде N». Иногда кажется, что победить в этой битве невозможно.

В докладе расскажу, как подходить к коммуникации для решения таких проблем, которые не решаются месяцами, а также поделюсь личным опытом и граблями, на которые можно было не наступать.

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

Рабочие конфликты как неизбежное. Как добиться цели, не сгореть эмоционально и сохранить хорошие отношения?

Коммуникация
Soft Skills
Эмоциональный интеллект
Доверие команды внутри и снаружи
Безопасная коммуникация, культура
Типовые ошибки
Лайфхаки
Команда
Алёна Рыжкова

Холдинг Т1, Группа Иннотех

Я третий год работаю менеджером проектов в банке из топ-10. Координирую работы 5-7 команд, которые не подчиняются мне напрямую. Несмотря на это, я научилась договариваться, находить решения и достигать целей проекта. При этом учитываю интересы всех участников и укрепляю отношения в команде.

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

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

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

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

Когда проблема — не проблема. НЖЯ — инструмент Теории Ограничений

В теории ограничений (Голдратт) есть отличный инструмент проблематизации — НЖЯ (НеЖелательное Явление). Грубо говоря, это правильная формулировка проблемы. Что такое правильная формулировка — формулировка, которая не вызывает желания оправдываться или обвинять, не сводит решения к одному единственному, сокращает количество эмоциональных споров, уменьшает количество предположений и субъективизма. Это такая формулировка, после которой хочется радостно бежать решать, иногда перед этим, правда, хочется свернуться в позу эмбриона и тихо плакать.

НЖЯ — это не самый простой, но гарантированный путь к такой формулировке. А ещё оказывается, что 40-80-... карточек с проблемами, можно безболезненно заменить на 10-15 НЖЯ и они опишут все проблемы системы, с которым большинство коллег легко согласится. Потом ещё окажется, что все проблемы/НЖЯ в системе связаны, а значит решать в первую очередь нужно всего несколько. А в конце выяснится, что причина всех НЖЯ системы в неразрешённом системном конфликте, который мы своими руками постоянно воспроизводим.

Приходите, должно быть интересно, весело и полезно.

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

Построение системы обратных связей внутри команды и вне её

Teamlead
Коммуникация
Soft Skills

Все мы неоднократно слышали про модели обратной связи и пробовали их применять, помните, самое простое: «похвалить, поругать, похвалить»? Но я столкнулся с тем, что обратная связь или даже базовая петля обратной связи бесполезна. Оказалось, что необходимо выстраивать сложные петли обратной связи, чтобы почувствовать «пульс» своей команды.

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

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

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

Топ-3 ошибок найма IТ-специалистов: на что может повлиять тимлид?

HR
Коммуникация
Мотивация сотрудников

Типичные проблемы найма глазами тимлидов (на основании исследования в телеграм-каналах). Эти проблемы — сигналы о том, что:
* нет согласия между ЛПР (кейс найма консультантов по ИБ, цифры: воронка, сроки, упущенная прибыль). 3 решения;
* рекрутинг «без человеческого лица» (кейс поиска разработчика, цифры: воронка, сроки). 5 решений;
* нет баланса требования — условия (кейс поиска аналитика, цифры: воронка, сроки). 3 решения.

Решения рассматриваем с 2 точек зрения:
* что можно изменить в компании в целом,
* что может сделать тимлид?

Зачем что-то менять в найме? Практическая выгода тимлида.

Польза: чек-лист для самоанализа процесса найма (все ли я делаю для эффективного найма в компании?).

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

Три субкультуры в IT-компаниях

Все хотят работать в «плоских» организациях, но мало кто хочет брать на себя ответственность за решения!
Все хотят, чтобы сотрудники были креативны, нацелены на результат, ответственны, мотивированы, но все равно продолжают указывать им, что надо делать (считая всех безответственными)!

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

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

Далее посмотрим на невидимые границы в развитии, которые сотрудники и руководители вместе сами на себя накладывают (а потом жалуются друг на друга), гипотезу разворота в самосознании, чтобы быть востребованным не только сегодня…

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

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

Кругозор (5)

Как то, что мы видим, влияет на наше состояние, поведение и решения

С помощью зрения мы получаем до 90% информации об окружающем нас мире. Я расскажу, как то, что мы видим, влияет на наше состояние, поведение и решения, и как это влияние проявляется в пользовательском опыте и не только.

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

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


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

Как пасти котят, или Проекция опыта работы с дошкольниками на команду

Коммуникация
Мотивация сотрудников
Расширение кругозора
Команда
Лилия Герасименко

One! International school

Многие руководители отмечали, что когда их дети подрастают, то подходы, которые работают с их детьми на разных ступенях взросления, работают и в айти-командах. А что, если дети не твои и их гораздо больше одного-двух?

Кроме игр и бесконечного бесилова, детей надо замотивировать на обучение, командное общение, обсуждение последних произошедших событий (ну все, как и во взрослой команде: ИПР, ретро, зарядка...).

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

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

Как окунуться в новую предметную область и не утонуть

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

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

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

«Модная болезнь»: что нужно знать про профессиональное выгорание, чтобы вовремя помочь себе и команде

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

На выступлении:
* опишем, как это все ощущается внутри и как проявляется во внешней жизни, проведем самодиагностику;
* разберем причины выгорания — какие звоночки вы упорно пропускали;
* внутренние и внешние причины выгорания — как перестраивать свою жизнь;
* определим пути, как выбираться из выгорания, если в него все же угодили, и о том, как его профилактировать;
* а также обязательно отделим выгорание от того, что им не является: «похоже, я выгорел» — звучит ярко, но не всегда соответствует действительности.

С выступления вы уйдете с конкретными и понятными рекомендациями: как быть и что делать, чтобы не гореть, а вполне себе сиять.

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

История внедрения трансформационных изменений в кластере из 600+ инженеров

Devops / другое
Корпоративная культура и мотивация
Teamlead
Личное развитие
Эмоциональный интеллект
Трансформационные изменения
Доверие команды внутри и снаружи
Лайфхаки

МТС стал экосистемой благодаря масштабной технологической трансформации как в плане организации и управления, так и в разрезе платформ и технологий. Чтобы успешно справляться с вызовами рынка, всем элементам экосистемы необходимо обеспечивать высокую скорость и гибкость.

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

В докладе мы последовательно разберем опыт внедрения новых практик в DevOps-кластере МТС Digital, затронем тему построения взаимодействия с командами, методы эффективной рефлексии для руководителя, лучшие практики и оптимизацию процессов изменений.

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

Оптимизируй себя (9)

Ресурсы и инструменты для развития тимлида: приоритеты, баланс, «помощь зала»

Управление / другое
Teamlead
Личное развитие
Эмоциональный интеллект
Делегирование задач
Трансформационные изменения
Лайфхаки
Менторинг
Образование

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

Мы обсудим:
* Где искать источники знаний и как курировать поток информации?
* Как найти ресурсы (внутренние и внешние) для роста?
* Как найти экспертов и менторов в нужной области?
* Как расставлять приоритеты и прокачивать навыки, когда рабочие задачи никто не отменял?
* Как поддерживать баланс энергии и не забросить все на полпути? Как не выгореть от нагрузки?

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

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

Сила нетворкинга, или Нетворкинг как стиль жизни

Нетворкинг является мощнейшим инструментом в жизни как руководителя любого уровня, так и обычного инженера. Так почему же им часто пренебрегают? В докладе разберемся в этом.

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

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

Искусство спрашивать, или 42 вопроса, которые ускорят развитие вашей команды и вас самих

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

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

Сохраним эти списки вопросов, чтобы их можно было использовать в работе (и в жизни) сразу после доклада.

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

Принятие сложных решений в условиях неопределенности

Многие начинающие руководители впадают в ступор при достижении некоторого уровня неопределенности.

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

Неопределенность надо любить! Она нас развивает и помогает формировать новые нейронные связи.

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

Менеджерский путь: вверх или вширь

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

Хочу поделиться, чем такая ситуация отличается от вертикального роста. Что мне пришлось поменять в своем отношении к работе, как поменять отношение к процессам. И глобально ответить на вопрос, как отвечать за в два раза бОльшую зону, при этом не работая x2 часов и не теряя в качестве.

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

Как помочь нашему мозгу, чтобы он помог нам

Soft Skills
Личное развитие
Лайфхаки

Вы узнаете об инструментах, которые помогут вам выйти на новую орбиту вашей жизни и работы команд. При этом первый шаг мы сделаем, не выходя из аудитории.

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

Система управления с обратной связью

Как не упустить важное, если в сутках всего 24 часа, а масштаб растет? Что делегировать, а что нет? Как держать под контролем ровно то, что нужно? Что делать, если чувствуешь, что твои подходы к управлению стали плохо работать?

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

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

Как работать с заказчиком из тяжелой промышленности при реализации цифровых проектов

Мы поговорим о том, какие типы заказчиков встречаются в тяжелой промышленности и как себя вести с каждым из них.

Обсудим, как объяснить ЛПР, что он получит в конце, если он не понимает, о чем речь или «4 способа культурно доносить ценность своей идеи без мата».

Как проверить заказчика на «потенцию» к реализации цифровых проектов — вам сказали, что проект полностью поддерживают и готовы во всем помогать? Не верьте, пока не пройдете по следующим шагам...

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

Источники развития для руководителя

Хочу поговорить о том, насколько широким должен быть кругозор руководителя, о различных стратегиях саморазвития. Хочу покритиковать традиционные подходы, такие как ИПР и развитие по матрице компетенций, и предложить более «созерцательный» путь.

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

Оптимизируй свою команду (14)

Уволить нельзя оставить: баланс между эффективностью и эмпатией

Управление / другое
Teamlead
HR
Коммуникация
Управление командой
Soft Skills
Эмоциональный интеллект
Татьяна Сеземина

Холдинг Т1, Группа Иннотех

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

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

Как дать негативный фидбэк: хардкорные кейсы

Коммуникация
Мотивация сотрудников
Управление командой
Soft Skills
Личное развитие

Обратная связь — мощный инструмент. Но бывает, что тимлиды не всегда доносят негативную или развивающую обратную связь до тиммейтов.

Каждый сталкивается с разными трудностями, давая фидбэк. Это страшно, это тревожно, это некомфортно. Однако это обязанность тимлида — передавать команде негативную и развивающую обратную связь.

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

Приходите, разберем хардкорный фидбэк!

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

Как мы научились нанимать тимлидов

Я работаю руководителем отдела бэкенда в Яндекс 360. Мы создаём виртуальный офис, в который входят Почта, Диск, Документы, Телемост, Календарь, Заметки, Мессенджер, Рассылки,Трекер, Вики и Формы. Раньше эти продукты существовали по отдельности (буквально в тихой гавани с размеренным развитием), но в 2020 году их объединили в экосистему Яндекс 360. А крупные компании начали переезжать к нам.

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

Далеко не все старшие разработчики в нашей команде готовы становиться тимлидами, а младшие ещё не доросли, и нужно нанимать с рынка. Но как нанять такого тимлида, который поможет нам развивать команду, растить инженеров и вольётся в нашу культуру? Как понять, что он не поломает нам команду? Что впишется в нашу культуру? Кто такой вообще этот тимлид? Что он должен делать?

Кажется, нам удалось вывести для себя формулу найма тимлидов.

В докладе подробно расскажу:
* как мы попытались решить задачу найма лидов, пользуясь уже привычными инструментами в Яндексе и почему это не сработало;
* как пришли к общему пониманию, кто такой тимлид;
* какие навыки тимлидов мы считаем самыми важными, как их проверить и как объективно оценить;
* как оптимизировали новый трек найма лидов, и что у нас получилось на сегодняшний день — поделюсь нашим опытом;
* в завершение доклада расскажу о других сложностях, с которыми мы столкнулись по пути и что мы с этим делали.

Небольшой дисклеймер:
* в докладе я буду говорить о найме линейных руководителей, т.е. тимлидов, у которых прямом подчинении 5-7 разработчиков или QA. Наем руководителей среднего звена немного отличается, хотя многие подходы могут быть применимы и для этого;
* доклад не является универсальной методологией найма тимлидов, это просто опыт нашей компании;
* я буду больше фокусироваться на построении процесса найма, а не на найме одного или двух тимлидов.

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

Как внедрять инженерные практики в сопротивляющихся командах

Тимур Мухтаров

Газпромбанк

1. Сопротивление. Как определить и разобраться с его причинами.
2. Как ясно и эффективно представить преимущества практик команде и показать, как они смогут повлиять на работу.
3. Как наладить открытую и эффективную коммуникацию в команде, чтобы преодолеть сопротивление.
4. Шаги по обучению команды новым навыкам и предоставление поддержки для успешного применения инженерных практик.

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

Круглый стол «Как измерить качество команды? Метрики vs программисты»

Методологии и процессы разработки ПО; Сроки и приоритеты
Продуктовая разработка

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

На эти вопросы мы поищем ответы в компании опытных экспертов, которые поделятся личным опытом внедрения и использования метрик в разработке коммерческих продуктов в сфере IT.

Поговорим о таких вещах, как:
* CycleTime / LeadTime;
* SLI/SLO/SLA;
* Web Vitals;
* количество уязвимостей;
* количество багов;
* количество сбоев;
* тестовое покрытие;
* количество строк кода :)
и о многом другом.

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

Играть или не играть? Как развивать команду с помощью игры

Расширение кругозора
Фиксация знаний
Инструменты
Методологии
Образование
Внутреннее обучение

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

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

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

Оценка производительности команд: минимум данных — максимум пользы

Пошагово расскажем о методике подсчета производительности команд, где мы «поженили» аджайл, скрам, вотерфол, канбан и т.д., и выделили универсальные метрики производительности, которые можно получить из любого таск-трекера. Таким образом, минимальное кол-во метрик может показать максимальное кол-во результатов (данных для анализа), максимальную репрезентацию реальной картины

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

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

100 новых АйТишников в год, или Как мы растим стажеров

Базы знаний / wiki
Онбординг
Менторинг
Образование
Внутреннее обучение
Подбор команды

* Хотите запустить стажировку, но готовы ли вы к этому? Сколько стоит “бесплатный стажер”? Как научиться учить других?
* Где искать стажеров? Почему публикация на карьерных сайтах - это всего лишь 15% успеха, а HR начинает сёрфить университетские каналы в соцсетях.
* Работаем над первым впечатлением стажера о компании и развенчиваем миф, что новички — это бесплатная рабочая сила.
* Учим так, чтобы было интересно. Составляем программу обучения и эффективно расходуем время наставника.
* Инструменты контроля процесса обучения, оценки роста и как следить за уровнем мотивации.
* Интегрируем стажера в профессиональную команду. Как подготовить к реальной работе, чтобы новичок не стал обузой.
* Учимся у стажера. Почему важно проводить ретро для оценки эффективности программы обучения.

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

Инженерная культура. Что это и почему она важна?

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

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

Карьерный путь начинающего специалиста с обеих сторон (руководитель/сотрудник)

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

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

В докладе мы вместе разберём, кому и для чего нужно нанимать стажёров. Рассмотрим путь начинающего специалиста и роль ментора в процессе его адаптации. Разберём основные особенности работы: стиль управления, тип и объём задач, поговорим про важность развивающей обратной связь и её роль в развитии, рассмотрим построение карьерного трека начинающего специалиста в команде (ИПР): стажёр → джун → middle.

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

Климат в команде как инструмент повышения эффективности

Корпоративная культура и мотивация
Teamlead
Коммуникация
Мотивация сотрудников
Управление командой
Soft Skills
Эмоциональный интеллект

Практические рекомендации по созданию командной атмосферы. Проверено на распределенных командах.

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

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

Принципы построения команд, которые работают

Модели руководства
Поиск и развитие команды
Управление / другое

Решаемые проблемы:
* С чего начать создание команды?
* Что должен делать руководитель? Где моя зона ответственности?
* Как руководителю команды не быть единственным ответственным за результат?
* Какие вопросы задавать команде при проблемах, чтобы не заставлять оправдываться?
* Как организовать обратную связь с руководителем и для решения каких задач можно ее использовать?

За 12 лет в технической поддержке я прошел путь от инженера до руководителя тимлидов. Подготовку к переходу в руководители HR начал с вопроса: «А тебе это точно нужно?». Нужно. Но с чего начать? Как понять, что относится к моим обязанностям, а где со мной «советуются», возвращая задачу назад? И как заставить все это работать?

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

Конвейер роста тимлидов

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

Как построить такой процесс? Поделюсь своими соображениями, а также поделюсь не только успехами, но и провалами на этом нелегком пути, чтобы слушатели могли не скакать по тем же граблям.

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

Как превратить такой простой (но сложный) онбординг в инструмент развития всей команды

Большие проекты/команды
Корпоративная культура и мотивация
Коммуникация
Мотивация сотрудников
Управление командой
Эмоциональный интеллект
Управление проектами

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

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

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

Митапы и мастер-классы (11)

Применяем Event storming как навык эффективной коммуникации между разработкой и бизнесом

Поиск и развитие команды
Продуктовая разработка
Управление / другое
Teamlead
Управление командой
Управление разработкой
Личное развитие
Управление проектами
Трансформационные изменения
Agile / Scrum
Расширение кругозора

Приходите научиться Event Storming’у, если у вас когда-либо были сложности с тем, чтобы:
* узнать у Бизнеса, что он действительно от вас хочет, и начать говорить на одном языке;
* донести до Бизнеса, где есть вопросы и сложности в разработке;
* вовлечь всю команду в анализ работы продукта;
* получить общее видение и понимание того, что с ним происходит;
* разложить нюансы поведения продукта в понятную последовательность действий и увидеть узкие места.

Event Storming не только поможет разобраться со сложностями, описанными выше, но и облегчит поиск новых эффективных решений на стыке технологий и бизнеса.

В процессе воркшопа мы познакомимся с базовыми понятиями инструмента и научимся их применять.

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

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

Деловая игра «Ожидания заказчика: выяснять и управлять»

Методологии и процессы разработки ПО; Сроки и приоритеты
Управление / другое

Как здорово общаться с заказчиками или стейкходерами на одном языке. А что, если вы не знаете его язык? Как будете действовать?

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

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

Как формулировать проблемы так, чтобы их решения приближали к цели (НЖЯ, ТОС)

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

Прежде чем бросаться решать проблемы, хорошо бы правильно их сформулировать. Что проблемой назовёшь, то и будешь решать. А ещё хорошо бы договориться с товарищами о необходимости решать эту проблему прямо сейчас.

В теории ограничений (Голдратт) есть инструмент проблематизации — НЖЯ (НеЖелательное Явление). Грубо говоря, это правильная формулировка проблемы. Что такое правильная формулировка — формулировка, которая не вызывает желания оправдываться или обвинять, не сводит решения к одному единственному, сокращает количество эмоциональных споров, уменьшает количество предположений и субъективизма. Это такая формулировка, после которой хочется радостно бежать решать, иногда перед этим, правда, хочется свернуться в позу эмбриона и тихо плакать.

На мастер-классе потренируемся на ваших реальных примерах формулировать правильно: не «у нас плохая коммуникация», а «мы 50% трудоемкости проекта тратим на переделки», не «новый начальник — не очень», а «текучка выросла на 10%», не «сложно распространять знания — не читают, не знают где искать, не используют», а «в базе знаний часто нет информации, которую запрашивают сотрудники».

Приходите, должно быть интересно, весело и полезно.

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

Отзывы как ресурс. Мастер-класс по работе с качественными данными с помощью дизайн-мышления

Инструментальная поддержка, декомпозиция задач
Методологии и процессы разработки ПО; Сроки и приоритеты
Метрики
Инструменты
Методологии

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

МК будет интересен всем, кто участвует в создании продуктов, а также HR-специалистам.

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

Я их боюсь: как тимлиду спокойно управлять командой и влиять на эффективность бизнеса

В своем докладе я хочу предложить:
1. разобрать связь мыслей с эмоциями. Разложить по полочкам самые частые мысли тимлидов, которые приводят к страху (например, «Люди — это черный ящик. С ними все непонятно», «Боюсь оказаться плохим руководителем для него», «Не имею права предлагать, у меня нет такого уровня экспертизы» и т.д.) и показать ограниченность этих суждений.
2. показать как мы обманываемся эмоциями, думая, что эмоция вначале, а действие потом. Рассказать, какую информацию несет страх и как его трактовать.
3. обсудить 3 вида страха и способ действий при каждом из них.

За 2 с лишним года работы в компании я разговаривала с 40+ тимлидами. Это были интервью по управленческим компетенциям, развивающие встречи и коучинговые сессии. И когда мы обсуждали препятствия на пути достижения личных, профессиональных и бизнес-целей, то чаще всего в качестве главного препятствия коллеги называли неуверенность в себе. Чем больше мы говорили об их неуверенности, тем очевиднее становились ее причины. Где-то не хватало теоретической базы в менеджменте, где-то — практического опыта в решении вопросов с командой или технических задач, но самый большой вес коллеги присваивали страху.

«Страшно, что ошибусь», «страшно, что не поймут и не пойму», «страшно, что опозорюсь и моя репутация навсегда будет испорчена», «страшно, что не достигну результата и придется увольняться» — именно эти страхи озвучивали они.
Страхи настолько сильны, что тимлиды:
* предпочитают избегать сложных разговоров с подчиненными, что приводит к накоплению проблем и росту непонимания;
* не могут внедрять инициативы, и это замедляет не только скорость изменений в компании, но и выстраивание стандартных базовых процессов в группе и между отделами;
* не могут отказывать коллегам и руководителям, берут все задачи подряд и закапывают сами себя, а потом выгорают;
* страх заставляет их молчать на общих встречах по проектам, где есть руководители выше уровнем и коллеги из других департаментов, снижая эффективность кросс-функциональной команды и формируя имидж «робкого, безыдейного новичка».

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

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

Маркер всевластья, практика визуальных встреч

Коммуникация
Управление командой
Управление разработкой
Управление проектами
Расширение кругозора
Лайфхаки
Фиксация знаний
Инструменты
Методологии

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

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

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

Мастер-класс будет включать работу как с традиционными, так и с цифровыми инструментами. От флипчартов и досок до цифровых приложений — мы исследуем различные способы визуализации ваших идей.

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

Как совмещать Agile и план-факт культуры

Большие проекты/команды
Модели руководства
Корпоративная культура и мотивация
Поиск и развитие команды
Управление / другое
Вирна Штерн

Aletheia Digital

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

Сложность, которая есть сейчас — это смешение корпоративной культуры, в которой человечество жило со времени Адама Смита, и цифровой, формально начавшейся с появления Agile-манифеста.

В головах винегрет из практик и интернет-мемов!

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

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

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

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

Командные встречи: неизбежное зло или секрет вашей антихрупкости

Дарья Вьюнова

OTUS Онлайн-образование

С первого взгляда, что сложного в том, чтобы провести групповой созвон или еженедельную встречу?

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

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

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

Коммуникативная компетентность в работе тимлида++, или Конец эпохи делегирования

Модели руководства
Корпоративная культура и мотивация
Поиск и развитие команды
Управление / другое
Вирна Штерн

Aletheia Digital

«Люди и взаимодействие важнее процессов и инструментов» — первый тезис Agile-манифеста. И это главный вызов в работе начинающего управленца, который еще вчера отвечал только за себя, а теперь выясняется, что:
1. С людьми нужно коммуницировать!
2. Люди далеко не всегда тебя понимают!
3. С людьми надо создать договоренность, не на словах, а чтобы было сделано то, о чем договаривались!
4. Классическое делегирование в IT-культуре работает плохо (и, вообще говоря, не должно!).
5. Люди включают «дурака», когда понимают, о чем речь, но не согласны по сути.
6. Люди — сложные субъекты, где «много всего» и вывести их на объективность — непростая задача.

На мастер-классе мы будем экспериментировать и исследовать, пожалуй, самую сложную, базовую часть взаимодействия: как организовать взаимодействие по делу, как отделить мешающую деловой коммуникации субъективность или хотя бы нивелировать ее влияние на общее дело. А также как осуществлять баланс между «бесчеловечным» взаимодействием по делу и социальным, душевным общением между людьми, без которого первое (взаимодействие по делу) не получается!

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

Запускаем цикл непрерывных улучшений

Алексей Лосев

Яндекс Маркет

Елена Большакова

Яндекс Маркет

Сергей Тесленко

Яндекс Маркет

Процесс разработки программного обеспечения зависит от многих факторов. Часть из них находится в нашей зоне влияния, часть случайна и непредсказуема.

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

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

За 2 часа, благодаря моделированию 5 разных подходов, сэкономим время на эксперименты с вашими реальными командами.

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

Воркшоп «Офисные кобры и те, кто с ними в команде»

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

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

Приходите на воркшоп, через практику разберемся:
1) кто эти типичные кобры среди коллег, в чем их «опасное поведение» и как быстро его распознать;
2) как стать укротителем — на кейсах отработаем схему действий при столкновении с кобрами.

Жду на воркшопе всех, кто устал терпеть и готов предпринимать активные действия.

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

Резерв (3)

Системное мышление — нужно ли оно в IТ и зачем?

Личное развитие
Расширение кругозора
Методологии

Системное мышление — мощный инструмент построения моделей реального мира и проектирования его изменений. Но действительно ли такие мощные инструменты общего характера необходимы архитектору, разработчику в повседневной работе для проектирования или разработки? Ведь существует много прикладных моделей и подходов, таких как для с4 model и Archimate для архитектуры, или ООП и DDD для разработки кода, Event Storming чтобы разобраться с предметной областью и много других.

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

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

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

Как помочь команде стать эффективной

Модели руководства
Корпоративная культура и мотивация
Поиск и развитие команды

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

Чаще всего в таких случаях начинают внедрять OKR и KPI или чинить, ставя «амбициозные цели». Но такие изменения не приносят нужного результата: демотивируют команду, вызывают сопротивление «системе» и нередко приводят к увольнениям после бонуса.

Мы обсудим результаты исследования, проведенного на Saint TeamLeadConf 2023, и поговорим о том, что такое пороки команды, как их диагностировать в вашей команде и какие изменения в действительности стоит делать, чтобы сделать работу команды более эффективной, а не бороться с новыми сложностями.

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

Софт-скилы тимлида. Классификация и алгоритм развития

* Симптомы проблем с софт-скилами тимлида.
* Soft skills — недостаточно формализованные hard skills.
* Soft skills и взаимодействие с командой, бизнесом и собой.
* Алгоритм выявления проблем с софт-скилами и саморазвития.
* Метрики эффективности работы тимлида, связанные с soft skills.

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

TechTalk (4)

Ретроспектива и ее ценность для команды разработки

Сергей Мехоношин

Газпромбанк.Тех

1. Разгадаем загадку ретроспективы, во время которой исчезают все разработчики.
Как сделать ретро действительно полезной активностью, а не поводом для не поработать; как ретро влияет на продуктивность команд.
2. Почему конфликты в команде — это не всегда плохо? Какие конфликты ведут к росту в команде, а какие, наоборот, мешают взаимодействию. Почему разрешение конфликтов важнее их замораживания. И какую роль играет ретроспектива в разрешении конфликтов.

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

Проекты 0-1: туристы не открывают новые земли

Рефакторинг
Методологии и процессы разработки ПО; Сроки и приоритеты
Большие проекты/команды
Оценка сложности проекта
Антикризисный менеджмент
Поддержка и развитие legacy систем
Teamlead
Управление командой
Управление разработкой
Трансформационные изменения
Алексей Панаэтов

МТС Диджитал

Поговорим о выборе эффективных процессов разработки для компаний, проходящих через трансформацию. Сфокусируемся на периодах, когда компания только начинает делать продукт (стартап) и когда разворачивается (переделывает имеющийся продукт) Эти этапы развития компании называют проектами 0-1.

Расскажу про каждый из этапов, поделюсь кейсами из практики.

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

Зрелая команда: во что инвестировать прежде всего

Максим Морев

Газпромбанк

* Что такое зрелая команда и зрелая инженерная культура?
* Какие этапы при построении и цели.
Поговорим про:
* стандарт разработки, который развивается сообществом, «командой»;
* про людей
** ситуативность:
от диктатуры к делегированию при построении команды при жесктих темпах разработки.
** вовлеченность:
1:1, неформальное общение.
** Индивидуальный План Развития.

Итог: переход одним днем и повышение.

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

Построение команды Customer Happiness с нуля внутри компании для успешной интеграции собственных платформ

Дмитрий Бодин

МТС Диджитал

Расскажу про наш опыт организации команды Customer Happiness, которая призвана закрыть все потребности новых потребителей платформы и ускорить онбординг, а также их поддержку на протяжении всего времени использования.

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