Доклады

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

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

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

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

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

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

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

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

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

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

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

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

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

За 8 лет работы внешним экспертом и консультантом у меня появились свои подходы и инструменты для создания, поиска и управлениями знаниями.

В докладе подробно рассмотрю, что мне позволяет эффективно проводить исследования, выполнять RnD-проекты, решать сложные задачи, работать с большим числом источников, быстро находить информацию, накапливать знания и повышать насмотренность. Расскажу про персональную базу знаний на 15к заметок и 50к связей на базе Obsidian, про кастомный поиск по 1к инженерных блогов на базе Programmable Search Engine и другие инструменты. Поделюсь проблемами и следующими шагами по построению персонального экзокортекса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как следствие, падение CSAT и других KPI. Потеря лояльности — отток старых и недополучение новых клиентов.

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

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

В своём докладе я дам ответы на важные животрепещущие вопросы:
* Что общего у манулов и мануалов?
* В чём проблема динозавров в голливудских фильмах и при чём тут глоссарий?
* Как связаны винтажные фотографии, формат JPEG и пользовательская документация?

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

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

Воркшоп "Обмен знаниями" с игрой "Раскрой тайные знаки" предоставит вам возможность погрузиться в интерактивное обучающее событие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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