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

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

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

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

Страшно ли жить с продуктом, который базируется на open source

Считаете, что на базе опенсорса невозможно построить энтерпрайз-проект? Это доклад для вас

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

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

Мы будем опираться на опыт использования опенсорс-решений в системе хранения данных TATLIN.OBJECT и поделимся практическим опытом решения этих проблем в реальном продукте.

Программный комитет ещё не принял решения по этому докладу

Куда развиваться техлидам

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

Программный комитет ещё не принял решения по этому докладу

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

Алёна Буторина

ООО "ОМК-ИТ"

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

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

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

Хрестоматия по работе над процессам для CTO, техлидов и тимлидов

Продуктовая разработка
Управление командой
Метрики

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

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

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

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

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

Покажу какими процессами стоит заниматься CTO, техлиду и тимлиду, а куда лезть не стоит.

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

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

Программный комитет ещё не принял решения по этому докладу

С метриками сквозь тернии к звёздам

Никита Елагин

СберМаркет

Ты хочешь достичь максимума эффективности и автономности команды, но где он?

Ты делаешь результат, но бизнес его не признаёт?

Команда сгорает, но мир не меняется?

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

СберМаркет

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

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

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

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

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

Автоматизация без бед. Когда "да", а когда "нет"?

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

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

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

Догфудинг как способ сделать свой сервис качественнее

Юзабилити, дизайн интерфейсов
Управление разработкой

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

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу

Техночетверг, или Как отделить техдолг от продуктовых задач

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

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

Программный комитет ещё не принял решения по этому докладу

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

Фёдор Борщёв

Федя и Самат

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

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

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

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

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

ВКонтакте, VK

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

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

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

Будущее управления состоянием

Redux, REST, GQL, unidirectional dataflow, immutability - всё это ведёт нас в бездну к лагающим, глючным приложениям, прибитым гвоздями к серверу. А будущее-то за децентрализованными системами с настолько оптимистичными интерфейсами, что они работают даже в оффлайне, а потом синхронизируются хоть в реальном времени, хоть переносом на флешке.

Программный комитет ещё не принял решения по этому докладу

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

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

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

В больших производственных компаниях, основной вид деятельности которых никак не связан с разработкой и внедрением ПО, из-за большого количества ИТ-систем и сервисов возникает необходимость централизованного управления ИТ-архитектурой для целей построения единой ИТ-экосистемы компании. В таких компаниях появляется отдельная роль ИТ-архитектора, процессы и инструментарии по управлению ИТ-архитектурой.
При разработке и внедрении информационной системы архитектору необходимо задумываться не только как спроектировать систему, чтобы она смогла заработать, но и как спроектировать систему, чтобы она могла функционировать и через 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: Безопасность (3)

XXE-атаки: скрытые угрозы обработки XML

Java
Безопасность программного кода, SQL и прочие инъекции
Application security
.NET
Атаки
Безопасность

Работа с XML-файлами (и основанными на XML форматами) может нести неожиданные угрозы безопасности. SSRF? Пожалуйста. Утечка данных? Как скажете. Но в чём суть уязвимости и как защитить свои приложения от подобных проблем? Об этом и пойдёт речь.

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

Программный комитет ещё не принял решения по этому докладу

Б - Безопасность

Каждое уважающее себя приложение должно быть безопасным, как и процессы вокруг создания. В докладе рассмотрим различные векторы атак, как выявить узкие места, что обязательно надо проверять и как не запутаться во всех этих CSRF, XSS, SAST, DDoS и других названиях. Успеем посмотреть на безопасность со стороны frontend, backend и инфраструктуры

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

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

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

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

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

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

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

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

Бесшовный переход на отечественное ПО: как быстро и эффективно это сделать

1. Роль аналитики в процессе перехода на отечественное ПО: не «как было», а «как должно быть»
2. Принципы успешного переноса данных на примерах кейсов Extyl.
3. Интеграция старой и новой систем. Как их обновлять, какие проблемы могут возникнуть в процессе.
4. Психологические аспекты перехода на новое ПО: как избежать синдрома отмены (старого портала) у сотрудников.

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

Яндекс Такси

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

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

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

Метрики производственного процесса как инструмент выстраивания взаимоотношений между командой и Бизнесом

Teamlead
Коммуникация
Управление командой
Управление разработкой
Бизнес-процессы
Управление проектами
Трансформационные изменения

a. Производственный процесс как способ унификации работы команд в крупных организациях позволяет снизить время на онбординг, повысить возможность ротации специалистов, выстроить единый воркфлоу команд и использовать best practicies всех команд в организации
b. Выстраивание производственного процесса может быть болезненным и это необходимо понимать на этапах его разработки
c. Самая сложная часть - выстраивание самого workflow и реализация его в таск-трекере и настройка всех необходимых интеграций для дальнейшего автоматического расчета метрик
d. Метрики производственного процесса позволяют доносить до Бизнеса текущие процессные изменения, дают опору при планировании загрузки команд, поддерживают необходимость перераспределения участников команд или поиск и набор новых специалистов.
e. При подготовке демо для Бизнеса и ретро метрики позволяют подсвечивать сильные места команд, которые можно учитывать при планировании, а также подсвечивать слабые места для поиска возможностей их усиления в дальнейшим
f. Дополнительно поделимся кейсами внедрения таких процессов в компаниях и тем, какие инструменты для измерения каких метрик подходят и как их презентовать бизнесу

Программный комитет ещё не принял решения по этому докладу

Как роль Feature Lead превращает разработчиков в супергероев. Секреты эффективности и полезные инструменты

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

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

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

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

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

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

Опыт Lamoda: как нам удалось укротить кросс-функциональный подход?

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Автосборка: Инновационный подход к улучшению эффективности и качества в IT-производстве

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

Этот доклад предназначен для наиболее значимых игроков в области IT: СЕО, CPO и CTO. Мы представляем "Автосборку" - прогрессивную процессообразующую систему, способную ускорить технологический процесс и повысить качество продукции. Будут затронуты ключевые темы унификации стандартов, стандартизации конфигураций и сборки, определения фаз готовности продукта и версионного контроля. В докладе показано, как "Автосборка" обеспечивает безопасное escrow, эффективное переиспользование артефактов, поддержку пофичной разработки и импортозамещение. Узнайте, как "Автосборка" позволяет выпускать качественные IT-продукты в запланированные сроки, обеспечивая конкурентное преимущество на рынке.

Программный комитет ещё не принял решения по этому докладу

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

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

В портфеле проектов одной компании было много небольших и средних систем, реализованных на одном стеке технологий. Каждая команда работала над своим проектом независимо, не было общего для всех шаблона проекта. Из-за отсутствия образца для подражания были проблемы на старте очередного проекта, когда команда мучительно выбирала какие из BestPractices она будет использовать, на каждом проекте заново изобретались решения для типовых задач (оптимистическая блокировки и аутбокс), а также делались типовые ошибки (отдельные модели для бизнес-логики и доступа к данным). Новый эффективный подход Vertical Slice Architecture вызывал опасения из-за отсутствия опыта его применения. Переключение разработчиков между проектами было болезненным.
Я расскажу об опыте унификации проектов в портфеле с использованием шаблона, реализованного на базе Чистой Архитектуры. Внедрение шаблона проекта и обучение команд разработчиков заложенным в него принципам позволило облегчить старт нового проекта, избежать типовых ошибок, переиспользовать существующие решения, упростить внедрение нововведений и упростить переключение разработчиков между проектами. Развитие проектов стало более динамичным, а поддержка - более простой, работа команд разработчиков стала как более комфортной, так и результативной.
Шаблон проекта выложен на GitHub, а инструкция по его использованию - курс на Udemy.

Программный комитет ещё не принял решения по этому докладу

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

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

Росбанк

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

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

Zero downtime deployment и базы данных

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

Успеть за 10 часов - создание и вывод высоконагруженного клиентского продукта на базе Технологических платформ

- Основные show stopers в development & delivery
- Подходы и практики по снижению LeadTime продукта
- Инструментарий и сервисы по автоматизации типовых задач
- Основные проблемы на этапе их эксплуатации
- Тренды по дальнейшей оптимизации

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

С4 model на практие

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

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

Программный комитет ещё не принял решения по этому докладу

Стейт-машины (The Good, The Bad and The Ugly)

Java
Бэкенд / другое
Архитектурные паттерны
Дарья Андреева

Яндекс.Технологии

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

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

2. Покажу итеративно, как можно их можно улучшить

3. Расскажу, как мы в Биллинге 360 решили проблему реализации стейт-машин с помощью spring-state-machine

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

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

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

Программный комитет ещё не принял решения по этому докладу

Не SOLID'ное программирование

Критически проанализируем известные принципы разработки (TDD, SOLID, DRY, YAGNI, KISS) и попробуем их починить.

Программный комитет ещё не принял решения по этому докладу

Нормально делай — нормально будет. Discovery → Delivery здорового человека

Управление разработкой
Бизнес-процессы
Управление проектами
Трансформационные изменения
Agile / Scrum
Типовые ошибки

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Внедрение практик управления Надежностью на ландшафте МТС

Большие проекты/команды
Процессы и инструменты в enterprise
Управление инцидентами
Observability в enterprise
Надёжность продакшена
DevOps / SRE

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

Мы поделимся - как нам удалось в короткие сроки подключить 250+ продуктов к платформе обеспечения надежности OPS Platform. В том числе расскажем, как мы нашли и поставили на мониторинг все SSL сертификаты продуктов, запустили практику PostMortem анализа и создали индикаторы качества SLI для критичных клиентских сценариев. Поговорим о технических и организационных проблемах и путях их решения.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

Применение технологий и инструментов искусственного интеллекта в распознавании и прогнозировании лесных пожаров Российской Федерации

Обработка данных

ПРИМЕНЕНИЕ ТЕХНОЛОГИЙ И ИНСТРУМЕНТОВ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА В РАСПОЗНАВАНИИ И ПРОГНОЗИРОВАНИИ ЛЕСНЫХ ПОЖАРОВ РОССИЙСКОЙ ФЕДЕРАЦИИ
Доцент кафедры “Информационно-измерительная техника” Южно-Уральского государственного университета, к.т.н., Кодиров Шахбоз Шарифович
kodirovss@susu.ru
Ученик МБОУ СОШ №8 имени М.И. Бусыгина, Кирпичев Владимир Эрнестович
kirpichev.vladimir@list.ru
Россия по праву считается лесной державой, на неё приходится 1/5 часть всех лесов мира, 1/2 часть всех хвойных лесов, леса занимают ~50% всей площади страны и составляют 1,2 млрд. Га. Защита лесных ресурсов от пожара является важной задачей управления лесным хозяйством. Основная причина гибели лесов - это пожары. На расходы по тушению лесных пожаров выделяются и тратятся огромные средства. По данным министерства природных ресурсов ущерб от лесных пожаров в 2021 составил 10.6 млрд рублей. Следует заметить, что реальный экономический ущерб от лесного пожара складывается не только из урона, нанесенного лесу, промышленным и другим объектам, но и из затрат, связанных непосредственно с тушением. Соответственно для того, чтобы минимизировать выше отмеченные ущербы и затраты, необходимо на ранних стадиях локализовать и ликвидировать пожары. Однако, для того чтобы на ранних стадиях предвидеть пожары (например, местоположение, тип пожара, возможное время возникновения), необходимо иметь достоверные прогнозы о рисках их возникновения. Для этого необходимо разработать систему мониторинга и прогнозирования рисков возникновения пожаров с применением передовых технологии обработки данных. Из сказанного выше становится очевидна огромная важность организации надёжной системы мониторинга и прогнозирования рисков возникновения пожаров для своевременного обнаружения и принятия мер по недопущению лесных пожаров, позволяющая минимизировать экономический, экологический (а в некоторых случаях и человеческий) ущерб [1-4].
Раньше проблема лесных возгораний являлась нерешимой ни в одной стране мира, поскольку условия возникновения пожара, характер его поведения и возможности его тушения зависят от сочетания множества самых разных факторов, как прямых, так и косвенных. Ныне существующие прогностические модели [3-6] имеют недостаточную точность прогнозирования, а также они построены на синтетических данных, что ограничивает их применять в реальных условиях. Кроме того, в существующих моделях не учитывается временные характеристики возникновения типов пожаров. Следовательно, необходимо разработать алгоритм обработки данных и модель прогнозирования лесных пожаров учитывающий временные и географические особенности территории Российской Федерации.
В представленной работе, предлагается новая методика разработки алгоритма обработки данных и модели прогнозирования лесных пожаров по времени и по локации их возникновения для территории Российской Федерации. В данной работе, применились самые передовые методы обработки данных, а также алгоритмы машинного обучения.
Основные результаты и выводы:
1. С применением алгоритма обработки данных и метода разведочного анализа данных (exploratory data analysis), выявлены неочевидные закономерности возникновения лесных пожаров, по времени и локации их возникновения. В частности, по графикам агрегированных значении возникновения лесных пожаров по месяцам года, по неделям года, по дням года, по дням месяца и дням недели, выявлены явные закономерности возникновения пожаров по времени.
2. С целью минимизации неполноты информации и повышения репрезентативности информации о возникновении лесных пожаров, на основе выявленных закономерностей, с применением инструментов «инженерия данных» (data engineering) были рассчитаны и введены дополнительные дискредитирующие элементы данных.
3. Для оценки статистической взаимосвязи между типами лесных пожаров и введенными элементами данных, рассчитаны парные коэффициенты корреляции и построена корреляционная матрица. По значениям коэффициентов корреляции, было установлено, что рассчитанные и введенные дополнительные элементы данных являются значимыми, и могут вполне использоваться в качестве входных данных для построения модели прогнозирования лесных пожаров.
4. На основе алгоритма «k-ближайших соседей (k-NN)», разработана модель прогнозирования лесных пожаров по времени и локации их возникновения. Разработанная модель на экспериментальных тестовых данных демонстрировал аккуратность (accuracy), точность (precision) и полноту (recall) прогнозирования от 0,82 до 0,925, что превосходит по точности традиционных методов на 15-20%.
5. С применением такого метода кластеризации как k-средних (k-means clustering), экспериментальные данные о лесных пожарах по времени и локации их возникновения были кластеризованы. Это было сделано для того, чтобы дополнительно оценить схожесть и различие между типами лесных пожаров.
Список литературы
1. Воробьев, Ю.Л. Лесные пожары на территории России: Состояние и проблемы/Ю.Л. Воробьев, В.А. Акимов, Ю.И. Соколов; Под общ. ред. Ю.Л. Воробьева; МЧС России. — М.: ДЭКС-ПРЕСС, 2004.
2. Коваль, Ю.Н. Анализ пожаров на территории Усинского лесничества / Коваль Ю.Н. Анализ пожаров на территории Усинского лесничества // Безопасность жизнедеятельности. - 2021. - №1 (421). - С. 50-53.
3. Станкевич, Т.С. Разработка метода оперативного прогнозирования динамики развития лесного пожара посредством искусственного интеллекта и глубокого машинного обучения // Вестник Иркутского государственного технического университета. - 2018. - Т. 22. - № 9. - С. 111-120.
4. Барталев, С.А., Стыценко, Ф.В., Егоров, В.А., Лупян, Е.А. Спутниковая оценка гибели лесов России от пожаров. – Лесоведение, – 2015. № 2, с. 83-94.
5. Бондур, В.Г., Гинзбург, А.С. Эмиссия углеродсодержащих газов и аэрозолей от природных пожаров на территории России по данным космического мониторинга. – Доклады Академии наук, – 2016. т. 466, № 4, с. 473-477. doi:10.7868/S0869565216040186.
6. Бондур, В.Г., Гордо, К.А., Кладов, В.Л. Пространственно-временные распределения площадей природных пожаров и эмиссий углеродсодержащих газов и аэрозолей на территории Северной Евразии по данным космического мониторинга. – Исследование Земли из космоса, – 2016. № 6, с. 3-20. Doi:10.7868/S0205961416060105.

Программный комитет ещё не принял решения по этому докладу

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

Управленческие метрики: хорошие и не очень

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

Программный комитет ещё не принял решения по этому докладу

«Банда пяти» или как паттерны проектирования бэкэнда сделать эффективным инструментом менеджера

Чем отличается опытный менеджер от не опытного?

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

Сама идея шаблонов проектирования появилась в 1970 годах для проектирований зданий и городов, было опубликовано 273 шаблона.
Через 20 лет она помогла создать концепцию шаблонов проектирования в среде программистов, после выхода нашумевшей книги известной под псевдонимом «Банда четырех». В книге описаны 23 классических паттерна, которые программисты могут использовать для решения повторяющихся проблем.

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

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

Программный комитет ещё не принял решения по этому докладу

Урри, где у него кнопка? Как тимлиду понять истинную мотивацию сотрудника

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

Программный комитет ещё не принял решения по этому докладу

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

* Динамика дефицита кадров за 10 лет
* Воронка подбора: как не упустить подходящего кандидата
* Компоненты профессионализма
* Hard и soft skills: что важнее и как соблюсти баланс
* Методики распознавания профессионализма
* Почему нельзя оценивать по резюме и рекомендациям
* Давать ли live coding в 2024 году?
* Типичные ошибки в оценке профессионализма

Программный комитет ещё не принял решения по этому докладу

Как управлять ИТ проектами, чтобы попадать в сроки

Большие проекты/команды
Управление проектами
Метрики
Инструменты
Проектный офис

Цель доклада: Поделиться успешным опытом планирования крупных проектов на основе данных о производительности и ошибках команды.
Тезисы:
- Почему не попадаем в сроки и чем это чревато.
- Благодаря чему мы научились попадать в сроки.
- Баланс между Agile и четкими целями и сроками.
- Чем оценка в часах лучше оценки в StoryPoints.
- Как получить от разработки метрики производительности.
- Как улучшить качество оценивания.

Программный комитет ещё не принял решения по этому докладу

Как подготовить идеальную встречу в формате Брейншторма

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как мне нанимать больше?

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

Программный комитет ещё не принял решения по этому докладу

Гибридная организационная культура компании Авито

На нашем рынке работают много замечательных IT-компаний. И нетрудно видеть, что они ведут себя по разному. Одни, как Google, создают “открытую” мобильную платформу для других вендоров. Другие, как Apple, замыкают эко-систему на себе, чтобы контролировать качество услуг. Третьи, как Amazon, стараются найти новые рынки и заполнить их быстрее конкурентов.

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

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

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

Затем я применю эти инструменты на компанию Авито, в которой я работаю.

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

Программный комитет ещё не принял решения по этому докладу

Как собеседовать CTO и не потратить вечность

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

Программный комитет ещё не принял решения по этому докладу

Как извлечь двойную пользу из «плана Б»

Кир Дергачев

Нетология

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

Трудные диалоги

Наталья Пешкова

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Геймер vs Менеджер: Как Игры Могут Усилить Ваши Навыки Управления

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

Webinar Group (на данный момент)

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

Программный комитет ещё не принял решения по этому докладу

Как тимлиду продвинуть свою идею руководству компании. И причем тут ChatGPT?

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

2) Генеративные модели и ChatGPT: Описание принципов работы генеративных моделей и ChatGPT, их возможностей и применений в бизнесе и управлении проектами. Приведение примеров успешного использования.

3) Применение ChatGPT для апробации идей: Объяснение, как использовать ChatGPT для проверки идей и сценариев. Описание методик работы с моделью для оценки потенциальных реакций и последствий.

4) Интеграция фреймворков описани психологического профиля (DISC и прочие) в связке с ChatGPT для предсказания реакции руководства на ваши идеи. Интеграция с ChatGPT

5)Выводы и будущее применения AI в управлении командами и проектами: Рассмотрение перспектив и предполагаемых вызовов использования AI и генеративных моделей в руководстве проектами и командами. Обсуждение возможных этических вопросов и вопросов безопасности.

Программный комитет ещё не принял решения по этому докладу

Системное управление текучестью

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

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

Программный комитет ещё не принял решения по этому докладу

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

Я тимлид, у которого довольно крупная команда (50 человек) и много операционки. А еще я увлекаюсь генеративными нейросетями и научился круто использовать их для автоматизации разных управленческих задач (даже performance review). Сейчас я развиваю внутренний продукт по автоматизации и применении GAN-моделей и постоянно совершенствую сценарии использования этого инструмента для эффективности и себя и команды. В докладе поделюсь конкретными кейсами и опытом prompt engineering.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Просто и понятно о том, как создать работающий процесс Performance review

Тезисы:
1. Из чего состоит процесс Perfomance review (выполненные цели, обратная связь 180/360 и тд, оценка по матрице компетенций, ИПР). Какие проблемы решает, к каким результатам может привести.
2. Как создать работающую матрицу компетенций (сложности и ошибки, техники создания, пример готовой матрицы).
3. Как создать ИПР + шаблон примера, как он может выглядеть.
4. Как построить встречу по perfomance review.
4. Как выглядят результаты Perfomance review и дальнейшие шаги.

Программный комитет ещё не принял решения по этому докладу

Выстраивание и поддержка привлекательной профессиональной среды для IT-экспертов в компании при дефиците ресурсов на развитие

В результате событий последнего года рынок труда в IT-сфере знатно поштормило: ушли с рынка западные компании с высоко развитой бизнес-культурой. Многие высококлассных специалисты уехали за своими компаниями за границу, кто-то уже возвращается.. Рынок но пуст, то переполнен
Я, как человек, обеспечивший переход большой группы IT-аналитиков из западной компании в Российскую, как лидер центра компетенций и руководитель отдела анализа, как неформальный лидер, удерживающий коллег в одной команде, - хочу поделиться своим опытом выстраивания и поддержки привлекательной для IT-специалистов мотивирующей, стимулирующей профессиональный рост среды.
Целевая аудитория доклада: Руководители IT-компаний и подразделений, директора, HR - желающие выигрывать в конкурентной борьбе работодателей, повышать лояльность сотрудников
Проблемы, с которыми сталкивается ЦА: 1) Конкуренция за счет больших ЗП - дорого и ненадежно, 2) Низкая лояльность сотрудников и высокая текучесть кадров, 3) НЕ очень понятно, как должно быть и чем завлечь специалистов, 4) HR-активности не помогают удержанию в должной степени, 5) Нехватка реально экспертности на всех уровнях для решения проблем
В результате выступления слушатели получат: 1) Критерии, по которым айтишники выбирают работодателя (с результатами опросов) - > идеальный работодатель (to be state), 2) практические рекомендации, как выстраивать трансформацию при ограничении ресурсов

Программный комитет ещё не принял решения по этому докладу

Уходи, но останься: как управлять увольнениями в команде

Антикризисный менеджмент
Teamlead
Мотивация сотрудников
Управление командой
Soft Skills
Ариадна Данцкер

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

Валерия Маленкова

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

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

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

Программный комитет ещё не принял решения по этому докладу

Теперь я teamlead: Применение новых инструментов для успешной адаптации в новой роли"

Алексей Салаев

ПАО Росбанк

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

Я их уже не перевариваю? Наш опыт адаптации людей в растущей команде

Недавно наша команда технических писателей и редакторов столкнулась с типичной ситуацией: привалила куча новой работы, а вместе с ней – и новых коллег. За полгода команда выросла на 40%. Пришлось много чего изменить, но мы выжили и кажется стали сильнее.
Я расскажу о нашем опыте быстрой адаптации новых людей:
- Без чего точно не взлетит (это в первую очередь про культуру в команде).
- Как мы изменили старый процесс адаптации, чтобы переварить всех этих чертовых гениев. И сократили время адаптации с трех месяцев до одного.
- Что еще пришлось сделать руководителю, чтобы сохранить здоровье и рассудок.
Никаких нейросеточек и магии Хогвартса, но нам помогло. Возможно, будет полезно и вам.

Программный комитет ещё не принял решения по этому докладу

Кругозор (3)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обучение (12)

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

Soft Skills
Личное развитие
DevRel
HR-маркетинг
Обучение на стороне
Образование
Внутреннее обучение
Валерия Суворова

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

Заявлять рынку о своей экспертизе лучше всего от лица самих экспертов. Но коллеги-технари часто не любят/не хотят или просто не умеют/бояться выступать публично.
С одной стороны, можно оставить их в покое и делегировать подобные задачи «продавцам». А с другой стороны, развитие навыков public speaking у профильных специалистов помогает не только выигрышно смотреться в глазах заказчиков, но и развивать экспертное коммьюнити, и даже эффективнее работать на проектах.
В докладе я расскажу, почему тренинги по софт скиллам/выступлениям/презентациям не работают сами по себе. Поделюсь своим опытом, как мы работаем над развитием навыков коммуникации и публичных выступлений в нашей технической команде, которая сейчас насчитывает больше 200 технических специалистов, и какие результаты мы получили.

Программный комитет ещё не принял решения по этому докладу

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

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

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

Как помочь новому сотруднику «войти в IT» (и стоит ли это делать)

Солдатова Оксана

ПАО Вымпелком

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

О себе: с 2019 года обучала 5 человек «войти в IT» с нуля — и до разных результатов (спектр от руководителя до джуна).
Расскажу о том как я бы работала с таки сотрудником сейчас, и попутно поделюсь байками о том, почему так, а не иначе.

Фокусы внимания:
— выбор среди десятков начинающих: что ищем?
— трек обучения: куда растим и в какие сроки?
— финансы: прикидываем затраты и пользу от сотрудника;
— оценка: вовремя вносим коррективы;
— эмоции: готовимся к потенциально тяжелым ситуациям, специфичным для новичков в IT (и в целом людей, принципиально меняющих сферу деятельности).

Программный комитет ещё не принял решения по этому докладу

Пока другие пылесосили рынок, мы развивали IT Академию

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

Программный комитет ещё не принял решения по этому докладу

Создание внешнего обучения. Альфа-Кампус.

Большие проекты/команды
Поиск и развитие команды
Soft Skills
Управление проектами
Типовые ошибки
HR
Образование
Внутреннее обучение
Подбор команды
Техинтервью
Мика Ратилайнен

Альфа-Банк

Расскажу, как создали Альфа-Кампус. Это внешнее ИТ-обучение от Альфа-Банка.
Мы сделали несколько факультетов, на которых бесплатно обучали начинающих специалистов. Расскажу, как создать команду, как мотивировать преподавателей и менторов, чем они должны заниматься, как создать факультеты, программы курсов, подготовить экспертов к лекциям, подготовить домашние задания, проверять их. Так же расскажу, как взаимодействовать с другими департаментами, например, hr-брендом и Академией, если они у вас есть. Обязательно рассмотрю, как и кого набирать на курсы, как проводить отбор учащихся, как измерять успешность обучения. И, естественно, самое главное, с цифрами покажу, зачем такие курсы компании, как они экономят деньги, время и работают не только на перспективу, но и помогают в моменте.

Программный комитет ещё не принял решения по этому докладу

Развитие Agile-Лидеров: как построить систему обучения и не собрать все "Грабли"

Как построить систему обучения и развития Agile-Лидеров?
Как её потом масштабировать для обучения нескольких сотен или тысяч Лидеров?
Какие "Грабли" лежат на этом пути?
Ответы на эти и другие вопросы вы получите в этом докладе.

Программный комитет ещё не принял решения по этому докладу

Процесс организации отдельной фронтенд команды.

Большие проекты/команды
Модели руководства
Управление командой
Управление разработкой

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

Только в веб-отделе 2GIS - 25 qa-инженеров. Прикол в том, что все мы растащены по отдельным продуктовым или фичевым командам. Еще как бонус - по 11 часовым поясам.

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

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

Программный комитет ещё не принял решения по этому докладу

Кто я? (2)

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

Юлия Аравина

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

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

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

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

[временное название] Как слушать доклады на TeamLeadConf

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

IT-карьера: Войди и останься!

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

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

Программный комитет ещё не принял решения по этому докладу

Управление по принципу наказуемой инициативы

- Знакома ли вам ситуация, когда прод упал, но никто кроме пользователей об этом не знает? Либо знает, но ничего не делает?
- Знакома ли вам обратная ситуация, прод упал, все побросали свои дела и принялись ЧТО-ТО с ним делать, давать советы, etc.?
- Знакома ли вам ситуация, когда коллега не делает того, что ты от него ожидаешь?

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

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

Программный комитет ещё не принял решения по этому докладу

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

Teamlead
Личное развитие
Трансформационные изменения
Менторинг
Обучение на стороне
Образование

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Пуленепробиваемый управленец или техники работы с эмоциями

Корпоративная культура и мотивация
Поиск и развитие команды
Обслуживание клиентов, техническая поддержка, обратная связь
Деловая встреча
Коммуникация
Мотивация сотрудников
Управление командой
Soft Skills
Личное развитие
Эмоциональный интеллект
Профессиональное развитие инженера
HR
Внутреннее обучение
Проектный офис
Команда

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

3 вредных мифа про тайм-менеджмент, work-life balance и прокрастинацию

Soft Skills
Личное развитие
Артур Орлов

Лаборатория структурной магии

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

IT-карьера: Войди и останься!

Продуктовая разработка
Управление / другое
Коммуникация
Мотивация сотрудников
Soft Skills
Личное развитие
Трансформационные изменения

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

Ожидания от роли тимлида и реальность

Кир Дергачев

Нетология

Бывает, что ожидания от роли тимлида сталкиваются с действительностью.

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

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

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

Рассмотрим разные ситуации и научимся находить выход из ситуации.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

Как не провалить ИТ-проект

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

Глобус-ИТ

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

Программный комитет ещё не принял решения по этому докладу

Конфликты внутри проекта: что нужно знать и уметь руководителю

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

Улучшаем качество продукта без тестирования или Software Testing Anti-patterns

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

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

Программный комитет ещё не принял решения по этому докладу

Сам себе деврел

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

- Коротко: зачем вообще это всё же можно делать и кому оно надо
- Целевая аудитория. Зачем и как её определить
- Темы. Как понять, чем можно поделиться с миром
- Инструменты и площадки. Как можно делиться, насколько это сложно и как это упростить
- Как начинать делиться экспертизой
- Как продолжать. Контент-план и метрики: три стадии просветления
- Дистрибуция и переиспользование контента. Как сделать так, чтобы минимум выступлений и статей давали побольше результата
- Где искать время и силы на эту активность

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Учитесь слушать

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

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

Чтобы научиться слушать и слышать собеседника, помогут простые советские… навыки активного и пассивного слушания. Поделюсь теми из них, которые лично использую на практике, тем самым сэкономив многие “пустые” часы и достигнув конечного результата быстрее. Никакого НЛП или психологических манипуляций, только конкретные инструменты и методики, наработанные за 10 лет в роли Head of QA. Послушаем?

Программный комитет ещё не принял решения по этому докладу

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

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

Align Technology

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

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

Команда в кризисной ситуации: техники решения конфликтов

Денис Фурсенко

ПАО Росбанк

1. Природа конфликта - почему он происходит?
Рассмотрим как возникает сопротивление при изменениях в команде и почему люди могут захотеть обострить ситуацию.

2. Роль руководителя в конфликте.
Изучим в каких конфликтах может участвовать руководитель (тимлид, менеджер). Как и зачем он может разжигать конфликт и гасить его.

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

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

5. Техники управления конфликтной ситуацией
В рамках истории из практики покажу пошаговый алгоритм как “разрулить” конфликтную ситуацию.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Формируем команду через конфронтацию

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

До встречи!

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

Контурная карта команды: как настроить отношения внутри и снаружи

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

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

Программный комитет ещё не принял решения по этому докладу

С людьми можно просто говорить

1. Как сделать из сотрудников команду: какие существуют подходы в управлении
2. Кейс: программа длительностью 8 месяцев: расскажем, как изменились участники
3. Покажем ключевой инсайт кейса. И сколько нужно было сделать для того, чтобы к этому инсайту прийти (дадим чек листы и методику)
4. Ответим на вопрос: что будет, если управленческая команда не видит ценности в том, чтобы разговаривать со своими сотрудниками?
5. Поговорим о том, как обучение руководителей в таком долгом формате повлияло на трансформацию команды и компании

Программный комитет ещё не принял решения по этому докладу

А что, если разделить команду?

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

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

"А что, если разделить команду?"
Те, кто никогда не слышал этих слов, скорее всего рано или поздно их услышат. Из доклада узнаем о том, как выйти из этого процесса с новыми эффективными командами, а не осколками старых.

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

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

Поиск и развитие команды
Networking, знакомство
Лайфхаки
Команда

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

Поделюсь своими лайфхаками, которые были проверены на личном опыте не одной команды:

1. Расскажу как понимать потребности своей команды.
2. Как создавать атмосферу доверия и поддержки.
3. Успешный найм сотрудников и адаптация новичков в команде
4. Как выстроить взаимодействие внутри, когда команда удаленная

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

Программный комитет ещё не принял решения по этому докладу

Самоуправляемая команда, которая никогда не грустит: правда или вымысел?

Teamlead
Коммуникация
Мотивация сотрудников
Управление командой
Soft Skills
Управление проектами
Делегирование задач
Agile / Scrum
Чепкасова Юля

МТС Диджитал

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

Евгений Веретенников

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

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

Итог — выгорание и разочарование в людях, в себе, в профессии.

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

Почему я?

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

И вот ты топ. Что делать если тебе дали в управление ещё кучу команд?

Большие проекты/команды
Модели руководства

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

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

P.S. Тезисы пока что набросочные, будет проработка

Программный комитет ещё не принял решения по этому докладу

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

Булат Усманов

Консультант

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

Программный комитет ещё не принял решения по этому докладу

«Mindset эффективного руководителя: как доводить проект до результата и не превращаться в гида для команды стейкхолдеров»

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

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

Подробнее о том, что будет в докладе:

- Кто такой руководитель и зачем он нужен в проекте
- Frame лидера
- Установки и убеждения эффективного руководителя
- Порочный круг руководителя "власть-ответственность"

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

Против шерсти: как внедрять изменения в сложившуюся команду

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

Как не наломать дров в новой роли или на новом месте: алгоритм на первые 90 дней

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

Я расскажу:

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

Программный комитет ещё не принял решения по этому докладу

Как сделать команду пожаробезопасной?

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Первые «девять с половиной недель» тимлида в новой роли

Вера Маневич

Одноклассники

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

- Стал ровнее остальных, что с этим делать? Мышление осталось прежним: если я не пишу код, я бесполезный? Стало лететь много различных других задач, кроме кода, и не успеваю их решать.
- первые шаги к возвращению доверия команды: начальный процесс one2one запущен
- первое делегирование команде: процесс "босса" спринта не остановить
- продолжаем делегировать и наращивать экспертизу в команде: переход от менторинга к коучингу
- сложный выбор между people management и написанием кода: (само)-рефлексия и подведение команды к новым реалям (больше "не пишу" код).
- работаем над bus-factor: первые наброски starmap и развитие экспертизы у команды (ИПР)

Программный комитет ещё не принял решения по этому докладу

Десять шагов руководителя к созданию и удержанию доверия команды

В докладе:

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

Как жить в матрице – проблема пересечения функционального и линейного управления

Управление / другое
Teamlead
Коммуникация
Управление командой
Soft Skills
Делегирование задач
Трансформационные изменения

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

Программный комитет ещё не принял решения по этому докладу

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

Мягкая сила: как неочевидные навыки становятся основным фактором развития продуктивных команд

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

Как роль тимлида связана с метачеловеком будущего?

Почему Мета - это совсем не про Цукерберга.

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

Программный комитет ещё не принял решения по этому докладу

Upscale или как растить синьоров помидоров?

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

Программный комитет ещё не принял решения по этому докладу

Села батарейка или как подогревать ресурс и мотивацию команды

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

1. Как забустить развитие сотрудника
2. Как удовлетворить запрос на челленджи, не теряя связь с реальностью
3. Как такой практикой не сломать выстроенные процессы
4. Как понять, что сотруднику не нужно развитие
5. Как измерить результат проведенной работы

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

СберМаркет

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

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

10 вредных советов для начинающего менеждера

Большие проекты/команды
Внедрение и поддержка
Teamlead
Личное развитие
Управление проектами
Типовые ошибки

10 вредных советов начинающему проджем менеджеру

1. Никогда не определяйте круг стейкхолдеров. Вам не все ли равно для кого внедрять проект и кто может на него повлиять?
2. Никогда не собирайте требования к проекту. Зачем заранее ограничивать себя и загонять в узкие рамки? Нам всем нужно пространство для творчества.
3. Никогда не проводите скоринг решений. Зачем выбирать лучшее, что подходит под ваши требования? Выбирайте то, что дешевле или то, что больше нравится на интуитивном уровне.
4. Никогда не проводите референс-визиты в компании, которые уже используют данное решение. Мало ли что они у себя внедрили? Не будем собирать чужой опыт и ошибки.
5. Никогда не проводите обучение для будущих пользователей. Достаточно получить от вендора ссылку на 1000 страничный help и переслать его пользователям. Читать ведь умеют?
6. Никогда не документируйте решения. Ведь команда, которая работала с вами на внедрении будет работать в компании вечно и в случае любой проблемы сможет быстро ее решить!
7. Никогда не привлекайте вендора к вашему внедрению и не просите его поделиться опытом других клиентов. Ведь ваша команда самая умная и ответственная и все сделает самостоятельно!
8. Никогда не фиксируйте список проблем, возникших при внедрении, сроки и ответственых за их решение. К чему этот формализм?
9. Никогда не проводите "lessons learned" после завершения проекта. Ведь каждый проект уникален и на каждом нужно набить свои шишки.
10. Никогда не запускайтесь по частям. Ешьте всего слона сразу! Или пан или пропал.

Программный комитет ещё не принял решения по этому докладу

Менторство как репетиция тимлида. Рефлексия наставника

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

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

Моя гипотеза - через опыт менторства.

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

Отрефлексируем этот путь, чтобы решить, действительно ли менторство - это нулевой уровень руководства.

Программный комитет ещё не принял решения по этому докладу

Сеньор в вакууме. Почему вы не тимлид?

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

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

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

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

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

Андрей Жуков

С7 ТехЛаб

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

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

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

История о том, как удалось наладить коммуникации с разработчиками и клиентами и сократить затраты бизнеса более чем на 90%.
Описание: Сразу скажу, здесь не будет никакой магии и танцев с бубнами. Я расскажу на конкретных примерах, как мы сократили затраты бизнеса на 94% в компании Gateway.fm, в которой трудится международная команда. Сделали мы это за счет целенаправленного структурирования коммуникаций и повышения уровня доверия между отделами Business sales и разработки. География команды - это Европа, Россия, Украина и Нигерия.

Программный комитет ещё не принял решения по этому докладу

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

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

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

Как модель зрелости команд помогла нам сократить lead time

Ольга Муттер

СберМаркет

Модель зрелости команд (Team Maturity Model TMM) – это список инженерных практик с описанием базового уровня для всех команд разработки в СберМаркете. Цель внедрения TMM — сильная инженерная культура. Ниже описано для чего TMM компании, команде, экспертам.

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

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

Программный комитет ещё не принял решения по этому докладу

Как делить команду и не убить ее при этом

Teamlead
Управление командой
Трансформационные изменения
Алексей Партилов

СберМаркет

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

Программный комитет ещё не принял решения по этому докладу

Опыт работы: не требуется, или почему 80% моей команды изначально не имели опыта работы по профилю компании

Более 8 лет я руковожу PR-агентством, которое сегодня входит в топ-15 самых известных на российском рынке и в топ-90 Национального рейтинга коммуникационных компаний. Вместе с командой мы добились классных результатов, за плечами десятки довольных клиентов. В кризисном 2022 году, когда зарубежные бренды (основные заказчики PR-услуг) стали уходить с рынка, а российские компании сократили бюджеты на продвижение, оборот агентства вырос на четверть по сравнению с 2021 годом. При этом с самого начала работы компании я осознанно нанимала людей только без опыта в PR. Сейчас с уверенностью могу сказать, что именно это помогло не только удержаться на плаву вначале, но и вырасти, а также не потерять индивидуальность в нашей высококонкурентной сфере. Почему так и кому подойдет такая стратегия, расскажу в своем выступлении.

Программный комитет ещё не принял решения по этому докладу

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

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

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

Адаптация под импортозамещение

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление продуктов от Startup-а до Enterprise и изменения в команде

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

Ключевые тезисы

Задачи старта - Discovery + Validation
Ключевые метрики
Выбор технологий
Выбор фреумворка запуска между проектным и продуктовыми подходами
Сбор команды сэтапа и ключевые требования для запуска

Стабилизация и первые пользователи - CustDev
Организация операционных процессов
Планирование и контроль результатов
Смена парадигмы проекта в пользу продукта
Контроль ключевых метрик

Рост аудитории - Growth
Отказ от принципов стартапа в пользу контроля
Формирование детальных метрик
Обоснование затрат и планирование
Смена команды и смена подходов в технологиям
Отказ от части компетенций в команде - Более фокусное развитие

Масштабирование и удержание рынка - Monetization
Пересмотр продукта и ключевых навыков
Сильное сегментирование команды
Переход от контроля в пользу целевого развития продукта
Data-driven во всех ключевых решениях
Усложнение требования к команде

Программный комитет ещё не принял решения по этому докладу

После запуска: реформируй или выгори

Поиск и развитие команды
Особенности процессов разработки и тестирования мобильного ПО
Управление командой
Делегирование задач
Трансформационные изменения
Фиксация знаний

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

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

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

Программный комитет ещё не принял решения по этому докладу

Внедряем аджайл по аджайлу в Яндекс Практикуме

Давид Роганов

Яндекс Практикум

В Яндекс Практикуме мы какое-то время назад начали то, что называем Scrum-трансформацией: начали внедрять этот фреймворк для разработки продукта, постепенно и осознанно. Про Scrum, Agile и вот это всё часто говорят в контексте разработки ПО, но это далеко не единственная область, куда можно приложить те же самые принципы.

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

Как работать с распределенными и удаленными сотрудниками?
Покажем, прокомментируем и отдадим фреймворк (авторская разработка TSQ Consulting) управления распределенной командой.
Привяжем практику к научно-методической работе. Покажем данные исследований, на которых базировались при создании фреймворка.
Ответим на вопросы по работе с дистанционными сотрудниками.

Программный комитет ещё не принял решения по этому докладу

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

Воркшоп-игра "Галактика": от проблемы до найденного решения

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

Механика воркшопа: команда собирается за общим столом (7-10 человек, сетап на команду: стол с реквизитом для творчества (большой ватман с нарисованным шаблоном планеты, цветная бумага, карандаши, клей, магниты/стикеры) и совместно работает над заданиями.

Программный комитет ещё не принял решения по этому докладу

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

Вирна Штерн

Aletheia Digital

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

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

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

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

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

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

Как я провел лето

Тезисы для публткации

Программный комитет ещё не принял решения по этому докладу

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

Наталья Пешкова

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

Анна Матросова

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

Как вообще можно управлять людьми не имея никакого официального влияния?
Задача сложная, но осуществимая.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вирна Штерн

Aletheia Digital

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

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

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

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

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

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


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

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

Искусство заметковедения: или как при помощи структурирования информации можно погрузиться в новую профессиональную область и написать книгу

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

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

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

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

Как готовят аудиторов смарт-контрактов

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

Программный комитет ещё не принял решения по этому докладу

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

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

СберМаркет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фантастические техписы и места их обитания

— Кто-нибудь знает, как это работает?
— Петя знал. Но уволился.
— А документация?.
— Была у Пети в чертогах разума.

— О нет, мы запустили новый продукт, а пользователи не разобрались в интерфейсе!
— Может, пересмотреть интерфейс?
— Нет! Есть идея лучше! Давайте опишем напишем к нему инструкцию!

— Мы большая серьёзная компания.
— А документация у вас есть?
— Ну у нас есть Вася. Он умеет много чего. И писать документацию по ГОСТам.

Если эти ситуации вам знакомы и защемили сердечко — доклад поможет разобраться как всё это чинить и чьими силами.

Имя вашему спасителю — технический писатель. Вот какими они бывают:

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

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

Программный комитет ещё не принял решения по этому докладу

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

Мини-сообщества экспертов: как создавать, управлять и извлекать информацию

Митапы
Networking, знакомство
Типовые ошибки
Лайфхаки
Документация
Фиксация знаний
Инструменты
Методологии
Культура КМ
Картирование знаний
Техинтервью
Екатерина Потапова

Команда смыслов

Часто для тех или иных задач управления знаниями одного эксперта недостаточно, и даже серия интервью с разными людьми не даст нужного объема информации. В этом случае эффективны группы экспертов - если они работают вместе на протяжении определенного времени, это создает значимый кумулятивный эффект. Эксперты обмениваются мнениями, спорят, дополняют друг друга, – в общем создают совместный продукт, который значительно ценнее их отдельных интервью. Как их “сгуртовать”, создать мини- (или даже микро-) сообщество, получить результат и сделать это не усложнением, а повышением эффективности работы? Наша команда разработала ряд инструментов для создания такого сообщества и управления им и уже тиражировала этот подход в нескольких организациях. Расскажу все, что мы прошли на пути к созданию таких сообществ за последние несколько лет: типажи экспертов, грабли, на которые наступали, инсайты, которые получали.

Программный комитет ещё не принял решения по этому докладу

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

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

Деврел-бюро

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

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

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

Почему так?

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

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

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

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

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

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

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

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

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

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

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

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

Типовые ошибки
Лайфхаки
Базы знаний / 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: Создание и поддержание баз знаний Мастер-классы (4)

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

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

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

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

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

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

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

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

Документация
Инструменты
Команда

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

В докладе расскажем:
- Почему начали разрабатывать, а потом согласились купить готовое решение. И зачем снова вернулись к разработке.
- Как выбирали: работать в Markdown или в WYSIWYG-редакторе. А потом решили не выбирать.
- Каким образом внедрили Git в рабочий процесс нетехнических специалистов так, что они даже не заметили этого.
- Что за мегазорд у нас получился и почему он всем нравится.

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



Программный комитет ещё не принял решения по этому докладу

Принцип Парето для написания текстов: 20 приемов, которые дадут 80% результата

Лайфхаки
Документация
Фиксация знаний
Инструменты
Екатерина Потапова

Команда смыслов

Ксения Киселева

Команда смыслов

«Я же говорю по-русски, у меня все получится» или «откладываю до последнего, не могу выразить то, что мне хотелось»: диапазон нашего отношения к написанию текстов очень широк. Когда большинству из нас приходится ради дела писать тексты, обычно это происходит по наитию – ведь нас никто этому не учил (не считать же подготовку к ЕГЭ курсом эссеистики). При этом от умения излагать свои идеи, аргументы, просьбы, формулировать задачи или описывать продукт во многом зависит и личная успешность, и успех компании.
Этот ценнейший метанавык нужен и разработчикам, когда они выступают в роли экспертов, и всем видам управленцев. Хорошая новость: он возникает не только из практики, но и из знаний об устройстве текста, и существует много приемов, которые можно освоить быстро и применять постоянно. Мы постарались упаковать в полуторачасовой мастер-класс основные подходы и лайфхаки: из чего состоит хороший текст, как побороть страх белого листа, какие есть инструменты,чтобы писать достаточно хорошие тексты достаточно быстро.
На мастер-классе вы узнаете немного теории о том, как писать и редактировать текст (от инструкции до отчетов), попробуете улучшить чужой текст и написать свой собственный, получите обратную связь. На выходе (помимо новых навыков) – чек-лист из 20 пунктов для работы с текстами в будущем и рекомендации, как развивать свое мастерство.

Программный комитет ещё не принял решения по этому докладу

KnowledgeConf: Резерв (3)

Translators assemble: как масштабировать работу над переводами и не переругаться насмерть

Что делать, если объёмы переводов внезапно вырастают, и вот вам уже требуется не один переводчик-локализатор, а целая команда или даже две? Налаживать связи внутри команд и между ними, конечно.

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

Программный комитет ещё не принял решения по этому докладу

Как экспертам компании делиться знаниями и не тратить на это 100 часов

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

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

Виды обучения под разные цели: e-learning; blended learning - шаринг опыта;

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

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

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

Программный комитет ещё не принял решения по этому докладу

docs as code

СУЗ / системы управления знаниями
Документация

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

Рассмотреть такие системы можно по многим причинам, и вот лишь некоторые из них:

- вы доросли до ревью требований
- вы понимаете значимость удобства редакторов кода
- вам нужна open source self hosted система или мало денег
- вы сидели на google docs и хотите получить инструмент следующего уровня
- вам нужна отчуждаемая система документации
- вы хотите автоматизировать пайплайн качества документации с помощью стат-анализа, уменьшив объем ручного труда

Мы рассмотрим:
- Принципы работы, в каком случае подход будет оправдан, а когда нет
- Классификацию и основные инструменты, в т.ч. инструмент от facebook в сочетании с различными редакторами
- Преимущества которые дает docs-as-code подход, в т.ч. ревью, запросы на изменение, статические анализаторы качества документации

Мы успешно используем и внедряем docs-as-code подход на многие проекты в заказной разработке для крупных корпораций.

Программный комитет ещё не принял решения по этому докладу