Доклады

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

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

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

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

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

Расскажу о том, как достичь успеха на примере нескольких проектов.

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

Как задать именно тот вопрос, который сдвинет дело с места? С какой целью мы задаем вопрос? Кому его задаем? Сколько контекста достаточно для ответа на него? А про то ли мы спрашиваем?

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

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

С позиции Теории Ограничений мы с вами подумаем о следующих вопросах:
* а почему, если кто-то простаивает, то это плохо?
* в чем опасность оценки трудозатрат в часах?
* как можно оптимизацией сделать хуже?
* бывает ли так, что, работая меньше, мы приносим пользы больше?

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

Приносите ноутбуки - мы будем работать в электронной доске и клеить на ней электронные стикеры. Созданные таким образом истории вы сможете забрать с собой для дальнейших размышлений.

Расскажу, как эволюционировал подход к управлению и какие принципы Toyota адаптируются к IT. Покажу, почему классические подходы не работают в реальности команд. Расскажу, какие инструменты из TBP действительно применимы — 5W, RCA, Диаграмма Исикавы, A3 — и как ими пользоваться. Объясню, почему виноват не человек, а процесс, и что делать, если лидер «сходит с ума».

Как запустить новое подразделение без готового запроса и выстроенных процессов:
* с чего начать: выявление реальных потребностей бизнеса и IT;
* договариваться со смежниками: цель, формат и распределение ролей;
* как перенести разрозненные знания в доступную систему (документация + AI-бот);
* как убрать «лички» и настроить единый вход для запросов;
* как нанять и онбордить команду в условиях неопределенности;
* метрики, которые помогают доказать ценность и держать фокус;
* ревизия легаси-процессов: что оставить, что пересобрать;
* база знаний для сотрудников и клиентов: ускорение и прозрачность;
* работа с сопротивлением и удержание собственной энергии руководителя.

Результат: автономная функция, связавшая бизнес, продукт и IT.

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

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

Как автоматизировать? Что? Расскажу.

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

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

Привет! Я Толя. Руковожу командой рекомендательной системы в сегментном маркетинге МегаФона. Работаю с данными половины страны — это миллиарды событий ежедневно.

Представьте: 50% A/B-тестов шли в топку из-за бардака — «это не мое», бесконечный поиск ответственных, потерянные знания, результаты, которые уходят в стол. Реально больно.

Поделюсь опытом, как я в Мегафоне прошел этот путь и построил культуру, которая помогает растить выручку, а не выгорать.

Расскажу о трех ключевых пунктах, которые я изменил в процессах на несколько кросс-функциональных команд и поменял культуру A/B:
1. про то, что помнить все — необязательно, но важно сохранять знания;
2. про то, что важно приоритизировать все инициативы и как я внедрил оценку эксперимента как продуктовой фичи;
3. про то, что нужно качать культуру вместо геройства и самоотверженности, находить тех, кому не все равно, и делегировать им ответственность.

Культура системности, прозрачности и совместной работы — вот что превращает адхок в двигатель бизнеса. A/B-тестирование — это про людей и процессы, а не только про данные.

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

Но так было не всегда…

Расскажу о своем опыте внедрения Scrum и Agile в большом анимационном сериальном производстве на примере проекта «Бум Земли».

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

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

Мир меняется так быстро, что нужно уметь адаптироваться и находить нестандартные решения. Креативное мышление все чаще становится ключевым софт-скилом, в том числе в IT.

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

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

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

1. Росатом — не только атом: десятки ИИ-разработок от NLP до LLM и выведенные на рынок продукты.
2. Две вселенные: ИИ в производственной компании и производственной корпорации.
3. Как все начиналось — корень будущих ошибок.
4. Ключевые «грабли» и как мы их исправляем:
* синхронизация стратегии корпорации и стратегии ИИ: к чему мы пришли за N лет;
* единый центр экспертизы;
* принцип 3 китов: новый подход к гипотезам и их скорингу;
* инфраструктура: это было больно;
* «свежая кровь»: почему Росатому непросто работать с набором и как мы это решили.
5. Выводы и фокус на ближайшие годы, в том числе внедрение генеративного ИИ.

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

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

Расскажу о практическом кейсе становления сложного релизного цикла SDK кроссплатформенного мобильного видеоредактора:
* особенности разработки SDK для малого числа клиентов;
* как разрабатывать взаимосвязанную фичу одновременно и со стороны SDK, и со стороны клиента;
* организация CI/CD для проектов со сложными интеграциями;
* расскажу, как общие рекомендации, такие как чистая архитектура, документирование процессов и рефлексия, помогли в этом практическом случае.

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

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

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

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

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

1. Миф о совершенстве: почему «идеальный лидер» — это иллюзия.
* Проблема: согласно опросам консалтинговых компаний сотрудники не доверяют руководителям, которые скрывают слабости. Культ «безупречности» приводит к токсичной атмосфере, где ошибки замалчиваются, а инновации блокируются.
* Решение: разрушаем миф через кейсы: команды с «неидеальными» лидерами быстрее адаптируются к изменениям.
* Уникальность: вместо абстрактных призывов показываем, как перфекционизм убивает прибыль.

2. Уязвимость ≠ слабость: как она усиливает влияние.
* Проблема: сотрудники не делятся идеями, если лидер не признает ошибок.
* Решение: только сильный менеджер может позволить себе быть слабым и использовать это как инструмент достижения своих целей и повышения результатов команды.

3. Что такое эмпатия на работе?
* Проблема: зачастую сотрудники считают, что менеджеры игнорируют их личные обстоятельства.
* Решение: определение эмпатии через три компонента: когнитивный («понимаю»), эмоциональный («сопереживаю»), действенный («помогу»). Пример: лидер, который перенес дедлайн из-за болезни ребенка сотрудника, сохранил его лояльность.
* Уникальность: развенчиваем мифы («эмпатия — быть добреньким») через чек-лист «Что эмпатией не является».

4. Как проверить, что вы неэмпатичный лидер?
* Проблема: значимая часть конфликтов возникаюет из-за негибкости менеджеров.
* Решение: чек-лист «7 красных флагов» — игнорирование эмоций, шаблонные фразы («все через это проходят»), упор только на метрики. Интерактив: тест «3 индикатора неэмпатичности» (например, «вы не помните контекст сотрудников»).
* Уникальность: даем «зеркало», чтобы менеджеры сами диагностировали проблемы, а не ждали фидбэка.

5. Как вовремя засечь тревожные сигналы в команде?
* Проблема: сотрудники скрывают стресс, пока не станет поздно отрабатывать возражения.
* Решение: анализ цифрового следа — краткие «ок» в чатах, пассивность на встречах, формальное выполнение задач. Инструмент «Карта активности»: таблица для фиксации, кто молчит/опаздывает/перебивает.
* Уникальность: учим «читать» невербалику на удаленке через чаты и Zoom-встречи.

6. Первые шаги к эмпатичности: с чего начать?
* Проблема: менеджеры боятся, что эмпатия отнимет время и авторитет.
* Решение: правило 3хП — признавайте незнание, просите о помощи, показывайте эмпатию. Ритуалы: «Эмоциональный барометр» на планерках (смайлики вместо статусов), 1:1 без рабочих тем.
* Уникальность: даем чек-лист «5 шагов за 5 дней» — от анализа чатов до первого «спасибо за честность».

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

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

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

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

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

В индустрии доминирует нарратив «будь громче, заметнее, активнее». Но что делать тем, чья сила — в глубине, а не в яркости? Как расти, когда твоя компания не выстраивает систему поддержки для «тихих профессионалов»?
В IТ-командах 60% лидеров — интроверты, но корпоративные правила видимости написаны экстравертами. Результат: талантливые специалисты остаются «невидимками», их идеи игнорируют («это не моя работа»), а карьера упирается в потолок — потому что «нужно больше коммуницировать» или «просто выступай чаще!» (спасибо, кэп).

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

* Практические стратегии карьерного роста для тех, кто предпочитает substance over style.
* Неформальное лидерство: как зарабатывать авторитет через менторство, внутренние инициативы, экспертную позицию и инициативу/ответственность.
* Стратегия «точечной видимости»: куда направлять усилия для максимального эффекта при минимальных «публичных» действиях.
* Работа с сопротивлением: как доносить идеи в организациях, где статус-кво сильнее инноваций.

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

Что вы получите:
* чек-лист понятных шагов для роста «тихого профессионала»;
* конкретные кейсы трансформации личного влияния;
* инструменты для навигации в корпоративных реалиях.

Нам хочется быть эффективными и реализовывать больше интересных проектов! Мы стремимся сохранять эффективность во всех сферах. Возможно ли это? Да, но с оговорками.

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

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

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

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

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

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

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

Что будет с зубами, если их не чистить? Недели, месяцы, годы. Примерно то же происходит с психикой, за которой не ухаживают. Зубам-то повезло, их видно. С ментальной гигиеной есть одна маленькая проблемка: люди в теории соглашаются с тем, что это важно и nice to have, но им некогда и неохота выделять внимание и время, чтобы на постоянной основе заботиться о том, чтобы в голове было «проветрено», напряжение не накапливалось и был нормальный уровень энергии для работы и жизни. Проблему замечают тогда, когда человек уже выгорел, его качество жизни на дне и никакой энергии и в помине нет.

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

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

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

Я дам вам 5 простых, понятных, быстрых и научно доказанных инструментов, и вам хватит их на всю жизнь, чтобы поддерживать свою психику в прекрасном состоянии. Предложу алгоритм, как внедрить практики в свою жизнь на постоянной основе. Также мы обязательно потренируемся физически управлять своим вниманием и вернем себе контроль над этим важнейшим психическим процессом, который в последние годы совершенно отбился от рук (СДВГ, привет!).

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

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

Первая часть этой серии докладов про прозрачную культуру коммуникаций «Игра в открытую» была про то, как уметь приносить плохие новости, особенно тем, кто для нас значим. Но что делать, если проблема на столе адресована лично тебе? Когда тебе задают неудобный вопрос на all-hands, прямо указывают на промах или нарушают границы?

В такие моменты от тебя ждут реакции — и твой ответ задает тон всей ситуации.

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

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

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

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

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

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

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

Разберемся, как работать с сопротивлением и прийти к успеху,

* Почему хаотичное обучение (курсы, книги, статьи) не дает роста и приводит к выгоранию.
* Как связать саморазвитие с карьерными целями и рабочими задачами.
* Моя система.
* Как себя мотивировать.
* 3 практических шага, которые слушатели смогут применить на следующий день.

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

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

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

Я 25 лет руковожу и 10 лет консультирую команды и компании, и одной из самых интересных задач всегда было «первое знакомство». Что такого спросить и на что посмотреть, чтобы сказать — этот тимлид молодец и построил классную команду, а вот тот — еще сможет улучшить результаты? Как определить, эти конкретные люди достигли своего максимума? Что я, как руководитель, могу изменить в условиях работы команды или как измениться сам, чтобы отдача была на 100%. О чем я забываю, выстраивая работу?

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

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

Мы в hh.ru захотели системного подхода: чтобы руководителями становились те, кто действительно хочет и может ими быть. Так появилась наша модель компетенций тимлида. Мы не просто набросали чек-лист — мы годами оттачивали модель, делали ее живой, точной и применимой. Сейчас она используется для оценки, обратной связи, карьерных решений и развития.

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

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

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

Что делать, когда аналитики работают в разных командах, с разными процессами и без общей системы планирования?

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

Счастливый сотрудник эффективнее на 15%, посчитали ученые. Ок, хочу, дайте мне много счастливых команд, сейчас как рванем!!

Эээ, а как? Что я, как тимлид или менеджер, могу сделать, чтобы повлиять на это неуловимое состояние. И себе хочу.

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

В истории известны случаи, когда команда работает успешно. И случаи, когда команда разваливается. Для второй ситуации известно 100500 способов, как этого достичь — про них пишут статьи, рассказывают тренеры (что никому не мешает повторять это снова и снова). Но есть ли инструкция, как собрать успешную команду?

За 25 лет в IТ я создал и развалил не один десяток команд. По мотивам этих подвигов у меня сформировалась некая система координат в 3+1 пространстве. По ее измерениям можно распределить участников команды и попытаться понять — кто нам еще нужен и где у нас будут проблемы. Решение не претендует на универсальность, но как чек-лист для самопроверки годится.

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

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

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

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

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

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

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

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

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

Я руковожу командой из более чем 1000 человек и 50+ лидеров. Все, что у меня есть и что я умею, — это команда. И одна из моих важнейших задач – это учить управленцев управлять управленцами.

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

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

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

Рынок найма в IT изрядно перетряхнуло за последние 3 года. Весной на 1 вакансию QA в среднем было 60-80 откликов. Многие кандидаты научились грамотно оформлять CV, однако, когда дело доходило до тех. собеса, нанять часто было некого.

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

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

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

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

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

Мотивация — это не магия. Иногда достаточно перестать мешать людям хотеть работать.

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

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

В докладе на основе более чем 10-летнего опыта работы в RnD-командах известных компаний будет рассказано, какие особенности RnD стоит знать и использовать тимлидам, руководителям разработки продукто-инфраструктурных команд и Product manager’ам, чтобы оптимизировать процессы команд, которые занимаются RnD.

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

Что на самом деле скрывается за понятием инженерной культуры? Зачем она команде? Как ее развивать? Почему тимлид должен этим заниматься, с чего начать и как вовлечь команду?

Обо всем этом — на основе реального опыта, ошибок и работающих решений — поговорим в моем докладе.

Мы, тимлиды, мечтаем о командах без конфликтов: открытые ссоры и затаенные обиды точно не помогают продуктивной командной работе. Поэтому мы с гордостью говорим: «У нас дружная команда!». А всегда ли настоящая дружба — благо? Или тут своя The Big Friend Theory: где сегодня поддержка, а завтра рушатся процессы.

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

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

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

1. Зачем проводить Squad Health Check?
* Роль оценки здоровья команды в поддержании высокой производительности и вовлеченности.
* Выявление проблем внутри команды до того, как они станут критическими.

2. Методики и инструменты для оценки состояния команды.
* Популярные инструменты и подходы для проведения Health Check (например, шаблоны опросов, простые анкеты, ретро-сессии).
* Как выбрать подход, который соответствует вашей команде и организации.

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

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

5. Как engineering manager может эффективно проводить health check, мотивировать команду и использовать полученную информацию для дальнейшего роста.

Цель: научить команды писать постмортемы, снижать количество багов и тестировать релизы в срок.
Контекст: международный Ride-hailing-сервис, 48 стран, 50 кросс-функциональных команд, 300+ инженеров.
Проблема: ни один из инженеров вам не подчиняется.

Интригует?

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

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

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

Доклад будет особенно полезен, если вы:
* работаете в платформенной команде;
* техлид в компании со сложной структурой;
* продакт-менеджер, которому нужна помощь нескольких команд;
* руководите DevOps/-QA-/Security-практиками;
* постоянно отбиваете попытки ребят из списка выше впихнуть что-то непонятное вам в работу.

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

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

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

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

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

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

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

Раунд первый — при помощи зрителей мы найдем самые популярные ответы на вопросы: почему разработчики не читают требования и почему аналитики пишут много букв.

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

И в заключение добавим практические рекомендации, как разработчикам и аналитикам действовать в этой ситуации.

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

Вы приходите в проект, а там — джуны, неопределенность в процессах, горящие сроки, и отсутствует документация. Бизнес ждет результата, а команда не готова к вызовам.

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

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

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

Нужно реализовать проект с непонятными требованиями и сроком «вчера»? А может, проект уже давно не укладывается в дедлайны, команда выгорела, но нужно как-то его достойно дотащить до релиза? А еще бывает, заказчик давно разочарован в работе исполнителей, отношения испорчены, и перед вами задача все это исправить — как быть?

Во всех случаях на помощь приходит она — грамотно организованная антикризисная команда с инструментами мониторинга и предотвращения «кризисов».

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

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

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

Рискну предположить, что в любой матрице самым сложным этапом является оценка сотрудника. Листаешь огромный список компетенций, останавливаешься на пункте «делает/умеет» и не знаешь, что поставить: «хорошо» или «плохо»?
Размытые критерии — боль почти каждой компании. Мы прошли тот же путь.

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

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

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

🔥 Почему вам стоит прийти на доклад «Минздрав предупреждает: аутстафф рискован для жизни»?

📌 Вы узнаете:
✔ почему традиционные аутсорс и аутстафф тормозят рост IT-компаний;
✔ какие скрытые риски несет аутстафф для бизнеса и разработчиков;
✔ как гибридный аутстафф решает проблемы бюрократии, ответственности и скорости.

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

🔧 Как это работает?
* Фокус на результат, а не на процесс.
* Минимизация зависимости от ключевых сотрудников.
* Оптимизация затрат и качества разработки.

📢 Для кого этот доклад?
👉 Руководители IT-компаний, CTO, Product Owners.
👉 Тимлиды и менеджеры, уставшие от бюрократии.
👉 Разработчики, которые хотят влиять на продукт, а не просто выполнять задачи.

💥 Если вы хотите выйти за рамки классических моделей и повысить эффективность команды — этот доклад для вас!

📍 Жду вас на выступлении! Будет полезно, честно и без воды. 🚀

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

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

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

В докладе мы поговорим про архитектуру и практику внедрения RAG в реальные проекты: от поиска с помощью LLM в ваших проектах до обогащения внутренней LLM или чат-бота реальными корпоративными данными.

Часто ли вы замеряете связанность и связность (или прочность) на своих проектах и системах? А на энтерпрайз-архитектуре? :)

Впервые начав измерять эти архитектурные параметры на разных архитектурных уровнях, мы приходим к тому, что связанность (coupling) и прочность (или связность, cohesion) — это про примерно одно и то же, и может возникнуть недоумение — почему тогда одно из этого — хорошо, а другое — почему-то плохо? :) Давайте разбираться.

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

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

Поделюсь ссылкой на свой Open Source-репозиторий с инструментами для измерения архитектурных метрик и покрытия архитектуры тестами (и приглашу всех стать контрибьюторами). И, надеюсь, добавлю в вашу копилку +1 принцип проектирования распределенных систем :)

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

В этом докладе я расскажу, как работает наша спецгруппа быстрого реагирования (SWAT/Tiger Team) в Авито:
* как мы находим «критические точки» — места, где технический долг и архитектурные проблемы сильнее всего замедляют развитие продукта.
* как расставляем приоритеты, чтобы не просто устранять симптомы, а добиваться долгосрочного эффекта.
* как строим Roadmap, балансируя между срочными исправлениями и стратегическими улучшениями.
* как взаимодействуем с командами, чтобы не мешать, а помогать — и не становиться «аварийной службой», которую вызывают только в крайних случаях.
* как измеряем результат, чтобы убедиться, что после нашей работы команды действительно могут двигаться быстрее.

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

* Какие инженерные практики действительно экономят деньги, а какие — просто красиво звучат?
* Как перевести инженерные решения в язык метрик, денег и эффектов?
* Что говорят об этом DORA, SRE и Software Engineering at Google?
* Покажу формулы, кейсы, реальные расчеты и антипаттерны — и помогу вам объяснить бизнесу, зачем нам, вообще, все это нужно.

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

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

Рассказ является логическим продолжением прошлого выступления SLI/SLO/SLA в микросервисном приложении.

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

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

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

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

Декомпозиция — на удивление больная тема для большинства команд, а ведь от нее зависит адекватность оценок, правильный порядок выпуска функционала, сама возможность выпуска MVP и запуска инкрементального производства. Распределение ролей, velocity, capacity, предсказуемость и прочее бинго.

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

Чего достигли наши команды благодаря «Трём карандашам»:
* сокращение ТТМ по бизнес-эпикам с 9 до 1,5 месяцев;
* точность оценки достигла требуемых 85-90% гарантии поставки;
* у команд появился ритм;
* удовлетворенность участников команд поднялась на 25% (по результатам исследования CSI);
* удовлетворенность бизнеса поднялась на 43% (по результатам исследования CSI).

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

Канвас груминга — лист бумаги, разделенный по вертикали на три области:
* чужой бэк (внешние зависимости),
* фронт или бизнес-логика;
* Наш бэк.

Три принципа груминга:
* трехзвенная архитектура;
* принцип работы пользовательского интерфейса;
* и, собственно, сами «Три карандаша».

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

Что мы с вами обсудим еще:
* почему «Три карандаша» занял свое место в разработке и стал основой для разработки на большом предприятии;
* как он решает проблемы разработчиков, согласования требований между командами, стримами, департаментами;
* как он помогает решать проблему онбординга новых разработчиков в команду;
* где в «Трёх карандашах» место старым добрым и хорошо проверенным User Story Mapping, Customer Journey Mapping, Gherkin, INVEST, story slicing.

* Техлиду на заметку — как встроить AI в каждый этап разработки.
* Расскажу, как использовать искусственный интеллект при запуске MVP.
* Как автоматизировать автотесты, код-ревью, написание документации.
* Поделюсь инструментами, которые реально работают в продакшне.
* Покажу, как встроить AI в существующий процесс разработки без ломки пайплайна.
* Разберем, что стоит автоматизировать в первую очередь.
* И какую роль должен сыграть техлид, чтобы команда приняла эти изменения.
* В конце дам чек-лист, как начать внедрение AI в разработку.

Релиз — ключевой момент в жизни любого проекта. Неважно, работаете ли вы в стартапе, крупной корпорации или над опенсорс-проектом, вопрос организации релизного процесса рано или поздно встанет перед вашей командой. Каким этот процесс должен быть? Чего все хотят? Почему одни мечтают об «автоматической магии», а другие боятся любого шага без «ручной проверки»? Что работает в больших компаниях, а что — в маленьких командах? Как себя чувствует релиз, если вы в enterprise-сегменте с тяжелыми регламентами?

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

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

Обсудим, какая роль менеджера и административный флоу для организации, согласования и утверждения релиза. Ну и, конечно же, поговорим про техническую сторону: различные Git-flow, стратегию версионирования, обязательные проверки, организацию CI/CD и выбор инструментов.

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

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

Моя цель — посеять мысль «а и правда, что ждет нас через пару лет и не придется ли все переписывать?» и желание найти ответы на эти вопросы вместе со всеми участниками процесса разработки и планирования.

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

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

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

Кажется, неделя прошла. А что именно сделано — сформулировать сложно.

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

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

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

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

Воркшоп, где вы ощутите на себе, что ничегонеделание — это трудно.

Что нужно? Ничего! Просто приходите и будем вместе учиться отдыхать от ответственности, не избегая ее.

Креативная практика на создание вашего варианта никсен-слота, практическая часть доклада «Witherwill — тренд общества усталости, или Как отдыхать от ответственности». Если вы не были на докладе, но устали от необходимости постоянно принимать решения — тоже добро пожаловать, в начале будет краткое интро о целях практики.

Тонете в задачах сотрудников вместо стратегии? Они спрашивают там, где нужны их решения?

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

Результат: чек-лист из 10 шагов. Научитесь:
* задавать открытые вопросы (без советов!);
* слушать по «эффекту резиновой уточки»;
* развивать эмоциональный интеллект;
* повышать автономность команды и сокращать переработки.

Итог: инструмент, чтобы сотрудники предлагали СВОИ решения, а вы — экономили время и энергию.

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

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

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

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

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

Вы попробуете разные способы решения конфликтов в формате командного турнира. Работая в группах по 4–5 человек, вы будете обсуждать реальные кейсы, отправлять «бойца» в диалог с тренером, разбирать итоги и зарабатывать очки. Каждый раунд — это новый инструмент: как управлять эмоциями, давать обратную связь в конфликте, уважать границы, распознавать и останавливать манипуляции.

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

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

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

Пожалуйста, обратите внимание: видеотрансляция и запись мастер-класса вестись не будут.

Работая в команде, мы непрерывно сталкиваемся с необходимостью принимать решения.

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

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

Мы разберемся:
* как создавать убедительные аргументы и как быть убедительным;
* что такое сильные аргументы, как сделать линию аргументирования ясной и структурированной;
* какие аргументы работают и убеждают собеседников, какие — нет.

Бонус — я поделюсь со всеми участниками мастер-класса основными уловками в аргументировании, о которых полезно знать, чтобы быть к ним готовым.

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

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

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

Вы попадаете в ситуации, когда надо срочно найти что сказать, чтобы защитить свою позицию, отстоять проект или идею, защитить сроки?

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

Устали от теории? Хотите учиться на чужих ошибках? Мы предлагаем лучше — научиться на своих!

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

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

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

Разбор и фидбэк: после каждого раунда — разбор и персональные рекомендации от опытных экспертов-практиков.

Тимлиды все чаще вовлекаются в наем и сталкиваются с потоком сотен резюме — и что в них видят?
* 50% кандидатов — не разработчики, но хотят «войти в айти»;
* резюме перегружены «водой» и списками технологий;
* тестовые задания не в моде – проверять навыки на входе сложно;
* время тимлида уходит на сортировку «шума» вместо собеседований.

«Как выловить настоящего разработчика среди сотен откликов: практикум для тимлидов» — это интерактивный мастер-класс с групповыми заданиями и разбором реальных кейсов массового найма.

Что будет на практике:
* групповая работа с «пакетами резюме» (в том числе шумными и противоречивыми);
* проектирование стратегии найма для позиции Python-разработчика;
* дискуссия: кого позвать, кого отсеять и почему;
* отработка сценариев с использованием ИИ-ассистентов в процессе найма;
* обсуждение рисков: как не упустить сильного кандидата.

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

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

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

На мастер-классе расскажу об основных инструментах обратной связи: boff, бутерброд и свой фреймворк.

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

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

Тема сессии: закрытая, но открытая дискуссия для тимлидов, хедов, СТО и тех, кто рулит. Как расти без выгорания, держать баланс между техом и управлением, принимать тяжелые решения, масштабировать процессы и сохранять людей. Здесь не объясняют, кто такой тимлид — здесь обсуждают, как быть им лучше.

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

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

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

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

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

* Фокус на убытках: что теряет бизнес, игнорируя IT-инвестиции?
* Язык цифр и метрик: всегда переводите техническое в конкретные бизнес-результаты (деньги, скорость, риски).
* Доказательства через пилоты: не теории, а быстрые, измеримые эксперименты.
* Инвестиции vs. Затраты: четкое разделение в бюджете и коммуникации.
* Доверие: самый недооцененный компонент успешности проектов.
* IT как актив: технологии — это рычаг для достижения бизнес-целей.

Я расскажу про разные виды оргструктур в IT — от плоской до Spotify, с какими проблемами можно столкнуться в каждой и как их можно решить, в том числе и с фреймворком Team Topologies.

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

Фреймворков для анализа продуктивности разработки много (DORA, SPACE, Kanban-метрики, ...). Но для конкретной ситуации они могут быть слишком универсальны, сложны во внедрении или не соответствовать текущим потребностям.

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

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

1. Сравним подходы управления классическим IT-продуктом и технологией автономного вождения.
2. Какие навыки необходимы для управления продуктом в автономном транспорте?
3. Продуктовые вызовы на текущем этапе развития технологии автономного вождения.

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

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

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

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

Автономные транспортные средства в мире разрабатываются разными технологическими компаниями уже более 10 лет. Однако на дорогах они — все еще редкость. С какими проблемами и вызовами в области автономного вождения сталкиваются разработчики? Какие технологии лежат в основе и как они применяются в реальной жизни? И когда уже автономный транспорт станет обыденностью?

Автономный транспорт и реальная жизнь — сделать невозможное возможным.