Руководство по эксплуатации. Всё, что нужно знать о документе.
В чем разница между User Guide и How-to Guide? На первый взгляд кажется, что особой разницы нет. Оба этих типа документации в той или иной мере содержат пошаговое объяснение того, какие шаги нужно выполнить дабы достичь определенной цели. Таким образом, и в User Guide и в How-to Guide почти наверняка будет последовательное описание действий, необходимых для выполнения той или иной пользовательской задачи. Что же тогда их отличает? Расскажу, как эту разницу понимаю я😺 Начнем с того, что у этих документов разная целевая аудитория. User Guide нужен для того, чтобы условному новичку вообще рассказать о том, что из себя представляет объект описания. А вот How-to Guide помогает уже опытному пользователю с решением конкретной задачи в рамках объекта описания. Давайте посмотрим на примере youtube, чтобы было понятнее)) Представим, что есть человек, который вообще никогда не пользовался youtube. User Guide расскажет что такое ютуб, для чего он нужен, что там размещается, как там работает функция поиска, на что и куда нужно нажать, чтобы посмотреть видео и тд. В то же время How-to Guide может помочь пользователю, который уже знаком с площадкой youtube, узнать, например, как выставлять в видео тайм коды, как загрузить свое видео, как настроить монетизацию (когда-то это было актуально) и тд. Краткий итог такой: User Guide нужен для новичков, чтобы те могли узнать, что из себя представляет тот или иной сервис и как начать с ним работу, а How-to Guide объясняет уже опытным пользователям как решить некоторые специфические задачи с помощью этого сервиса. В общем, сначала нужно понять, что 2x2=4, прежде чем решать квадратное уравнение) А как вы понимаете разницу между этими двумя типами документации? Пишите в комменты 🙂
Что такое User Story с примерами
User Story (пользовательская история) - это краткое описание требований к функциональности, которая должна быть реализована в программном продукте или сервисе. User Story - это инструмент Agile-разработки, который позволяет описать конкретный функциональный элемент продукта из точки зрения пользователя, а не разработчика. Понятнее не стало? Давай проще. Мы говорим о более правильной и корректной формулировке задач, чтобы каждому участнику команды разработки было ясно о чем идет речь в задаче. Мы всегда куда-то спешим и экономим время на всем...