Публикации
Как привлечь интерес к вашему проекту с помощью хорошей документации
23.07.2014
Мы не раз уже писали о важности наличия хоть какой-то (а в идеале качественной) документации. Эми Скаварда абсолютно с нами согласна. Представляем вам её размышления по этому поводу.
Нередко я встречаю циклы новостей о сообществах, которые недружелюбны по отношению к женщинам или новичкам, или людям, которые ещё не стали их частью. Под «новостями» я подразумеваю, когда кто-то постит что-то близкое его сердцу о какой-то несправедливости, и когда другие этот пост комментируют или пишут свои собственные сообщения; в общем, мораль этой истории такова – Но мы должны быть лучше, чем они!
Это нормальное и желаемое поведение в рамках целого сообщества. Это неплохо, потому что заставляет людей задуматься о своем поведении, как членов сообщества, каково быть аутсайдером и как можно развиваться. Это позитивные шаги, потому что они вытекают из честного желания людей быть лучше. Это потрясающе. Читать дальше…
Встречайте MadCap Pulse
30.06.2014
Мы завершаем серию статей о продуктах компании MadCap Software. Сегодня речь пойдёт о MadCap Pulse — веб-портала для работы над документацией, одинаково удобного как для пользователей документации, так и для её создателей.
MadCap Pulse — единственная платформа для документации, которая объединяет скрытую от пользователя отчётность и аналитику наряду с открытым социальным взаимодействием, позволяющая заказчикам контента подключаться, взаимодействовать и делиться знаниями.
Аналитика, отчётность и социальное взаимодействие для вашей документации
MadCap Pulse добавляет аналитику и отчётность, рейтинги и социальное взаимодействие в вашу документацию, — три компонента используются по отдельности или вместе — чтобы предоставить возможность понять, как пользователи используют и взаимодействуют с вашим контентом.
- Будьте в курсе с помощью потрясающих возможностей аналитики и отчётности
- Рейтинги для обратной связи по качеству контента и полезности
- Используйте силу социальных технологий
Не позволяйте английскому в качестве второго языка стать источником раздражения!
04.06.2014
Сейчас большая часть вакансий сопровождается крупной надписью – «Знание английского языка обязательно». Технические писатели не стали исключением. Нередко возникает необходимость создать англоязычный документ либо перевести уже существующий. Зачастую писатель берётся за такую работу, не сомневаясь в своей компетенции – ведь, казалось бы, чего сложного, тему я знаю, термины есть в словаре, да и язык я учил с 6 лет, а однажды даже общался с живым американцем. Мы ни в коем случае не сомневаемся в вашем профессионализме, но хотим предостеречь от частой ошибки – полагаться только на свои знания и не пользоваться услугами редактора.
Те, для кого английский – второй язык, зачастую несправедливо страдают. Это потому что всё, начиная от языкового выражения, заканчивая понятиями, теряет ясность. И это может привести к неправильному впечатлению и неоправданному превосходству над ними носителей языка. Читать дальше…
Итоги конференции Гипербатон
27.05.2014
24 мая 2014 года в Москве прошла конференция Гипербатон, проводимая компанией Яндекс. На конференцию съехались специалисты по документированию и техническому переводу из разных уголков России и ближнего зарубежья. В течение субботнего дня прозвучали 7 тематических докладов, так или иначе связанных с тематиками технического писательства, локализации программных продуктов и документации, а также технического перевода. В работе конференции, кроме докладчиков от компании Яндекс приняли участие представители компаний Лаборатория Касперского, ABBYY и ПроТекст.
Открыла конференцию Светлана Каюшина, руководитель службы разработки технической документации компании Яндекс. Светлана пояснила выбор названия конференции, которая проводилась впервые, рассказала о предпосылках организации конференции. Также Светлана предложила присоединиться к сообществу технических писателей, организованному компанией Яндекс.
Продолжил конференцию Кирилл Маслинский, ведущий разработчик технической документации компании Яндекс с докладом о профессии технического писателя. Кирилл рассказал об истории этой профессии, профессиональной идентичности технических писателей, а также привёл интересную статистику о людях, которые приходят в профессию технических писателей и качествах, которыми они должны обладать.
Арина Кирпичева, разработчик технической документации компании Яндекс, рассказала о первых 5 месяцах своей работы в компании. Её работа связана с документированием API сервиса Яндекс.Карты. Арина рассказала о том, с какими проблемами ей пришлось столкнуться в начале работы и как они были преодолены. Она внушила слушателям мысль о том, что какая бы сложная задача перед писателем не стояла, её всегда можно решить, разбив сложную задачу на этапы и не пренебрегая горизонтальными связями в компании, в которой работаешь. Читать дальше…
Зачем мне нужна DITA? (часть 2)
25.04.2014
Мы завершаем статью, рассказывающую о преимуществе DITA над другими средствами авторинга. Но не считайте, что мы навязываем эту среду всем нашим читателям. Реалии таковы, что DITA не всегда может окупиться или стать самым оптимальным решением для каждого. Следите за нашим блогом, мы постараемся привести плюсы и минусы лучших из существующих решений.
DITA повышает удобство использования
DITAпредставляет переход от главо- и книгоориентированного авторинга к топикоориентированному, где каждый фрагмент информации является ясным и полным сам по себе. Кроме того, каждый фрагмент или топик имеет четкую цель. Ядро DITA включает в себя различные типы топиков, каждый написан, чтобы выполнить конкретную цель пользователей: концепт-топик для объяснения, топик-задача для инструктажа и топик-сноска для подробной информации.
Разделение контента на отдельные, часто используемые, но чёткие топики делает его более доступным для поиска. Пользователи могут перемещаться прямо к необходимой им информации, читать только соответствующую информацию (потому что остальное отбрасывается), а затем заниматься своими делами.
Зачем мне нужна DITA? (часть 1)
23.04.2014
Мы снова вернулись к одной из самых обсуждаемых тем нашего блога – DITA и важность её внедрения. Давайте ещё раз вспомним все преимущества этого стандарта.
Дарвиновская Архитектура Типизированной Информации (DITA) является стандартом на базе XML, который используется в основном для технической и всё чаще и для других типов документации. Мы уже представляли вам статью «Что такое DITA и зачем нам это нужно?». Мы подробно остановились на «что», а теперь хотели бы ещё раз подчеркнуть «зачем». И это вопрос, который вам нужно задать себе, если работа над созданием технического контента – часть вашей ежедневной работы.
Ответ обманчиво прост: Никуда от этого не денешься; если вы не применяете DITA как стандарт документации, вы работаете гораздо медленнее и менее эффективно, чем должны бы.
Требует ли внедрение DITA времени, усилий и знаний? Да, это так. И тогда вы сможете пожинать плоды в течение следующих… нуууу… в течение всего обозримого будущего. Читать дальше…
Эджайл и технические коммуникации: командный подход (часть 2)
05.03.2014
Представляем вам продолжение статьи Алиссы Фокс о работе команд по эджайл-методологии. Сегодня вы узнаете, на ком лежит ответственность за результат при командном подходе, и о том, как обеспечить рациональное использование рабочего времени каждого члена команды вне зависимости от его роли и от времени выполнения своих функций представителями других ролей в команде.
Качество — это ответственность всей команды
Наряду с тем, что использование командного подхода, когда участвует вся команда целиком, даёт множество внутрикомандных преимуществ, наиболее очевидным внешним преимуществом является повышение качества продукта. Вся команда ответственна за разработку, тестирование и документирование по каждой из пользовательских историй до тех пор, пока спринт не будет окончен. Инженеры по качеству направляют эти усилия таким образом, чтобы вся команда работала над обеспечением выполнения всех этапов спринта.
Мы обнаружили, что для достижения наших целей в каждом спринте нам необходимо как можно больше автоматизировать тестирование. Автоматизированное тестирование быстрее, надежнее и менее подвержено ошибкам. Инженеры по качеству взаимодействует с группой разработки, чтобы обеспечить выполнение модульных тестов (unit tests) и повысить внимание к моментам, в которых существуют пробелы. Инженер по качеству должен также направлять усилия на разработку и автоматизацию приемочных тестов (acceptance tests), а также на выполнение исследовательских тестов (exploratory tests). Другими словами, ручное тестирование — это не самый гибкий (agile) способ получения высококачественного продукта. Для получения дополнительной информации о гибком тестировании и различных видах тестирования смотрите блог Лизы Криспин (Lisa Crispin) www.lisacrispin.com.
Тенденции технических коммуникаций: Хорошо, но не безупречно
17.07.2013Пятая часть из серии статей о тенденциях в области технических коммуникаций
Как и вы, я прошел через все эти мотивационные разговоры. Качество – первое правило работы. Если это стоит делать, стоит сделать это хорошо. Либо безупречно, либо никак.
И я проникся. Я стремлюсь к качеству. Я всегда стараюсь сделать всё возможное.
Но вот, что забавно: определение качества меняется. Некоторым очень тяжело смириться с этим, но факт есть факт. Некоторое время назад я писал об этом в статье «Переосмысление совершенства».
Что вызвало изменения?
Отчасти это влияние реорганизации, которая началась в области разработки программного обеспечения и неизбежно распространяется на другие дисциплины. При реорганизации качество определяется тем, что отвечает ожиданиям клиента («пользовательские истории»). Это означает, что качество не определено (если оно вообще когда-то было определено) тем, что мы думаем и что знаем о хорошем писательстве и хорошем дизайне. Другими словами: если после прочтения вашей инструкции клиенты не звонят в техподдержку, не важно, что она напечатана шестым кеглем на задней стороне коричневого бумажного пакета. Это хорошая инструкция.
В современной реальности все, что мы публикуем, можно мгновенно пересмотреть и переиздать. Когда я только начал работать в области технических коммуникаций, я торжественно вручал печатнику стопку корректурных листов и ждал книгу. Когда книга сходила с печатного станка, все – от блестящего оформления до самых досадных опечаток – было неизменно. Но теперь всё не так. Так зачем ждать совершенства? Почему бы быстро не отдать клиентам контент? Если спустя некоторое время я найду опечатку, или если изменится номер какой-нибудь детали, я могу обновить документ одним кликом.
Интервью с директором по информационным технологиям Data Conversion Laboratory Тэмми Билицки (часть 2)
03.07.2013Начало интервью см. в предыдущей публикации.
Путь к стратегии преобразования данных: Применяйте динамичный подход
Согласно Тэмми, современным организациям необходимо присмотреться к «динамичным документам и динамичным данным» в контексте разработки и реализации комплексной «стратегии, касающейся документов, данных, использования и возможности организации потока данных такими способами, которые содействуют корпоративной мобильности».
Во время своей работы в проектном управлении и управлении поставками, Тэмми стала сертифицированным скрам-мастером (Certified Agile Scrum Master), являясь сторонником этого подхода в разработке и реализации стратегии преобразования данных организации. «Динамичность – это то, что нужно в 2013 году. Компании больше не хотят позволять вам уходить и разрабатывать контент в вакууме и возвращаться назад, надеясь, что он соответствует целям их бизнеса».
«Динамичность (agile) – чрезвычайно полезная методология для преобразования данных и разработки контента», – говорит она, – «потому что не всегда возможно открыто определить все требования. При разработке продукта мы определяем цели, среду разработки, обращаемся к специалистам в соответствующей области, и поэтапно создаём продукты, чья поддержка стандартно изменяется в содержании и качестве. То же самое верно по отношению к документации – она делается поэтапно».