Доклады

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Тема полезна руководителям команд и с точки зрения сотрудников, и с точки зрения самих себя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы поговорим о том какие типы заказчика встречаются в тяжелой промышленности и как себя вести с каждым из них.
Обсудим как объяснить ЛПР что он получит в конце, если он не понимает о чем речь или "4 способов культурно доносить ценность своей идеи без мата"
Как проверить заказчика на «потенцию» к реализации цифровых проектов – Вам сказали, что проект полностью поддерживают и готовы во всем помогать? Не верьте пока не пройдете по следующим шагам

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

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

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

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

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

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

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

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

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

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

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

В докладе подробно расскажу:

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

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

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

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

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

Хотите запустить стажировку, но готовы ли Вы к этому? Сколько стоит “бесплатный стажер”? Как научиться учить других?

Где искать стажеров? Почему публикация на карьерных сайтах это всего лишь 15% успеха, а HR начинает сёрфить университетские каналы в соц сетях.

Работаем над первым впечатлением стажера о компании и развенчиваем миф, что «Новички — это бесплатная рабочая сила».

Учим так, чтобы было интересно. Составляем программу обучения и эффективно расходуем время наставника.

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

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

Учимся у стажера. Почему важно проводить ретро для оценки эффективности программы обучения.

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

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

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

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

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

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

За 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) как стать укротителем - на кейсах отработаем схему действий при столкновении с кобрами

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

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

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

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

Одна из частых ситуаций в работе с командой — отсутствие желаемого руководителем результата, здравых ответственности и требовательности друг к другу, сопротивление (казалось бы) хорошим и нужным решениям.
Чаще всего в таких случаях начинают внедрять OKR и KPI, или чинить, ставя "амбициозные цели". Но такие изменения не приносят нужного результата: демотивируют команду, вызывают сопротивление "системе" и нередко приводят к увольнениям после бонуса.
Мы обсудим результаты исследования, проведенного на Saint TeamLeadConf 2023, и поговорим о том, что такое пороки команды, как их диагностировать в вашей команде и какие изменения в действительности стоит делать, чтобы сделать работу команды более эффективной, а не бороться с новыми сложностями.

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

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

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

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

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

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

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

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

В последнее время все больше компаний и их сотрудников предъявляют повышенный спрос на развитие горизонтальных коммуникаций и обмен опытом. Способствует этому несколько факторов, главные из которых - ставший нормой удаленный формат работы и переход к организационным моделям на основе кросс-функциональных команд.
Как часто вы сталкивались с тем, что вам не у кого спросить профессионального совета и обсудить последние новости из вашей индустрии? Вас не покидает чувство, что кто-то до вас в компании уже точно сталкивался с вашей текущей задачей, но вы не знаете, как этих людей найти? Или быть может для решения вашей задачи вы уже видели 10 разных инструментов, которые применяются в других командах, но не понимаете, какой выбрать?
В докладе мы поговорим о внутренних профессиональных сообществах как об одном из способов решения этих проблем. У нас в билайне комьюнити позволяют сотрудникам выходить за рамки рутинных задач, помогают им расти профессионально и карьерно.
На личном опыте я расскажу, как подобные сообщества строить и развивать, поделюсь практическими советами и инструментами, которые можно будет применить в своей работе.
Обсудим:
- что из себя представляют профсообщества и какие практические задачи в компании они помогают решать
- что необходимо для успешного функционирования профсообществ, какие барьеры могут быть на пути их создания и развития и как с ними справляться
- как организовать процессы накопления и обмена опытом между разными командами и специалистами внутри них
- как обучать, развивать сотрудников и выявлять самых перспективных
- как с помощью профсообществ драйвить развитие инженерной культуры в компании
- как неформальные мероприятия помогают поддерживать здоровые отношения в коллективе, повышать лояльность сотрудников и снижать текучку
Уверен, материал будет полезен руководителем, которые настраивают обмен знаний в команде или между командами; деврелам, работающим над привлекательностью HR бренда; а также активным инженерам, которые хотели бы поучаствовать в развитии культуры и процессов в своей компании.

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

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

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

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

В рамках доклада я расскажу о реальном кейсе, как мы запустили Сообщество по развитию скиллов в личной эффективности, как альтернативу долгим классическим тренингам, в которых надо принимать участие в конкретное время, проходить нудные тесты после, и, после которых, как правило, качественных изменений в личной эффективности не происходит. Сообщество - это способ сделать обучение и развитие доступным, удобным и закрепляющим знания и навыки за счет коротких практик, которые участники применяют на протяжении долгого времени, а также за счет взаимной обратной связи и поддержке.
Поговорим:
- Про структуру сообщества - центральные активности, поддерживающие рутины, роли участников и т.д.
- О мотивации участников, что побуждало ребят шарить свои знания, оставаться в сообществе, поддерживать активности и рутины
- Расскажу о достигнутых результатах
- Поделюсь выводами, которые мы сделали. Будем честными - не все сработало идеально, как ожидали) Но позитивные результаты и опыт, которым можно делиться, точно есть! Поэтому я буду говорить и о позитивных лайф-хаках, которые можно брать и делать, так и о уроках, которые мы вынесли из нашего опыта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добро пожаловать в общество любителей диких котов!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы предъявляем к своему ПО ряд требований:

* мониторинг
* надежность
* безопасность
* производительность
* масштабируемость
* стандартизация развертывания
* управление версиями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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