Как стать автором
Обновить
54.47

Подготовка технической документации *

Всё о деятельности технических писателей

Сначала показывать
Порог рейтинга
Уровень сложности

Как оживить документацию?

Время на прочтение3 мин
Количество просмотров7.3K
Наверное, каждой команде знакома эта боль — неактуальная документация. Как бы команда ни старалась, в современных проектах мы релизимся так часто, что описывать все изменения практически нереально. Наша команда тестирования совместно с системными аналитиками решили попробовать оживить нашу проектную документацию.



На web-проектах Альфа-Банка используется фреймворк для автоматизации тестирования Akita, который использует для BDD-сценарии. К настоящему моменту фреймворк набрал большую популярность благодаря низкому порогу входа, удобству использования и возможности тестировать верстку. Но мы решили пойти дальше — на основе описанных тестовых сценариев формировать документацию, тем самым сильно сокращая время которое аналитики тратят на на извечную проблему актуализации документации.

По сути, вместе с Akita уже использовался плагин по генерации документации, который проходил по шагам в сценариях и выгружал их в формат html, но для того, чтобы сделать этот документ востребованным, нам нужно было добавить:

  • скриншоты;
  • значения переменных (config File, учетные записи пользователей и т.д.);
  • статусы и параметры запросов.

Мы посмотрели на наш существующий плагин, который был, по сути, статическим анализатором и формировал документацию на основе описанных в .feature-файлах сценариев. Решили добавить динамики, и для того, чтобы не городить плагин над плагином, приняли решение написать свой собственный.
Читать дальше →
Всего голосов 25: ↑23 и ↓2+21
Комментарии0

Немного технической лирики о C++ Tools от JetBrains, и при чем тут единороги

Время на прочтение4 мин
Количество просмотров9K
Начну не с моего типичного “Привет, Хабр! У нас тут очередной крутой релиз”, а с “Привет, меня зовут Настя, я ПММ в JetBrains и я отвечаю за наши инструменты для C++”. Или нет, попробую еще раз, вот так: “Привет, пишет вам C++ разработчик с 8-летним стажем, который 5 лет назад нашел-таки себе применение в любимой и знакомой компании мечты – JetBrains, а потом в сутках внезапно закончились часы, а идеи всё прут”.

Нет, это не традиционный пост о поисках кандидатов на вакансию. Я попытаюсь рассказать про то, почему инструментов для C++ у нас несколько и какие есть идеи и планы у нас на их счет, а еще почему вы не забудете C++, если перестанете писать на нем как разработчик, а станете PMM-ом (спойлер, если вы не член комитета стандартизации языка C++, то у вас большие шансы узнать язык даже лучше). А если после этого вам захочется поучаствовать в этом в роли PMM-а, то я буду рада вашим резюме на anastasia.kazakova@jetbrains.com.
Читать дальше →
Всего голосов 30: ↑27 и ↓3+24
Комментарии40

Как мы считаем метрики разработки и поддержки документации. Доклад Яндекса

Время на прочтение6 мин
Количество просмотров8.3K

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



Рассказывает Юрий Никулин, руководитель службы разработки технической документации.


Для начала давайте определим, что такое производительность. В классическом понимании, это время на производство единицы продукции или количество продукции, произведенное в единицу времени.


Например, это количество произведенных телефонов за месяц или количество времени на производство тысячи телефонов. Возникает вопрос, как измерять интеллектуальный труд, которым занимается наш отдел.


Всего голосов 24: ↑20 и ↓4+16
Комментарии2

Как «снести» вашу документацию и начать жить

Время на прочтение13 мин
Количество просмотров10K
Сегодня поговорим о том, как избавиться от документации, которая не работает, описывает какое-то легаси, не организована, не соответствует идентичности вашего бренда, да что там — просто плохой документации. Чтобы затем подготовить и реорганизовать хорошую, валидную, логично организованную и соответствующую идентичности бренда документацию. И как только вы сможете избавиться от документации — все станет радужно и прекрасно.



Под катом перевод доклада Александры Уайт, технического писателя из компании Google, на конференции Write the Docs Prague 2018. А уже через неделю 26 апреля 2019 Александра выступит на нашей конференции KnowledgeConf с докладом «How to create compelling multimedia documentation». Александра расскажет, как встроить мультимедиа форматы (видео, аудио, gif) в процесс создания артефактов и упаковки знаний, когда мультимедиа форматы подойдут лучше всего, а когда не будут работать, как измерять эффективность мультимедиа артефактов и преодолевать их ограничения.
Читать дальше →
Всего голосов 37: ↑36 и ↓1+35
Комментарии0

Истории

ProКонтент 2019: конференция для технических писателей и всех, кто работает с текстами

Время на прочтение1 мин
Количество просмотров2K
Мы в каждый год устраиваем отдельную конференцию для всех, кто причастен к созданию технических текстов. В этом году она пройдет 4 апреля.

На этот раз наша конференция — особенная. И тому есть две причины. Во-первых, мы впервые пригласили внешних спикеров. От «Лаборатории Касперского» будет только два доклада, а остальные — от сотрудников компаний Intel, Positive Technologies, Logrus IT и ECommPay IT.

image
Читать дальше →
Всего голосов 10: ↑10 и ↓0+10
Комментарии2

Чем занимается UX-писатель?

Время на прочтение7 мин
Количество просмотров14K
Привет, Хабр! Представляю вашему вниманию перевод статьи «What do UX writers do all day?» автора Yael Ben-David.

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

image
Читать дальше →
Всего голосов 9: ↑9 и ↓0+9
Комментарии2

Вредные советы: как правильно писать техническую документацию? Часть вторая

Время на прочтение10 мин
Количество просмотров6.6K
Советы по грамотному написанию технической документации для пользователей.
Часть 2


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

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

В этой части мы подробно разберем топики, из которых в основном состоит пользовательская документация (особенно User’s Guide) – а именно task-топики, в которых рассказывается, как решить конкретную задачу.

image
Читать дальше →
Всего голосов 13: ↑12 и ↓1+11
Комментарии4

Вредные советы: как правильно писать техническую документацию?

Время на прочтение7 мин
Количество просмотров12K

Советы по грамотному написанию технической документации для пользователей.
Часть 1


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

На этот раз под катом – руководство нашего технического писателя Андрея Старовойтова, которое поможет сделать вашу документацию для пользователей проще и понятнее (описанные приемы применяют при документировании своих продуктов Apple, Microsoft и другие компании).
Читать дальше →
Всего голосов 24: ↑22 и ↓2+20
Комментарии4

Второй митап Write the Docs Moscow. House Techwriters: не забывайте что мы существуем

Время на прочтение7 мин
Количество просмотров2.3K
Хотя второй по счету митап Write the Docs Moscow состоялся уже месяц назад, опубликовать отчет и краткие конспекты докладов никогда не поздно. Мы успели обсудить ну практически все: от документирования RESTful API до профессиональных траекторий техписателя.

Митап, кстати собрал не только «техписательское гетто», но и широкий круг других специалистов, кто так или иначе работает испытывает боль с документацией на проекте: тимлиды, аналитики, тестировщики и даже один технический директор.

Читать далее
Всего голосов 11: ↑11 и ↓0+11
Комментарии0

Как не превратить корпоративную базу знаний в хаос: наш опыт борьбы с Confluence

Время на прочтение5 мин
Количество просмотров30K


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

Как этого избежать, ну или хотя бы снизить возможные издержки? Как сделать вашу корпоративную базу теплой и ламповой? Попробую ответить.
Добро пожаловать под кат
Всего голосов 13: ↑13 и ↓0+13
Комментарии6

Новый взгляд на документирование API и SDK в Яндексе. Лекция на Гипербатоне

Время на прочтение19 мин
Количество просмотров7.3K
Меня зовут Андрей Поляков, я руководитель группы документирования API и SDK в Яндексе. Сегодня я хотел бы поделиться с вами докладом, который я и моя коллега, старший разработчик документации Юлия Пивоварова, прочитали несколько недель назад на шестом Гипербатоне.


Светлана Каюшина, руководитель отдела документирования и локализации:
— Объемы программного кода в мире в последние годы сильно выросли, продолжают расти, и это влияет на работу технических писателей, которым приходит все больше задач на разработку программной документации и документирования кода. Мы не могли обойти стороной эту тему, посвятили ей целую секцию. Это три взаимосвязанных доклада, посвященных унификации разработки программной документации. Я приглашаю наших специалистов по документированию программных интерфейсов и библиотек Андрея Полякова и Юлию Пивоварову. Передаю им слово.
Всего голосов 21: ↑20 и ↓1+19
Комментарии0

Пишем техническую документацию: руководство для непрофессионала

Время на прочтение10 мин
Количество просмотров25K


Осенью 2016 года нам с коллегой поручили улучшить документацию и контент в моей бывшей компании. Мы потратили год на все виды документации: справочник по API, руководства, учебные пособия, сообщения в блогах. До этого я 5 лет писала доки, но официально не обучалась этому. Но и неопытной меня нельзя назвать: кроме документирования API для проектов и стартапа, я ещё преподавала Python Flask на семинарах во время учёбы на последних курсах в университете. Но сейчас выпала возможность сосредоточиться только на любимом деле: помогать специалистам всех уровней через техническую документацию.

В этом году я многому научилась в сообществе Write The Docs, у других провайдеров API, а также методом проб и ошибок. В прошлом году я поделилась опытом в докладе «Что мне хотелось бы знать о написании документации» на конференции API Strategy and Practice в Портленде. Эта статья — обзор полученных знаний.
Всего голосов 30: ↑30 и ↓0+30
Комментарии7

Sir Markdown. Лекция Яндекса

Время на прочтение10 мин
Количество просмотров28K
При разработке документации мы руководствуемся не только стандартами, но и удобством её использования. Стандарты определяют состав и форму документации, а формат строится исходя из удобства. Разработчик Сергей Бочаров рассказывает о пути Markdown-документа и о проблемах, которые приходится решать в обмен на простоту использования этого формата.


У меня иногда складывается впечатление, что не он служит для нас, а мы служим для этого формата. Поэтому — сэр Markdown.

Всего голосов 70: ↑67 и ↓3+64
Комментарии20

Ближайшие события

7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань

UX-писатель: анатомия единорога

Время на прочтение10 мин
Количество просмотров6.4K
Тот, кто часто заглядывает на англоязычные площадки, наверняка слышал о загадочном UX-писателе — не то копирайтере, не то проектировщике, не то чем-то среднем. Мода на эту профессию началась в прошлом году, когда сразу несколько крупных компаний, от Amazon до Paypal опубликовали соответствующие вакансии, чем вызвали бурный резонанс в сообществе. До отечественного IT сектора это поветрие не дошло, но вот отголоски дискуссий периодически доносятся и вызывают недоумение — что это все-таки за зверь? В этой статье я хочу обобщить все, что понял о сути и содержании профессии UX-писателя из штудирования зарубежных источников: зачем они нужны, что входит в круг их обязанностей и что отличает их от обычных людей (то есть дизайнеров с копирайтерами).


С чего все началось?


Интерес к проблеме отношений текста с дизайном не ослабевает уже несколько лет. Тут можно вспомнить и сакраментальное высказывание «Копирайтинг мертв» от Тони Бригнулла, и множащихся сторонников нового подхода «сначала контент» (content first), и, в качестве завершающего аккорда, недавнее выступление Джона Маэды, в котором он заявил, что «дизайнеры не понимают важность слов» и назвал писательство «навыком-единорогом». Во всем этом прослеживается одна мысль: текст играет серьезную роль не только в продвижении продукта, но и в самом продукте; это критически важная составляющая, которая требует внимания и осмысления, а не набор штампованных вспомогательных элементов.
Читать дальше →
Всего голосов 6: ↑6 и ↓0+6
Комментарии1

Как усилить команду дизайнеров при помощи толкового писателя

Время на прочтение7 мин
Количество просмотров5.7K
Шесть доводов почему писатель (райтер, writer) — это турбонаддув для дизайна (от специалиста по UX в Dropbox).
image

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

В своем выступлении “Design in Tech 2017 " (Дизайн в технологиях 2017) Джон Маэда сказал: «Слова действительно важны, потому что графика иногда не содержит никакого смысла.» Fast Co Design продолжили эту мысль в статье под названием «Забудьте о коде: Манера письма это главный навык дизайнера».

Звучит просто, верно? Чтобы быть великим дизайнером, нужно знать, как писать. Ничего страшного. Ты пишешь все время. Электронная почта, спецификации, твиты — ничего сверхъестественного.

Я писатель и бывший учитель английского языка и я считаю, что писать трудно. Тяжело учиться писать и тяжело этому научить. Вот почему на Амазоне более 500,000 книг о написании текстов!

Механику письма достаточно трудно постичь, но знаете ли вы, что на самом деле трудно? Такие понятия как выбор слов, тон и ритм. Чтобы овладеть этими навыками, потребуется целая вечность.

Так что же делать команде дизайнеров?
Читать дальше →
Всего голосов 15: ↑13 и ↓2+11
Комментарии3

10 вещей, которые ненавидят UX-писатели

Время на прочтение3 мин
Количество просмотров10K
image

Выдуманные диалоги, реальные ситуации


Вот уже много лет как у меня есть возможность общаться с UX-писателями из кучи разных фирм. Даже если мы работаем над абсолютно несвязными продуктами, мы сталкиваемся с поразительно схожими проблемами.

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

Если вам интересно, каково это, быть UX-писателем, вот небольшое обзор.
Читать дальше →
Всего голосов 18: ↑17 и ↓1+16
Комментарии7

VMware vSphere 6 для технических писателей

Время на прочтение11 мин
Количество просмотров22K
image


Статья повествует о том, как организовать работу техническим писателям и коммуникаторам, если объектом для создания документов выступают виртуальные среды, построенные на базе платформы VMware vSphere, а также программное обеспечение, функционирующее в таких средах. Статья также будет полезна широкому кругу технических специалистов, которым по роду деятельности приходится сталкиваться с подобными объектами.

Увертюра


Зачем это нужно?


К задумке этой публикации меня сподвигло всеобщее развитие виртуализации и облачных вычислений. Использование этих технологий, с одной стороны, позволяет предприятиям более эффективно использовать имеющиеся аппаратные ресурсы, с другой стороны – даёт возможность более удобно организовать доступ к приложениям, в том числе для удалённых и мобильных пользователей. Всё больше предприятий предоставляют своим клиентам облачные сервисы.
Читать дальше →
Всего голосов 18: ↑15 и ↓3+12
Комментарии31

Пьеса «Технический долг»

Время на прочтение6 мин
Количество просмотров76K

Пьеса «Технический долг» в 9 частях. Ставится и показывается впервые.


Часть 0: В пустой комнате стоят Разработчик (Р) и Менеджер (М).

М: Я собрал нас тут, чтобы рассказать пренепреятнейшее известие: система КРОТОПОН, которая работает на продакшане заглючила и мы потеряли кучу денег. Кроме того нет никого, кто знает как она работает. Поэтому (с придыханием) наш СЕО дал мне священную миссию — написать новую систему. Как ты думаешь, за два месяца справишься?

Р: А что делать-то нужно?

М: Да там немного, всего лишь пару десятков систем связать и рюшечки навесить.

Р: Эй, да это же на год работы! И вообще требования будут?

М: (В телефон) Да, конечно, за пол года справимся. (Разработчику) Ну ты тут пока начинай, а я тебе требования потом донесу.

Менеджер уходит.

Р: Но тут же…

Разработчик тяжело вздыхает, затаскивает в комнату инструменты и начинает что-то сооружать.
Читать дальше →
Всего голосов 201: ↑195 и ↓6+189
Комментарии196

Stackoverflow запустил раздел «Документация»

Время на прочтение1 мин
Количество просмотров28K

Вчера произошло достаточно значимое событие на рынке разработки. Точнее в сфере поддержки и сопровождении программных продуктов. StackOverflow запустил раздел документация. Почему это важно?

Читать дальше →
Всего голосов 55: ↑44 и ↓11+33
Комментарии52

7 правил написания технической документации мирового класса

Время на прочтение12 мин
Количество просмотров82K

Введение


Написание технического документа — трудное дело. Чтение плохо написанного технического документа является более трудным и, вероятно, более болезненным делом, чем его написание. Требуется большая работа, чтобы создать ясное, точное, интересное техническое описание. Поэтому, чтобы сделать жизнь хоть немного проще для всех участвующих сторон, я хотел бы поделиться с вами семью правилами, которым я следую, создавая техническую документацию.

Эти правила — не моё собственное изобретение. Скорее, я просто сформулировал их из того опыта, который появился благодаря общению со многими талантливыми техническими и литературными редакторами за более чем десять лет работы. Всё, что я понял в этом деле, сформировалось потому, что другие показали мне путь. У меня не находится достаточно слов, чтобы выразить им в полной мере мою благодарность.

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

Итак — эти 7 правил:
  1. Скука убивает
  2. Прежде чем начать, выясните точно для себя, какие действия вы ожидаете от читателя, осилившего ваш труд
  3. Пишите в соответствии с правильно сформированной структурой
  4. Избегайте неоднозначных местоимений
  5. Ясность = иллюстрации + слова
  6. Когда имеете дело с понятиями, концепциями и т.п., используйте логическую иллюстрацию и пример
  7. Не опасайтесь переделок

Читать дальше →
Всего голосов 26: ↑25 и ↓1+24
Комментарии17