Comments 12
Мы делали так: объявили кункурс в ВУЗе на програмерской специальности с целью найти толькового писателя. Оценивали любой собственноручный мануал к любой программе. Победитель получал на лето работу на 250$. В итоге девочка писала в следующем образом: показывался/объяснялся очередной модуль, осваивался писательницей, она уходила и писала дома (софт и БД у нее были). Потом я правил сам мелочи. Все довольны, програмеры мануал не писали, документ получился понятным для пользователей.
У нас программеры не пишут мануал :) они консультируют пишущего и правят, если это необходимо
У наших пользователей в основном такие:
1. разбиение на части/главы по: процессам, пользователям, задачам.
2. наличие пошаговых инструкций
3. скриншоты с подписями
4. перекрёстные гиперссылки внутри инструкции
5. сквозная актуальность
6. возможность распечатать
А как по-вашему распределить «основной текст» мануала и пошаговые инструкции? В виде примеров или лучше подготовить отдельный раздел файла «Приложение»?
Мы делали так: идёт основной текст мануала, действия описываемые первый раз описываются пошагово со скринами. Далее по тексту действие просто называется и ссылается на пошаговую инструкцию.
показателем хорошего мануала для меня может быть:
1. Чтобы его было достаточно, и мне не пришлось искать информацию где-то еще (например в Интернете)
2. Никаких разногласий. Иногда бывает — в программе называется одним словом, в мануале расписывается другим
3. Примеры использования, т.е. чтобы получить одно — нужно сделать вот это, затем это и тд.
4. Он должен быть актуальным, это очень важно (иначе зачем нам мануал, который уже устарел и не подходит для свежей версии)
5. Его нужно делить по категориям. Никакой кучи… никому не хочется разгребать большой текстовый файл, чтобы найти маленькую инструкцию

ну всё… сегодня пятница, поэтому в голову больше ничего не лезет :)
А вот такой вопрос: если программный продукт имеет модульную систему и в конечной сборке набор этих самых модулей определяется по желанию заказчика, как поступить? писать отдельный мануал для каждого модуля? (возможно, это будет не удобно для прочтения) или поступить более сложно, но индивидуально — собирать мануал в единое целое под каждый реализованный проект для каждого заказчика?
В хорошем мануале должно быть просто искать. Поэтому формат или «плоский» html (весь текст в одном файле) или PDF с текстовым слоем.

Хороший мануал можно читать от корки до корки, а можно пользоваться им как справочником. Например, www.mpi-forum.org/docs/mpi-2.2/mpi22-report.pdf Если так не получается, то надо писать две части, выполняющие эти две задачи.
В хорошем мануале должно быть можно найти ответы на любые возникающие вопросы, и найти их быстро. Лично я не люблю, когда мануал написан грамматически кривым языком, или когда его писали программисты, не понимающие, что мануал пишется для пользователей, или же когда по стилю видно, что автор не разбирается в том, о чем пишет.
А верно ли тогда писать мануалы отдельно для простых пользователей и отдельно для администраторов?
Конечно. Посмотрите по сайтам программ — очень часто отдельно лежит User guide, отдельно Admin guide.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
2000
Location
Россия
Website
www.mcn.ru
Employees
101–200 employees
Registered