Самая крупная мультиформатная конференция для тимлидов и руководителей

30 ноября 2023 и 1 декабря 2023

Москва, Кампус СКОЛКОВО

Доклады

Инструментарий руководителя (5)

Как стимулировать креативное мышление в команде ИТ-специалистов

Такая хрупкая вещь, эта креативность, то она есть, то ее нет. То классные идеи, а то тухляк. Можно ли как-то этим процессом управлять? Прямо управлять - нет, но создать условия мозгу, где вероятность креативности и идей повышается, вполне возможно. К тому же у нас несколько типов креативности - 1) когда надо придумать несколько вариантов решения проблемы и 2) когда надо придумать что-то реально новое, фичу в продукте, которой ни у кого еще нет и 3) когда из вороха данных нужно найти мелкую жемчужинку ценности. За это отвечают разные части мозга и стимулируют их разными личными и командными практиками.

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

Почему KPI+деньги не работает

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

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

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

Создание гильдии лидеров изменений

Модели руководства
Управление / другое
Бизнес-процессы
Надежда Смирнова

Независимый консультант

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

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

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

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

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

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

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

Как правильно принимать неправильные решения

Дарья Рябченко

ПАО СК "Россгосстрах"

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

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

Нам не по пути: как правильно увольнять

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

ООО ГК Иннотех

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

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

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

Кругозор (3)

Меняя себя и других - понимай устройство: инженерная модель личности

Коммуникация
Soft Skills
Личное развитие

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

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

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

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

Неизбежное сопротивление без потери рассудка

Коммуникация
Управление командой
Управление проектами

Друзья, бывает, что надо что-то менять, было ли у вас такое? Жизнь так устроена, что изменения будут происходить. Некоторые изменения будут происходить с нами, некоторые с окружающим нас миром. Главная трудность этих изменений, что их не хочется делать, никто их не любит. Поэтому, я хочу донести до Вас мысль, что реальность такова - сопротивление любым изменениям - неизбежность! Это атрибут любых изменений.
Мы поговорим с Вами об источниках возникновения сопротивлений, рассмотрим методики работы с ними и рассмотрим кейс использования одного из таких методов на практике.

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

Онбординг как инструмент для руководителя

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

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

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

Обучение (2)

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

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

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

Как руководителю не тратить время на информационный мусор?

Типовые ошибки
Лайфхаки
Инструменты
Методологии
Обучение на стороне
Образование
Картирование знаний
Инфобезопасность
Алексей Морозов

НКО Научные исследования социальных инноваций

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

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

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

Кто я? (1)

Карьерные кризисы: инструкция по применению

Юлия Аравина

Независимый консультант

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

В докладе обсудим:
-Как, когда и почему сейчас люди оказываются в карьерном кризисе
-Внутренние психологические блокеры для смены деятельности
-Как помочь себе в карьерном кризисе
-На что опираться при поиске новой работы [в новой сфере]

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

Управляй собой (5)

Как научиться быстро включаться в работу? Приемы управления своим состоянием.

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

Проблема не в том, что разные люди обладают разным темпераментом или инструментами таймменеджмента. Чаще всего они просто не умеют включаться в работу, фокусироваться на задачах и выходить из рабочего режима. Это приводит и к срывам дедлайнов, и к выгоранию в перспективе. Нарушается тот самый work-life balance.

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

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

1. Как настроить рабочее пространство?
2. Как влияет одежда на работоспособность и почему дискомфорт может быть полезен?
3. Как найти свой ритуал входа в работу на примере великих писателей и актеров?

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

«Relax, take IT easy: как вернуть спокойствие в работу, даже если сейчас устал и хочешь уйти. 3 инструмента специально для технарей»

Структура презентации:
Первая часть: бизнес-предпосылки (результаты опроса вовлеченности, текучести, стратегические цели компании), создание системы обучения и развития, разработка конкретных инструментов обучения, развития, поддержки сотрудников.
Вторая часть: работа с сотрудниками на основе их запросов, реальные отзывы, описание точек старта и результата каждого сотрудника.
Третья часть: 3 конкретных инструмента, которые использовал каждый сотрудник на сессиях и между ними (на основе 84 сессий с 10 сотрудниками внутри Bercut (тимлиды, старшие аналитики, старшие тестировщики, инженеры, старший специалист в HR и 400 сессий с внешними клиентами (не только технические специалисты).

Тезисы:
- коучинг как инструмент удержания и развития ИТ сотрудников, которые находятся внизу своего человеческого опыта (чувствуют разочарование, страх, усталость);
- примеры кейсов, в которых коучинг работает в ИТ;
- инструменты, достойные распространения: 3 конкретных инструмента, которые сработали с технарями.

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

Обезвреживаем 5 установок, из-за которых ты и твои сотрудники не растут.

Поиск и развитие команды
Teamlead
Управление командой
Личное развитие
Эмоциональный интеллект

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

А дальше: снова “поиск новых”, “онбординг”. А новые-то сотрудники приходят с теми же неэффективными установками.
Более того - установки могут проявиться каждый раз при переходе специалиста на новый уровень.

Мы расскажем про 5 установок, которые тормозят профессиональный рост. И дадим инструменты, чтобы преодолеть их вредное действие. И для себя, и для своих сотрудников. Здесь и сейчас:
- инструменты, чтобы просто взять и сделать;
- приемы как “натренировать” себя действовать по-новому, не давая установке сработать;
- способы страховки рисков: установка как надоедающий инцидент на проде. Воспроизводится в самый неподходящий момент. Страхуем себя на будущее и минимизируем потери.

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

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

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

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

Осознанность 2.0 (рабочее название)

Евгений Идзиковский

Частная практика

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

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

Понимание окружающих (1)

Теряем доверие, а потом пробуем его вернуть

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

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

Взаимодействие с окружающими (5)

Диалог как IT инструмент

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

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

Прозрачность процессов как инструмент эффективного взаимодействия

Исаева Анастасия

АО Газпромбанк

1. Что такое прозрачность?
2. Как она обычно воспринимается рядовыми сотрудниками?
3. Зачем прозрачность нужна команде?
- Управление ожиданиями
- Снижение доли микроменеджмента
- Уменьшение количества “Брентов” в команде и компании
- Сбор метрик, помогающих улучшить процесс

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

ИмаДЖУНариум – представление джунов о лидах

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

ИмаДЖУНариум – представление джунов о лидах. Тема взаимодействия джунов и лидов не инновационна,
однако не перестает быть актуальной. На сегодняшний день огромное количество курсов выпускает на рынок труда
сотни новичков, которые с безумной мотивацией приступают к поиску своей первой работы,
имея лишь теоретическое представление о том, как устроен мир айти: процессы, команды и, конечно же,
взаимодействие с лидами.
В своем докладе я поделюсь результатами опроса трудоустроенных в 2023 году выпускников it-курсов о том, какие ожидания могут быть у нового неопытного сотрудника и как они порой разбиваются о скалы суровой реальности, а также отвечу на вопросы:
1. Откуда берутся эти самые ожидания?
2. Какие эмоции испытывает новый сотрудник при неудачном опыте взаимодействия с лидером команды?
3. На какие категории новички условно делят тимлидов?
4. Насколько важно оказалось чувствовать себя комфортно в новом коллективе?
5. Как общение с лидом влияет на продуктивность и мотивацию?

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

Сложный начальник: как быть?

Teamlead
Коммуникация
Мотивация сотрудников
Личное развитие
Команда
Evgeniy Morozov

Align Technology

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

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

Мне не нравится мой тимлид, что делать?

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

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

Команда, а не группа (3)

Становление команды: путь к самоорганизации. Миф или необходимость?

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

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

До встречи!

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

Успешное масштабирование и разделение команд

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

СберЗдоровье

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

Расскажу:

1) Когда есть необходимость делиться
2) Как безболезненно поделить команды так, чтобы всем участникам было комфортно и каждая команда была независимой единицей
3) Поделить между собой функционал, даже если код находится в монолите
4) Разделить бизнес-задачи и бизнес-лидов на два разных направления
5) Обрасти новыми командными ритуалами и артефактами
6) Нанять необходимых людей в новые команды, если это необходимо

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

Как я вырастила кадровый резерв команды

Большие проекты/команды
Модели руководства
Поиск и развитие команды
Типовые ошибки
Менторинг
Культура КМ
Внутреннее обучение
Команда
Подбор команды

Стал руководителем - начинай готовить кадровый резерв, а я расскажу, как это сделать.

Почему я?

3 года я была в роли тимлида тимлидов, ИТ-лидера стрима, трайба … можно называть это по разному. Начинала с команды в 40 человек и вырастила ее до 150+ в пике.
Прошла длинный путь, стараясь построить коммуникации и процессы так, чтобы не было узких звеньев и с уходом любого человека (в том числе меня), процесс не буксовал.

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

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

Я - руководитель и лидер (5)

Как начать руководить незнакомыми тебе людьми

Марина Перескокова

Яндекс.Беспилотные технологии

В марте 2023 года я, имея опыт руководства фронтенд-разработчиками, стала руководить службой разработки, где люди занимаются фронтендом, 3д графикой на WebGL, бекенд разработкой на Python и C++, пишут код для беспилотных такси и роботов-доставщиков, а также занимаются тестированием.

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

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

Как стать эффективным менеджером

Управление командой
Soft Skills
Личное развитие
Типовые ошибки
Лайфхаки
Гончарова Марина

Билайн (ООО ВК-ИТ)

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

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

Практический алгоритм действий для начинающих тимлидов

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

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

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

«(Путь) Из разработчика в СЕО».

«(Путь) Из разработчика в СЕО».
Спикер: Сергей Мельник, CEO Алисы и умных устройств Яндекса

За последние 15 лет Сергей вырос из разработчика в СЕО Алисы и умных устройств Яндекса с командой в 1500 человек в управлении. За это время он побывал в разных ролях: инженера, тимлида, техлида, руководителя продукта и СЕО.

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

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

Делегирование задач и сфер ответственности: простая и работающая методика

* Когда уже пора делегировать, а когда делегирования можно избежать
* Что можно, а что нельзя делегировать
* Делегирование задач VS делегирование сфер ответственности
* Делегирование, доверие другим и «снятие себя с пьедестала»
* Простой алгоритм делегирования задач: как снять с себя рутину
* Важность и способы промежуточного контроля
* Баланс между макро- и микроменеджментом
* Алгоритм делегирования ответственности: как перестать думать о проблемах и не потерять контроль
* Увольнение сотрудников. Когда пора, а когда нельзя

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

Менторство и развитие (3)

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

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

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

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

Как и зачем тимлиду расти выше по карьере

Сергей Яныкин

СберМаркет

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

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

Развлечения тимлида в бигтехе

Teamlead
Управление разработкой
Личное развитие

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

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

Трансформационные изменения в командах (8)

Союз меча и орала. Как внутренней разработке работать с заказчиками разной зрелости и культуры

Андрей Жуков

С7 ТехЛаб

Читая умные книжки и слушая умных людей, часто думаешь: да что же такое, почему только только у меня не выходит сквозной процесс! Не только у тебя. В большой компании зачастую разные подразделения, для которых ведется разработка, разительно отличаются и по культуре, и по зрелости, и в итоге в команде вынуждены появляться такие роли, о которых никто тебе никогда не рассказывал.
В докладе попробуем разобраться с типами заказчиков и топологией команд под этих заказчиков. А также разберемся, когда не стоит тащить все сразу в инхаус.
Система и топология команд будет рассмотрена на примере подразделения по обработке и анализу данных (data engineering, data science, ml, ai)

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

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

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

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

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

1. Обзор реальных кейсов по поддержке психологического состояния сотрудников в марте 2020 и в марте 2022 на примере 3х ИТ компаний
2. Инструменты диагностики состояния сотрудников по шкалам: физическое состояние, эмоциональное возбуждение, активация, спокойствие, тонус
3. Инструменты по улучшению состояния сотрудников по каждой шкале

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

Как конкурировать с тем, у кого ресурсов сильно больше?

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

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

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

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

Стандарты кодирования
Совместная работа, система контроля версий, организация веток
Методологии и процессы разработки ПО; Сроки и приоритеты
Большие проекты/команды
Поиск и развитие команды
Продуктовая разработка
Управление командой
Управление разработкой
Бизнес-процессы
Трансформационные изменения

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

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

Почему конфликты нужно любить, а не бояться

Модели руководства
Корпоративная культура и мотивация
Поиск и развитие команды
Типовые ошибки
Лайфхаки
Команда
Подбор команды

Спикер: Елена Бубнова, руководитель Поиска, Яндекс

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

— Как относиться к конфликтам в команде?

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

— Типологизация “офисных” конфликтов: из-за личных отношений, нехватки ресурсов, непонимания или ложного ощущения достигнутой договоренности, из-за “территориальный интересов [Здесь покажем на 1 слайде + может дать рекомендации, где про это почитать]

— Способы “вскрытия” конфликтов на примере кейсов: визуализация договоренностей, донесение истинных мотивов, подключение медиатора (взгляд со стороны, озвучивание несогласий), прямое столкновение

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

— Польза от конфликтов: рост тимлида, рост команды, экономия ресурсов бизнеса

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

Новый дивный мир: Как изменилась мотивации и система ценностей разработчиков и что делать дальше?

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

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

А у нас свой agile-велосипед: почему мы не используем популярные фреймворки

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

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

Мастер-классы (7)

6 кейсов 1:1 – встреч, как проводить и что нельзя делать, чтобы проводить их эффективно

Вирна Штерн

Aletheia Digital

Сегодня можно наблюдать, что 1:1 -встречи превратились в обязаловку, когда обсуждается все и сразу, утратив смысл и превратившихся в еще одну рутинну.
Чем НЕ является такие 1:1-встречи (хотя именно так их иногда проводят):
— это не обратная связь – для этого есть другой формат и другие правила;
— не обсуждение текущих дел – для этого есть много других встреч в работе;
— не социальный треп для создания доверия – оставьте это политикам)).

Мы разберем 6 кейсов с различными целями и различными правилами проведения 1:1-встречи, которые нельзя смешивать! Посмотрим на личный опыт участников мастер-класса и фреймворки, рекомендованные опытными командами.

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

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

Кто я как лидер? Куда я могу дальше расти? Какие мои успешные стратегии лидерства? Что нового я могу взять себе?
Выйдя с Мастер класса, участник может взять для себя следующие вещи:
1) куда я дальше могу расти? (исключая контекст развития разных навыков как технических, так и софт)
2) попробовать новые стратегии лидерства
3) увидеть и расширить свой кругозор в лидерстве
А осмысление этого со временем может порадить инсайты и решения:
1) почему я выгораю
2) есть другой путь и он не только вверх по карьерной лестнице, выжигая себя
3) возможно и не стоит менять одну компанию за другой
4) мой собственный смысл лидерства и как я могу влиять и быть лидером в рамках компании

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

Влияние без полномочий

Natalya Peshkova

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

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

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

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

Это непросто, но вполне осуществимо!

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

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

Jobs to be done для тимлидов продуктовых команд

Продуктовая разработка
Управление / другое
Коммуникация
Управление командой
Расширение кругозора

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

Мастерская будет полезна для:
новых тимлидов\команд:
- Погружение в продукт
- Помощь в фокусировке команды и передачи ключевого контекста работы
Для опытных тимлидов\команд:
- Помощь в фокусировке команды и передачи ключевого контекста работы

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

Воркшоп по аналитическому чтению

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

Читать следует меньше, а думать больше

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

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

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

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

5 способов организация командной работы

Вирна Штерн

Aletheia Digital

Мы по-прежнему считаем, что быть экспертом и знать ответы на все вопросы — это круто! Стивен Деннинг (автор «Эпохи Аджайл») говорит о глобальной смене роли менеджера – теперь он должен способствовать самоорганизации команд, а не контролировать и давать советы!
Однако организовывать групповую коммуникацию, слушать других, принимать чужую точку зрения – это не простая работа, требующая от руководителя специальных умений - не только навыка «накидывать»)

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

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

Развитие управленческой зрелости у молодых тимлидов

Что покажем на воркшопе:
- Поисследуем реальность инструмент "проблемная сетка" - найдем точку, откуда берут начала проблемы, с которыми сталкивается молодой управленец (основано на книге "Азбука системного мышления");
- Соберем набор компетенций, которые должны быть у эффективного руководителя
- Соберем набор поведенческих индикаторов (действий), по которым можно понять проявляется ли требуемая компетенция или не проявляется;
- Соберем ИПР по soft skiils для участников воркшопа для одной soft компетенции

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


Продолжительность 1,5 часа

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

TechLeadConf: Путь техлида (7)

Как защитить бизнес при внедрении LLM

Поиск и развитие команды
Будущее рынка разработки ПО
Трансформационные изменения

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

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

Метрики успеха: Как эффективно управлять техническими командами с помощью данных

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

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

Разрешать или запрещать? Процессы и правила написания кода: гибкость vs регламенты. Есть ли между ними взаимосвязь, и где рецепт идеального сочетания.

Когда компания растет, встает вопрос о том, как адаптировать процессы управления и разработки ПО к появлению большого количества команд и продуктов, а также требованиям к надежности и безопасности. Нужна ли для крупной компании жесткая административная модель управления, или можно делегировать принятие основных решений на уровень отдельных команд? И если да, то каких именно решений? Как избыточной стандартизацией и регламентами не помешать росту продуктивности, но при этом излишней гибкостью не навредить стабильности продукта и предсказуемости кода. Об этом поговорим на круглом столе с представителями-управленцами из индустрий e-commerce, EdTech, FinTech, FoodTech, GovTech.
Участники (6-8 человек): тимлиды, руководители по agile-трансформации, цифровизации, руководители практики Project Management.

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

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

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

Олег Федоткин

СберМаркет

Технический лидер — человек, который ведет проекты, вводит регламенты и стандарты на уровне всей компании и двигает вперед уровень технологической культуры. Но как все это делать, не имея ни капли административных полномочий?

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

Зачем разработчикам продуктовое мышление?

На кейсах из Mindbox расскажем к чему приводит когда разработчик не вовлечен в проработку идеи на ранних этапах (discovery). Например, как мы потратили полгода и сделали фичу, которой пользуется 1 клиент. И наоборот: как правильные вопросы на старте и упертость разработчика позволили найти простое решение в продукте и сэкономить 2-3 месяца разработки, кучу тойла и негатива.
Основная мысль: разработчику полезно подключаться к продуктовой разработке.
Формат: сторителлинг, истории из жизни разработчиков

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

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

Непрерывное развертывание и деплой
Автоматизация разработки и тестирования
Методологии и процессы разработки ПО; Сроки и приоритеты
Управление разработкой
Управление изменениями
Время разработки и поставки задач
Автоматизация разработки, доставки, эксплуатации
Метрики

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

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

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

Фёдор Борщёв

Федя и Самат

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

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

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

Не делай то, чего можно не делать

Богдан Гаркушин

ВКонтакте, VK

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

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

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

Назад в будущее. Как мы выстраиваем процесс управления архитектурой ИС

Павел Мутовин

Иркутская нефтяная компания

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

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

Раз архитектура — «as Code», почему бы её не покрыть тестами?!

Раз уж микросервисная архитектура теперь "as code" (расскажу как это сделать, например, с помощью plantuml), то её можно на неё можно и нужно писать тесты! :)
Рассмотрим разные видов тестов — на соответствие паттернам и принципам проектирования, тесты на актуальность архитектуры, тесты на соответствие архитектуре новых изменений во взаимосвязях сервисов.

Заставим архитекторов снова писать код 😅

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

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

Отказоустойчивость
Стандарты кодирования
Безопасность программного кода, SQL и прочие инъекции
Архитектуры / другое

Безопасность во многих компаниях стоит особняком. Вместо того, чтобы беспокоиться о качестве вашего продукта, "безопасники" твердят о ГОСТ-ах и ISO, о разных сертификациях и авторизационных протоколах - вещах важных, но вне фокуса основного архитектора. При этом их деятельность "подрывает" производительность, debugability, да вообще все. Однако, есть способы сделать безопасность своим союзником на пути к качеству.

В этом докладе мы обсудим, как практики безопасности пересекаются с практиками повышения качества кодовой базы. Поговорим о secure by design и функциональной безопасности. Чем Google best practices пересекаются с регуляторными нормами ФСТЭКа. Порешаем классические архитектурные trade-off-ы и при чем здесь incident response time, одна из важнейших характеристик мира секурити.

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

Риски. Они везде...и даже в твоей архитектуре

Архитектуры / другое
Теория
Дмитрий Бардин

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

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

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

Архитектура от словаря: определения как базис проектирования

DDD — это стильно, модно, уже не очень «молодежно», но до сих пор нечасто применимо! Словарь — это понятно, неинтересно, «покрыто пылью», но привычно и является стандартом на начальных этапах проектирования.
Я хочу предложить вам найти связь между словарем и DDD. На примерах понять, как словарь может стать отправной точкой DDD и как, описывая бизнес-контекст, оказывать влияние на архитектуру и выстраивать разумную коллаборацию, основанную на симбиотических связях между бизнесом и разработкой.
Что по итогу:
1) Основы DDD – общая теория. Язык и словарь – как основа DDD и выстраивания разумной коллаборации между бизнесом и разработкой
2) Поделюсь методикой эволюционного, а не революционного внедрения DDD, вместе с новыми проектами в компании (методика апробирована и дает хорошие результаты)
3) Разберем правила формулирования определений, и поймем, как через определения строить архитектуру
4) Тренировочная часть формулирования определений и их влияния на архитектуру.
5) Помогу найти свой стиль «словоплетства» и дам обратную связь.
6) Разберем процесс внедрения такого подхода в компании, работу с возражениями

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

Рефакторинг без ущерба для бизнеса, как его продать и не умереть в процессе

Во время взрывного роста Учи.ру под капотом платформы сервис стал неповоротливым и нашим фронтам пришлось работать в трагичных условиях. В Учи.ру был легаси-монолит ruby on rails + slim. Через несколько лет барахтанья в этом деле, стали очевидные несколько основных проблем: фронтам было больно работать с данной системой почти физически, масштабируемость была не комильфо, простор для повышения эффективности разработки не наблюдался. Еще немного перчинки добавляла процессная история, когда таски водопадом падали с продактов на лицо фронту(1, реже 2 человека) и беку(1, реже 2 человека).

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

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

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

Как интегрировать legacy сервисы в мобильное приложение дешево и быстро. Кейс Альфа-Банка

Фронтенд / другое
API
Архитектурные паттерны
Рефакторинг
Критерии выбора технологий для проекта
Продуктовая разработка
Проектирование информационных систем
Мобильные решения для enterprise
Legacy системы, жизненный цикл продуктов
Интеграция web и enterprise-решений
Распространение приложений, магазины приложений
Архитектура мобильного приложения
Поддержка и развитие legacy систем
Микросервисы
Безопасность
Инструменты
Команда
Артём Зяблицев

Альфа-Банк

Расскажу, как мы строили архитектуру мобильного приложения для сотрудников Alfa People. Особенность заключалась в том, что нужно было объединить под капотом десятки корпоративных систем без огромного штата разработчиков. В итоге мы выбрали микросервисную группировку архитектуры: Frontend на ReactJS, Middle-часть – Node.js (NestJS). А сервисы внутри приложения разрабатываем с адаптивным вебом: делаем один раз - работает в веб и мобилке. Плюс новая архитектура позволила доставлять новые сервисы до клиента без обновления приложения. Расскажу про наш подход и какие проблемы у нас возникли в процессе разработки, чтобы вы могли избежать их, если будете внедрять похожее решение.

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

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

Строим систему управления доступом по ГОСТу: Envoy, OPA, Keycloak

Системы прав доступа
Защита информации
Бэкенд / другое
Распределенные системы

При работе над информационными систем наша компания часто сталкивается с тем, что функции идентификации, аутентификации и авторизации в лучшем случае смешиваются в единый модуль, а в худшем, сильно связаны (coupling) с бизнес-логикой приложения. Из-за такого подхода разработчики перестают понимать где же в их приложении лежат столь важные функции безопасности, связанные с управлением доступом. Чревато это как уязвимостями *(OWASP TOP 10: A07:2021-Identification and Authentication Failures, A01:2021-Broken Access Control)*, так и сложностью аттестации на соответствие требованиям по защите информации.

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

Важно понимать, что показанные инструменты являются лишь примером. Важна сама идея, подход, описанный в ГОСТ Р 59383 и ISO/IEC 29146, а они не ограничивают вас в используемых техгологиях.

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

TechLeadConf: Импортозамещение (1)

Доклад "Деликатный переезд с SF на BPM"

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

Яндекс Такси

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

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

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

Техлид на большом проекте в Авто.ру

Александр Коныгин

Яндекс Вертикали

- Как устроена разработка в Авто.ру. Спойлер: Да! У нас нет бизнес и системных-аналитиков
- Что такое большие проекты и какие проблемы там возникают
- Добавляем новую роль - техлид. Что делает и что не делает. Границы ответственности с проджект-менеджером
- Стадии проекта. Что делает техлид на каждой. Немного рекомендации как это можно делать. Например:
* быстро погружаемся в доменную область и описываем "как сейчас"
* план запуска. Зачем нужен и на что обратить внимание
- Где взять техлида
- Что получилось:
* это действительно помогает
* применять надо с осторожностью

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

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

QA как сервис для централизованного управления качеством продукта в условиях Agile

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

Росбанк

Когда в 2019 году Банк вступил на тропу ИТ-трансформации и началось масштабное появление Agile-команд, развивающих свою часть продукта самостоятельно, единое «Управление качества» в Росбанке было полностью расформировано. Специалисты переданы в команды, процессы и обязанности – тоже.
Но как обеспечить функционирование Банка всё же с учётом что это единый ИТ-организм и падение одной системы – влечёт проблемы в другой? Или как закрыть «ресурсный голод» - когда какая-то команда может позволить себе выделить бюджет на выделенного инженера по нагрузке, а какая-то – не может нанять даже «ручника»? И как в таких условиях управлять качеством?
Одним из ответов стал подход «Тестирование как сервис», распространяемый подразделением, находящимся в Core IT. И в данном докладе коснёмся следующих тем:
·       Вендор внутри? Или почему было просто не нанять 100500 внешних сотрудников
·       Как эволюционировали, какие идеи сработали, какие докрутили, исходя из открывшихся нюансов
·       Как это выглядит внутри и как работает в части 4 основных сервисов – методология тестирования, автоматизация тестирования, нагрузочное тестирование, инструменты тестирования
·       В чём плюсы для сотрудников такого подразделение и где легко сгореть
·       Какие результаты, куда движемся и какие проблемы ещё только предстоит решить

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

Как RnD (Research and Development) появляется в крупных ИТ-компаниях

В своем докладе отвечу на вопросы:
— Зачем крупным ИТ-компаниям заниматься RnD?
— В какой момент RnD может появляться и как может выглядеть?
— Какие задачи могут стоять перед RnD-направлением?
— Как может происходить внедрение инноваций и как сделать этот процесс эффективным?
Для доклада буду использовать примеры из мировых BigTech-компаний и, конечно, из своей работы в Тинькофф.

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

Практика внедрения Chaos Engineering в Росбанке и МТС

Надёжность продакшена
Проверка гипотез на проде: технологии и команды
Логи, метрики, ошибки
DevOps / SRE

Тезисы и план выступления описан тут: https://docs.google.com/document/d/1tPNq64RrSUmIUSfqTBqFzAYhDKnXkolODj-KS5YShZ4/edit?usp=sharing

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

Чистая архитектура в монолите: плюсы и минусы

Python
Архитектуры / другое
Legacy системы, жизненный цикл продуктов
Web-scale IT / другое

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

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

TechLeadConf: Искусственный интеллект в разработке (1)

Как мы ВКонтакте ускоряем t2m c помощью ML

Функциональное тестирование

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

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

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

Системный подход к адаптации тимлидов

Ольга Елисеева

Инфосистемы Джет

За прошлый год мы выросли в 1,5 раза и на ходу меняли организационную структуру, формируя новые группы. Перед нами встал логичный вопрос "Кто возглавит? Есть ли люди внутри или нужно идти искать на рынке?" В итоге мы выбрали в пользу внутренних кандидатов и почти одновременно вывели 8 молодых руководителей
Много докладов посвящено ондбордингу новых сотрудников, но мало, кто говорит о том, как происходит адаптация тимлидов
А ведь адаптация молодых руководителей в компании - это важный этап в развитии карьеры и обеспечении успеха как самого руководителя, так и компании в целом
В своем докладе расскажу о том:
1. С какими проблемами, как правило, сталкиваются руководители на старте и как их решать
2. Как мы выстроили процесс адаптации, какие инструменты используем для погружения в новую роль
Доклад будет полезен, как руководителям, кто расширяет свою команду и берет экспертов на роль руководителя. Так и тем экспертам, кто планирует вступить на этот путь.

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

Радикальные практики шаринга знаний

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

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

А что, если автоматизировать онбординг в Jira?

Метрики
Онбординг
Инструменты
Лилия Пелепелина

СберМаркет

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

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

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

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

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

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

Корпоративная культура и мотивация
Networking, знакомство
HR
Коммуникация
Мотивация сотрудников
Лайфхаки
Онбординг
HR
Инструменты
Внутренние митапы
Команда

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

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

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

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

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

На нашем прошлом докладе [https://knowledgeconf.ru/2020/abstracts/6770] мы говорили о том, как управлять знаниями по безопасности, кому и для чего это может быть важно.

За последние три года мы видели, как несколько крупных команд проходили этот путь. На докладе поговорим про главные сложности и ответим на вопросы, которые помогут их решить:

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

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

Обучение проектированию: аналитики и разработчики - есть контакт

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

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

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

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

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

База знаний - зеркало организационных процессов

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

На примере LamodaTech рассмотрим, как может меняться база знаний и формат передачи знаний в такой эволюции:

1. Стартап, где разработчики работают рядом друг с другом и разрабатывают одновременно несколько систем, которые автоматизируют ключевые бизнес-процессы компании.
2. Системно-ориентированные команды, когда системы уже настолько сложные, что для каждой требуется своя команда. Команды могут работать изолированно, но периодически приходится делать кросс-системные (кроссфункциональные) проекты.
3. Виртуальные проектные команды (vTeam), когда компании требуется разрабатывать в основном кроссфункциональные проекты и изолированно работать невозможно.
4. Продуктовые команды, когда можно выделять изолированные команды с меньшим количеством пересечений внутри изменений сервисов и бизнес-процессов.

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

На эти вопросы я попробую ответить в рамках своего доклада и буду рада обсудить со слушателями их опыт.

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

Умный помощник в действии: Как снять нагрузку с эксперта с помощью АI

Лайфхаки
Базы знаний / wiki
Документация
Инструменты

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

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

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

Риски и правила что можно поручить умному помощнику и не боятся раскрыть корпоративную тайну

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

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

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

DevRel
Профессиональное развитие инженера
Лайфхаки
Методологии
Культура КМ
Привитие культуры КМ
Внутренние митапы
Внутреннее обучение
Алексей Долгушев

Деврел-бюро

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

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

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

Почему так?

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

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

На всякий случай лишний раз сверимся, а зачем лично нам вся эта история про втягивание экспертов в распространение знаний.

Сверимся по матчасти, поразбираем кейсы, попрактикуемся.

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

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

Отвечаем осмысленно

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

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

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

KnowledgeConf: Единая точка правды (4)

База знаний - конструктор или как угодить всем

Типовые ошибки
Лайфхаки
Базы знаний / wiki
Документация
Фиксация знаний
Онбординг
Методологии

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

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

В продолжение культовой книги Clean Code: Сlean Language для синхронизации команды перед проектом

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


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

Корпоративный поиск на коленке, знания и обмен ими

Knowledge Ops
Инструменты
Игорь Цупко

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

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

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

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

Продуктовая разработка
Документация
Обзор
Инструменты
Методологии

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

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

Мы обсудим:
- Что такое продуктовые тексты и где они встречаются?
- Что такое знания о продукте и как они связаны с продуктовыми текстами?
- Как работа с текстами помогает продуктовой команде и команде разработки сохранять и передавать знания о продукте?
- Как организовать работу с текстами и знаниями о продукте?
- Как эффективная работа с текстами и знаниями помогает продуктам развиваться и расти?

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

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

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

Как мы внедряли взаимовыгодную систему внутренних обучений

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

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

Пять значений фразы «нам нужно всё задокументировать»

Последние пять лет мы (documentat.io) занимаемся заказной разработкой документации для российских IT-компаний.

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

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

В нашей практике такого рода просьбы сводятся к пяти направлениям работы:

- Описание требований к уже существующей системе (реверс-инжениринг требований).
- Создание пользовательской документации.
- Создание архитектурной документации, адресованной исключительно разработчикам.
- Создание API-документации (причем обычно речь идет о вводных и обучающих статьях (howtos/tutorials), а не к непосредственному написанию аннотаций к методам или правке Сваггера).
- Комментарии в коде (в стиле Javadoc или в свободном формате).

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

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

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

Онбординг в большой команде: процессы, продукт, архитектурный ландшафт

Онбординг
Менторинг
Привитие культуры КМ
Внутреннее обучение
Злата Занина

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

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

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

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

Мы не будем делать базу знаний и как антропология помогла нам это понять

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

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

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

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

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

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

ООО "АйТи Капитал"

Развитие культуры обмена опытом может привести не только к положительным результатам в области производительности, развития навыков и создания единого место правды у команды, но еще и иметь некоторые позитивные побочные эффекты. Однажды мы в команде решили разрушить внутренние границы обмена опытом и стали транслировать наши внутренние митапы во вне компании, так чтобы любой мог посмотреть как мы обмениваемся опытом внутри команды. Здесь мы и словили приятные побочные эффекты. Так родился "Техкружок", один из самых популярных технологических сообществ в отрасли; так мы вовлекли в процесс обмена знаниями огромное количество людей (из вне), так мы сформировали свой технологический бренд, так мы повысили привлекательность себя как работодателя, так мы повысили мотивацию наших сотрудников участвовать в процедуре развития культуры менеджмента знаний. На сегодняшний день в нашей практике уже несколько различных стримов (видов собраний): техкружок, конскружок, обмен знаниями, кругозор, и почти каждый из них мы транслируем на внешние ресурсы. В своем докладе я расскажу, почему мы продолжаем развивать культуру обмена опытом подобным путем, как это связано с DevRel и какие еще преимущества мы от этого получаем.

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

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

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

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

“Как из панды сделать воина дракона” - или как мы оптимизировали передачу продуктовых знаний

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

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

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

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

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

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

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

KnowledgeConf: Создание и поддержание баз знаний Мастер-классы (2)

Строим свою Вселенную знаний с помощью AI (Мастер-Класс по созданию WIKI)

Базы знаний / wiki
Документация
Фиксация знаний
Онбординг
Инструменты

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

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

Результаты исследования российских ИТ-решений по управлению знаниями KMS tools

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

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