Доклады

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

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

Расскажу несколько ярких примеров и покажу, почему происходит так, а не по-другому. И почему так будет происходить всегда, даже если вы сильно умнее тех, кто придумал прошлые KPI. На это есть системные причины. Ну и британские учёные тоже кое-что доказали :) KPI, показатели — это очень важные и необходимые инструменты. Но не нужно привязывать к этому деньги.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На встрече в формате «мозгового штурма» мы обсудим с вами несколько важных для нас вопросов:
1. Чего не хватает современной конференции? Тренды? Направления?
2. Какие темы вы бы хотели услышать в следующих программах.
3. Какие форматы стоит добавить, а от каких, возможно, стоит отказаться.
4. Возможно, есть какие-то спикеры, которых хотелось бы видеть в программе.
5. А может быть не хватает конференции для СТО?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идейное продолжение летнего доклада на SaintTeamLead2023.

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

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

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

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

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

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

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

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

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

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

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

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

До встречи!

«А что, если разделить команду?» — те, кто никогда не слышал этих слов, скорее всего, рано или поздно их услышат.

Из доклада узнаем о том, как выйти из этого процесса с новыми эффективными командами, а не осколками старых.

Кто-то ушел в отпуск и не передал дела? Внезапно увольняется самый ценный разработчик? И все это на фоне бурного роста команды с 40 до 150+ человек.

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

Знакомая ситуация? Тогда приходите на мой доклад.

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

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

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

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

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

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

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

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

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

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

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

Чтобы бороться с этим необходимо искать и комбинировать возобновляемые источники смыслов для каждой команды и каждого инженера в отдельности:
* Мотивация личная невозможна без мотивации команды. Справедливость и теория Адамса.
* Оптимальное распределение задач хуже неоптимального. Трудовые инвестиции или попробуйте убедить бизнес.
* Вывод целей разработки ПО в офлайн. Делайте вехи ощутимыми.
* Персональный опыт и травмы прошлого. Учитывайте предыдущие проекты инженера, повторяйте положительный опыт и избегайте повторения ситуаций, приводивших к провалам.
* Управляйте ожиданиями команды. Они не должны быть несбыточными, но их не может не быть вовсе.

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

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

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

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

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

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

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

Создать крутую команду и поддерживать в ней рабочий настрой весьма непросто. Эта задача значительно усложняется в кризисное время — нервы у всех на пределе, каждый может впасть в депрессию, «забив» на важные задачи, или сорваться и дестабилизировать рабочую атмосферу... Поэтому тимлидам крайне важно уметь работать с командой в условиях кризиса.

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

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

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

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

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

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

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

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

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

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

* Многие лидеры, будь то тимлиды, менеджеры или директора, часто сталкиваются с вопросом: «Куда мне дальше расти?». Традиционные подходы к развитию часто сводятся к приобретению новых навыков или взбиранию по карьерной лестнице, что может привести к выгоранию или чувству неудовлетворенности.
* В рамках мастер-класса предлагается новый подход к лидерству, основанный на модели вертикального развития лидеров. Я кратко ознакомлю участников с этой моделью и на конкретных примерах покажу ее проявления в профессиональной среде. Это поможет лидерам задуматься про свою роль, расширить кругозор и определить новые стратегии действий. Участники узнают о разнообразных логиках действия, начиная от оппортуниста и заканчивая алхимиком, и об их применении в практической деятельности.
* После мастер-класса участники смогут лучше осознать свои сильные стороны в управлении, заметить неэффективные стратегии лидерства, узнать и примерить на себя разные логики действия. В игре можно будет попробовать новые модели действий и, взаимодействуя с другими участниками, проверить на практике эффективность своих текущих подходов к лидерству. Как итог можно будет определить направления для своего дальнейшего развития лидерства.

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

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

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

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

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

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

На Мастер-классе потребуется собственный ноутбук.

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

Участники мастер-класса унесут с собой
* наброски рассказа о себе несколькими способами,
* понимание ЧТО, КОМУ, О ЧЁМ и КОГДА рассказывать,
* какие и кому задавать вопросы.

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

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

Что вы получите:
1. Множество Голосов: возможность услышать разнообразные точки зрения, а не одну «правильную».
2. Глубокое Понимание: осмысление темы через обмен опытом и знаниями с коллегами из разных областей.
3. Интерактивный Формат: возможность стать частью дискуссии, а не просто слушателем.

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

На Мастер-классе потребуется собственный ноутбук.

Это формат нетворкинга по командам для решения своих задач. Комбинируем тимлидов с тимлидами, продактов с продактами, etc.

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

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

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

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

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

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

Мастерская будет полезна:
для новых тимлидов/команд:
* погружение в продукт;
* помощь в фокусировке команды и передачи ключевого контекста работы;
для опытных тимлидов/команд:
* помощь в фокусировке команды и передачи ключевого контекста работы.

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

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

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

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

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

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

Если у вас есть ощущение, что команда может больше, этот мастер-класс для вас.

Я дам четыре инструмента (само)анализа, которые применяю в консалтинге, когда провожу аудиты компаний и команд. Инструменты основаны на исследованиях компании Гугл, института Гэллоп, модели «Спиральной динамики» Грейвза и американских инструкциях по саботажу от 1943 года. :)

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

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

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

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

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

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

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

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

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

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

Матрица динамична и каждый раз расширяется, например, когда на рынке происходят существенные изменения, такие как запуск совершенно новых продуктов (например, цифровой рубль) или повышается доступность работы с Generative AI. Также матрица помогает команде отследить точки роста: например, если только один человек обладает уникальной компетенцией, резонно распространить ее еще на нескольких сотрудников, чтобы команда чувствовала себя еще более уверенно. Об остальных аспектах матрицы и ее актуализации — смотрите в интервью!

«Работающий продукт важнее исчерпывающей документации» гласит один из принципов Agile-манифеста. Действительно ли отказ от исчерпывающей документации на проекте ускоряет процесс создания продукта? Если да, то как выстроить процесс проектирования в такой команде и не потерять в качестве? Что в такой команде будет являться результатом работы аналитика? И какие сегодня наблюдаются тенденции в работе с документами?

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

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

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

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

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

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

1. Беспилотник как программно-аппаратный комплекс сенсоров и софта. Роль команды локализации в этом.
2. О том, как локализация превратилась в мультикоманду на стыке железа и софта.
3. При чем здесь калибровки, и почему этим занимается локализация.
4. Как команда локализации выступает интегратором компетенций в использовании измерений сенсоров в алгоритмах?
5. В чем заключается связь команды локализации и железа. Какое именно железо имеется ввиду. Почему самодостаточность команды локализации с точки зрения компетенций в железе и софте — это преимущество.
6. Как устроен процесс разработки и как это согласуется с правилом «не более 7 человек на 1 тимлида».

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

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

Расскажем, как в большинстве таск-трекеров организовать мониторинг реализации инженерных практик (Code review, тестирование, управление техническим долгом).

В докладе рассмотрим практические кейсы анализа метрик и конкретные планы изменений, которые улучшали показатели команды. Подойдет для таких систем, как Jira, Youtrack, Kaiten, Redmine, Asana и другие, где есть Cumulative Flow Diagram или аналоги.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В своем докладе отвечу на вопросы:
* Зачем крупным IТ-компаниям заниматься RnD?
* В какой момент RnD может появляться и как может выглядеть?
* Какие задачи могут стоять перед RnD-направлением?
* Как может происходить внедрение инноваций и как сделать этот процесс эффективным?

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

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

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

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

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

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

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

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

За прошлый год мы выросли в 1,5 раза и на ходу меняли организационную структуру, формируя новые группы. Перед нами встал логичный вопрос «Кто возглавит? Есть ли люди внутри или нужно идти искать на рынке?». В итоге мы выбрали в пользу внутренних кандидатов и почти одновременно вывели 8 молодых руководителей.

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

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

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

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

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

Звучит привлекательно, не правда ли?

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

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

Взаимодействие строится на нескольких уровнях.

Первый — функциональный. Я расскажу о том, как мы поддерживаем связь между продуктовыми/проектными командами и разными специалистами внутри них.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему так?

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

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

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

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

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

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

Мы придумали как создать «хранилище справочников», а уже из них, как из Lego, собирать базу знаний под конкретные цели.
В докладе расскажу о придуманной методологии и покажу, как мы её реализовали в Confluence.

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

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

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

Рассказ основывается на личном опыте запуска корпоративного поиска.

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

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

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

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

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

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

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

«Хочу всё задокументировать» — нормальное состояние тимлида. Мы все прекрасно понимаем, что хорошая внутренняя документация решает множество проблем команды разработки:
* структурирует внутренние коммуникации;
* снижает bus factor;
* удешевляет онбординг;
* снижает риски архитектурных ошибок при эволюции проекта.

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

Что значит «задокументировать»? Какой набор документов мы считаем необходимым и достаточным? Кто и как пишет эти документы?

Что значит «всё»? Как мы определяем необходимое «документационное покрытие» предметной области проекта?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результаты исследования будут представлены в докладе.

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