Видео от Linkedin о пользе качественного онбординга сотрудников, оно конечно в стиле "розовые пони и радуга", там слишком много обнимашек на квадратный метр, но суть отражена хорошо, как в неплохой социальной рекламе.
Об онбординге новичков мы обязательно поговорим в следующих постах.
Смотреть: https://vimeo.com/156754695
Об онбординге новичков мы обязательно поговорим в следующих постах.
Смотреть: https://vimeo.com/156754695
Vimeo
LinkedIn | Make a Difference
Landon and Brandon were identical in every way…until they got separate hiring managers.
Как считать/выявлять bus factor на проекте
Все говорят про фактор автобуса, фактор грузовичка или фактор кирпича, — это число разработчиков, инженеров на проекте, которые могут попасть под автобус/грузовик/кирпич, в результате чего проект остановится.
Проще – это мера сосредоточения информации о системе, проекте. Самый критический фактор автобуса — это единица.
Термин, конечно, не новый, он появился в сфере управления бизнесом еще в 1998 году.
“Автобус” может быть любой, например, отпуск, увольнение, уход в запой, уход в декрет, поездка с целью медитации и просветления в ретрит на Бали на год, да что угодно, это образно. Но гораздо сложнее понять, где эти места в системе, где заключается автобусный фактор, чтобы его снизить.
Как посчитать фактор автобуса? Представим, у вас есть 30 человек на проекте, который занимается веб-разработкой, в нем есть API, фронтенд и дизайн, без деталей. 5 человек разрабатывают API, 10 – фронтенд и еще 5 занимаются дизайном, ваш фактор автобуса – 5.
Потенциальные сигналы о наличии фактора автобуса:
- У вас есть разработчики, чей код вы не ревьюите. Почему? Да он крутой чувак, смысл его ревьюить, он пишет в своем стиле. Потом никто никогда не разберется в этой код базе.
- У вас нет единого нейминга классов, переменных, структуры расположения модулей в проекте, нет требований к документированному коду и вы это не проверяете, ни вручную, ни автоматически.
- CI/CD на проекте настраивал один человек, все просят его добавить, изменить pipeline, но никто не вдается в детали.
- У вас есть давно закомментированные куски кода без понимания, почему это так и в каких ситуациях из нельзя ни в коем случае раскомментировать.
- Документация и база знаний хранится в личных спейсах или еще хуже - на локальных машинах, которые могут отформатировать.
Можно ли выявить его автоматически?
Да, но это будет только диагностика, более глубоко придется копать тимлиду вручную. Например, вот такой тул есть для Git/HG репозиториев, он позволяет найти файлы, где основным контрибьютором по строкам кода является один человек.
В дополнение
Также советую посмотреть выступление Артема Быковца Bus Factor и риски его игнорирования.
Все говорят про фактор автобуса, фактор грузовичка или фактор кирпича, — это число разработчиков, инженеров на проекте, которые могут попасть под автобус/грузовик/кирпич, в результате чего проект остановится.
Проще – это мера сосредоточения информации о системе, проекте. Самый критический фактор автобуса — это единица.
Термин, конечно, не новый, он появился в сфере управления бизнесом еще в 1998 году.
“Автобус” может быть любой, например, отпуск, увольнение, уход в запой, уход в декрет, поездка с целью медитации и просветления в ретрит на Бали на год, да что угодно, это образно. Но гораздо сложнее понять, где эти места в системе, где заключается автобусный фактор, чтобы его снизить.
Как посчитать фактор автобуса? Представим, у вас есть 30 человек на проекте, который занимается веб-разработкой, в нем есть API, фронтенд и дизайн, без деталей. 5 человек разрабатывают API, 10 – фронтенд и еще 5 занимаются дизайном, ваш фактор автобуса – 5.
Потенциальные сигналы о наличии фактора автобуса:
- У вас есть разработчики, чей код вы не ревьюите. Почему? Да он крутой чувак, смысл его ревьюить, он пишет в своем стиле. Потом никто никогда не разберется в этой код базе.
- У вас нет единого нейминга классов, переменных, структуры расположения модулей в проекте, нет требований к документированному коду и вы это не проверяете, ни вручную, ни автоматически.
- CI/CD на проекте настраивал один человек, все просят его добавить, изменить pipeline, но никто не вдается в детали.
- У вас есть давно закомментированные куски кода без понимания, почему это так и в каких ситуациях из нельзя ни в коем случае раскомментировать.
- Документация и база знаний хранится в личных спейсах или еще хуже - на локальных машинах, которые могут отформатировать.
Можно ли выявить его автоматически?
Да, но это будет только диагностика, более глубоко придется копать тимлиду вручную. Например, вот такой тул есть для Git/HG репозиториев, он позволяет найти файлы, где основным контрибьютором по строкам кода является один человек.
В дополнение
Также советую посмотреть выступление Артема Быковца Bus Factor и риски его игнорирования.
👍2
Кому в организации подчиняется специалист по управлению знаниями
Далеко не во всех организациях есть выделенный специалист или отдел по управлению знаниями, эту роль исполняют тимлиды, техписатели, менеджеры проектов, HR, но если он есть, то кому подчиняется?
APQC провела исследование среди 317 компаний и сделала инфографику по итогам. В 30 процентах компаний специалист или отдел по управлению знаниями подчинается напрямую высшему руководству, в 16 процентах - входит в подразделение по обучению и развитию, в 15 - отделу по управлению персоналом.
Когда специалист или отдел по УЗ подчинается напрямую руководству компании, он работает эффективнее, получает большую поддержку и понимание и проще получает необходимый бюджет. Кроме того, само управление знаниями получает больший вес и становится частью статегических приоритетов. Это, можно сказать, common sense.
Далеко не во всех организациях есть выделенный специалист или отдел по управлению знаниями, эту роль исполняют тимлиды, техписатели, менеджеры проектов, HR, но если он есть, то кому подчиняется?
APQC провела исследование среди 317 компаний и сделала инфографику по итогам. В 30 процентах компаний специалист или отдел по управлению знаниями подчинается напрямую высшему руководству, в 16 процентах - входит в подразделение по обучению и развитию, в 15 - отделу по управлению персоналом.
Когда специалист или отдел по УЗ подчинается напрямую руководству компании, он работает эффективнее, получает большую поддержку и понимание и проще получает необходимый бюджет. Кроме того, само управление знаниями получает больший вес и становится частью статегических приоритетов. Это, можно сказать, common sense.
Делюсь с вами ставшим очень полезным для меня материалом об адаптации новых сотрудников в компании "Флант"
И речь не только о базе знаний или обучении, но и о налаженных процессах, например, гибкой системе постановки и оценки задач, которая снижает порог вхождения.
Его написал Игорь Цупко, чей канал @lovely_it_hell я неистово рекомендую всем, кто занимется налаживанием процессов и управлением хотя бы одним разработчиком.
Ссылка: https://habr.com/company/flant/blog/419051/
И речь не только о базе знаний или обучении, но и о налаженных процессах, например, гибкой системе постановки и оценки задач, которая снижает порог вхождения.
Его написал Игорь Цупко, чей канал @lovely_it_hell я неистово рекомендую всем, кто занимется налаживанием процессов и управлением хотя бы одним разработчиком.
Ссылка: https://habr.com/company/flant/blog/419051/
Хабр
Как «Флант» помогает новичкам
В предыдущей статье было рассказано про найм в нашу компанию, но это ещё полбеды — ведь не менее важно и грамотно ввести нового сотрудника в курс происходящего!...
👍1
Продолжаем неделю онбординга на канале, теперь на очереди материал от Avito о том, как новички проводят первые недели в компании
В статье написано про основные внутренние инструменты,welcome-тренинги, процесс Performance Review, тьюторинг и так далее.
Ccылка: https://habr.com/company/avito/blog/427837/
В статье написано про основные внутренние инструменты,welcome-тренинги, процесс Performance Review, тьюторинг и так далее.
Ccылка: https://habr.com/company/avito/blog/427837/
Habr
Первые дни в команде разработки — как это бывает у нас
Когда только собираешься выйти на новую работу, хочется в деталях представлять себе, что тебя ожидает. В этом посте я расскажу, как обычно строится первый рабочий день и первые недели в нашей команде,...
Прошу прощения за перерыв в контенте - мы тут готовим кое-что интересное для всех, кто интересуется управлением знаниями в IT. Stay tuned!
Сегодня я поделюсь интересным артефактом - это Гайд для новых сотрудников геймдев-компании Valve (разработчик игры Half-Life), изданный аж в 2012 году. Что в нем интересного?
То, что многие практики, которые мы начинаем применять в онбординге и обучении сотрудников сейчас уже были опробованы в Valve тогда: гильдии, перфоманс ревью, плоская структура, Peer-ревью и так далее.
Вот небольшие выдержки из этого Гайда.
«Эта книга не о том, какие инструменты вам нужно настроить или где найти программный код, она о том, какой выбор вам придется делать и как это делать и о том, как не сойти с ума от того, что вы теперь с нами».
«Мы хотим видеть в своих рядах инноваторов, а это значит - создать среду, в которой они смогут расцвести. Поэтому компания построена как плоская структура. У нас нет иерархии. Да, у нас есть основатель/президент компании, но даже он - не ваш босс. Эта компания принадлежит вам, управляйте как возможностями, так и рисками. Плоская структура позволяет избавиться от организационных барьеров».
Поскольку структура плоская, вам не назначают проект. Вы сами выбираете, над чем хотите работать после того, как зададите себе несколько вопросов. Вот почему у всех рабочих столов есть колеса. Вы сами решаете, где его установить, куда направить ваши стопы, точнее колеса».
«Внутри компания делится на «группы заговорщиков» (cabals). Каждая группа - это мультидисциплинарная команда. Мы самоорганизовываемся во временные группы с самого начала существования компании. Они создаются, чтобы выпустить продукт или одну небольшую фичу. И как любая группа или решение - формируются органически».
«Чтобы оценить ценность каждого члена команды компания использует stack ranking. Участники команды оценивают каждого из коллег, но не себя, по четырем параметрам: уровень технических скиллов, продуктивность (выхлоп), вклад в группу и вклад в продукт. Эта информация сводится в единый ранк и становится доступна всей компании».
«Каждый может взять на себя роль, наиболее ему подходящую. Каждый может быть дизайнером, каждый может подвергать сомнению работу другого, каждый может быть стратегом, пытаясь понять, что лучше всего подходит нашим клиентам».
«Если ваша основная роль на связана с написанием кода - вы и мы приложим усилия, чтобы вы получили понимание того, как работает код. Расширение кругозора и уровня понимания - это всегда плюс».
«Мы ценим людей в форме буквы Т. Это люди, кто одновременно и универсалы (обладают широким набором навыков), и эксперты в отдельной области».
Самый интересный раздел, на мой взгляд, это «В чем Valve пока не так хороша». Компания, которая честно прямо в гайде для новичков рассказывает о своих минусах - это как минимум интересно.
Сегодня я поделюсь интересным артефактом - это Гайд для новых сотрудников геймдев-компании 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.
9 декабря исполнилось 50 лет самой известной презентации в истории информационных технологий и интерфейсов ― The Mother of All Demos (Мать всех демонстраций) Дугласа Энгельбарда, он известен, как создатель гипертекста, компьютерной мыши и графического интерфейса.
Сам Энгельбарт вдохновлялся концепцией Memex Ванневара Буша (работа As We May Think, 1945 года). Memex ― это система хранения знаний и работы с ними.
Энгельбард и его команда хотели создать ядро управления информацией, гарантирующее, что накопленные знания не будут утеряны или не станут недоступными из-за смены форматов и протоколов. Он предлагал записывать информацию в пятибитном двоичном коде. Он предложил в качестве решения среду On-Line System (NLS).
К сожалению, система была чересчур новаторской и сложно для усвоения средним пользователем, поэтому не получила широкого распространения и уступила более простой документориентированной. Это привело к рождению двух принципиально разных ответов на вопрос: должна ли система хранения и потребления информации быть предельно простой и дружелюбной?
Из его идей появились современные имплементации контекстного поиска, обмена мгновенными сообщениями, гиперссылки, множественные окна, протокол удаленного доступа, протокол виртуальных терминалов.
Посмотрите запись презентации, она длится полтора часа, но это того стоит.
А для тех, кто любит почитать, а не посмотреть, есть ссылка на статью на Computer History.
YouTube
The Mother of All Demos, presented by Douglas Engelbart (1968)
"The Mother of All Demos is a name given retrospectively to Douglas Engelbart's December 9, 1968, demonstration of experimental computer technologies that are now commonplace. The live demonstration featured the introduction of the computer mouse, video conferencing…
👍1
EnhanCV: Проблема не в отсутствии навыков, а в том, что они не нужны работодателям
Работодатели в сфере IT часто жалуются на недостаток квалифицированных кадров и отсутствие предложения на вакансии.
Портал поиска работы и составления резюме Enhancv проанализировал 114 000 резюме на 102 самых распространенных позиций в США. Созданный ими скрипт искал 10 самых упоминаемых навыков в описании позиций и в резюме и сравнивал совпадения.
Анализ показал, что разрыв между желаемыми навыками и имеющимися у соискателей составляет всего 0.5 процента. Это значит, что на рынке всего на полпроцента меньше резюме с желаемыми навыками, чем позиций с описанием этих навыков.
Но проблема в другом, часто соискатели обладают огромным числом навыков, которые не нужны работодателю.
В IT самыми «недоквалифицированными» являются блокчейн-разработчики и джуниор разработчики ПО, а самыми «переквалифицированными» - Java и .Net разработчики.
Например, для джуниор разработчиков этот разрыв в среднем составляет 30.2 процента, а для блокчейн - 20.5.
В то же время, Java и .Net разработчики обладают на треть большими навыками, чем требуют компании.
Причем разрыв в навыках между самыми недо- и переквалифицированными позициями составляет 60 процентов.
Это значит, что соискателям нужно развивать навыки, которые необходимы работодателям, а не индустрии.
Разрыв в опыте тоже преувеличен, средний работодатель требует на 1.5 месяца больше опыта работы, чем есть у среднего соискателя.
Работодатели в сфере 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.
Она была запущена 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
Настало время делиться знаниями!
На этом этапе от вас не требуется готовый доклад, нужен абзац-полтора понятных и простых тезисов, которые вы хотите донести до аудитории 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 вполне могут существовать, монополисты действительно не делают многого, чем занимаются бизнесы в конкурентной среде, однако не стоит забывать об адаптации сотрудников, профессиональном росте и удержании, даже монополист нанимает новых людей, вводит их в строй и удерживает действующих сотрудников, материальная мотивация имеет предел прочности, для пункта пять, можно согласиться, что управление знаниями - это важно, но не срочно, если речь о выживании компании.
Один из признанных KM-экспертов Ник Милтон на прошлой неделе в своем блоге поразмышлял на тему "А каким компаниям или командам не нужно управление знаниями?". Многие позиции и примеры компаний очень спорные, давайте поспорим в комментариях.
Вот какие кейсы и типы компаний он выделил:
1. Компания - монополист, она не испытывает давления рынка, не волнуется о проблемах роста или эффективности, контроля расходов, потому, что нет конкурентов.
2. Компания, бизнес которой не меняется. Если нет изменений, то и обучения - не проблема. Продукт не меняется, не меняются процессы, неизменными остаются клиенты и конкуренты, большие инвестиции в управление знаниями для таких компания - это пустая трата времени и денег.
3. Компания, которая производит труд, а не знания. Существуют организации, где нет никаких знаний, например, компании-производящие одежду для масс-маркета или неквалифицированный труд по контракту. Если вы не продаете знания, вам не нужно ими и управлять.
4. Бизнес одного человека, основанный на навыке. Еще один кейс, когда управлять знаниями не так важно, если ваш бизнес основан на навыке одного человека, например, гастролирующий скрипач.
5. Когда у вас есть проблемы поважнее. Они должны быть действительно серьезными, но бывают ситуации, когда управление знаний не в приоритете. Например, Lehman brothers в период ипотечного кризиса 2008 года.
Мой комментарий: большинство позиций и кейсов довольно спорные, сложно придумать типы бизнесов, удовлетворяющие этим описаниям на сто процентов, где совсем не нужно управлять или хотя бы фиксировать знания. Кейсы 1 и 5 вполне могут существовать, монополисты действительно не делают многого, чем занимаются бизнесы в конкурентной среде, однако не стоит забывать об адаптации сотрудников, профессиональном росте и удержании, даже монополист нанимает новых людей, вводит их в строй и удерживает действующих сотрудников, материальная мотивация имеет предел прочности, для пункта пять, можно согласиться, что управление знаниями - это важно, но не срочно, если речь о выживании компании.
Nickmilton
The organisations for which KM is not important
There are a few cases where Knowledge management is not needed in an organisation, and where the organisation need not bother with KM. ...
👍1
Сервис Superjob отказался от графы «образование» в текстах вакансий, при составлении резюме поле останется доступным
Интерфейсы в немалой степени определяют наше восприятие, поэтому это важный шаг, может мы наконец-то движемся к рынку, где skill set и наработанный опыт важнее, чем название позиции/профессии/должностная инструкция?
Mel.fm.
Интерфейсы в немалой степени определяют наше восприятие, поэтому это важный шаг, может мы наконец-то движемся к рынку, где skill set и наработанный опыт важнее, чем название позиции/профессии/должностная инструкция?
Mel.fm.
Мел
Superjob отказался от графы «образование» в вакансиях, потому что работодатели больше ценят опыт
Сервис по поиску работы Superjob убрал графу «образование» из объявлений вакансий. При составлении резюме графа осталась доступной, сообщает ТАСС.
Образовательный сайт Coursera назвал 10 самых популярных курсов 2018 года. На втором месте - курс про обучение
Эксперты Coursera отобрали самые популярные курсы вручную на основе оценок пользователей, количества записавшихся и отзывов. На второе место они поставили курс Learning How to Learn, совместный проект канадского Университета Макмастера и Калифорнийского университета в Сан-Диего.
Он рассказывает о методах и принципах обучения в разных сферах: наука, спорт, музыка, литература, математика. В частности, о том как мозг использует две модели обучения, как инкапсулирует фрагменты (чанки) информации, как работает память и т.д.
Эксперты Coursera отобрали самые популярные курсы вручную на основе оценок пользователей, количества записавшихся и отзывов. На второе место они поставили курс Learning How to Learn, совместный проект канадского Университета Макмастера и Калифорнийского университета в Сан-Диего.
Он рассказывает о методах и принципах обучения в разных сферах: наука, спорт, музыка, литература, математика. В частности, о том как мозг использует две модели обучения, как инкапсулирует фрагменты (чанки) информации, как работает память и т.д.
Расшифровка доклада про матрицу компетенций с SaintTeamLead
На Хабре вышла статья с расшифровкой моего с Константином Кафтан доклада о матрице компетенций в командах техподдержки и разработки.
На Хабре вышла статья с расшифровкой моего с Константином Кафтан доклада о матрице компетенций в командах техподдержки и разработки.
Хабр
Тут живут драконы: матрица компетенций как инструмент тимлида
Не исключено, что вы скажете: «Матрица компетенций? Серьезно?». Скорее всего вы что-то уже слышали про этот инструмент, и даже сделали какие-нибудь выводы, почему не хотите...
Мы запустили чат Конференции KnowledgeConf, обсуждаем там практические кейсы, проблемы, делимся советами, критикуем инструменты, а также скоро будем голосовать за форматы, доклады и развлечения, которые будут на конференции.
Присоединяйтесь к дискуссии @KnowledgeConfTalks
Присоединяйтесь к дискуссии @KnowledgeConfTalks
Pecha-Kucha как способ шаринга знаний внутри компании
Уже какое-то время (около года) у нас в компании проводятся сессии клуба Печа-куча, это динамичный дискуссионный формат, когда у спикера есть 20 слайдов и по 20 секунд спича на каждый, в сумме - 6 минут рассказа на заранее определенную тему.
Сначала у нас не получалось следовать ему строго, но к 3-4 сессии мы настроили автопереключение слайдов. Иногда ребята рассказывают о работе, например, недавно об оптимизации wifi сетей в офисе (звучало как: Почему я медленно хожу с ноутбуком по офису и нормальный ли я человек?), чуть раньше - про то, почему не читают документацию, а иногда - о чем-то совершенно рандомном, например, дизайн компьютерных игр, работа в Тайване или пчеловодство. Это убивает двух зайцев - выращивает спикеров внутри компании даже из самых стесняшек и позволяет делиться информацией между совершенно не пересекающимися командами.
Формат был признан успешным и даже один из квартельных бизнес-ревью (QBR) одной из команд попробовали провести в виде печи-кучи, конечно, с бизнес-обсуждениями это получилось не очень успешно, но попробовать стоило)).
Но еще более интересно то, что CSO (главный стратег) компании знаком с изобретателем формата Марком Дитэмом, он предложил его, когда жил в Токио и работал в Tokyo's Klein-Dytham Architecture, и был очень удивлен, что в России кто-то продолжает использовать его "детище".
Уже какое-то время (около года) у нас в компании проводятся сессии клуба Печа-куча, это динамичный дискуссионный формат, когда у спикера есть 20 слайдов и по 20 секунд спича на каждый, в сумме - 6 минут рассказа на заранее определенную тему.
Сначала у нас не получалось следовать ему строго, но к 3-4 сессии мы настроили автопереключение слайдов. Иногда ребята рассказывают о работе, например, недавно об оптимизации wifi сетей в офисе (звучало как: Почему я медленно хожу с ноутбуком по офису и нормальный ли я человек?), чуть раньше - про то, почему не читают документацию, а иногда - о чем-то совершенно рандомном, например, дизайн компьютерных игр, работа в Тайване или пчеловодство. Это убивает двух зайцев - выращивает спикеров внутри компании даже из самых стесняшек и позволяет делиться информацией между совершенно не пересекающимися командами.
Формат был признан успешным и даже один из квартельных бизнес-ревью (QBR) одной из команд попробовали провести в виде печи-кучи, конечно, с бизнес-обсуждениями это получилось не очень успешно, но попробовать стоило)).
Но еще более интересно то, что CSO (главный стратег) компании знаком с изобретателем формата Марком Дитэмом, он предложил его, когда жил в Токио и работал в Tokyo's Klein-Dytham Architecture, и был очень удивлен, что в России кто-то продолжает использовать его "детище".
Ни дня без мыслей об онбординге
Сегодня принесла ссылку на интересный доклад Андрея Гоменюка из Badoo Tech Добро пожаловать на борт: вводим новых разработчиков в команду.
Андрей рассказывает, как они прошли путь от "нагромождения ссылок" до понятной, полуавтоматической и поставленной на рельсы процедуры включения новичков в проекты, в ходе которой он проходит все те же процедуры: билет, ветка, релиз, что и в продакшен режиме, а еще участвует в интересном мыслительном эксперименте по проектированию уже существующих в компании фич ака "почувствуй себя архитектором".
https://youtu.be/GJZbzEME_og
Сегодня принесла ссылку на интересный доклад Андрея Гоменюка из Badoo Tech Добро пожаловать на борт: вводим новых разработчиков в команду.
Андрей рассказывает, как они прошли путь от "нагромождения ссылок" до понятной, полуавтоматической и поставленной на рельсы процедуры включения новичков в проекты, в ходе которой он проходит все те же процедуры: билет, ветка, релиз, что и в продакшен режиме, а еще участвует в интересном мыслительном эксперименте по проектированию уже существующих в компании фич ака "почувствуй себя архитектором".
https://youtu.be/GJZbzEME_og
YouTube
«Добро пожаловать на борт: вводим новичков в строй» — Андрей Гоменюк, Badoo
«Когда выходит новый сторудник, лиду хочется, чтобы тот как можно раньше приступил к задачам и стал самостоятельной боевой единицей. Можно «взять за ручку» и провести человека через все круги адаптации, но что делать лиду в быстрорастущей команде?
Я расскажу…
Я расскажу…
Игровое обучение
Как объяснить сложное в простой форме - иногда помогают игры. Не всегда, это зависит от материала, который нужно подать. Но вот хороший пример 👇
Сотрудник Google Мартин Ширле создал игру, которая основана на различных показателях SEO-инструмента Lighthouse. Целью проекта, согласно описанию на GitHub, является визуализация основных показателей и проблем, связанных с загрузкой страницы, в виде игры.
Все это организовано в форме уничтожения бластером астероидов, которые символизируют ресурсы веб-страницы и потенциал их оптимизации (отличается цветом). Чем лучше организован сайт - тем проще проходить игру.
Потыкать в игру можно здесь.
Как объяснить сложное в простой форме - иногда помогают игры. Не всегда, это зависит от материала, который нужно подать. Но вот хороший пример 👇
Сотрудник Google Мартин Ширле создал игру, которая основана на различных показателях SEO-инструмента Lighthouse. Целью проекта, согласно описанию на GitHub, является визуализация основных показателей и проблем, связанных с загрузкой страницы, в виде игры.
Все это организовано в форме уничтожения бластером астероидов, которые символизируют ресурсы веб-страницы и потенциал их оптимизации (отличается цветом). Чем лучше организован сайт - тем проще проходить игру.
Потыкать в игру можно здесь.
Яндекс запустил образовательный сервис Яндекс.Практикум
Перед запуском сервиса Яндекс проанализировал 400 тысяч вакансий разработчиков за последние четыре года, чтобы выяснить какие специальности наиболее востребованы на ИТ-рынке.
Сейчас в Практикуме доступны две профессии: «Фронтенд-разработчик» и «Веб-разработчик», а также вводный курс по аналитике данных от Школы анализа данных. Каждому студенту выделяется наставник, чтобы обсуждать задания и помогать с вопросами.
Обучение в Практикуме длится 6–9 месяцев. Вводный 20-часовой курс бесплатен — люди могут начать учиться и оценить, насколько им подходит выбранная профессия.
Что думаете? Взлетит сервис или нет?
Перед запуском сервиса Яндекс проанализировал 400 тысяч вакансий разработчиков за последние четыре года, чтобы выяснить какие специальности наиболее востребованы на ИТ-рынке.
Сейчас в Практикуме доступны две профессии: «Фронтенд-разработчик» и «Веб-разработчик», а также вводный курс по аналитике данных от Школы анализа данных. Каждому студенту выделяется наставник, чтобы обсуждать задания и помогать с вопросами.
Обучение в Практикуме длится 6–9 месяцев. Вводный 20-часовой курс бесплатен — люди могут начать учиться и оценить, насколько им подходит выбранная профессия.
Что думаете? Взлетит сервис или нет?
Приходите прямо сейчас в @KnowledgeConfTalks обсуждать, как считать эффективность процессов управления знаниями в IT компаниях
Forwarded from Techwriter's Daily
Техническое писательство vs Управление знаниями
Сара Марек, эксперт по управлению знаниями в Foxtel рассказывает на митапе WTD в Мельбурне о том, чем схожа и чем отличается работа технического писателя и «менеджера знаний». Она рассказывает, как можно совместить обе эти роли в вашей работе.
Технический писатель, очевидно, пишет документацию, инструкции, гайды, технические тексты.
Менеджер знаний управляет процессом создания, распределения, использования и управления знаниями, информационными ассетами внутри организации. По мнению Сары знания – это недостающее звено между стратегией компании и ее достижением.
В чем сходства между этими двумя направлениями:
- Прежде всего, это процесс написания текстов, текст как одна из форм существования знания
- Работа с системами управления контентом
- Стайлгайды
- Работа с SME (экспертами), понимание аудитории
Отличия:
- Понимание и разработка дизайна системы, управление пользователями, их поведением
- Аналитика и исследования
- Оптимизация поиска информации
- Измерение и обоснование эффективности созданной системы
- KM взаимодействует с большим количеством подразделений – HR, управление организацией
- Аудитория преимущественно внутренняя, контент потребляется внутри.
П.С. Если вам стало интересно, как расширить свою роль в компании в сторону управления знаниями, про это скоро будет целая конференция http://knowledgeconf.ru/2019 Она гораздо шире и создана не только и не столько для технических писателей, как для владельцев бизнеса и управляющих разработкой, но думаю будет нам интересна. Особенно, если вы работаете над внутренней документацией.
Сара Марек, эксперт по управлению знаниями в Foxtel рассказывает на митапе WTD в Мельбурне о том, чем схожа и чем отличается работа технического писателя и «менеджера знаний». Она рассказывает, как можно совместить обе эти роли в вашей работе.
Технический писатель, очевидно, пишет документацию, инструкции, гайды, технические тексты.
Менеджер знаний управляет процессом создания, распределения, использования и управления знаниями, информационными ассетами внутри организации. По мнению Сары знания – это недостающее звено между стратегией компании и ее достижением.
В чем сходства между этими двумя направлениями:
- Прежде всего, это процесс написания текстов, текст как одна из форм существования знания
- Работа с системами управления контентом
- Стайлгайды
- Работа с SME (экспертами), понимание аудитории
Отличия:
- Понимание и разработка дизайна системы, управление пользователями, их поведением
- Аналитика и исследования
- Оптимизация поиска информации
- Измерение и обоснование эффективности созданной системы
- KM взаимодействует с большим количеством подразделений – HR, управление организацией
- Аудитория преимущественно внутренняя, контент потребляется внутри.
П.С. Если вам стало интересно, как расширить свою роль в компании в сторону управления знаниями, про это скоро будет целая конференция http://knowledgeconf.ru/2019 Она гораздо шире и создана не только и не столько для технических писателей, как для владельцев бизнеса и управляющих разработкой, но думаю будет нам интересна. Особенно, если вы работаете над внутренней документацией.
👍1