Единственная профессиональная конференция только для тимлидов

Доклады

База (8)

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

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

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

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

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

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

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

ГК Иннотех

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

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

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

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

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

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

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

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

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

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

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

Teamlead
Коммуникация
Soft Skills
Артем Селезнев

СберМобайл

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На гребне игры: польза игры в обучении взрослых и повышении узнаваемости бренда

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

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

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

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

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

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

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

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

Кругозор (3)

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

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

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

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


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

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

• у тимлидов/руководителей, где бы они ни работали, зачастую стек задач плюс-минус довольно стандартный, но на любом месте всегда есть специфика предметной области, в которую необходимо погружаться
• ведь согласитесь, есть разница как работать внутри проектов DWH, телекома, атомной отрасли или e-com?
• и вот ты в новой «предметке»: с чего начать? как не утонуть в море информации? на чем фокусироваться? как не падать духом, если ничего не понимаешь и не можешь сразу говорить с командой на одном языке и прочее, прочее, прочее
• разберем эти и другие вопросы и составим чеклист, чтобы без стресса вливаться в любые предметные области

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

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

Анна Бабич

Психолог, ACT терапевт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратная связь 80 lvl — как дать негативный фидбек, если человек плачет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Газпромбанк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как провести процессное изменение на 8000 человек

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aletheia Digital

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

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

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

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

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

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

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

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

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

Aletheia Digital

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резерв (3)

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

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

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

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

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

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

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

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

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

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

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

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

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

KnowledgeConf: Онбординг (2)

Жизнь после онбординга: как "включать" сотрудников в компании в периоды изменений без потерь

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

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

Безменторье: как мы создали систему менторства в быстро растущем отделе

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

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

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

KnowledgeConf: Коммуникация и связи между отделами (2)

Как создавать и развивать внутренние профессиональные сообщества

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

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

Оффбординг: как прощаться с сотрудником как амбассадором компании

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

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

KnowledgeConf: Извлечение и упаковка знаний экспертов (3)

Как стать 10x экспертом

Аудит
Лайфхаки
Базы знаний / wiki
Фиксация знаний
Инструменты
Методологии

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

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

Интуитивно понятно? Как извлекать знания, если они находятся в зоне неосознанной компетентности

Личное развитие
Лайфхаки
Фиксация знаний
Инструменты
Внутреннее обучение

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

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

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

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

Поиск и развитие команды
HR
Коммуникация
Мотивация сотрудников
Личное развитие

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

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

KnowledgeConf: Единая точка доступа к знаниям (2)

Выбираем оптимальную архитектуру базы знаний

Типовые ошибки
Лайфхаки
Базы знаний / wiki
СУЗ / системы управления знаниями
Инструменты
Методологии
Картирование знаний
Николай Сенин

Независимый исследователь

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

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

Прозрачная структура проектов в компании от стратегии до исполнителя

Ольга Муттер

СберМаркет

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

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

KnowledgeConf: Передача знаний в командах (2)

Строим свою систему грейдов с нуля

Фиксация знаний
Онбординг
HR
Менторинг
Внутреннее обучение
Картирование знаний

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

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

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

Как мы строили внутреннее IT-обучение так, что бы пострадало как можно меньше разработчиков

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

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

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

KnowledgeConf: Создание баз знаний (3)

Проектирование или реинжиниринг базы знаний: с чего начать и можно ли сформулировать универсальные требования?

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

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

Практические грабли при внедрении управления знаниями в техподдержке

Обслуживание клиентов, техническая поддержка, обратная связь
Типовые ошибки
Лайфхаки
Базы знаний / wiki
СУЗ / системы управления знаниями
KCS / knowledge-centered service
Фиксация знаний
Онбординг
Методологии
Support

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

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

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

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

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

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

Общество любителей диких котов: пользовательская документация как часть внутренней базы знаний

ТЗ/Help/Мануал - форматы и применение
Управление разработкой
Управление проектами
Базы знаний / wiki
Документация
Фиксация знаний
Инструменты

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

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

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

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

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

KnowledgeConf: Резерв (2)

Как "Матрицы компетенций" стали "Матрицами вдохновения": История развития и обмена знаниями в организации.

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

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

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

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

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

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

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

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

Федор Васильев

ООО "Почтатех"

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

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

KnowledgeConf: Мастер-классы (1)

Обмен знаниями игра: «Раскрой тайные знаки»

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

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

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

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

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

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

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

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

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

Яндекс Такси

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

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

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

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

Роман Хаимов

Рексофт

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

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

Методология принятия инженерных решений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как на основе опенсорса построить систему инженерного аудита для 70+ команд

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

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

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

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

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

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

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

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

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

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

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

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

Росбанк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Prompt Engineering - новый обязательный навык для руководителей. Выжимаем из ChatGPT максимум.

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

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

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

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

TechLeadConf: Резерв (2)

Как не превратить систему из 100+ микросервисов в зоопарк технологий и решений

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

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

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

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

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

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

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

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