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

В данный момент у нас нет отдела технической документации... Есть команда, состоящая из 6 человек: 4 разработчика, 1 тестировщик и 1 технический писатель. Задачи назначаются не отдельного человека, а на команду. В основе - принцип самоорганизации команды. Основной акцент не на достижении членом команды какого-то своего результата, а именно вклад в решение задач команды.

Доброе утро!

[QUOTE]writer пишет:
Поделимся опытом в добывания информации от разработчиков. Как вы узнаете про новый функционал, каким образом записываете информацию (диктофон, текстовые заметки, примечания/правки в документации...).
[/QUOTE]Сейчас я работаю по Agile. Мне он нравится тем, что я равный член команды и участвую в процессе обсуждения доработок, планировании работ, их оценке. Каждый день у нас stand up, на котором я могу озвучить свои результаты, и главное, вопросы и трудности, которые у меня возникают. Поскольку задачи ставятся на команду, а не на конкретного участника, то в достижении цели заинтересованы все, из-за чего автоматически устанавливаются отношения взаимопомощи. Считаю, что пока что это самая удачная практика в моей карьере технического писателя, а работаю я им почти 9 лет :)))

Мой первый шаг - наладить доброжелательные отношения. При общении стараюсь быть вежливой и ненадоедливый. Всегда предлагаю такой вариант: "Василий (например), я сейчас пишу руководство по работе с модулем "<Название модуля>". Я изучила функционал, но у меня есть некоторые вопросы. Когда вам было бы удобнее меня проконсультировать? Консультация по времени примерно займет <ваша оценка в часах или минутах>". Конечно, предварительно я действительно трачу время на изучение функционала, записываю себе вопросы и уже с этим перечнем иду к программисту в назначенное время. В конце беседы всегда спрашиваю: "В каком формате вам можно задавать небольшие вопросы, которые могут возникать в процессе разработки документа?" Конечно, вопросы должны быть по существу и по адресу.
Короче, моя тактика такова, что я не спрашиваю, можно мне задавать вопрос или нет. Я просто спрашиваю, только стараюсь это делать максимально удобно для программиста. Если встречается программиста, который отказывается отвечать на мои вопросы, регулирую этот вопрос через начальство с качественным обоснованием, почему мне нужна консультация.

[QUOTE]fs444 пишет:
Всем привет. Только начинаю путь технического писателя. В одной из фирм предложили выполнить тестовое задание - написать "Руководство оператора" к любой программе записи CD. При этом использовать "ГОСТ 19.505-79 Руководство оператора". Пока мне никто не перезвонил)) Кому не сложно, прошу оценить уровень выполненной мною работы. [url]https://yadi.sk/i/tk2xm_IRXAoCp[/url]
[/QUOTE]По содержанию для новичка неплохо, но вот оформление хромает. Попробуйте поизучать стили.
Еще неплохо было бы пронумеровать и подписать рисунки, а также инструкции сделать в виде нумерованных списков.
Если доведете до ума, сможете отправлять пример как приложение к резюме  ;)

[QUOTE]Виктор Фигурнов пишет:
ISO/IEC/IEEE 26515:2011 Systems and software engineering -- Developing user documentation in an agile environment
[/QUOTE]
Стандарт подходит тем, кто по Agile работают.

Я бы полностью переписала руководство пользователя, а ПМИ написала бы только на функции, перечисленные в ТЗ.

У меня, наоборот )) Если появляются, то сразу несколько и комплектами ))

[QUOTE]writer пишет:
так вот и вопрос...на что?)
[/QUOTE]В зависимости от контекста :)

[QUOTE]writer пишет:
никакой, но без него никак)) просто система понимает что груз поступил и его повезли куда-то)
[/QUOTE]Придумала только один вариант: распределение груза по машинам :) ) Мне кажется такой вариант понятнее "привязки" или "связки".

Занимаюсь с фрилансом с 2010 г. Всегда все по-разному. Но, по моим наблюдениям, основной сезон - лето и ноябрь-декабрь. С оплатой тоже по-разному. Сейчас у меня, например, есть выгодный заказ. Работаем по договору подряда. До этого было вообще все тихо. В целом, меня доход от моей подработки устраивает. При наличии постоянной работы доход получается нормальным. Ну, для меня нормальным, конечно ))

Один отпуск прошел мимо меня в этом году. А в сентябре пока что планируется Турция, Белек.

[QUOTE]writer пишет:
Есть, например, груз, чтобы его отвезти, нужно привязать к нему машину. Чтобы это все заработало, нужно в окне Груз выбрать машину, в окне Машина , выбрать груз. Вот такой пример.
[/QUOTE]А какой процесс автоматизируется при этом? ;)

3. в окне "перечень объектов".

[QUOTE]writer пишет:
Критерий тоже стараюсь не использовать, но вся предыдущая документация как раз одни настройки критериев )
[/QUOTE]Ох! Считаю, надо заменить во всей документации :(

"Переключатель" - больше к производственному термину относится (применим к техническому устройству). Радиобатон - поле выбора одного значения. Поэтому пишу так: "В поле <название поля> выберите значение ... " (если нужно описать выбор определенного значения) или "В поле <название поля> выберите одно из значений ... " (если нужно описать все возможные значения поля).

Зависит от контекста настройки. Иногда устанавливаю признак, иногда включаю режим, иногда выбираю условие и т.д, и т.п.. Слово "критерий" вообще не использую. Оно мне не нравится. Впрочем, слово "параметр" тоже стараюсь не употреблять.

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

Настройка связи параметров?

Сегодня случайно наткнулась:
[url]https://www.firebase.com/how-it-works.html[/url]

Почти за 10 лет опоздала один раз на 10 минут. Не знаю, считается ли 10 минут опозданием.

[QUOTE]Виктор Фигурнов пишет:
Более подробно смотрите здесь:

[url]http://deseng.ryerson.ca/dokuwiki/design:usage_scenario[/url]
[url]http://www.redline-software.com/eng/products/surfcop/scenarios/[/url]
[/QUOTE]Такие сценарии, скорее, при проектировании пишутся.

[QUOTE]writer пишет:
ну к примеру, есть банковское ПО, руководство пользователя описывает всю инструкцию для пользователя, что нужно и не нужно, а типовой сценарий работы, это что-то типа "Как положить денежку на карту", "Как снять денежку", "Как посмотреть баланс на карте" вот такие сценарии.
[/QUOTE]В руководстве пользователя разве эти действия не описываются? Изложение руководства пользователя может идти от интерфейса и от действий пользователя. Я обычно исхожу как раз от действий пользователя. Если изложение от действий, то в нем оно строится таким образом: цель, которую нужно достичь пользователю - действия, которые необходимо выполнить. Если достичь цель можно несколькими способами, то описываются все случаи. Я так понимаю, что сценарии просто кратко описывают процедуру выполнения действий пользователя для достижения целей (без подробного описания полей формы, например). Допустим, "Зайдите в такой-то раздел, нажмите такую-то кнопку, заполните такую-то форму и т.д., и т.п. Мне даже больше тест-кейсы напоминает, чем юз-кейсы. Только более мультимедийные.

[QUOTE]Орлов Андрей пишет:
Если заказчики - это НИИ, министерства и ведомства, то считайте и читайте так: "фирма получает госзаказы, которые гарантирует её стабильность, фирма штат которой 200 человек минимум, и для этих заказчиков следование букве РД 50-34.698-90 обязательно"
[/QUOTE]Это точно! Для госзаказчиков разработка по РД 50-34.698-90 - это святое :))

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