Доклады

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Безопасность во многих компаниях стоит особняком. Вместо того, чтобы беспокоиться о качестве вашего продукта, "безопасники" твердят о ГОСТ-ах и 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 человека).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На примерах рассмотрим, какие проблемы были решены с помощью 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До встречи!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему я?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я расскажу:

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

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

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

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

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

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

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

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

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

В докладе:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Кто-нибудь знает, как это работает?
— Петя знал. Но уволился.
— А документация?.
— Была у Пети в чертогах разума.

— О нет, мы запустили новый продукт, а пользователи не разобрались в интерфейсе!
— Может, пересмотреть интерфейс?
— Нет! Есть идея лучше! Давайте опишем напишем к нему инструкцию!

— Мы большая серьёзная компания.
— А документация у вас есть?
— Ну у нас есть Вася. Он умеет много чего. И писать документацию по ГОСТам.

Если эти ситуации вам знакомы и защемили сердечко — доклад поможет разобраться как всё это чинить и чьими силами.

Имя вашему спасителю — технический писатель. Вот какими они бывают:

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

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

Часто для тех или иных задач управления знаниями одного эксперта недостаточно, и даже серия интервью с разными людьми не даст нужного объема информации. В этом случае эффективны группы экспертов - если они работают вместе на протяжении определенного времени, это создает значимый кумулятивный эффект. Эксперты обмениваются мнениями, спорят, дополняют друг друга, – в общем создают совместный продукт, который значительно ценнее их отдельных интервью. Как их “сгуртовать”, создать мини- (или даже микро-) сообщество, получить результат и сделать это не усложнением, а повышением эффективности работы? Наша команда разработала ряд инструментов для создания такого сообщества и управления им и уже тиражировала этот подход в нескольких организациях. Расскажу все, что мы прошли на пути к созданию таких сообществ за последние несколько лет: типажи экспертов, грабли, на которые наступали, инсайты, которые получали.

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

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

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

Почему так?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В докладе расскажем:
- Почему начали разрабатывать, а потом согласились купить готовое решение. И зачем снова вернулись к разработке.
- Как выбирали: работать в Markdown или в WYSIWYG-редакторе. А потом решили не выбирать.
- Каким образом внедрили Git в рабочий процесс нетехнических специалистов так, что они даже не заметили этого.
- Что за мегазорд у нас получился и почему он всем нравится.

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

«Я же говорю по-русски, у меня все получится» или «откладываю до последнего, не могу выразить то, что мне хотелось»: диапазон нашего отношения к написанию текстов очень широк. Когда большинству из нас приходится ради дела писать тексты, обычно это происходит по наитию – ведь нас никто этому не учил (не считать же подготовку к ЕГЭ курсом эссеистики). При этом от умения излагать свои идеи, аргументы, просьбы, формулировать задачи или описывать продукт во многом зависит и личная успешность, и успех компании.
Этот ценнейший метанавык нужен и разработчикам, когда они выступают в роли экспертов, и всем видам управленцев. Хорошая новость: он возникает не только из практики, но и из знаний об устройстве текста, и существует много приемов, которые можно освоить быстро и применять постоянно. Мы постарались упаковать в полуторачасовой мастер-класс основные подходы и лайфхаки: из чего состоит хороший текст, как побороть страх белого листа, какие есть инструменты,чтобы писать достаточно хорошие тексты достаточно быстро.
На мастер-классе вы узнаете немного теории о том, как писать и редактировать текст (от инструкции до отчетов), попробуете улучшить чужой текст и написать свой собственный, получите обратную связь. На выходе (помимо новых навыков) – чек-лист из 20 пунктов для работы с текстами в будущем и рекомендации, как развивать свое мастерство.

Что делать, если объёмы переводов внезапно вырастают, и вот вам уже требуется не один переводчик-локализатор, а целая команда или даже две? Налаживать связи внутри команд и между ними, конечно.

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

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

Виды обучения под разные цели: e-learning; blended learning - шаринг опыта;

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

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

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

Инженерный подход при создании документации имеет достаточно широкий пласт последователей.

Рассмотреть такие системы можно по многим причинам, и вот лишь некоторые из них:

- вы доросли до ревью требований
- вы понимаете значимость удобства редакторов кода
- вам нужна open source self hosted система или мало денег
- вы сидели на google docs и хотите получить инструмент следующего уровня
- вам нужна отчуждаемая система документации
- вы хотите автоматизировать пайплайн качества документации с помощью стат-анализа, уменьшив объем ручного труда

Мы рассмотрим:
- Принципы работы, в каком случае подход будет оправдан, а когда нет
- Классификацию и основные инструменты, в т.ч. инструмент от facebook в сочетании с различными редакторами
- Преимущества которые дает docs-as-code подход, в т.ч. ревью, запросы на изменение, статические анализаторы качества документации

Мы успешно используем и внедряем docs-as-code подход на многие проекты в заказной разработке для крупных корпораций.