Знание - это прежде всего стандарты (правила) представления информации "как знания".
Не могу согласится. Каждый человек обладает какими-то знаниями и может ими делится без определения заранее правил, при этом наличие правил (как чего-то ограничивающего) не будет на мой взгляд стимулировать делиться знаниями. Получается всё-таки начать стоит с создания мотивации и атмосферы для обмена знаниями, а дальше если будет потребность создать правила
Обогащающая - это тип команды, а вебинар - это пример паттерна взаимодействия "фасилитация", который она в том числе использует.
У обогащающей команды по сути три главные задачи:
Обучение (вебинары, гайды).
Тестирование гипотез (как платформа работает в реальных продуктах).
Фасилитация изменений (документация, улучшение API).
Ваши предложения (а, б, в) — это как раз пункты 2 и 3. При этом, например, тестирование гипотез - это паттерн взаимодействия "сотрудничество"
Вебинары бывают всё же полезны в формате коротких сессий по запросу: «Как исправить ошибку X в новом API» (ответы на конкретные вопросы) или «Разбор кейса: Как команда Y внедрила фичу Z за 2 дня».
В этом примере я говорил про то, что тут нет понятных всем скучных митингов ради галки. Фасилитация так как направлена на обучение и передачу знаний (чтобы команды могли работать автономно) может быть выражена в созвонах но это именно помощь в решении конкретных задач или выявленных болей + она подстраивается под обратную связь и если командам такой формат не нравится то можно выбрать видеоролики или текстовую документацию
В моей практике это всегда ложится на плечи архитекторов и некоторой "антитунельной" службы. Конечно нужен реестр сервисов в специализированных каталогах или просто в Confluence, в котором будет описана существующая функциональность. Однако часто в каких-то моментах создаваемый сервис будет похож на уже существующие и вот это принятие решения действительно ли это дубль или пересечение обосновано автоматизировать полностью невозможно.
В остальном по инструментам для украшения хаоса: стандартизация (как в крупную клетку на всю компанию, так и отдельные прикладные руководства), архитектурные ревью, воркшопы (для информирования о существующем функционале) и стартовые шаблоны для типовых сервисов
Картинка топ!
Не могу согласится. Каждый человек обладает какими-то знаниями и может ими делится без определения заранее правил, при этом наличие правил (как чего-то ограничивающего) не будет на мой взгляд стимулировать делиться знаниями. Получается всё-таки начать стоит с создания мотивации и атмосферы для обмена знаниями, а дальше если будет потребность создать правила
Обогащающая - это тип команды, а вебинар - это пример паттерна взаимодействия "фасилитация", который она в том числе использует.
У обогащающей команды по сути три главные задачи:
Обучение (вебинары, гайды).
Тестирование гипотез (как платформа работает в реальных продуктах).
Фасилитация изменений (документация, улучшение API).
Ваши предложения (а, б, в) — это как раз пункты 2 и 3. При этом, например, тестирование гипотез - это паттерн взаимодействия "сотрудничество"
Вебинары бывают всё же полезны в формате коротких сессий по запросу: «Как исправить ошибку X в новом API» (ответы на конкретные вопросы) или «Разбор кейса: Как команда Y внедрила фичу Z за 2 дня».
В этом примере я говорил про то, что тут нет понятных всем скучных митингов ради галки. Фасилитация так как направлена на обучение и передачу знаний (чтобы команды могли работать автономно) может быть выражена в созвонах но это именно помощь в решении конкретных задач или выявленных болей + она подстраивается под обратную связь и если командам такой формат не нравится то можно выбрать видеоролики или текстовую документацию
В моей практике это всегда ложится на плечи архитекторов и некоторой "антитунельной" службы. Конечно нужен реестр сервисов в специализированных каталогах или просто в Confluence, в котором будет описана существующая функциональность. Однако часто в каких-то моментах создаваемый сервис будет похож на уже существующие и вот это принятие решения действительно ли это дубль или пересечение обосновано автоматизировать полностью невозможно.
В остальном по инструментам для украшения хаоса: стандартизация (как в крупную клетку на всю компанию, так и отдельные прикладные руководства), архитектурные ревью, воркшопы (для информирования о существующем функционале) и стартовые шаблоны для типовых сервисов