Comments 12
Мы делали так: объявили кункурс в ВУЗе на програмерской специальности с целью найти толькового писателя. Оценивали любой собственноручный мануал к любой программе. Победитель получал на лето работу на 250$. В итоге девочка писала в следующем образом: показывался/объяснялся очередной модуль, осваивался писательницей, она уходила и писала дома (софт и БД у нее были). Потом я правил сам мелочи. Все довольны, програмеры мануал не писали, документ получился понятным для пользователей.
У наших пользователей в основном такие:
1. разбиение на части/главы по: процессам, пользователям, задачам.
2. наличие пошаговых инструкций
3. скриншоты с подписями
4. перекрёстные гиперссылки внутри инструкции
5. сквозная актуальность
6. возможность распечатать
1. разбиение на части/главы по: процессам, пользователям, задачам.
2. наличие пошаговых инструкций
3. скриншоты с подписями
4. перекрёстные гиперссылки внутри инструкции
5. сквозная актуальность
6. возможность распечатать
показателем хорошего мануала для меня может быть:
1. Чтобы его было достаточно, и мне не пришлось искать информацию где-то еще (например в Интернете)
2. Никаких разногласий. Иногда бывает — в программе называется одним словом, в мануале расписывается другим
3. Примеры использования, т.е. чтобы получить одно — нужно сделать вот это, затем это и тд.
4. Он должен быть актуальным, это очень важно (иначе зачем нам мануал, который уже устарел и не подходит для свежей версии)
5. Его нужно делить по категориям. Никакой кучи… никому не хочется разгребать большой текстовый файл, чтобы найти маленькую инструкцию
ну всё… сегодня пятница, поэтому в голову больше ничего не лезет :)
1. Чтобы его было достаточно, и мне не пришлось искать информацию где-то еще (например в Интернете)
2. Никаких разногласий. Иногда бывает — в программе называется одним словом, в мануале расписывается другим
3. Примеры использования, т.е. чтобы получить одно — нужно сделать вот это, затем это и тд.
4. Он должен быть актуальным, это очень важно (иначе зачем нам мануал, который уже устарел и не подходит для свежей версии)
5. Его нужно делить по категориям. Никакой кучи… никому не хочется разгребать большой текстовый файл, чтобы найти маленькую инструкцию
ну всё… сегодня пятница, поэтому в голову больше ничего не лезет :)
А вот такой вопрос: если программный продукт имеет модульную систему и в конечной сборке набор этих самых модулей определяется по желанию заказчика, как поступить? писать отдельный мануал для каждого модуля? (возможно, это будет не удобно для прочтения) или поступить более сложно, но индивидуально — собирать мануал в единое целое под каждый реализованный проект для каждого заказчика?
В хорошем мануале должно быть просто искать. Поэтому формат или «плоский» html (весь текст в одном файле) или PDF с текстовым слоем.
Хороший мануал можно читать от корки до корки, а можно пользоваться им как справочником. Например, www.mpi-forum.org/docs/mpi-2.2/mpi22-report.pdf Если так не получается, то надо писать две части, выполняющие эти две задачи.
Хороший мануал можно читать от корки до корки, а можно пользоваться им как справочником. Например, www.mpi-forum.org/docs/mpi-2.2/mpi22-report.pdf Если так не получается, то надо писать две части, выполняющие эти две задачи.
В хорошем мануале должно быть можно найти ответы на любые возникающие вопросы, и найти их быстро. Лично я не люблю, когда мануал написан грамматически кривым языком, или когда его писали программисты, не понимающие, что мануал пишется для пользователей, или же когда по стилю видно, что автор не разбирается в том, о чем пишет.
Sign up to leave a comment.
Что такое хороший мануал к ПО?