Доклады

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

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

Чаще всего дело в нас. И хорошая новость в том, что раз дело в нас, то это можно изменить.

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

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

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

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

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

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

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

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

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

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

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

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

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

Я три года работаю руководителем проектов в Холдинге T1 на проектах крупного банка, входящего топ-10. У меня нет своей команды и прямых подчиненных. Чтобы успешно закрывать проекты, мне необходимо привлекать и координировать ресурсы большого числа людей и команд. В этом направлении я накопила большой практический опыт и хочу им поделиться.

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

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

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

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

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

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

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

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

Увидимся на докладе!

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

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

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

One-to-One Максима Дорофеева и Романа Ивлиева — беседа в формате двух точек зрения. В развитие первой дискуссии про обучение джунов обратим свои мысли и взоры на более старших товарищей.

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

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

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

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

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

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

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

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

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

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

Я расскажу вам о том, как собрать внутри компании команду и «вытянуть» штучный инфраструктурный проект для российского рынка — запустить отечественную IaaS-платформу. Не просто собрать команду, но и замотивировать, не растерять и успешно завершить проект!

За время доклада вы узнаете, что предпринять, когда: цель есть, команды нет, путь не определён, ресурсы не подвезли, дедлайн скоро. Что делаем?

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

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

Сейчас в компании работает 50+ человек.
У нас около 50 клиентов из большого энтерпрайза и большие сложные проекты.

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

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

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

Впервые на площадке TeamLead++ Conf пройдет особенное мероприятие, сочетающее пользу и азарт, — «Тимлид-контест».

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

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

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

Спойлер: по идее не должно пострадать ни одного тимлида. Но это не точно.

Ведущий «Тимлид-контест» — Алексей Обровец.

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

С профессором РАН, астрономом и популяризатором науки Дмитрием Вибе поговорим о том, как обстоят дела с предсказуемостью и порядком в астрономии. В частности, разберём, почему телескоп Джеймса Уэбба задержался с запуском более чем на десятилетие и вырос по бюджету в 20 раз, и почему диаметр зеркала Ошеломляюще большого телескопа сдулся со 100 метров до 39.

Меня зовут Михаил Семенов, я лидер продукта Platform V Pangolin в СберТехе. Pangolin — это реляционная СУБД, созданная нами для высоконагруженных приложений. В 2019 году я пришел в СберТех создавать этот продукт с нуля — и с нуля же набирал себе команду. Сейчас Pangolin делает больше 100 человек, а к концу года нас должно стать 120.

Руководителям команд, которые растут очень быстро (а это часто происходит в IT) неизбежно приходится менять подходы. И на этом пути можно собрать кучу грабель. Ведь в группе на 10-30 разработчиков — одни процессы, а в команде на 50-100+ человек — совсем другие. Расскажу о том, какие типичные грабли я успел собрать, перестраиваясь на управление большой командой, и какие решения оказались самыми работающими.

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

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

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

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

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

1. Свобода воли — миф или реальность? Если реальность, почему мы бываем недовольны своим поведением.
2. Психика как объект — зачем нужна, к чему стремится.
3. Механизмы психики, которыми она пользуется, чтобы достичь целей из пункта 2.
4. Структура проблемы / травмы.
5. Как современная терапия работает с этим, учитывая первые 4 пункта.
6. Что можно сделать самостоятельно для изменения своего поведения или состояния.
7. Почему другие себя так ведут? Можно ли повлиять на чужую мотивацию, чужое поведение? Как?
8. Как сделать так, чтобы ты и команда лучше перформили, а климат в коллективе был лучше.

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

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

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

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

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

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

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

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

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

Зачем тимлиду самому измерять крутость своей тимлидскости:
* планирование своего развития как тимлида;
* получение обратной связи от команды и кросс-функциональных подразделений;
* продвижение по карьерной лестнице;
* аргументация рейза ;)

«Разработка — это круто, ну, а менеджмент — отстой» — к сожалению, с таким пониманием в IT-мире приходится сталкиваться до сих пор.

Когда способный тимлид отмахивается от разговоров про дальнейший рост, а разработчики просят не рассказывать им «вот это всё» (менеджерское) невольно задаёшься вопросом — а ту ли дорогу я выбираю, когда решаю расти дальше? Именно на этот вопрос я постараюсь ответить в своём докладе — расскажу про свой путь в мидл-менеджмент; поделюсь сложностями и инсайтами, которые встретил; подсвечу ловушки, в которые угодил сам.

Ура! Я — тимлид! Должность есть, обязанности есть, знания есть. Но почему, когда я говорю, что надо делать, или даже предлагаю что-то дельное, вечно какие-то возражения, сомнения, не готовы меня воспринимать лидом, и, вообще, меня надо слушаться!! Нет, не слушаются и не особо слышат. Почему?

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

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

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

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

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

В рассказе буду опираться на научные исследования. Заряженную воду и календари желаний оставлю на следующий раз.

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

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

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

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

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

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

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

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

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

Проблема в том, что управление — это не личное желание, не опыт, не умение стратегировать и тем более не набор практических навыков. Это все вместе и еще что-то! И в этом наборе вам может не хватить какого-то элемента, который вы не видите (или не хотите видеть!

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

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

Я поделюсь научными исследованиями такого явления как zoom-выгорание и практическим опытом, как мне самой удается проводить более 20 онлайн-встреч в неделю и сохранять продуктивность.

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

А еще дам короткие упражнения для снятия стресса / повышения бодрости до и после встреч, чтобы были силы и на другие задачи!

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

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

Какие преимущества и риски в процессе стажировок? Мы выяснили опытным путем, когда создали проект «Нашкодим».

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

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

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

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

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

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

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

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

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

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

Чаще всего в таких случаях начинают внедрять OKR и KPI или чинить, ставя «амбициозные цели». Но такие изменения не приносят нужного результата: демотивируют команду, вызывают сопротивление «системе» и нередко приводят к увольнениям после бонуса.

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

Расскажу, как мы продуктовым и технологическим подходами объединили три разных витрины Мой МТС, ставя перед собой цели по:
* достижению консистентности данных;
* улучшению t2m;
* повышению надежности решений;
* снижению количества сотрудников.

Я хочу поговорить о концепции «Лидера-Слуги» — модели, которая ориентирована на поддержку и ставит людей в центр. За последние три года внедрение этого подхода в корпоративной среде показало значительные положительные изменения: рост доверия и усиление командной сплочённости. Хотя адаптация к этому стилю требует времени и не всегда проходит быстро, это важный шаг к созданию самоорганизованного и гармоничного коллектива.

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

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

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

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

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

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

VK Клипы – сервис коротких вертикальных видео, интегрированный в социальную сеть ВКонтакте. За 4 года его становления было все: от быстрого старта во времена пандемии и запуска отдельного приложения за три месяца после до интеграции с другими контентными сервисами ВКонтакте и 2 миллиардов просмотров клипов ежедневно. Каждый раз происходило изменение запроса бизнеса, и под него необходима была адаптация.

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

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

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

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

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

Старина Эдд был таки прав: если есть способ сделать что-то неправильно, человек именно так и сделает!

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

Мы будем говорить:
* о рисках, об их вероятности и неизбежности и о том, как риски ведут к ненадежности;
* о неубывающей неопределенности и эффекте «испорченного телефона» в управлении;
* о математических основах управления рисками и надежностью;
* о способах понижения локальной энтропии в коллективе через управление рисками и о методах такого управления;
* и, конечно же, о законах Мерфи!

Я слышал от разных людей, в том числе на Teamlead Conf, что они пробовали Story Points и разочаровались в них.

Мне стала интересна причина. Что же людей не устраивает? В этом докладе я постараюсь дать ответ на этот вопрос. А конкретно мы разберем:
1. зачем, вообще, оценивать задачи? Есть ли альтернативы? Спойлер: есть;
2. способы оценки: человеко-часы, футболки и Story Points. Плюсы и минусы;
3. антипаттерны при использовании Story Points;
4. мои рекомендации по тому, как внедрить Story Points, и нужно ли это делать.

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

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

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

Я расскажу о комплексном подходе к решению этих задач и поделюсь своим опытом. Масштаб — 10 кросс-функциональных команд, общее количество сотрудников — 100+. За основу беру Performance review, который задает цикличность и сроки. На него нанизываются все остальные процессы и инструменты: карта персонала (текущая картинка, траектория), карта рисков, ИПРы, план пересмотров и т.д.

Такой подход позволяет:
1. повышать уровень осознанности тимлида и его понимание, что происходит в команде: баланс команды, Bus-фактор, заменяемость сотрудников, траектории развития сотрудников, подсвечивать потенциальные вакансии;
2. планировать сложные траектории развития сотрудников, например, «обмены» между командами;
3. работать с групповыми рисками. Например, когда существуют различные невысокие риски, но у большого количества сотрудников. Либо один общий высокий риск, который затрагивает несколько человек в разных командах;
4. отвечать на вопрос «из кого собирать новую команду», в первую очередь — её основное ядро, оценивая при этом последствия для «команды-донора».

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

* Автоматизация старых процессов дает только дорогие старые процессы, но не сокращает потери.
* Разработчики против своего спасения, как работать с change management и негативом к любым трансформациям.
* Итоги — на 20% быстрее. Где мы так тормозили?
* Вредные советы: хотите заруинить трансформацию — спросите меня как.

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

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

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

Что станет делать владелец продукта или менеджер в такой ситуации? Конечно, нанимать команду профессионалов. По данным Хабр Карьеры за первое полугодие 2024 года, 30% вакансий — это senior-квалификация, и 55% — это middle.

Специалистов, которые имеют высокую квалификацию и имеют за плечами огромный опыт, иногда называют «звездами». Работа со «звездой» в команде не только даёт плюсы в виде высокой экспертизы, но также приносит минусы, которые перетекают в риски.

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

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

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

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

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

В своем докладе я расскажу, как переосмыслил четыре простых действия: поиск, наем, адаптацию и развитие. Как осознанность в них позволила мне на сложном и перегретом рынке 1С за один год вырастить команду управленцев в 7 (!) раз. И почему в долгосрочной перспективе мне не грозит текучка кадров.

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

Высокая вовлеченность сотрудников невозможна без активного участия лидеров. Лидеры должны уделять время на общение и демонстрировать заинтересованность в своих сотрудниках. Без личной вовлеченности руководителей невозможно достичь значимых результатов.

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

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

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

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

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

А как быть, если я ошибся с выбором тимлида, но понял это слишком поздно?

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

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

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

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

Мы будем конструировать, общаться, соревноваться и делиться инсайтами.

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

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

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

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

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

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

Если вы столкнулись с такими сложностями, попробовали с ними справиться, но не оч. получилось — приходите на мастер-класс.

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

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

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

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

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

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

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

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

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

На нашем воркшопе будем учиться принимать Обратную связь.

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

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

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

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

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

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

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

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

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

* Мозг человека & компьютер — сходства и различия.
* Грабли в общении, на которые все наступают.
* Как доносить свои мысли, чтобы они заходили — модель SCARF.
* Практическая отработка компонентов модели.

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

Вы уже многократно пробовали трансформировать процессы, но они все никак не меняются? На воркшопе мы разберём именно ваш кейс!

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

Вам останется только реализовать этот план!

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

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

Если такие антипаттерны принятия решений вам знакомы, и вы хотите понять и попрактиковать:
* как принимать рациональные решения быстро и эффективно,
* как принимать решения в условиях неопределенности,
* как перестать использовать голосование большинством как основной метод принятия решения в команде,
приходите на воркшоп — мы разберем 25+ техник принятия решений командой на кейсах и попрактикуемся в их применении.

Главная точка роста любой команды — компетенции её руководителя.

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

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

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

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

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

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

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

На TechTalk’е расскажу о том, как «нанять» себе такого Virtual TeamMate’а, с чего начать, что взять за основу, какие есть успешные кейсы, а куда лучше не ходить, чтобы не создать «Франкенштейна».

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

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

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

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

* Расскажу про концепцию Moving Motivators из Management 3.0 как эффективное средство стимулирования мотивации сотрудников в команде;
* представлю варианты адаптации Moving Motivators под уникальные потребности сотрудников и контекст команды для достижения оптимальных результатов;
* поделюсь, как мы адаптировали этот инструмент на для наших 1:1;
* расскажу про успешное использование Moving Motivators в реальных рабочих ситуациях и их влияние на динамику и результативность работы.

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

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

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

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

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

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

Что делать с адаптацией, если число людей в проекте выросло с 4 до 50, а систем на поддержке — с 2 до 50+?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Как научить виртуального ассистента извлекать информацию из этой базы знаний и формулировать ответы на вопросы пользователей.
* Где хранить статьи.
* Как по ним искать.
* Как нарезать на тематические фрагменты и какие возникают при этом проблемы.

4. Как управлять затратами:
* использовать ли LLM и платить за каждый ответ;
* не использовать LLM (или использовать ограниченно).

5. Метрики и процесс дополнения базы знаний.

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

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

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

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

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

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

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

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

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

* Почему нам в отделе, строящем процессы для компании SM Lab, понадобилась матрица компетенций.
* Как мы, оттолкнувшись от нее, пошли дальше и создали полноценное комьюнити, а затем начали писать Индивидуальные планы развития.
* Как такая система помогает нам создавать большие проекты для компании.
* С какими сложностями сталкиваемся, какие проблемы решаем сейчас и что планируем.

1. Продуктовый подход помогает определить, за какую Базу Знаний готовы платить.
2. Я пришел на место человека, которому не удалось запустить Базу Знаний. Расскажу о том, как я учел его опыт и смог запустить продажи на внешнюю аудиторию.
3. Для разработки продукта необходимо назначить владельца и наделить его соответствующими полномочиями. Поделюсь своими наблюдениями о месте владельца Базы Знаний в организационной структуре компании.
4. Сложности в разработке Базы Знаний: нужно продумать UI/UX-решения и провести отдельный Cust Dev для процесса обновления Базы Знаний. Расскажу, как сделать Базу Знаний «живой», какие знания сохраняются, кто является ЦА и какие задачи они решают.
5. Роли внутри команды, отвечающей за Базу Знаний.
6. Сложности роли «хранителя»: работа с предметной областью, перевод знаний экспертов в доступную для всех методологию, фасилитация методологических встреч. Необходимые компетенции.
7. Решение конфликта между отделами: что добавлять в Базу Знаний, что нет и в каком виде.
8. Планы по развитию продукта — работа с разными клиентскими сегментами.

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

За последние 10 лет я прошёл стандартную эволюцию личной базы знаний: конспектировал на бумаге, на карточках, вёл разные тетради, создавал структуру в Word, развивал базу знаний в Notion, OneNote, iPad и в конце концов познакомился с Obsidian и Zettelkasten. Наши отношения были разными: временами я любил свои заметки, а временами хотелось всё удалить и начать заново.

В докладе я расскажу про этапы отношений с базой знаний:
* этап первичной одержимости. Это время, когда моя база знаний активно росла с 0 до 4500 заметок. Я расскажу, какие основные ошибки совершал и что посоветовал бы себе-начинающему, чтобы как можно раньше начать извлекать пользу из базы знаний и не допустить её превращения в кладбище заметок;
* этап переосмысления. Это время, когда я начал честно отвечать себе на вопрос: «А зачем мне база знаний? Для чего?» Здесь я рассказываю, почему удалил 1500 из 4500 заметок, по каким принципам перестроил структуру базы знаний и какие привычки внедрил для эффективной работы с информацией;
* этап использования базы знаний на 100% и усиления себя в разных сферах. Я расскажу о том, как в 2023 году начал экспериментировать с подключением LLM к базе знаний и как мой AI-ассистент помогает мне сегодня в личной жизни и работе.

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

В Додо и Дринкит большая команда поддержки клиентов — 500+ человек в 10+ командах. Все эти команды обрабатывают 750 000 обращений клиентов в чате, на горячей линии, соцсетях и практически любых источниках коммуникации, а помогают им менеджеры рекламаций, тренеры, тимлиды и другие команды.

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

Расскажу, как мы построили профессиональные сообщества, про нашу базу знаний и AI в ней, поделюсь лучшими практиками оптимизаций и улучшения системы знаний, воркшопы и Q&A-сессии, влияние этого всего на поддержку клиентов и бизнес в целом.

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

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

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

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

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

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

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

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

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

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

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

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

Domain-Driven Design — набор подходов к разработке, который, с одной стороны, на слуху, а с другой, к нему очень сложно подступиться. Есть большие книги (Эванс, Вернон), но далеко не все их читают и еще меньше людей читают их до конца. А даже и дочитав, могут упустить суть за обилием деталей.

Алексей в своем докладе раскроет основы DDD и даст рекомендации по погружению в тему.

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

Автор, который долгое время занимается темой защищенности сетей, а теперь помогает строить новую сеть доставки контента, разберет в докладе вопросы взаимодействия с CDN-сервисами, такие, как:
* быстродействие. Как отслеживать, что вас ускоряют, и насколько значимо это ускорение? Сценарии задержек и потери трафика у сервисов на базе anycast и GeoDNS;
* атаки на отказ (DoS, DDoS). Как злодей может использовать CDN для атаки на клиента? Выдержит ли CDN-сеть атаку — и что предпринять на своей стороне, если нет? Как мы решаем задачу защищенности своего сервиса;
* потребление ресурсов и затраты. В какой ситуации может кратно вырасти чек? Какие настройки на стороне источника влияют на отданный объем, полосу пропускания и число запросов? Сигналы и метрики, которые помогут предотвратить проблему;
* как держать яйца в разных корзинах? Использование нескольких CDN сразу. Или, может, пора поднять собственный распределенный кэш? В каких случаях такие подходы имеют смысл, и что для этого придется поменять в своей инфраструктуре?

Доклад исключительно практический, где на простых и понятных примерах разберем хитрые приёмы и шаблоны, которые могут использоваться при построении систем потоковой обработки информации (stream processing). В частности, разберем особенности Kafka и RabbitMQ. Это история о развитии нашего продукта, взлетах, а главное, падениях. Тут подробно разберем допущенные ошибки и принятые решения, как и почему они помогли устранить проблемы. Поговорим, почему так важно выбрать наиболее подходящий инструмент, а не следовать трендам вслепую. Как оказалось, несмотря на всю специфику нашего проекта, история совсем не уникальна, чем и должна быть привлекательна для слушателя.

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

В докладе расскажу о подходе к стабильности нашей Аналитической платформы.

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

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

Хочу поделиться опытом, как мы в Garage Eight привнесли в команду mob-programming и поддержали этой практикой экстремального программирования наш флип на Scrum. Расскажу, как заинтересовать команду погрузиться в такой подход разработки, какие болячки 100% вылезут и как с ними работать.

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

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

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

Но можно добиться таких тестов, которые действительно будут проверять код, действительно будут показывать его работоспособность. Для этого нужно каждый тест увидеть красным. А для этого, прежде чем писать функциональность, нужно написать тест. Это и есть разработка через тестирование, или TDD (test-driven development) — и именно этим мы займёмся на воркшопе.

Приходи, и мы вместе разберёмся, что такое TDD, как писать тесты так, чтобы им можно было верить и как рефакторить без страха.

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

Но работа с открытым кодом требует особых подходов и практик внутри компании. Поэтому для координации, наладки процессов и продвижения своих открытых проектов в зарубежных компаниях создают Open Source Program Office, OSPO.

В своем выступлении докладчик поделится опытом создания OSPO или комитета по открытому коду в российской компании-разработчике ПО. Александр взялся за эту задачу в Positive Technologies полтора года назад и за это время ощутил ее сложность во всей полноте. Он расскажет о непростом процессе культурного сдвига в сторону Open Source у разработчиков и их руководителей, о мозговых штурмах и выборе лучших практик открытой разработки. Докладчик также поделится полезными хитростями, которые помогают постепенно раскрутить маховик открытой разработки и достичь поставленных целей.

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

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

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

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