Доклады

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы управление знаниями перманентно приносило пользу, не вызывало боли у тех, кто им занимается, и негатива у тех, кто не понимает, зачем это все, нужно: а) вывести этот процесс из подполья и б) добавить активности по фиксации и переиспользованию знаний во все бизнес-процессы. Это звучит сложно и нереализуемо. Но на самом деле достаточно просто понять, что продукт мало просто создать — сам себя он не продаст и не поддержит. Это понимание должно возникнуть у менеджмента и дальше спуститься во все подразделения компании в виде конкретных 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+ кейсов: где какие практики срабатывали в тех компаниях, с которыми я имел возможность работать и кого наблюдал.

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

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