Comments 18
Потому что ни кто не хочет тратить на это своё время.
Всё написано юридическим языком, чтобы к ним нельзя было придраться.
Это не интересная повесть, которую хочется читать, поэтому не стоит привлекать.
Это только обязательства, которые на вас накладывают по закону.
Вопрос статьи поставлен несколько неверно, так как проблема не в пользователях, а в программах и программистах.
Создатель программы должен исходить из простой мысли, что средний условный юзверь, это условный "умственно отсталый человек", который не читал и читать не умеет, и проектировать интерфейс и алгоритм взаимодействия программы с пользователем исходя из этого факта. Не знаю, какая практика и идеология сегодня, но ещё в начале 2000-х считалось правилом хорошего тона то, что минимум 50% кода описывало защиту от "дурака", т.е. от несанкционированных действий пользователя.
Идеальная программа вообще не должна требовать чтения документации пользователем, для нормальной работы с ней.
Естественно идеал недостижим, но стремиться надо.
Создатель программы должен исходить из простой мысли, что средний условный юзверь, это условный "умственно отсталый человек", который не читал и читать не умеет, и проектировать интерфейс и алгоритм взаимодействия программы с пользователем исходя из этого факта. Не знаю, какая практика и идеология сегодня, но ещё в начале 2000-х считалось правилом хорошего тона то, что минимум 50% кода описывало защиту от "дурака", т.е. от несанкционированных действий пользователя
Тут главное не переборщить, вовремя остановиться и помнить другое правило: создайте программу, которой может пользоваться любой дурак, и только дурак захочет ею пользоваться. :-)
... создайте программу, которой может пользоваться любой дурак, и только дурак захочет ею пользоваться.
Вы правы. Но, это опять же проблема программиста, а не пользователя: Если программист дурак, то и программа у него дурацкая. :)
Когда-то давно у меня в руках оказалось официальное руководство по ЕМНИП "Виндовс сервер" на русском языке. Это было что-то типа такого:
Для входа в панель изменения настроек режима отображения панели инструментов выберите пунт меню "Панель изменения настроек режима отображения панели инструментов"
И такое творчество встречается и сейчас...
Идеальная программа вообще не должна требовать чтения документации пользователем, для нормальной работы с ней.
Смотря в какой сфере программа. Если это простая рисовалка для детского развития на Андроид - это да, она максимально интуитивно понятная будет. Но если это серьёзный продукт (профессиональный графич.редактор, CRM, и т.п.), то лучше иметь документацию. Она понадобится минимум для двух случаев:
юзер (админ) таки что-то не может найти и ему придётся заглянуть в доку. И лучше, чтобы она была, чем он будет надоедать саппорту.
юзер (админ, что намного печальнее) что-то сломал/некорректно настроил/удалил какие-то привязки с другим ПО/и т.п., и теперь непонятно как починить без переустановки продукта. То есть ему надо увидеть таки рекомендуемый способ настройки нужных параметров и заново их конфигурировать.
Ну и да, даже у телеграма есть раздел с мануалами https://telegram.org/faq и явно не ради удовлетворения конкурса на поставку ПО гос.конторе 😊
Основная проблема - это разный уровень подготовки пользователей. Ну, и личностные характеристики, конечно. Каждый конечный пользователь всегда переоценивает свои знания и пропускает разделы "быстрое знакомство" или "учебник". А дальше... Про F1 помнят уже только динозавры. Этот пункт можно вычеркивать. Разница между меню "справка" и бумажной документацией из моего опыта не принципиальна. А вот содержимое... Но тут все очень специфично для продукта, и выдавать готовые рецепты было бы дурным тоном. А вот выкладывание видеоуроков (коротких) с решением типовых задач и внятными комментариями по "углублению"... Да, "динозавров" это выбешивает. Быстрее прочитать. Но это отлично работает с современной аудиторей.
Отдельно стоит сказать о тех случаях, когда формат, стиль и содержание документации четко регламентировано. В некоторых случаях можно попробовать пересмотреть регламент, но чаще разумным вариантом будет выпуск документа типа "Руководство по быстрому старту". Было бы неплохо, чтоб оно шло приложением к обязательной документации и не занимало больше двух страниц.
Вообще по документации это очень больная тема. Что касается пользовательской документации, то в идеале ее должны писать не разработчики. Но то в идеале. А в реальной жизни единственный совет, который можно и должно дать разработчику - в документации должен быть четко обозначенный пункт, открыв который типовые действия смог бы выполнить школьник из начальной школы. Идеально уложиться в две страницы - т.е. быть шпаргалкой, в которую всегда можно заглянуть не занимаясь поиском по многостраничному талмуду. И именно эту шпаргалку надо корректировать основываясь на обратной связи.
.... Что касается пользовательской документации, то в идеале ее должны писать не разработчики. ...
В идеале "Руководство пользователя" должно быть частью ТЗ выданного заказчиком программисту.
Но, в свою очередь, встретить грамотное ТЗ, такая же проблема, как встретить грамотное "Руководство пользователя".
Что касается пользовательской документации, то в идеале ее должны писать не разработчики.
Да, есть специальный отдел у крупных контор для этого - технические писатели. Они обладают скиллом писать понятно о сложном, и в то же время достаточными айти-скиллами, чтобы разобраться в продукте максимально глубоко. У любого крупного разработчика ПО есть обширные разделы инструкций, достаточно зайти на сайт Adobe, Яндекса, та кого угодно.
Когда пишет документацию разработчик - он тратит своё время не на свои обязанности. Это оправдано только если фирма маленькая, или это некий стартап, в общем есть момент экономии на кадрах. Или если самому разработчику это по приколу, и у него получается неплохо )
Про две страницы - зависит от продукта. По фотошопу условному не просто так сотни сайтов с инструкциями, та и свой хелп есть, т.к. продукт весьма сложен и без документации ты просто можешь не найти простой способ что-то сделать, и будешь заниматься "попиксельным рисованием".
Согласен. Единственный момент, который хотелось бы уточнить сформулировала еще мартышка из известного мультика. Т.е. вопрос какую компанию уже считать достаточно крупной чтобы создавать отдел подготовки документации. Да и документация для пользователя разительно отличается от документации для разработчика и каждая из них отличается от документации для отдела сопровождения разработок. В идеале разные документы должны писать разные люди. А навык документирования своей работы еще ни одному разработчику не мешал. Он, помимо прочего, позволяет взглянуть на свое творение со стороны и понять что бы стоило сделать более понятным (в том числе и интуитивно).
С двумя страницами - признаю. Погорячился. Впрочем, тот же фотошоп он весьма обширен и какую задачу там считать типовой вопрос крайне интересный. При этом открытие и импорт, создание, сохранение и экспорт, печать - безусловно типовые операции для практически любого программного продукта. И, пожалуй, в две страницы можно уложиться.
Но в общем - совершенно согласен с вашими доводами.
Часто, их пишут профессионалы, для профессионалов. Потому и не читается. А если и читается, то не понимается)
Проблема в том что грамотное и полное ТЗ окончательно может сформироваться уже при 90%% готовности проекта, т.к. много доп согласований и изначально не закладываемых работ и решений, т.к. изначально тз может звучать в стиле "семь красных линий", а после начала работы с заказчиком проект может стать вполне реализуемым, но не отвечать изначальному ТЗ
По личному опыту разработки и использования различных продуктов большинство "ситуаций" вызвано неверными действиями пользователей, не читавших документацию. А вот дальше вопрос почему не читают:
не хотят (решается в стиле если ничего не помогает прочтите наконец инструкцию, т.е в стиле пром предприятий расписывается за инструктаж, т.е расписываемся по прочтению, )
инструкция слишком короткая, без пояснений сложных моментов.
инструкция слишком сложная и ее не возможно воспринимать пользователям к их непосредственным действиям , т.е в какой момент какую последовательность применять.
есть несколько инструкций общая и отдельные составляющие проекта, но непонятна связанность для конкретных действий конечного пользователя при работе с проектом
Инструкции есть все но некоторые части слегка устарели после обновлении версии проекта.
на основании все выше перечисленного ну и немного подсмотрел пришел к выводу что оптимальным это написание краткой инструкции в стиле "быстрого старта", но ссылками на инструкции составляющих частей, и расширенную инструкцию с подробным описанием моментов работы в проектом.
на основании все выше перечисленного ну и немного подсмотрел пришел к выводу что оптимальным это написание краткой инструкции в стиле "быстрого старта", но ссылками на инструкции составляющих частей, и расширенную инструкцию с подробным описанием моментов работы в проектом
На самом деле у нас тоже похожий подход в компании: мой отдел технических писателей составляет полную исчерпывающую документацию по всем разделам продукта, но есть короткие статьи с решениями определённых задач. Например, т.к. мы занимаемся видеосвязью, есть статья "Как позвонить пользователю", "Как организовать вебинар" и так далее.
Исходя из собственного опыта и процессов создания и демонстрации инструкций, скажу что в разных компаниях по-разному. Мало того, для каждого индивидуальный подход нужен. Особенно для топ-менеджмента. Одни очень довольны строгими инструкциями и за каждое лишнее слово спросят, другие очень не хотят инструкций в тестовом формате, только демонстрация или видеоинструкции, третьи пытаются сами и спрашивают только то что не поняли и довольны таким подходом...
Хорошим решением был бы способ "автоматической" написания документации во время написания/правки кода, иначе на нее у программиста не остается времени никогда т.к. всегда есть код который надо написать/исправить.
Секрет хорошего руководства пользователя - "Больше картинок, меньше слов".
Почему пользователи не читают документацию или как можно улучшить руководство пользователя