Доклады

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

В докладе поговорим о том, как создать культуру обмена знаниями и опытом:
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+ кейсов: где какие практики срабатывали в тех компаниях, с которыми я имел возможность работать и кого наблюдал.

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

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