Комментарии 2
У меня несколько другой вопрос: как вы заставляете сотрудников эту базу знаний наполнять и поддерживать в актуальном состоянии? Написание хорошей качественной статьи даже для внутреннего пользования, даже когда проект уже выполнен - большая работа. Инструментария Azure DevOps нам хватает за глаза, но по факту программисты могут в гит и контроль версий, кое-как могут в комментарии к коду и вообще не могут в текст/схемы: зачем, почему, где проблема и как решали (с ними надо сесть, поговорить, переварить - изложить). Опять же внутренняя документация и "внешняя" (для клиента) это сильно про разное. В итоге по R&D проектам Вики виду я, когда силы есть, вроде все хвалят, всем очень нравится, но рядовые разработчики не пишут потому что для них это самый низкий приоритет задач (особенно если писать код он любит и умеет, а писать текст - нет). CEO вроде ценность понимает, признает и пару раз наглядно уже экономию времени и ресурсов наблюдал при смене ключевых сотрудников, но "прям вот сейчас не приоретет". Когда вики ведет CSO по остаточному принципу, это объяснимо в рамках среднего размера компании, но явно не оптимально.
Хороший вопрос, спасибо! У нас тоже ведение бз было рабочей зоной отчуждения. Поэтому внедрили 2 подхода: статьи пишут менеджеры проектов, руководители отделов, тимлиды - эти статьи обстоятельные, т.к они всю полезность для себя и своей команды понимают. 2 подход: разработчики со своей стороны тоже все, что можно пишут и описывают в бз (проблемы, решения, какие-то отчеты и тд), потому что руководитель иначе не примет работу. Конечно, система еще не на 100% идеальна, но основной массив знаний по продуктами и проектам оседает в бз. База знаний у нас своя, поэтому функционал релизим сначала у себя, пробуем на всех отделах, потом дорабатываем по отзывам, ловим баги и тд. Надо делать так, чтобы ведение бз занимало у человека как можно меньше лишних телодвижений. На эту тему есть статья от руководителя команды разработки Как мы внедрили свою же базу знаний в команду разработки базы знаний: какую придумали структуру, шаблоны и инструменты / Хабр (habr.com)
Как я управлял внедрением базы знаний. Во второй раз получилось