Knowledge and bacon - Управление знаниями в IT

2021-06-27 14:46:24 Софт скиллы — это новый чёрный

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

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

За билетами Открыть/Комментировать

2021-06-25 12:49:08 Вебинар для тех, кто хочет войти в тему управления личными знаниями

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

Методик миллионы, и Second Brain, и практики Тиаго Форте, и Zettelcasten, но в них бывает тяжело разобраться самому Если вы хоть раз находили старые записи по теме и радовались, как ребенок, что оказываетс вы это все уже записывали — это для вас.

Записаться в ФБ Открыть/Комментировать

2021-06-09 19:25:39 14 июня стартует очередной сезон Podlodka TeamLead Crew о найме команды и о мотивации

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

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

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

Подробная программа и билеты на сайте. Открыть/Комментировать

2021-06-08 11:25:59 Несколько кейсов про онбординг

Онбординг новичков в ИТ-командах — тема, не теряющая актуальность последние лет 5. Все хотят ускорить time to first production code, сделать путь новичка максимально комфортным и даже сделать онбординг конкурентным преимуществом при найме.

Вот еще пара кейсов за последнее время.

- В Miro шаблонизировали процесс онбординга, сопроводили его описаниями основных процессов и даже ввели должность онбординг-ментора. Читать на Habr.
- Руководитель нескольких успешных стартапов Дон Неуфельд предлагает относиться к онбордингу, как к вашей системе сборки, просто собираете и релизите вы — разработчика. В этом случае процесс будет масштабируемым, не зависящим от коннкретных людей и с возможностью контроля исходника (отслеживание изменений и версионирование). Ну и мой любимый принцип — каждый новых сотрудник должен обновить онбординг. Читать на Medium. Открыть/Комментировать

2021-04-28 13:05:43 Friendly Asked Questions #2 — про документацию

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

Ответы дали авторы каналов Уютный Адочек, DocOps и The Know All
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8

@the_know_all — Лана Новикова

Документация — один из способов организовать коммуникацию по какому-то каналу. Это решение, а давайте вернемся к проблеме. Зачем документация и какую вашу проблему и проблему бизнеса она решит?
Проблема — неосведомленность сотрудников о том, что делается в другом проекте. Эту проблему может решить не только документация, но и, например, периодические демо, сессии обмена знаниями, shadowing (когда периодически специалисты из одного проекта переключают контекст и работают в паре с коллегами из другого в формате «тени»). Техническому директору это надо «продавать» в его терминах: ускорение разработки, снижение эскалаций, снижение рисков инцидентов.
В тему организации обмена знаниями между отделами есть хороший доклад Марии Палагиной


@docops — Ник Волынкин

Давай тут разделим проблему на три части.
1. Команда не пишет. Стань первым, кто начнёт это делать. Когда будешь в чем-то разбираться — делай заметки. Так у команды будет хороший пример. Постарайся рассказывать команде о том почему и как это делаешь, и замечать, как твоя работа реально будет помогать коллегам.
2. Тимлид не поддерживает идею документирования. Вы, наверное, сейчас теряете время на погружение в задачу и на изобретение велосипедов, теряете мотивацию людей, плохо учитесь на ошибках (и будете их повторять). Всё это напрямую мешает работе тимлида и ставит его задницу под удар начальства. Не предлагай тимлиду писать доки — предлагай ему помощь в его работе.
3. Техдир идёт на конфликт. Лучше приходить к техдиру с тем, что уже работает хоть на небольшом масштабе. И ещё, техдиру нужен запрос, который можно решить только на его уровне. Плохо: "Сделай так чтобы мой тимлид заставил нас писать доки". Хорошо: "Мы начали писать анализ инцидентов, это помогает, давай это распространим на всю компанию".

@lovely_it_hell — Цупко Игорь

Можете ли вы писать документацию самостоятельно, подавая пример коллегам? Если в компании не выделяют время на изменения и инициативы — возможно пора поменять компанию.
Описанные реакции — странные. Троллинг и агрессия руководителя в ответ на инициативу подчинённого — звучит не здорово.
Если я правильно понимаю, вы хотите вдохновить коллег, побудить их к действиям. Попробуйте покидать им хороших примеров (возможно вы просто сейчас более "насмотрены" на хорошую доку, чем они), докладов, пописать короткие посты в чатики команды — но без нажима и требований. Вода камень точит и со временем какие-то идеи осядут в головах. Открыть/Комментировать

2021-04-26 09:03:57 Бот Валера теперь в open source

Чат-боты в последние годы стали неплохим подспорьем в налаживании процессов управления знаниями и автоматизации разного рода рутины. Многие видели, а кто не видел – посмотрите доклад Татьяны Бунто из HFLabs про бота Валеру с SECR-2019, который взял на себя часть рутинных задач в переписке, например, если кто-то делится ссылкой на документ из базы знаний: отображает его название и проект, если кто-то делится ссылкой на задачу из Jira — кратко отображает её описание, если кто-то отвечает на эту задачу в чате — публикует комментарий и в задачу тоже, а ещё помогает искать по тикет-трекеру и базе знаний прямо из чата. Кстати, там в комментариях под видео Ольга Павлова рассказала о том, что делает похожий чат-бот в «Собаке Павловой».

Но сейчас не об этом, а о том, что разработчик Валеры выложил в открытый доступ код бота: https://github.com/mehanizm/valera Форкайтесь, улучшайте, дополняйте, пользуйтесь! Открыть/Комментировать

2021-04-18 11:58:43 ​​Как формулировать вопросы, чтобы оценивать глубину знания?

В пятницу послушала доклад Наталии Савастюк Как формулировать вопросы, чтобы оценивать глубину знания на SQA Days. Он был посвящен тому, как на основе таксономии Блума строить вопросы на собеседованиях.

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

⁃ Есть два подхода к обучению: Higher-Order Thinking Skills и Low-Order Thinking Skills. Первые — это навыки мышления высшего порядка, такие как анализ, синтез, оценка и критическое мышление. Считается, что учащиеся должны овладеть навыками более низкого уровня, прежде чем они смогут заниматься навыками более высокого порядка.
⁃ В основе подхода лежит таксономия Блума. Он разбил все знания на уровни глубины освоения.
⁃ На первом уровне есть только фактические знания. На втором понимание, на третьем превращение в практический опыт, применение, далее идёт анализ, когда знание распадается на составляющие, и на самом высоком уровне идут анализ, оценка и создание нового.

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

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

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

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

Ссылка на слайды Открыть/Комментировать

2021-04-16 15:35:45 100 компаний, которые будут иметь значение на рынке KM

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

Помимо гигантов, вроде Google, Microsoft, IBM, AWS, Deloitte, Accenture, из интересных мне туда попали:
⁃ Keeeb — компания, которая разрабатывает решения в сфере корпоративного поиска и цифровых рабочих мест. Они делают продукт, который позволяет собрать фрагментированные источники информации в единое пространство. https://www.keeeb.com/
⁃ Ontotext — компания делает продукт по преобразованию структуры знаний компании в графовую базу данных с возможностью визуализации, построения таксономий и словарей, что, например, позволяет находить новые связи и эффективнее рекомендовать контент. https://www.ontotext.com/
⁃ Clarabridge — они делают интересный сервис по анализу текста и речи на базе AI, вы скармливаете сервису записи разговоров и логи чатов службы поддержки, а он анализирует тональность дискуссии и другие маркеры и предлагает вам инсайты и пространство для улучшения коммуникации. https://www.clarabridge.com/
⁃ Synaptica — система управления бизнес-таксономией и тезаурусом, которая позволяет анализировать корпоративный контент, индексировать сущности, строить связи, искать по ним, описывать сущности стандартизированным языком. https://www.synaptica.com/
⁃ Capaсity — ещё одна система для помощи команде саппорта: встроенный AI умеет распознавать вопросы и ответы в разговорах и автоматически добавлять их в базу знаний, его можно подключить к множеству корпоративных каналов коммуникации и хранилищ. Ещё одна киллер фича: это расширенная аналитика и сбор данных, это позволяет понять, какие именно знания уже приносят вам наибольшую ценность, какие ещё являются «белыми пятнами», кто вносит самый большой вклад в наполнение ответов, какие знания требуют обновления и так далее. По словам разработчиков, модель обучится на вашем контенте всего за пару недель. https://capacity.com/

На самом деле интересных систем и платформ в списке еще много, но я выбрала топ наиболее заинтересовавших именно меня. Пишите ваших фаворитов в комментариях. Открыть/Комментировать

2021-04-15 15:43:39 Бесплатные занятия для тимлидов и тех, кто хочет ими стать

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

Занятие Первые шаги тимлида на новом месте пройдёт уже завтра, 16 апреля в 20:00 и будет посвящено тому, как быстро «заонбордиться снизу» — быстро собрать нужные знания о продукте и команде и добиться быстрых побед, а также, какие компетенции нужно развивать тимлиду, а занятие Организация процесса разработки программного обеспечения состоится 26 апреля в 20:00 и расскажет о том, какие есть подходы и модели к организации процесса разработки.

Для участия пройдите регистрацию по ссылке.

В качестве PS хочу добавить, что ещё со времен KnowledgeConf 2020 вдохновлена процессом подготовки и онбординга преподавателей в Otus, там он выстроен очень круто и зрело, об этом в своем докладе рассказывала Дарья Вьюнова. Дождитесь, когда запись выложат в общий доступ и обязательно посмотрите! А пока можете посмотреть интервью с Дарьей на канале MoreView. Открыть/Комментировать

2021-04-08 15:45:00 ​​Техника Root Cause анализа

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

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

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

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

Пример довольно абстрактный, в реальности у вас будут стрелки не линейные, а много ответвлений и несколько «root cause», например, разрастающийся скоуп, неправильная приоритизация, добавление фич в релиз на ходу, сложный процесс самого релиза и прочее . Для построения таких цепочек полезно использовать Root Cause фреймворк.

Идея в том, что наша проблема - это не проблема, а симптом, мы не чиним ее саму по себе, а we need to go deeper.

Пишете по центру проблему, от нее рисуете стрелки: вверх последствия, вниз - причины. Итерируем по такому дереву несколько раз, добавляем-убираем. Причин обычно будет несколько, можно сосредоточиться на тех, которые ведут к наибольшему числу последствий. Далее придумываем контрмеру на один root causes и пробуем её. Если добились небольшого улучшения — чиним дальше.

Исходя из найденного в ходе такого исследования можно дальше строить метрики эффективности.

Есть еще хак, а как понять, что это root cause?
Визуально верный признак — если много стрелок идут вверх и ничего вниз.

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

Техника отлично подойдет для ретроспектив и выученных уроков. Открыть/Комментировать