Спасибо большое!

а можно глянуть ваши видео?

к счастью, не я их снимаю, а наша техподдержка :D ща найду пример

например вот: https://support.pandadoc.com/hc/en-us/articles/360019574054--Editor-2-0-Review-Document-Analytics

дисклеймер: я вообще не пишу пользовательскую документацию в пандадоке 😄 но она разумно устроена и решает свои задачи

Сами видосы делают ребята из тп? Кто в целом на себя эту задачу берёт?)

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

А в целом лучшая практика писать доку и видосы у техрайтеров или тп?)

мое мнение - хорошо бы был техрайтер, который доводит то, что написала техподдержка (support/knowledgebase articles) до ума. у тп экспертиза по продукту, у техрайтер возможность делать всё единообразно

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

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

Кайф, спасибо. Ещё помучаю, раз такое дело)) по готовым решениям есть опыт? Условно базу знаний делаете свою или в панде готовые решения используете и почему?)

на будущее - https://www.wappalyzer.com/lookup/ )

этот хелп центр сделан на зендеске, видимо проще было купить решение из коробки

А был опыт с другими решениями?

не, как-то не доводилось, может коллеги что-то добавят. я там выше кидала ссылку на write the docs коммьюнити, можно там поспрашивать

Вот это мне нравится - “much of the time it does not matter“. https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Commas/faq0067.html

Коллеги, приветствую. Подскажите, пожалуйста, в документе "Концептуальный проект" каким образом формулируются предложения? Исходя из позиции "Должен быть", как и в ТЗ?

в 6-м разделе Концепции "должны быть"

Здравствуйте. Мы добавляем таблицы с информацией по инфраструктуре и принимаемым ключевым арх. решениям с обяз. указанием перед ними, что это предполагаемая история — без долженствования, но с тем фактом, что в рамках данной концепции будет использоваться, т.к. является оптимальным вариантом по тем или иным соображениям. Сам факт структурированного размещения информации в таблицы позволяет убрать большой объем текста, а также удается избегать частичный или полный дубликат ТЗ. ФТ в этом случае могут быть описаны в формате списка use cases (без их полного описания)

Спасибо за развёрнутый ответ. Учту ваш опыт.