Предполагаю, если Вы спрашиваете про базу знаний, то документацию пишите для коллег и внешний портал с продающей документацией Вам не нужен. Обращаться к базе будут как разработчики, так и тестировщики, менеджеры, аналитики и другие коллеги, выполняющие разные функции в команде. Я верно предположила? Отталкиваясь от этого предположения, я делаю вывод, что, скорее всего, под базой знаний Вы подразумеваете некий пул статей о проекте, который поможет Вам делиться информацией без лишних созвонов и переговоров, оптимизировать этот процесс, передавать и сохранять знания внутри команды. Как правильно, небольшие компании хранят такую информацию в doc-файлах или корпоративной Wiki, но я считаю этот формат неудобным. Трудно поддерживать актуальность, версионность и решать конфликты при работе одновременно нескольких людей с одним документом. На мой взгляд идеального решения не существует. Но я бы посмотрела в сторону использования систем контроля версий. Например, можно вести базу знаний прямо в Gitlab или Github, в приватном репозитории, рядом с кодом. Читать такую документацию смогут коллеги с разными навыками, у GitLab есть неплохой инструмент для этого, GitLab Pages (а если есть желание и ресурсы, то можно даже настроить выгрузку в ту же Wiki), одним, словом, посмотрите в сторону подхода Docs-as-code.А вот, чтобы поддерживать в таком формате документацию, нужно уметь работать с Git'ом, но это, думаю, для Вас, как для разработчика, не проблема. Всё зависит от ресурсов, целей, уровня, масштабов и навыков команды и Вашего технического писателя.
Подскажите, пожалуйста, верно ли я поняла Ваш вопрос? Ответила ли на него?
Про целевую аудиторию Вы совершенно правы. Это действительно важный момент. Обратите внимание, что я начала статью именно с этого – рассказала, кому она будет полезна и для кого предназначена: "тем, кто отчаянно нуждается в документации, но не обладает ресурсами и навыками технического писателя ", я честно говорю о том, что "…не смогу вместить весь свой опыт в одну статью, но точно задам направление и помогу, как минимум, создать черновик документации". Разработчик или тестировщик берутся за документацию не от хорошей жизни и обычно не знают, с чего начать. Поэтому я намеренно использую слова "статья" и "документация" в связке. А именно, употребляю слово "статья" в качестве синонима "единица документации".
Что касается других замечаний, полагаю, это уже следующая ступень – "для опытных". Перегружать информацией: нюансами и тонкостями тех, кто только начинает, не имеет смысла. Спасибо за идею для второй части!
Я не сталкивалась с командами, которые пробовали бы такой подход и предпочитаю писать тексты самостоятельно с самого начала, потому что могу, умею, практику.
Часто в попытке сэкономить время и сократить трудозатраты, можно наоборот потратить еще больше и первого, и второго. Если не обработать предварительно текст и не подготовить развернутый промпт, а закинуть всё, что есть по проекту, почти полностью заполнив контекстное окно, то с высокой долей вероятности нейросеть выдаст ерунду, но с очень убедительной подачей. И получится, что нужно: сначала подготовить промпт для нейросетки, потом проверить результат и исправить ошибки. Проще сделать самому. Тема, на самом деле, холиварная и интересная. Возможно, послужит основой для одной из следующих статей.
Предполагаю, если Вы спрашиваете про базу знаний, то документацию пишите для коллег и внешний портал с продающей документацией Вам не нужен. Обращаться к базе будут как разработчики, так и тестировщики, менеджеры, аналитики и другие коллеги, выполняющие разные функции в команде. Я верно предположила? Отталкиваясь от этого предположения, я делаю вывод, что, скорее всего, под базой знаний Вы подразумеваете некий пул статей о проекте, который поможет Вам делиться информацией без лишних созвонов и переговоров, оптимизировать этот процесс, передавать и сохранять знания внутри команды. Как правильно, небольшие компании хранят такую информацию в doc-файлах или корпоративной Wiki, но я считаю этот формат неудобным. Трудно поддерживать актуальность, версионность и решать конфликты при работе одновременно нескольких людей с одним документом. На мой взгляд идеального решения не существует. Но я бы посмотрела в сторону использования систем контроля версий. Например, можно вести базу знаний прямо в Gitlab или Github, в приватном репозитории, рядом с кодом. Читать такую документацию смогут коллеги с разными навыками, у GitLab есть неплохой инструмент для этого, GitLab Pages (а если есть желание и ресурсы, то можно даже настроить выгрузку в ту же Wiki), одним, словом, посмотрите в сторону подхода Docs-as-code.А вот, чтобы поддерживать в таком формате документацию, нужно уметь работать с Git'ом, но это, думаю, для Вас, как для разработчика, не проблема. Всё зависит от ресурсов, целей, уровня, масштабов и навыков команды и Вашего технического писателя.
Подскажите, пожалуйста, верно ли я поняла Ваш вопрос? Ответила ли на него?
Благодарю за такой развернутый комментарий!
Про целевую аудиторию Вы совершенно правы. Это действительно важный момент. Обратите внимание, что я начала статью именно с этого – рассказала, кому она будет полезна и для кого предназначена: "тем, кто отчаянно нуждается в документации, но не обладает ресурсами и навыками технического писателя ", я честно говорю о том, что "…не смогу вместить весь свой опыт в одну статью, но точно задам направление и помогу, как минимум, создать черновик документации". Разработчик или тестировщик берутся за документацию не от хорошей жизни и обычно не знают, с чего начать. Поэтому я намеренно использую слова "статья" и "документация" в связке. А именно, употребляю слово "статья" в качестве синонима "единица документации".
Что касается других замечаний, полагаю, это уже следующая ступень – "для опытных". Перегружать информацией: нюансами и тонкостями тех, кто только начинает, не имеет смысла. Спасибо за идею для второй части!
Я не сталкивалась с командами, которые пробовали бы такой подход и предпочитаю писать тексты самостоятельно с самого начала, потому что могу, умею, практику.
Часто в попытке сэкономить время и сократить трудозатраты, можно наоборот потратить еще больше и первого, и второго. Если не обработать предварительно текст и не подготовить развернутый промпт, а закинуть всё, что есть по проекту, почти полностью заполнив контекстное окно, то с высокой долей вероятности нейросеть выдаст ерунду, но с очень убедительной подачей. И получится, что нужно: сначала подготовить промпт для нейросетки, потом проверить результат и исправить ошибки. Проще сделать самому. Тема, на самом деле, холиварная и интересная. Возможно, послужит основой для одной из следующих статей.