« когда редактор решит изменить ответ на вопрос: “сколько дней требуется на ремонт?”, он автоматически обновится во всех каналах.»

Это в общем-то везде быстро и несложно происходит. Сложность в том, чтобы когда в сервисном отделе захотят поменять условия обслуживания:
1. у редактора появилась задача на актуализацию статьи (+ юридических документов)
2. изменение условий было невозможно, пока не будет готово обновление статьи и остальных документов
3. в какой-то момент ответственный человек нажал кнопку, и текст статьи и бизнес-логика в информационной системе сервисного отдела поменялись *одновременно*.

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

трекер задач это неплохо. спасибо

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

то есть я имею ввиду именно методологию

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

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

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

Вот теперь всё понятно стало

Сарказм?

Ответил в контексте знаний о проекте. Но контекст требований, применимости есть у любых знаний.

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

Я на проектах делаю условно-дерево (т.е. Как бы ветки, но по факту - независимы от корня) с некоторым количеством базовых измерений/классификаторов + опциональные

Коллеги, может кто-нибудь поделиться ссылками на тему организации базы знаний? Интересно почитать и увидеть какие-нибудь типизированные структуры БЗ, типизированные подходы к организации, лучшие практики, что-нибудь на эту тему)

*тут должна быть ссылка на pragmatic knowledge guide*

Можно прям lgtfy-сервис сделать, ведущий на гайд))

Если там надо думать как бы поискать, это такая себе база знаний

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

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

а нынче как вообще без поиска?..

если ты про гайд — он ещё в начале своего пути