Публикации
Эджайл и технические коммуникации: 4 обязательных пункта, чтобы стать членом эджайл-команды (часть 2)
22.01.2014
Мы заканчиваем статью с советами техническому писателю, как стать полноправным членом команды. Сегодня мы узнаем, почему так важно брать на себя ответственность, что делать, чтобы остаться в проекте и почему иногда нужно спорить с разработчиками.
Участвуйте во всех областях разработки
Независимо от того, сколько раз вы это слышали или говорили, фраза «Я просто писатель» не освобождает вас от активной вовлеченности – невозможно стать одним из ключевых членов команды без полного погружения. Алан Прингл пишет об этом на сайте Scriptorium. Такой уровень участия гарантирует, что вы полностью вовлечены в проект с самого начала и знаете все требования, дизайн и что стоит за дизайном программного обеспечения. И это даёт вам дополнительное преимущество: «имидж», уважение, которое нужно, чтобы остаться в проекте.
Вы можете заработать этот имидж, выполняя несколько важных действий:
Эджайл и технические коммуникации: 4 обязательных пункта, чтобы стать членом эджайл-команды (часть 1)
20.01.2014
Мы продолжаем цикл статей, посвящённых такому понятию, как эджайл. Сегодня речь пойдёт о том, почему технический писатель должен стать частью команды и как это сделать.
Эджайл-разработка в значительной мере опирается на быструю и чёткую коммуникацию. Следовательно, может показаться, что коммуникация не будет для нас проблемой. В конце концов, мы же профессиональные коммуникаторы. Дело в том, что коммуникация эджайл-команды часто наталкивается на препятствие в виде предвзятых идей о том, что технический писатель делает или какой вклад может внести в команду. И эти предубеждения поддерживаются как техническим писателем, так и другими членами эджайл-команды. Хотя, вероятно, вы и не можете изменить устоявшиеся понятия других людей, вы можете избавиться от своих собственных. Далее — четыре обязательных пункта для любого технического писателя, стремящегося стать ключевым членом эджайл-команды.
Говорите
Звучит почти слишком просто, не так ли? Но многие технические писатели стесняются говорить в критические моменты и упускают возможности, которые могут и не повториться. Вас должны услышать, иначе вы не получите нужной информации, поэтому крайне важно, чтобы вы говорили на совещаниях и при личных встречах, связанных с каждым аспектом разработки продукта. Задавайте вопросы, много вопросов, и используйте все знания, чтобы внести свой вклад в развитие дискуссии. Говорите ради пользователей продукта. Защита интересов пользователя – роль, которую давно уже лелеют технические коммуникаторы, а это значит, что нужно говорить, пока не раскроются все проблемы и не найдутся решения. Например, если графический интерфейс трудно использовать, предложите и проведите тест на удобство пользования, чтобы непосредственно показать разработчикам борьбу, которую пользователи будут вести с текущим дизайном. Или, если вы узнали, что совещание по планированию проходит без вашего присутствия, поговорите с тем, кто его проводит, и попадите в список участников.
Технический писатель Google. 3 месяца в компании (часть 3)
17.01.2014
Мы заканчиваем публикацию статьи технического писателя Google Сары Мэддокс. Сегодня мы узнаем, какие инструменты используют работники компании, какими навыками должны обладать и какие преимущества можно получить, устроившись работать в Google.
Слова, код, разметка
Нужно ли уметь писать код, чтобы быть техническим писателем в Google? Это наиболее обсуждаемый вопрос. Я думаю, всё зависит от должности, занимаемой в Google. Для моей позиции, я бы сказала, было бы весьма невыгодно не уметь скомпоновать программный код.
Почти все, что мы создаем – это слова. Мы пишем в HTML или Markdown в зависимости от нашего выбора, либо существующего формата, если мы обновляем документ.
Технический писатель Google. 3 месяца в компании (часть 2)
15.01.2014
Мы продолжаем статью Сары Мэддокс – технического писателя компании Google, в которой она рассказывает о своём рабочем дне, интересных традициях и безумно вкусных пирожных в кафе неподалёку.
День из жизни
Я приезжаю рано, около 7.30 утра. Но я прихожу на работу далеко не первая. Народ подтягивается в любое время суток – когда им удобнее.
Босые ноги, кофе, Большая Красная
Я бросаю ноутбук на стол и бегу к кофеварке. По пути я прохожу конференц-зал и улыбаюсь паре босых ног. Почему-то в это время дня здесь всегда находится парень, который развалился в кресле и чатится с кем-то через Google Hangout. Я вижу только ноги и коленки, выше стекло затемнено. Думаю, он разговаривает с семьей где-то на другом континенте, а раннее утро – лучшее время их поймать.
Технический писатель Google. 3 месяца в компании (часть 1)
13.01.2014
Представляем статью Сары Мэддокс, которая несколько месяцев назад получила место технического писателя в корпорации Google и теперь делится впечатлениями с читателями своего блога.
Многие спрашивают меня, каково же быть техническим писателем в Google. Я стала частью команды Google три месяца назад. Теперь, как красноречиво заметил мой руководитель, «блеск первых впечатлений от работы стирается», и я принимаюсь за будничную работу. Итак, каково это?
Тяжело ответить на этот вопрос. Это бодряще, страшно, весело, разочаровывающе, вдохновляюще, утомительно. Всё, чего можно ожидать от новой работы, и ещё многое. Мне это нравится. Чаще всего 😉
Чтобы ответить на вопрос, я начала записывать какие-то случайные мысли, а потом описала «день из жизни». Надеюсь, это даст вам некоторое представление о том, что я здесь творю.
Как писать кратко и понятно
10.01.2014
Представляем статью Инны Якименко, эксперта по документированию компании First Line Software (г. Санкт-Петербург), посвящённую упрощённому техническому языку.
Поделюсь своим опытом технического писателя, как уложить свою мысль в краткую и легко воспринимаемую форму.
Сертифицируясь по своей специальности в американском университете, я познакомилась с правилами написания и редактирования технических текстов, которые применяют зарубежные специалисты по технической коммуникации.
С Новым годом и Рождеством!
30.12.2013Уважаемые друзья!
Спасибо за минуты общения, которые вы подарили нам в 2013 году. В 2014-ом году мы порадуем вас новыми ивентами, челенджами, тренингами и даже релизами 🙂
Желаем в Новом году творческой активности, финансового благополучия и лошадиной силы!
Оставайтесь с нами — будет интересно!
А вы допускаете эти ошибки? (Часть 6)
27.12.2013
Мы заканчиваем цикл публикаций, посвящённый самым распространённым ошибкам технических писателей. Сегодня мы рассмотрим преимущественно лексические ошибки и приведём несколько советов для оптимизации работы в команде.
Употребление нечёткого определения («Это»).
Не начинайте предложение со слова «это», если только его употребление не очевидно.
Пример:
Неправильно: Наденьте заземляющий браслет, который прилагается к полке с оборудованием. Это предотвращает статические помехи от повреждений печатной платы.
Правильно: Наденьте заземляющий браслет, который прилагается к полке с оборудованием. Браслет предотвращает статические помехи от повреждений печатной платы.
А вы допускаете эти ошибки? (часть 5)
25.12.2013
Сегодня речь пойдет о мелочах, на которые зачастую не обращают внимание ни начинающие, ни более опытные технические писатели. В частности, об орфографии и правильном использовании времён.
Расположение информации в неправильном порядке
При описании пошаговых действий многие писатели первым делом сообщают пользователю, что делать, а уже потом – где это делать. На самом деле, вы должны сначала сообщить пользователю, где задача выполняется, и только потом, как она выполняется. Это называется «ориентирование пользователя».
А вы допускаете эти ошибки? (Часть 4)
23.12.2013
Представляем вам продолжение статьи, предостерегающей неопытных технических писателей от самых распространённых ошибок. Сегодня речь пойдёт о слишком сложных шаблонах, неправильном форматировании и отсутствии глоссария.
Использование навороченных шаблонов
Многие компании не имеют достаточных навыков, чтобы создавать свои собственные шаблоны, и поэтому передают эту работу на аутсорсинг в другую компанию. Первая ошибка многих из этих сторонних компаний – это создание единого шаблона, как я уже писал выше. Вторая ошибка – добавление в шаблон такого количества ненужных функций, что его невозможно использовать.
Я когда-то работал в телекоммуникационной корпорации, которая, несмотря на её размер и долгое время существования, еще только начинала развивать собственную политику и процедуры создания документа. В какой-то момент компания разослала шаблон для писателей с указанием, что мы должны использовать его в дальнейшем. Он включал всякие фантастические функции, такие как сетки знаков, обрезные метки, таблицы, которые будут использоваться в одном виде документа, и таблицы, которые будут использоваться в другом, заголовки для этого и заголовки для того, все виды автоматических функций управления документами (ни одна из которых не работала) и многое, многое другое. К сожалению, никто из нас не мог понять, как его использовать, поэтому мы и не использовали.