Вы вероятно говорите по большей части о технической документации (API, системные требования, архитектурные схемы) для инженеров. Её у нас тоже ведут мои коллеги и там действительно нужно обладать, как вы подметили, компетенциями.
Я поэтому выше написала, за какие виды документации может отвечать техпис в команде. Всё зависит от проекта и требований к нему.
У нас разработчики "кодят", им некогда управлять пользовательской базой знаний, монтировать скринкасты или фиксировать изменения в продукте для его конечных пользователей🙂То же самое касается проектной документации с заказчиками.
Техпис — это технический писатель, тот самый писарь в компании, который отвечает за поддержание пользовательской (инструкции, гайды), технической (API, критерии приёмки фичей) и проектной (технические задания, ПМИ, др.) документации. Если хотите подробнее узнать о профессии, есть профстандарт: file_117526.pdf
Добрый день! Солидарна, что если компания получает десятки запросов от клиентов в день, то без поддержки сложно обойтись. Наша компания молодая :), поэтому, как правило, биздевы идут в отдел QA и приносят проблему, QA уже заводят тикеты. Если речь идет об улучшениях (не критичных инцидентах), просим клиентов приносить идеи на доску в публичный роадмап, потом в ченджлоге описываем, что сделали доработку.
Как показала практика, клиенты идут в документацию, когда выполнить операцию/запрос в приложении не получилось. Это не значит, что документация плохо написана. Наоборот, значит приложение нативно понятно разработано с точки зрения UX-дизайна.
Как опробованные решения для работы с пользовательской базой знаний, во-первых, стоит попробовать альтернативные форматы представления информации. Кто-то готов прочесть статью про функциональность, кто-то зайдет в ченджлог и по тезисам поймет, о чем новая фича. Кто-то рассчитывает посмотреть видео (скринкаст) и на слух за пару минут воспринять информацию. Мы уже используем формат инструкций и ченджлога, видео используем для описания сложной функциональности.
Во-вторых, ценно встраивать компоненты (иконки с инфо) в приложение, ведущие к разделам документации про выбранную для работы функциональность.
Идеальное решение, когда пользователь, не выходя из приложения, может узнать о всех нюансах функциональности (с помощью тултипов, всплывающих уведомлений, модальных окон или полноценного онбординга). Сейчас мы используем набор компонентов: иконки со ссылками на доку, тултипы, инфоплашки.
Вы вероятно говорите по большей части о технической документации (API, системные требования, архитектурные схемы) для инженеров. Её у нас тоже ведут мои коллеги и там действительно нужно обладать, как вы подметили, компетенциями.
Я поэтому выше написала, за какие виды документации может отвечать техпис в команде. Всё зависит от проекта и требований к нему.
У нас разработчики "кодят", им некогда управлять пользовательской базой знаний, монтировать скринкасты или фиксировать изменения в продукте для его конечных пользователей🙂То же самое касается проектной документации с заказчиками.
Обесценивание — тоже реакция, спасибо!
Видимо за усилием им поделиться публично что-то стоит:)
Та ещё смелость, получается😄
Техпис — это технический писатель, тот самый писарь в компании, который отвечает за поддержание пользовательской (инструкции, гайды), технической (API, критерии приёмки фичей) и проектной (технические задания, ПМИ, др.) документации.
Если хотите подробнее узнать о профессии, есть профстандарт: file_117526.pdf
Добрый день! Солидарна, что если компания получает десятки запросов от клиентов в день, то без поддержки сложно обойтись. Наша компания молодая :), поэтому, как правило, биздевы идут в отдел QA и приносят проблему, QA уже заводят тикеты. Если речь идет об улучшениях (не критичных инцидентах), просим клиентов приносить идеи на доску в публичный роадмап, потом в ченджлоге описываем, что сделали доработку.
Добрый день!
Как показала практика, клиенты идут в документацию, когда выполнить операцию/запрос в приложении не получилось. Это не значит, что документация плохо написана. Наоборот, значит приложение нативно понятно разработано с точки зрения UX-дизайна.
Как опробованные решения для работы с пользовательской базой знаний, во-первых, стоит попробовать альтернативные форматы представления информации. Кто-то готов прочесть статью про функциональность, кто-то зайдет в ченджлог и по тезисам поймет, о чем новая фича. Кто-то рассчитывает посмотреть видео (скринкаст) и на слух за пару минут воспринять информацию. Мы уже используем формат инструкций и ченджлога, видео используем для описания сложной функциональности.
Во-вторых, ценно встраивать компоненты (иконки с инфо) в приложение, ведущие к разделам документации про выбранную для работы функциональность.
Идеальное решение, когда пользователь, не выходя из приложения, может узнать о всех нюансах функциональности (с помощью тултипов, всплывающих уведомлений, модальных окон или полноценного онбординга). Сейчас мы используем набор компонентов: иконки со ссылками на доку, тултипы, инфоплашки.