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

Публикации

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

09.12.2013

01В заключительной части статьи речь идёт об эффекте, оказываемом эджайлом на технических писателей.


Воздействие на писателей

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

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

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



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

06.12.2013

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


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

Строго говоря, эджайл-процесс не покрывает неинженерные вопросы, касающиеся производства продукции, но руководители видят много преимуществ эджайла, которые помогают бизнесу в целом.

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

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



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

04.12.2013

01Сегодняшняя статья Алиссы Фокс посвящена технологии эджайл с позиции выгоды для руководителей предприятия. Первая часть статьи посвящена трудностям внедрения технологии эджайл в производственные процессы.


Если говорить о «самой чистой» форме этого процесса, эджайл-разработка втягивает в работу над пожеланиями пользователей посредством множества спринтов, пока их качество не станет достаточным для релиза чего-нибудь для ваших клиентов. Создание этих простых, независимых кусков производит потенциально готовый к отправке код в конце каждого спринта.

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

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



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

28.11.2013

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

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

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

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



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

15.11.2013

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


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

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

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

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

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



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

13.11.2013

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


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

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

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



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

11.11.2013

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


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

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

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



Как нанимать технического писателя (часть 5)

23.10.2013

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


Проверьте электронную версию тестового документа

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

  1. Нажмите кнопку «Показать/Скрыть».
  2. Из меню «Таблица» выберите «Показать сетку».
  3. В меню «Инструменты» выберите «Настройки», а затем выберите вкладку «Вид».
  4. Под «Знаки форматирования» выберите флажок «Все» и нажмите «ОК».

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



Как нанимать технического писателя (часть 4)

21.10.2013

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


Рассмотрите тестовый документ более внимательно

Теперь вернитесь к оглавлению и для примерно 20% пунктов проверьте, что заголовки записаны точно так же, как заголовки, на которые ссылаются, а также то, что они находятся на указанной странице. Другими словами, если в оглавлении написано, что вы найдёте заголовок «Бизнес-окружение» на пятой странице, откройте страницу 5 и проверьте. Так как все настольные издательские системы генерируют оглавления автоматически, любые отличия между заголовком в оглавлении и страницей, на которую он ссылается, говорит об оглавлении, которое модифицировалось вручную. Это серьёзный недостаток, показывающий, что будут обнаружены и другие серьёзные проблемы с документом. Если вы не сможете учить кандидата использованию текстовых редакторов, не нанимайте этого человека.

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



Как нанимать технического писателя (часть 3)

18.10.2013

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


Дайте общую оценку примеру документа

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

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

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

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