Доклады

База (8)

Как построить people management на данных, повысить вовлеченность разработчиков и сократить текучку на 10 п.п. всего за год

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

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

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

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

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

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

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

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

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

Делегирование для тимлида: как передавать другим свои задачи, если другие — программисты

Фёдор Борщёв

Федя и Самат

Когда программисты ставят задачи программистам — всё происходит по-особенному.

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

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

Построение эффективной команды через доверие

Владимир Черников

Технологический Центр Дойче Банка

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

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

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

Что делать, если ты стал тимлидом?

Максим Пудалов

Фонд Спутник

Доклад будет состоять из двух частей.

В первой я расскажу о ключевых вещах, без которых невозможно системное понимание роли тимлида, а именно: чем отличается тимлид от Project Manager’a, что такое инженерный менеджмент и что такое конечный продукт и как он изменяется.

Во второй я поделюсь наработанным практиками. Обещаю выдать много конкретики о том, как работать с проектом, с командой, с Product Owner’ом или Product Manager’ом. И все это на реальных кейсах и опыте :)

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

У меня сгорают люди — борьба с выгоранием себя и сотрудников

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

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

Усталость не проходит, прокрастинация, неохота работать, скучно? "Кончилось топливо"? Хорошая новость — у тебя нет внутри топлива. Эти ощущения — следствие неверной эксплуатации своего мозга. Расскажу, как починить!

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

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

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

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

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

Оптимизируем время команды. Как непрерывно и эффективно развивать команду, используя ИПР, внедрять новые проекты, не проседая по основным активностям

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

Росгосстрах

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

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

Сегодня мы узнаем:
* что такое индивидуальный план развития (ИПР);
* как за счёт построения процессов в команде можно вести и контролировать ИПР, не проседая по основным активностям с применением таких инструментов, как NAP, Kanban, jira timesheet.

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

Кругозор (10)

Языки разработки процесcов

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

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

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

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

Обсудим, что человечество придумало для понимания, разработки и сопровождения "киборг"-систем.

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

С корабля к единорогам. Тонкости перехода

Татьяна Крат

Почтатех

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

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

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

Разбираемся со стажировками: как, зачем и почему?

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

Но что такое стажировка? Кто такой стажер? Где его найти? Как быть, если приходящие студенты "ничего не знают"?

В своём выступлении я поделюсь опытом Санкт-Петербургского центра разработок Dell Technologies в выстраивании нашей стажерской программы, более 10 лет приносящей высокий уровень конверсии стажеров в инженеры (более 85%).

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

Почему проектный подход не работает в IT

В среде IT распространено мнение, что проектный подход, PMBOK — тяжелая, но работающая штука. И потому в случае "серьезных проектов" стоит к нему обращаться, а если руководитель говорит о каких-то практиках, ссылаясь на проектный подход, то к этому тоже стоит отнестись с уважением. К сожалению, это — заблуждение. Регламенты проектного подхода, RUP и PMBOK были в 1990-е разработаны для того, чтобы обеспечить гарантированный успех проекта, пусть ценой тяжелых процедур. Но это не дало гарантий, успешность проектов осталась примерно на прежнем уровне. И именно поэтому появились Agile-методы, признающие приоритет человеческого фактора над процедурами. С тех пор вышло несколько версий PMBOK, в которых пытались достичь успеха, но без успеха, и в результате сейчас PMI сертифицирует по Agile-методам.

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

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

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

Круглый стол "Наем в команду, а не в компанию"

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

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

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

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

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

Алла Царьгородская

Лаборатория Касперского

Если ты тимлид, то рано или поздно ты обязательно окажешься в такой жизненной ситуации: работает команда, работает, приносит результат своей целевой аудитории. Но жизнь не стоит на месте, компания развивается, появляются новые тренды, и вот это вот всё — словом, назрела потребность в изменениях, в крупных изменениях. И неудовлетворенность текущей ситуацией может исходить как от некоторых членов команды, так и от стейкхолдеров. А ты, в свою очередь, поймешь, что на 100% привычными тебе управленческими техниками тут не обойтись.

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

В своем докладе я расскажу про ту модель внедрения изменений, которую мы с коллегами путем проб и ошибок выстроили в нашем отделе разработки технической документации в ДИТ Лаборатории Касперского, чтобы переехать с одного инструмента (от связки MS Word + MS SharePoint) на другой (Atlassian Confluence), успешно внедрить данные изменения и вести эффективную коммуникацию со всеми (многочисленными!) заинтересованными сторонами. Сейчас, когда прошел год "полета" на новом решении, уже можно оглянуться назад и посмотреть, какие и где мы совершили ошибки, а где и почему мы справились на “отлично”.


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

Как выстроить работу отделов R&D и Customer Care в режиме win-win

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

Если ваш продукт, как и наш, технически сложный, отделу Customer Care (или техподдержке, если проще) требуется консультация со стороны разработчиков, как (правильно) помочь клиенту. Ребята приходят к разработчикам раз, два, десять, сто. Если не взять в свои руки процесс взаимодействия отделов, то разбор вопросов техподдержки естественным образом займет всё время разработчиков.

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

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

Как балансировать творческий процесс и бюрократию: мастерство канатоходца

Иван Ямщиков

Лаборатория ЛЕЯ | Яндекс | ВШЭ

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

Я попробую рассказать о нескольких простых идеях, при помощи которых можно балансировать между творчеством и бюрократией. Я проиллюстрирую свой рассказ примерами из работы в науке (в Высшей Школе Экономики и в Институте Макса Планка), в индустрии (в Яндексе, SkillFactory и ABBYY) и даже в небольшом и странном пет-проджекте — подкасте "Проветримся!".

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

Круглый стол "Инструменты контроля работы команды. Работает ли инструментальный контроль или нужно жить по понятиям"

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

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

В рамках панельной дискуссии хочется пообщаться на темы:
* Стоит ли использовать инструментальные средств контроля за сотрудниками.
* Успешные и неуспешные кейсы применения подобных практик.
* Есть ли альтернативные подходы к контролю исполнения работы или вообще не стоит заниматься этой деятельностью?

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

Как developer relations формируют бренд работодателя и зачем это вам

В докладе разберемся, почему в IT-среде понятие developer relations неотделимо от бренда работодателя и как DevRel им управляет.

* Почему IT-компаниям критически важен бренд работодателя;
* где искать собственный ответ на вопрос “какую задачу мы решаем, нанимая DevRel'а?”;
* как именно DevRel формирует сильный бренд: инструменты, форматы, каналы;
* корпоративная культура, удержание персонала, профилактика профвыгорания, прозрачность внутренних коммуникаций и другие зоны влияния DevRel'а;
* как для компании выглядит польза от сильного IT-бренда работодателя.

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

Оптимизируй себя (13)

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

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

Приоритизация не работает.

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

Так продолжается день изо дня, никакого просвета, никакой ясности.

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

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

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

Как тимлиду стать СТО

В этом докладе вы узнаете:
1. какие есть типичные карьерные сценарии перехода от роли тимлида к СТО;
2. на что обращают внимание работодатели при выборе СТО;
3. какие типичные карьерные ошибки совершают молодые руководители.

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

Пошаговый алгоритм старта проекта

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

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

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

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

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

Тимлид как интервьюер

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

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

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

Карьерный антирост в IT. Взгляд с обеих сторон

Елена Ролина

Альфа-Банк

* Опыт перехода на другую должность с позиции head of qa: хронология событий;
* когда наступает "тот самый момент", как распознать и как правильно подойти к решению задачи;
* какие факторы необходимо учесть при принятии решения;
* синдром самозванца в действии: как бороться?
* какие главные недостатки и преимущества удалось сформулировать по итогам такого опыта?
* главные ошибки, которые пришлось переделывать в преимущества;
* взгляд с другой стороны — нанимаю ли я бывших руководителей и на что смотрю в первую очередь?

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

«Отцы и дети» в IT: часики-то тикают

Тому, что мы сейчас понимаем под «IT-отраслью» примерно 20 лет. Порассуждаем о том, что такое айтишники «под 40» и «за 20», какие трудности могут возникать при их встрече на одной территории и действительно ли они очень разные.

Речь пойдет о том, как:
* увидеть в себе и своей команде ценностный конфликт;
* понять, почему он может сильно осложнить работу;
* не перепутать его ни с чем другим;
* помочь его решить себе и команде.
и, главное, — что со всем этим делать лиду, если ему уже не 20, ещё не 40, но тоже почему-то штормит?

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

Физкультура как инструмент тюнинга личной эффективности

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

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

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

Корни прокрастинации

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

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

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

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

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

Как управлять "без управления"

Евгений Харченко

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

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

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

Познакомлю с моделью servant leadership и расскажу, как это применять.

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

(Без)душный менеджмент, или Как получать удовольствие от работы

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

Выворачиваем всё наизнанку и говорим о том, как мотивировать(ся) на работе, будучи менеджером.

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

Как расти менеджерам на примере менеджерской линейки Авито

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

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

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

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

Софья Бреева

Утконос Онлайн

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

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

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

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

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

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

СберМаркет

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

Есть рабочие практичные алгоритмы, как это можно исправить!

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

И суммируем всё в единый фреймворк построения взаимовыгодных синергичных отношений с руководителем и компанией!

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

Оптимизируй свою команду (21)

Звёзды в IT-команде: зачем, сколько стоят, как удержать

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

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

В рассказе только живой опыт и практика работы с командами из VK.

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

Питательная среда для качественной внутренней коммуникации

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

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

Покажи мне свой Git, и я скажу, кто ты

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

С момента основания Evrone в 2008 году мы всегда были полностью удаленной заказной разработкой. И сейчас, когда на удаленку перешли все, мы смотрим на появляющиеся в мире процессы через призму того, что сами делаем уже много лет. Один из новых подходов, о котором я расскажу, ищет закономерности в git-активности разработчиков. На примере большого open source-проекта я покажу, как динамика пулл-реквестов, коммитов и комментариев рисует портреты разработчиков: "снайперов", "скаутов", "плюшкиных". Как можно по репозиторию команды увидеть формирование "островов знаний" или формального отношения к code review. Поделюсь нашим опытом: как не только диагностировать те или иные проблемы, но и решать их с разработчиками, которые работают на другом конце земного шара.

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

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

Анна Терентьева

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

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

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

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

Про что доклад:
* Создание доверительной атмосферы в коллективе, где 100 человек работают удалённо из разных городов и стран.
* Повышение открытости в команде от "нажалуюсь руководителю и промолчу" до "решу вопрос с коллегой напрямую": разбор кейсов в игровом формате.
* Объединение коллег в мощное комьюнити с единой целью (за счёт чего продуктивность команд растёт).

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

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

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

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

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

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

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

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

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

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

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

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

Компетенции в стриме: сохранить и приумножить

Василий Соболев

Газпромбанк

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

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

"Прогреваем кэш" мозга: что дает разработчикам власть над кодом и как ее (не) потерять

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

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

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

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

Иногда вместо того, чтобы попытаться решить с вами все свои проблемы, сотруднику проще "обнулиться" и сменить работу.

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

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

Тезисы:
* Поддержание мотивации сотрудников и заблаговременное выявление проблем.
* Как можно отслеживать градус напряженности в команде.
* Какие инструменты можно использовать для снижения напряженности.
* Как правильно корректировать поведение сотрудника, чтобы он воспринял серьезность ситуации и не нарушал ваши договоренности.
* Как не надо делать, если вы не хотите растерять членов команды.
* Как со всем этим могут помогать HR, KPI, опросы 360º и self-review.

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

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

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

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

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

Что делать, если команда выросла в 10 раз

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

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

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

Ставим адаптацию новичков на поток при помощи наставников

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

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

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

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

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


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

Культурный ТимЛид: роль и место в формировании культуры

* Расскажу, как меняется культура в ИТ-компании с ростом от 30 до 1200 человек.
* Покажу путь ТимЛида и его роль в формировании культуры ИТ, как роль меняется с ростом.
* Расскажу нашу историю роста и формирования культуры на стыке ИТ и медицины.
* Проговорим принципы, на которых основывается наша текущая культура.
* Пройдем этапы формирования культуры.

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

Наем в продуктовые команды: что делать, если ты не бигтех?

Хотя тема найма и является весьма заезженной, а активности, котоdevrel-активности становятся всё более массовыми, наем остаётся болевой точкой для очень многих. При этом в публичном поле можно встретить большое количество best practices, которые довольно сложно применять, если ты не Яндекс и не Google. Особенно это касается продуктовых команд, которым тяжело предложить кандидату какую-нибудь уникальную технологию, разработкой или использованием которой можно обогатить резюме. Тем не менее им точно есть что предложить рынку!

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

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

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

Ветер перемен: методы работы с изменениями в команде

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

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

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

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

На расстоянии плевка: специфика работы лидом во внутренней разработке

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

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

Система онбординга комфорт-класса

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

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

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

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

Осознанность и автономность. Как сделать команду-автопилот

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

Разберем несколько подходов/фреймворков работы с командой: целеполагание, активное слушание, модель РОСТ, поощрение инициативы.

В целом это позволит иначе посмотреть на процесс и управление командой и продуктом как C-level-руководителям, так и миддл-менеджерам: он работает в обе стороны (то есть его можно применять как с позиции “начальника”, так и в роли “подчиненного”).

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

Как заставить людей меняться

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

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

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

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

Любовь Гудкова

Индивидуальный предприниматель

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

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

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

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

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

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

TechTalks (3)

Опыт построения комьюнити бэкенд-разработчиков в Газпромбанке

Сергей Богданов

Газпромбанк

* Цели построения комьюнити;
* проблемы при реализации;
* важные компоненты на начальных этапах построения;
* практические советы по реализации и развитию комьюнити.

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

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

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

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

Как не допустить технологического дефолта

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

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

Митапы и мастер-классы (13)

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

Анастасия Ливенская

МВидео-Эльдорадо

Меня зовут Ася, я Agile-коуч, работаю с продуктовыми командами. Я активно использую для фасилитации встреч освобождающие структуры и вижу, как круто они меняют коммуникацию в команде и как качественно влияют на встречи.

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

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

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

5 точек управления командой

Александр Орлов

Стратоплан

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

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

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

Программа мастер-класса:
* Модель Такмана (FSNP+R).
* Модель Ленсиони (5 пороков команды).
* Кейс «Пять проблем Екатерины».
* Работа группы: макропроцессы повторяются в микропроцессах.
* План действий в вашей команде.

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

Инженерный подход к коммуникациям

Вирна Штерн

Aletheia Digital

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

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

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

Вовлекающее руководство на рабочих встречах — фасилитация

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

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

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

Мастер-класс "Как заставить людей меняться"

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

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

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

Команда как инженерная конструкция

Вирна Штерн

Aletheia Digital

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

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

Один результат на две команды

Вирна Штерн

Aletheia Digital

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

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

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

Вирна Штерн

Aletheia Digital

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

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

Featureban — игра-симуляция для демонстрации работы поточных систем

Featureban — игровая симуляция, которая показывает механику и преимущества вытягивающих систем.

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

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

Планирование командной работы

Вирна Штерн

Aletheia Digital

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

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

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

Светлана Болсуновская

Deutsche Telekom IT Solutions, Agilelab

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

Участники мастер-класса смогут усилить свои навыки:
1) распознавать непродуктивное поведение на встречах;
2) понимать возможные причины его возникновения;
3) эффективно переводить непродуктивное поведение в конструктив, когда это необходимо.

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

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

Governance meeting — помогаем команде принимать сложные решения

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

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

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

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

Соревнование команд на победителя в интеллектуально-психологической игре с цифрами и ставками

Вирна Штерн

Aletheia Digital

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

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

KnowledgeConf: Джуны и онбординг (6)

Создаем культуру доверия для обмена знаниями и ошибками

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

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

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

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

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

Онбординг для социофобушков

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

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

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

Онбординг новичков: как компании влюбить в себя сотрудника

- «Добро пожаловать в команду!» — кому и зачем нужен онбординг.
- Немного про Пребординг, зачем он нужен и чем отличается от Онбординга.
- Онбординг сотрудников в IT-компании и не только: онбординг как бизнес-процесс, роли и артефакты.

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

Быстрый старт разработчиков в Яндекс.Еде

Илья Шишков

Яндекс.Еда

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

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

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

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

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

На рынке не так много QA-специалистов, да и вообще айтишников, поэтому, когда мы столкнулись с нехваткой коллег, — решились на эксперимент, где взяли в команду 28 junior-спецов и вырастили 22 из них до middle за полгода.

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

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

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

Квест на входе: как новички в HFLabs онбордят сами себя

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

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

Группы вопросов, с которыми сталкивается каждый новичок:
1. Организационные. Где взять блокнот, ручку, кто мне выдаст компьютер?
2. Человеческие. Кто есть кто в команде, у кого что можно спрашивать?
3. Погружение в проект/продукт. Какими задачами я буду заниматься в ближайшее время? А какие процессы взаимодействия есть?
4. Развитие. Куда развиваться дальше? Кто со мной обсудит вопросы развития?

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

У квеста версия уже 2.0, первая версия пожила пару лет, мы собрали метрики и обратную связь, нашли точки отказа. Улучшили квест. Получили версию 2.0, которая используется 1,5 года. Но мы идем и к ее улучшению.

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

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

KnowledgeConf: Эксперты, bus factor (9)

Создание Body of Knowledge как процесс: от анализа потерь до укрощения экспертов

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

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

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

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

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

15 приемов, чтобы задать вопрос профессионалу

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

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

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

Dendron: Zettelkasten на стероидах

В докладе я расскажу про Dendron — это подход и инструмент для ведения базы знаний: https://www.dendron.so. Я сам до этого пользовался Foam и сменил его на Dendron, в докладе расскажу почему.

Расскажу, в чем его особенности и отличия от похожих инструментов: Roam, Obsidian, Foam и прочих.

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

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

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

Извлечение ошибок профессиональной деятельности на интервью с экспертом

Николай Сенин

Независимый исследователь

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

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

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

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

“Твоя моя не понимай”: когнитивные аспекты обмена знаниями в мире онлайн

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

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

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

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

Учимся задавать вопросы осмысленно

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

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

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

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

Заходят тимлид, менеджер и инженер в бар, а там матрица компетенций

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

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

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

Зачем я разбирала архив блокнотов за 10 лет: экзистенциальная сторона менеджмента знаний

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

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

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

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

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

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

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

KnowledgeConf: Гильдии и масштабирование знаний (11)

Рабочий процесс как процесс накопления знаний

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

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

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

Process Decision Record — простой инструмент постепенной рационализации процессов

Виталий Шароватов

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

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

* Можете ли вы ответить, насколько эффективны ваши процессы?
* Можете ли ответить, эффективны ли они вообще?
* А что вы подразумеваете под эффективностью?
* Решает ли каждая процессная активность какую-то проблему?
* Актуально ли ещё это решение?
* Можете ли хотя бы ответить, для чего какая активность была внедрена?
* А понимают ли ценность каждой активности ваши коллеги или члены команды?
* Знакомо ли вам, когда спрашиваете СТО "а почему у нас тестирование так работает?", а вам отвечают "так сложилось"?
* Бывает ли, что кажется, что какая-то процессная активность появилась просто потому, что "консультант так сказал", а сути не понимает никто?
* А что, если какие-то процессные активности были добавлены, когда команда состояла из 4 сеньоров-фулстеков, а сейчас в ней уже 12 специалистов разного уровня и разных специальностей?

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

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

Но можно же есть слона по частям 🙂

PDR — Process decision record — подход, дающий возможность любой команде комфортно съесть слона, — "рационализация процессов" по частям.

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

Документация — это про деньги

Семён Факторович

DocFactor (documentat.io)

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

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

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

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

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

Гильдии как способ взаимодействия в большой и растущей команде

Иван Миронов

Перекресток Vprok.ru

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

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

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

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

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

"Клуб Франклина" — внутренний клуб компетенций

Иван Преснов

Купибилет.ру

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

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

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

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

Позитивное управление контентом: как выстроить партнерские отношения с коллегами

Алиса Комиссарова

Positive Technologies

Ирина Рыбникова

Positive Technologies

Работа с контентом наиболее эффективна, когда она выстроена централизованно.

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

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

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

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

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

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

Как я принес воркшопы в команду Tarantool

Tarantool — не только база данных. Это полезная штука, но ее трудно объяснить в двух словах. И не только нашим клиентам, но даже собственным стажерам. Мы в VK помогаем строить решения на базе Tarantool, так что объяснять надо много и часто.

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

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

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

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

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

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

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

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

Почитать немного о том, чем команда Knowledge Management занимается в Exness, можно в моих статьях на Хабре:
https://habr.com/ru/company/exness/blog/505470/
https://habr.com/ru/company/exness/blog/515056/
https://habr.com/ru/company/exness/blog/574848/

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

Ландшафт коммуникаций

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

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

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

Строим внутренние и внешние сообщества

Алексей Долгушев

Деврел-бюро

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

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

Статьи для базы знаний — отдельная боль. Пишут единицы, да и то нерегулярно.

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

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

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

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

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

Спойлер: будем вдоль и поперёк эксплуатировать деврел-инструментарий.

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