​​Что делать, если в команде проекта 5-10 человек, а тяжеловесные вики не подходят или слишком дороги? Notion is the answer!

Для небольших команд, которым не нужна поддержка макросов, сложной разметки, сложного разграничения прав, хорошо подойдет Notion, это сервис (веб-сайт и приложение) для организации контента и совместной работы. У Notion есть бизнес-режим, можно создавать проектные workspaces, вести роадмап, agile-борды, календари, списки задач, хранить полезную информацию, причем он поддерживает все нужные виды контента: текст, таблицы, изображения, мокапы интерфейсов, заметки, списки и другое.

У пользователя есть полная свобода в перетаскивании блоков на страницах и перетаскивании самих страниц в иерархии. Блок — ключевой элемент архитектуры Notion, он может принимать любую форму. Также доступны готовые шаблоны страниц, например, Vision, Coding Guidelines, Employee Onboarding, Team Home, Blog Post, Design Spec, Editorial Calendar, даже CRM.

Ограничения и минусы

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

Нет интеграции с таск-трекерами, например, JIRA.

Плюсы

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

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

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

Evernote обходится дороже, к тому же, он скореезаметочник, а Notion — приложение для совместной работы с поддержкой большего числа типов контента. Другие альтернативы — Google Docs, Trello, Realtimeboard, Notion как бы пытается совместить их все с определенным успехом.

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

​​Долг компетенций

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

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

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

Уход специалиста сразу превращает такой код в "legacy", "not invented here", "to rewrite", "так исторически сложилось" и прочие штампы. Усложняется поддержка и, как правило, ухудшается точность декомпозиции задач при работе с таким кодом, поскольку не влезая в детали сложно оценить реальный объем изменений.

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

Что снижает долг компетенций

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

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

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

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

Еще по теме
http://www.leanway.no/a-deeper-look-at-competence-debt/
http://www.julianbrowne.com/article/competence-debt

​​OneBar — стартап, который предлагает создавать базу знаний вашей команды с помощью парсинга разговоров в Slack

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

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

Что предлагает OneBar — решение подключается к Slack API, парсит разговоры разработчиков, ищет в них вопросы и ответы на них и создает подобие внутреннего StackOverflow. Затем, при наличии информации бот также сможет рекомендовать экспертов в том или ином вопросе, встревать в разговор и предлагать ссылки на схожие ответы со словами "возможно, вы ищете это".

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

Бот использует Natural Language Processing, он умеет выделять в тексте сущности и группировать их по темам.

Сервис написан на Python и JavaScript, поисковый индекс на Elastic, используется API Slack и Google. Есть планы посмотреть в сторону Телеграм, но на практике — Slack самый популярный айтишный мессенджер, поэтому было принято решение сосредоточиться на нем.

Монетизировать сервис разработчики планируют не по количеству пользователей, а по вкладу в базу знаний, то есть по числу созданных ботом ответов на вопросы (100, 1000 и более 1000).

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

На Лайфхакер вышла статья про разные стили познания.

Почитать ее можно тут: https://lifehacker.ru/stili-obucheniya/

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

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

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

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

Смотреть: https://vimeo.com/156754695

​​Как считать/выявлять bus factor на проекте

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

Проще – это мера сосредоточения информации о системе, проекте. Самый критический фактор автобуса — это единица.

Термин, конечно, не новый, он появился в сфере управления бизнесом еще в 1998 году.

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

Как посчитать фактор автобуса? Представим, у вас есть 30 человек на проекте, который занимается веб-разработкой, в нем есть API, фронтенд и дизайн, без деталей. 5 человек разрабатывают API, 10 – фронтенд и еще 5 занимаются дизайном, ваш фактор автобуса – 5.

Потенциальные сигналы о наличии фактора автобуса:

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

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

- CI/CD на проекте настраивал один человек, все просят его добавить, изменить pipeline, но никто не вдается в детали.

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

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

Можно ли выявить его автоматически?

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

В дополнение
Также советую посмотреть выступление Артема Быковца Bus Factor и риски его игнорирования.

​​Кому в организации подчиняется специалист по управлению знаниями

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

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

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

Делюсь с вами ставшим очень полезным для меня материалом об адаптации новых сотрудников в компании "Флант"

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

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

Ссылка: https://habr.com/company/flant/blog/419051/

Продолжаем неделю онбординга на канале, теперь на очереди материал от Avito о том, как новички проводят первые недели в компании

В статье написано про основные внутренние инструменты,welcome-тренинги, процесс Performance Review, тьюторинг и так далее.

Ccылка: https://habr.com/company/avito/blog/427837/

​​Прошу прощения за перерыв в контенте - мы тут готовим кое-что интересное для всех, кто интересуется управлением знаниями в IT. Stay tuned!

Сегодня я поделюсь интересным артефактом - это Гайд для новых сотрудников геймдев-компании Valve (разработчик игры Half-Life), изданный аж в 2012 году. Что в нем интересного?

То, что многие практики, которые мы начинаем применять в онбординге и обучении сотрудников сейчас уже были опробованы в Valve тогда: гильдии, перфоманс ревью, плоская структура, Peer-ревью и так далее.

Вот небольшие выдержки из этого Гайда.

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

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

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

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

«Чтобы оценить ценность каждого члена команды компания использует stack ranking. Участники команды оценивают каждого из коллег, но не себя, по четырем параметрам: уровень технических скиллов, продуктивность (выхлоп), вклад в группу и вклад в продукт. Эта информация сводится в единый ранк и становится доступна всей компании».

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

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

«Мы ценим людей в форме буквы Т. Это люди, кто одновременно и универсалы (обладают широким набором навыков), и эксперты в отдельной области».

Самый интересный раздел, на мой взгляд, это «В чем Valve пока не так хороша». Компания, которая честно прямо в гайде для новичков рассказывает о своих минусах - это как минимум интересно.

Mother of all demos

9 декабря исполнилось 50 лет самой известной презентации в истории информационных технологий и интерфейсов ― The Mother of All Demos (Мать всех демонстраций) Дугласа Энгельбарда, он известен, как создатель гипертекста, компьютерной мыши и графического интерфейса.

Сам Энгельбарт вдохновлялся концепцией Memex Ванневара Буша (работа As We May Think, 1945 года). Memex ― это система хранения знаний и работы с ними.

Энгельбард и его команда хотели создать ядро управления информацией, гарантирующее, что накопленные знания не будут утеряны или не станут недоступными из-за смены форматов и протоколов. Он предлагал записывать информацию в пятибитном двоичном коде. Он предложил в качестве решения среду On-Line System (NLS).

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

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

Посмотрите запись презентации, она длится полтора часа, но это того стоит.

А для тех, кто любит почитать, а не посмотреть, есть ссылка на статью на Computer History.

​​EnhanCV: Проблема не в отсутствии навыков, а в том, что они не нужны работодателям

Работодатели в сфере IT часто жалуются на недостаток квалифицированных кадров и отсутствие предложения на вакансии.

Портал поиска работы и составления резюме Enhancv проанализировал 114 000 резюме на 102 самых распространенных позиций в США. Созданный ими скрипт искал 10 самых упоминаемых навыков в описании позиций и в резюме и сравнивал совпадения.

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

Но проблема в другом, часто соискатели обладают огромным числом навыков, которые не нужны работодателю.

В IT самыми «недоквалифицированными» являются блокчейн-разработчики и джуниор разработчики ПО, а самыми «переквалифицированными» - Java и .Net разработчики.

Например, для джуниор разработчиков этот разрыв в среднем составляет 30.2 процента, а для блокчейн - 20.5.
В то же время, Java и .Net разработчики обладают на треть большими навыками, чем требуют компании.

Причем разрыв в навыках между самыми недо- и переквалифицированными позициями составляет 60 процентов.

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

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

​​15 января исполняется 18 лет Википедии

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

Сейчас ресурс может похвастаться 5,7 миллионами статей на английском языке и 92 миллиардами просмотров страниц в 2018 году.

Концепция этого «коллективного разума» получила название «вики», что по-гавайски значит «быстрый».

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

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

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

Еще более интересно то, что при такой форме иерархии сам Джимми Уэйлс, идеолог концепции вики, убежденный анархокапиталист, противник бюрократии и поклонник книг Айн Рэнд.

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

ClueBot NG, написанный на C++, может быстро откатить подозрительные статьи, основываясь на обучающемся алгоритме. Он учится на наборе индикаторов, среди которых нецензурная лексика, плохая пунктуация. Согласно статистике, бот отлавливает до 70 процентов «вандализма».

Конечно, бот может ошибаться, есть отдельный ресурс, где можно зарепортить false positive.

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

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

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

А если вы совсем не знаете, о чем рассказать, то вот небольшой список идей от программного комитета:
- Передача знаний в командах разработки, инфраструктуры, тестирования и управления.
- Передача знаний в DevOps, SRE командах (lessons learned, incident management, постмортемы).
- Обучение новых сотрудников, корпоративный университет, welcome-тренинги в ИТ компаниях.
- Горизонтальная передача знаний: гильдии, сессии обмена знаниями, внутренние конференции, сообщества.
- Документация как один из способов передачи знаний в проектах.
- Стайлгайды для кода, дизайна и документации, консистентность наименований в разработке, глоссарии: как создавать, хранить, поддерживать.
- Специфика передачи знаний в распределенных и международных командах.
- Игровое обучение в ИТ компаниях. Боты, настолки. Геймификация, работают ли ачивки и внутрикорпоративные валюты?
- Как понять, что есть проблемы в управлении знаниями?
- Как оценить эффективность управления знаниями, какой профит оно принесло?
- Как продать идею knowledge management руководству, как получить поддержку?
- Как продать идею knowledge management сотрудникам компании?
- Как создать культуру и среду для непрерывного обучения в компании?
- Как обучать новичков? Как выращивать senior-ов в компании?
- Технологии и методики обучения как такового? Как вообще устроено обучение в человеческой голове?
- Как передать знания от уходящего сотрудника команде, чтобы ещё год не бегать к нему с вопросами.
- Knowledge Centered Support. Управление знаниями в командах поддержки и как экстраполировать их на всю компанию.
- Управление знаниями в удаленных командах.
- Методы и сервисы для фиксации архитектуры системы, схемы взаимодействий и зависимостей, журнал архитектурных решений (Architecture decision record (ADR)), как создавать, хранить и поддерживать в актуальном состоянии, генерация диаграмм и схем из текстового описания.
- Управление знаниями на уровне специалиста, команды, компании и профессионального сообщества.
- Управление знаниями для переиспользования технических решений, а не "создания велосипедов" и снижения рисков при смене команды и уходе сотрудников.

Ждем ваших заявок https://conf.ontico.ru/lectures/propose?conference=kc2019

Настало время делиться знаниями!

Кому не нужно управление знаниями?

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

Вот какие кейсы и типы компаний он выделил:

1. Компания - монополист, она не испытывает давления рынка, не волнуется о проблемах роста или эффективности, контроля расходов, потому, что нет конкурентов.

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

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

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

5. Когда у вас есть проблемы поважнее. Они должны быть действительно серьезными, но бывают ситуации, когда управление знаний не в приоритете. Например, Lehman brothers в период ипотечного кризиса 2008 года.

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

Сервис Superjob отказался от графы «образование» в текстах вакансий, при составлении резюме поле останется доступным

Интерфейсы в немалой степени определяют наше восприятие, поэтому это важный шаг, может мы наконец-то движемся к рынку, где skill set и наработанный опыт важнее, чем название позиции/профессии/должностная инструкция?

Mel.fm.

​​Образовательный сайт Coursera назвал 10 самых популярных курсов 2018 года. На втором месте - курс про обучение

Эксперты Coursera отобрали самые популярные курсы вручную на основе оценок пользователей, количества записавшихся и отзывов. На второе место они поставили курс Learning How to Learn, совместный проект канадского Университета Макмастера и Калифорнийского университета в Сан-Диего.

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

Расшифровка доклада про матрицу компетенций с SaintTeamLead

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

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

Присоединяйтесь к дискуссии @KnowledgeConfTalks

​​Pecha-Kucha как способ шаринга знаний внутри компании

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

Сначала у нас не получалось следовать ему строго, но к 3-4 сессии мы настроили автопереключение слайдов. Иногда ребята рассказывают о работе, например, недавно об оптимизации wifi сетей в офисе (звучало как: Почему я медленно хожу с ноутбуком по офису и нормальный ли я человек?), чуть раньше - про то, почему не читают документацию, а иногда - о чем-то совершенно рандомном, например, дизайн компьютерных игр, работа в Тайване или пчеловодство. Это убивает двух зайцев - выращивает спикеров внутри компании даже из самых стесняшек и позволяет делиться информацией между совершенно не пересекающимися командами.

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

Но еще более интересно то, что CSO (главный стратег) компании знаком с изобретателем формата Марком Дитэмом, он предложил его, когда жил в Токио и работал в Tokyo's Klein-Dytham Architecture, и был очень удивлен, что в России кто-то продолжает использовать его "детище".