Всё для технического документирования
+7 (495) 001-40-42
Разработка технической документации
Курсы для технических писателей
Программное обеспечение

БЛОГ

Что такое минимализм (часть 3)

29.11.2013

01Часть третья статьи о минимализме – о том, как преодолеть существующую ментальную модель пользователей и зачем это нужно.


Минимализм означает примерно следующее: минимизация в инструкциях препятствий в пользовательском процессе придания смысла. И это не предохранение пользователей от совершения ошибок вообще, а, скорее, помощь им в избежании тех ошибок, которые они бы совершили неминуемо. Фактически, ошибка – это такой момент, который можно узнать и, таким образом, избежать её, благодаря контенту.

Таким образом, хотя принципы – это хорошо для систем справки, которые соответствуют целям минимализма, знания принципов само по себе недостаточно, чтобы создать справку, которая будет минимизировать препятствия в процессе придания смысла пользователей.

Что принципы сами по себе не смогут сделать, так это как раз то, о чём гласит парадокс придания смысла: они не смогут сломать существующую ментальную модель у пользователей. Если ваша текущая ментальная модель – какой-либо вид систематического обучения (у большинства людей это так, не важно, в каком поле деятельности вы работаете), вы можете читать и впитывать принципы, но вы примите их в контексте систематического обучения. То, что у вас получится, будет напоминать сжатое систематическое обучение.

Читать дальше…


Записи докладов конференции ТехДок 2013

28.11.2013

Logo_TechDoc201327 и 28 ноября прошла конференция ТехДок 2013. Ура! 🙂

Спасибо всем докладчикам, участникам, а также информационным партнёрам, которые помогли нам собрать аудиторию. Максимальное одновременное количество участников онлайн было 118 человек, и цифра не опускалась весь день ниже 100. Мы очень рады, что мероприятие вызвало интерес и собрало множество положительных откликов! Теперь конференция для технических писателей станет ежегодным событием, и мы будем рады, если аудитория будет расширяться, и в России и странах ближнего зарубежья появится сообщество технических писателей, редакторов и переводчиков. Вместе веселее! 🙂

С удовольствием принимаем отзывы на электронную почту (info@protext.su), в соцетях и на сайте. Уже есть дельные замечания и мы постараемся учесть их в будущем.

Представляем записи докладов конференции. Читать дальше…


Что такое минимализм (часть 2)

27.11.2013

01Во второй части статьи с помощью цитат из книги Джона Кэрролла доказывается необходимость минимализма и невозможность преодоления парадокса придания смысла.


Приспособление к парадоксу придания смысла – это фраза Джона Кэрролла (John Carroll), использованная для описания того, что он или его коллеги узнали путём эксперимента над тем, как люди изучают компьютерные системы. Что мы могли ожидать: люди с наименьшими знаниями системы должны были полагаться на документацию больше всех, для того чтобы она провела их через незнакомые дебри. Новички читают документы; эксперты могут понять всё сами – это классическая модель. Кэрролл же выяснил, что всё с точностью до наоборот: чем меньше люди знают и меньше опыта имеют, тем меньше они читают документацию.

Причина и парадокс состоят в том, что люди подходят к новой системе с существующей ментальной моделью задачи и способа её решения. Документация, описывающая новый инструмент, конфликтует с этой ментальной моделью. Если методика говорит им сделать что-то, что не соответствует их ментальной модели, они верят своей ментальной модели больше, чем методике.

Читать дальше…


Что такое минимализм (часть 1)

25.11.2013

01Представляем первую часть статьи Марка Бэйкера о том, что такое минимализм в технической документации и как его достичь. В первой части речь идёт о причинах необходимости стремления к минимализму.


Спросите, что такое минимализм (в контексте технических коммуникаций), и вы, скорее всего, придёте к цитированию четырёх принципов минимализма.

Согласно Джо-Энн Хэкос (JoAnn Hackos), основные четыре принципа минимализма такие:

Принцип 1: Выбирайте подход, ориентированный на действие.

Принцип 2: Делайте документ удобным с точки зрения поиска нужной информации.

Принцип 3: Обеспечьте доступ пользователя к информации об ошибках и их устранении.

Принцип 4: Обеспечьте информацией о том, как сделать, как научиться и как систематизировать.

Это объяснение изнутри. Это всё равно, что отвечать на вопрос, что такое банка персиков, говоря, что это банка, в которой сироп и разрезанные персики. Это определение не содержит объяснение того, почему вы должны положить немного таких же изумительных, как и свежих персиков в банку. Это всё ответ на вопрос «что?», а не «зачем?».

Читать дальше…


Yahoo вырвала влиятельного технического писателя из NY Times

22.11.2013

Сегодняшняя публикация – новость и рассказ об одном из самых влиятельных технических писателей в мире, опубликованная в конце октября 2013 года, и оценка ситуации с печатными изданиями в Америке.


Yahoo-Technology Columnist

Саннивейл, Калифорния – ведущий колонки о технологиях и обозреватель гаджетов New York Times  Дэвид Пог (David Pogue) покинул газету, чтобы освещать те же темы для Yahoo.

Найм, анонсированный в понедельник, – это крайний шаг в попытке Мариссы Мейер, исполнительного директора компании Yahoo, привнести на сайт компании больше захватывающего контента, который обеспечит более частые посещения и задержит людей на сайте на более длительное время. Мейер надеется, что возросший трафик в значительной степени подстегнёт продажи рекламы, хотя такого пока ещё не было за первые 15 месяцев её работы на этой должности.

Читать дальше…


Эджайл и технические коммуникации: как видят скрам писатели (часть 2)

20.11.2013

01Во второй части статьи о работе скрам-команд речь идёт о роли технических писателей в этих командах и о преимуществах от этого процесса для них.


Преимущества скрама для писателей

Скрам-подход подключает писателей во все области разработки продукта, и это ключевой момент для вашего успеха в команде. Когда вы участвуете с начала и знаете требования, дизайн и намерения, стоящие за дизайном программного обеспечения, вы не только получаете необходимую информацию, которая требуется для описания продукта, но и демонстрируете другим командам, отвечающим за функциональность (разработка, контроль качества), что вы настроены серьёзно изучить продукт. В результате вы получаете неоценимое уважение, какие-то хорошие отзывы и приглашение присоединиться к оркестру на следующий сезон.

Читать дальше…


Эджайл и технические коммуникации: как видят скрам писатели (часть 1)

18.11.2013

01В данной статье Алисса Фокс, директор по производству информации и программному менеджменту из Техаса, рассказывает о том, как воспринимать и участвовать техническим писателям в производственных процессах, организованных по технологии скрам (scrum), входящей в идеологию эджайл (agile).


Среди всех форм разработки по эджайл, которые могут выбрать и использовать команды, скрам является наиболее распространённой. Скрам – это подход к разработке по эджайл, который делает акцент на близком взаимодействии посредством летучек с целью увеличения скорости и гибкости процесса разработки.

Скрам-команда состоит из владельца продукта (часто он является менеджером по продукту), разработки, инженеров по качеству и разработки информации (это вы!). Важно, чтобы писатели работали в скрам-команде бок о бок с разработчиками и инженерами по качеству, чтобы оставаться в курсе всех аспектов: дизайн, актуализация проекта, разработка продукта и т.д.

Читать дальше…


Разработка теории пользователя (часть 3)

15.11.2013

01В заключительной части статьи Марк Бейкер говорит о необходимости защищать созданную и утверждённую теорию пользователя, о необходимости отсылки к доказательствам положений этой теории и необходимости её постоянного совершенствования.


Защищайте вашу теорию пользователя

Когда документ, в котором закреплена ваша теория пользователя, завершён, и (будем надеяться) подписан широким кругом лиц вашей компании, и включен в официальный план проекта, защищайте его.

Не важно, насколько план может быть основан на фактах или предположениях – когда он завершён, относитесь к нему как к абсолютной истине. Используйте его как пособие по написанию контента, а также по определению образцов вашего контента. Убедитесь, что редакторы и критики критикуют в соответствии с теорией пользователя (и объясните им, что их отзывы имеют небольшую ценность, если они не согласуются с теорией пользователя как контрольной точкой).

Если кто-то просит вас включить контент, который не соответствует теории пользователя, объясните им, что их предложение не соответствует теории пользователя. Если они скажут, что теория неверная, спросите их, как она должна быть изменена и (в идеале) попросите их денег в количестве, достаточном, чтобы удовлетворить их просьбу.

Читать дальше…


Разработка теории пользователя (часть 2)

13.11.2013

01Во второй части статьи Марк Бейкер пишет о необходимости выработки общей теории пользователя для всех сотрудников компании, работа которых зависит от представления о среднестатистическом пользователе разрабатываемого продукта.


Распространите свою теорию пользователя

Наверняка в головах различных людей в вашей компании содержится громадное количество отфильтрованных знаний о пользователях. Например, инженеры поддержки тратят целый день на разговоры с пользователями, но их видение может быть пристрастным, так как они говорят только с теми людьми, которые не могут разобраться сами. Продавцы также тратят весь день на разговоры с клиентами. Однако их видение может быть также предвзятым, потому что, разговаривая с людьми, они помогают им принять решение о покупке, а не помогают им использовать продукт. С другой стороны, они часто знают, как никто другой в компании, о том, какие проблемы необходимо решать людям, которые покупают ваш продукт.

Читать дальше…


Разработка теории пользователя (часть 1)

11.11.2013

01Начинаем публикацию статьи Марка Бейкера, специалиста по структурному и основанному на топиках техническому писательству. В данной статье речь идёт о том, что технический писатель должен ясно представлять себе, для кого пишет, а для этого необходимо разработать собственную теорию пользователя.


Каждый документ пишется для читателя, это означает, что у каждого писателя есть теория читателя – идея о том, кто есть читатель. В технических коммуникациях читатель – это пользователь (продукта или сервиса). У каждого технического писателя, таким образом, есть теория пользователя. Эта теория может быть тщательно проработанной или существовать в неявном виде. Она может быть написана или существовать только в голове автора. Она может быть устоявшейся или меняться от начала документа к его концу. Но она всегда существует и имеет значение.

Хотя теория пользователей очевидна, она серьёзно влияет на то, как пишется документ. Она диктует не только выбор лексики и структуры предложения, но также и информации, которая предлагается. Она определяет, будет ли писатель определять понятие детально или просто сошлётся на него, как будто оно уже привычно читателю. Она определяет, будет ли писатель давать читателю рекомендацию провести некоторые задания для себя или попросить сделать их кого-то ещё.

Читать дальше…