techwriter (Все сообщения пользователя)

На море )) Уже жду - не дождусь ))

Всем привет! Еще недельку, и в отпуск! ))

Мне ворд выше 2007 вообще не нравятся :( Как-то слишком много глюков с функционалом, который работал в 2007 корректно.

[QUOTE]ADVANCED пишет:
В вашем случае, как я заметил, надо сначала подумать к какому уровню я отношусь, потом найти папку моего уровня, найти документ и перелистывать его полдня, а потом плюнуть, не найдя ответ и спросить у соседа
[/QUOTE]Деление документации не предполагало физического хранения файлов :)))
Структура документации - понятие абстрактное в данном случае.

[QUOTE]ADVANCED пишет:
Значит, что вместо разделения на уровни "начинающий", "опытный", "очень-опытный" - лучше наделать методичек, wiki, быстровызываемую справку и т.п. для всех. Какой-либо общий свод знаний Они сами определят к каком уровню относятся.

Для новых сотрудников написать туториал, методику работы с ПО.
Для старых "как не надо делать"
[/QUOTE]Так существует целая метода разделения видов документов, которые должны разрабатываться для уровней пользователей. Для каждого вида документа - свой определенный формат. То, что я сейчас описываю, не я же придумала. Это опыт забугорных техписов, которых я постоянно читаю. Я попробовала его применить на одном проекте и мне понравилось. Сейчас тоже планирую применять. По крайней мере, документацию при применении такого подхода люди начинают читать и появляется грамотный фидбек на документацию.

[QUOTE]ADVANCED пишет:
Это пользователь сам определяет. Мне кажется такое разделение и продумывание стадий пользования -лишняя трата времени и средств.
[/QUOTE]У всех разный опыт. Я лишней тратой времени и средств не считаю.

[QUOTE]ADVANCED пишет:
Разберусь за 1-10 минут не читая документацию - я не начинающий.
[/QUOTE]Так речь не о конкретном пользователе, а о среднестатистическим. И не всегда люди, которые считают, что могут разобраться за 1-10 минут догадываются о возможностях системы, которые могли бы реально облегчить им жизнь.
Читать/не читать - это вообще личное дело каждого. Моя задача - лишь создать базу, если захочется почитать. Создать такие условия, чтобы захотелось почитать, тоже задача технического писателя. Она намного сложнее, чем весь процесс разработки.

[QUOTE]ADVANCED пишет:
Аналитик должен уметь писать ТЗ, а писать его на самом деле может писатель.
[/QUOTE]Почему такая привязка к ТЗ? По-хорошему, все требования должны храниться в какой-нибудь системе управления требованиями. Повторюсь, не везде и не всегда в конторе существует ТЗ - документ, который содержит описание требований к системе. Во многих конторах все пользуются системой управления требованиями и счастливы не иметь ТЗ.

[QUOTE]ADVANCED пишет:
Руководство "начинающего пользователя" не писал уже пару лет. Но могу легко!
[/QUOTE]Это только так кажется. Я за всю свою практику видела всего лишь пару раз, чтобы интерфейс был описан внятно и понятно для пользователя. И вообще очень важен фидбек от людей, которые ее читают.
Фидбек по документации, которая разрабатывается, есть? Или это из серии "я знаю, что я пишу хорошо, а если пользователь не понимает, что я пишу, то он тупой?"

[QUOTE]ADVANCED пишет:
Руковожу отделом разработки ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ. Я технический писатель-системный аналитик. Занимаюсь системный анализом, анализом архитектуры систем для написания ТЗ, анализом БД, часто выступаю в роли Бизнес-аналитика для написания требований и спецификаций, а еще product owner-ом, дизайнером интерфейсов, тестировщиком, системным архитектором и консультантом по разным вопросам.
[/QUOTE]Нет, спасибо. Работала так, больше не хочу и не буду. Когда человек занимается всем подряд, то либо объемы работы невысокие, либо все это делается тяп-ляп. Наивысшее качество достигается, когда специалист занимается тем, что предусмотрено его специализацией.

[QUOTE]ADVANCED пишет:
[QUOTE] techwriter пишет:
[QUOTE] ADVANCED пишет:
Как минимум должна быть еще проектная документация - Техническое Задание (задание на разработку, технические требования, спецификация разработки и др.). и ГОСТ тут ВООБЩЕ НИ ПРИ ЧЕМ!!!
[/QUOTE]Разработкой проектной документации должны заниматься аналитики (бизнес и системные), не технические писатели. Технический писатель должен писать документацию для пользователя. ТЗ, ТТ, спецификации разработки являются всего лишь одним из источником информации для разработки документации для пользователя.
[/QUOTE]И чего ? Должны, я не спорю. Но могут писать и более полезную документацию.
Мы обсуждаем классификацию ТЕХНИЧЕСКОЙ документации , а не документацию, написанную начинающими техписами.
[/QUOTE]Что значит более "полезную"? Куда уж полезнее нормально задокументированных требований к системе?

[QUOTE]ADVANCED пишет:
[QUOTE] techwriter пишет:
Считаю, что каталоги документации должны храниться в таком виде:
Роль 1:
Начинающему <роль>:
Документы
Опытному <роль>:
Документы
Роль 2:
Начинающему <роль>:
Документы
Опытному <роль>:
Документы
[/QUOTE]Утверждение не верно! Каталоги документации не должны быть в таком виде :) Они могут быть такими в частном случае.

Глупо разделять на "начинающего" и "опытного" пользователя. Кто определяет границы опыта? Они аттестацию проходят у вас?
Это только лишняя головная боль и создание проблем всем вокруг.

Линуксоид, проработавший 10 лет с программой, перешедший на Windows и не знающий простейшие сочетания клавиш - начинающий пользователь программы?
А опытный бухгалтер, работающий с 1С >10 лет, начинающий тупить при смене темы рабочего стола и значков - тоже начинающий?
[/QUOTE]Границы определяются легко. Если пользователь не знаком с системой, видит ее первый раз в жизни, не знает интерфейса - он начинающий. Пользователь, который умеет выполнять стандартные функции системы - опытный. Опять же не надо усложнять. Первому еще рано выполнять задачи в системе, т.к. он только на стадии ознакомления. Для него должно быть подготовлено описание, которое идет от интерфейса системы. Второму уже неинтересно читать "элементарные" приемы работы с системой. Для него подготавливается описание, которое идет от действий пользователя в системе.
Уровень пользователя определяется исключительно его навыками работы с системой, на которую вы пишете документацию. Не важно, умеет он менять тему рабочего стола и значков или нет. Никакой головной боли нет. По крайней мере, мне опыт подсказывает, что пользователи не хотят читать объемную документацию, в которую свалено все и вся. Он обычно исходит из позиции: я являюсь тем-то, мне надо сделать то-то. Куда мне идти, чтобы это почитать?

[QUOTE]ADVANCED пишет:
Как минимум должна быть еще проектная документация - Техническое Задание (задание на разработку, технические требования, спецификация разработки и др.). и ГОСТ тут ВООБЩЕ НИ ПРИ ЧЕМ!!!
[/QUOTE]Разработкой проектной документации должны заниматься аналитики (бизнес и системные), не технические писатели. Технический писатель должен писать документацию для пользователя. ТЗ, ТТ, спецификации разработки являются всего лишь одним из источником информации для разработки документации для пользователя.

[QUOTE]ADVANCED пишет:
есть еще куча сопроводительной документации, которая относится к [B][U]правильной эксплуатации[/U][/B] продукта
[/QUOTE]Правильная эксплуатация продукта = правильное пользование продуктом. Разве нет?
Не важно, протокол, меры безопасности или инструкция. Документ используется человеком для выполнения правильных действий при работе с продуктом.
Презентация продукта - это отдельная тема. Если продукт презентуется с использованием видео-ролика, это разве вообще документация? Это информационный продукт. Поэтому забугром и принято любой вид представления и описания продукта называть информационным продуктом.
Еще раз повторюсь: если у меня есть свобода от ГОСТов, то я упрощаю и называю всю документацию пользовательской. При этом делается разделение по ролям уровням пользователя. Считаю, что каталоги документации должны храниться в таком виде:
Роль 1:
     Начинающему <роль>:
           Документы
     Опытному <роль>:
           Документы
Роль 2:
     Начинающему <роль>:
           Документы
     Опытному <роль>:
           Документы

[QUOTE]Виктор Фигурнов пишет:
[QUOTE] techwriter пишет:
Эксплуатационная документация" - это ГОСТовый термин, ИМХО. Поэтому и имеет смысл называть документацию эксплуатационную, если она разрабатывается по требованиям ГОСТа.
[/QUOTE]Гостовский солипсизм какой-то... На западе почти никто совковых Гостов не знает, а кто о них что-то знает, как правило, не имеет ни малейшего желания соблюдать эти странные архаичные предписания. Так что, у них на западе эксплуатационной документации поэтому нет? :D
[/QUOTE]Скорее, гостовский солипсизм - это строгое следование им и попытка "подпереть" ими все процессы документирования, исключая факторы индивидуальности процесса на различных проектах.
У них есть user documentation или information products. Даже больше скажу, у них есть types of information.

[QUOTE]ADVANCED пишет:
Это пользовательская документация. Она относится к эксплуатационной.
[/QUOTE]"Эксплуатационная документация" - это ГОСТовый термин, ИМХО. Поэтому и имеет смысл называть документацию эксплуатационную, если она разрабатывается по требованиям ГОСТа. Если технический писатель свободен от ГОСТа и его требований к комплектованию и содержанию документации, то имеет смысл руководствоваться принципом разработки документации, [B][U]ориентированной на пользователя[/U][/B] (=пользовательская документация).

[QUOTE]ADVANCED пишет:
[QUOTE] writer пишет:
[QUOTE]. Возможно начальству покажется нерентабельным занимать кучу писателей на поиск устаревшей информации, вместо того чтобы выполнять текущие задачи.
[/QUOTE]Скорее всего начальству "покажется", что техпис может сам, каким-то образом написать документацию имея только программу на руках и светлую голову. :D
[/QUOTE]А техпису может показаться, что раз никому это не надо было несколько лет, то и "мне не надо". Кто-нибудь когда-нибудть напишет :) ) И все останется как есть.
[/QUOTE]Не всегда у техписа есть такой выбор.

[QUOTE]ADVANCED пишет:
Есть его последователи, которым первоначальный носитель передавал знания. Конечно если проект все еще поддерживается. Если программист уволился несколько лет назад, а вопрос не возникал за эти годы, возможно это не актуально. В данном случае посоветовал бы обратиться к менеджеру проекта и обсудить целесообразность. Возможно начальству покажется нерентабельным занимать кучу писателей на поиск устаревшей информации, вместо того чтобы выполнять текущие задачи.
[/QUOTE]Вот, не факт. Случались случаи в моей практике, когда первоначальный носитель ничего не передавал, уволился, и функционал был не нужен несколько лет. Через несколько лет понадобился. Поскольку никто не знает, для чего он, требовалась документация. Приходилось с программистами копаться в функционале, по крохам собирать инфу и писать.

[QUOTE]ADVANCED пишет:
[QUOTE] techwriter пишет:
К сожалению, H&M у нас нет. Владею только HHW, поэтому у меня самописная chm-справка, которая состоит из HTML, CSS и JS.
[/QUOTE]DITA Open Toolkit :)
[/QUOTE]О да, своевременно :)))

Доброе утро

Какая актуальная тема :)))
К сожалению, H&M у нас нет. Владею только HHW, поэтому у меня самописная chm-справка, которая состоит из HTML, CSS и JS. Сегодня как раз будет привязывать справку к приложению и тестировать на пилоте :))
Тоже сначала хотели привязывать через Topic ID. Нам показалось муторным в дальнейшем работать с ID. Решили, что путь к файлу уникален.
Пробовали сначала автоматизировать процесс получения справки в нужном месте через вызов соответствующего файла, дабы сократить ручную работу программиста. Предполагалась соответствующая структура справки. Но не получилось из-за некоторых ограничений средств разработки. В итоге, договорились, что программист просто указывает в нужном месте путь к нужному разделу справки. Пользователь, находясь в этом разделе, нажимает кнопку F1. Открывается привязанный раздел справки.

[QUOTE]Elanor пишет:
На примере игры:
Если компания создала движок для создания компьютерных игр (был такой RPG Maker), то у этого движка два уровней пользователей: те, кто на нем создают игры ("разработчики" по сути), и те, кто в них играют (конечные пользователи - игроки).
[/QUOTE]Вот-вот. Я о том же :))) Есть системы, у которых есть фронт- и бэк-офис. Бэк-офис может быть как для администраторов, так и для разработчиков. Если бэк-офис существует, то и пользовательская документация по нему должна быть.

[QUOTE]Виктор Фигурнов пишет:
[QUOTE] techwriter пишет[/QUOTE]
[QUOTE]Виктор Фигурнов пишет:
Как правило, разработчик - не пользователь. Разработчик тампакса может быть мужчиной, например.  :)  [/QUOTE]
[QUOTE]А кто ж он?[/QUOTE]Мало ли кто. Программист, дизайнер, художник, менеджер, и т.д.

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

А в эту игру он не играет. Вообще. Значит, он не пользователь.
[/QUOTE]Это разные виды пользователей. Если вы утверждаете, что такого вида пользователя как разработчик не существует, то и документации для них вы не выделяется как класс. Вы что включаете в документацию разработчика?

[QUOTE]writer пишет:
если, например, этот пункт Выбираем носителя информации из числа разработчиков , реализовать нельзя? Т.е нужно самому разбираться в том , что сделано используя таски и какую-то рабочую документацию, в которой пара строчек о том как это должно работать)?
[/QUOTE]Или носитель информации уволился несколько лет назад :)))