Нужен ли техническому писателю техническое образование?

Нужен ли техническому писателю техническое образование?

Ответы (17)

Краткий ответ: нет.

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

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

Почему бы не иметь преимущество, если можно? Убедитесь, что вы отличный писатель, или найдите работу на любую тему, о которой вы собираетесь писать, но принимайте участие в концертах.

Я опытный технический писатель, специализирующийся на документации по API. По моему опыту, чтобы добиться успеха, техническому писателю нужны достаточные технические способности, чтобы (1) понимать потребности пользователей и (2) исследовать экспертов в предметной области (МСП). Если все, что вы собираетесь делать, это повторять, как попугай, то, что вам говорят МСП, вы упустите важные детали. МСП (в ​​любой сфере) имеют белые пятна; они так долго жили в глубинах своего кода, что могут забыть, что «очевидные» предположения не являются очевидными. У них также, как правило, есть определенная модель того, как пользователи будут использовать их продукт, которая может быть скорее умозрительной, чем реальной. (Я их не критикую, им часто не хватает информации.) Копаться во всем этом — работа технического писателя. (Также тестер, если он у вас есть.)

Когда я нанимаю технических писателей, я ищу определенный порог писательского мастерства, но затем я ищу технические способности. Я бы предпочел иметь компетентного писателя, который разбирается в технологии, чем писателя, который пишет отличную прозу, но нуждается в большой помощи, чтобы понять, что писать. Легче помочь компетентному писателю улучшить письмо, чем помочь кому-то глубоко понять соответствующую технологию.

Из моего опыта, не в явном виде. Но технический писатель должен понимать, о чем он пишет, чтобы эффективно донести это. Если вам нужна книга на эту тему, « Техническое общение » Майка Маркела — отличный ресурс по всем аспектам технического письма и общения.

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

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

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

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

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

Техническое письмо — это табуретка на трех ножках. Чтобы сделать это хорошо и эффективно, вам нужны три вещи:

  • Достаточное знание задачи пользователя, чтобы понять, что ему нужно знать и как сообщить об этом.

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

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

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

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

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

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

Если рынок очень техничный, они могут больше сосредоточиться на первом этапе.

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

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

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

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

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

Да, эффективный технический писатель будет иметь достаточно технических базовых знаний и опыта, чтобы создавать полезный контент из (часто скудного) исходного материала.

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

Должность «технический писатель» охватывает широкий спектр должностных обязанностей. В результате работающие технические писатели имеют широкий спектр технических навыков и требований к знаниям. Чем менее технический предмет, тем менее строго применима техническая хватка.

Писатели, работающие с документацией и помощью для конечного пользователя, часто менее нуждаются в глубоких знаниях программирования, например, хотя часто ожидается знание области, в которой должен использоваться продукт. Опыт в дизайне пользовательского опыта (когнитивная психология) часто является плюсом. И обычно существуют требования к производственным инструментам, используемым командой (Office, HTML, XML и т. д.).

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

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

Я работал с техническими писателями, у которых не было особого технического образования. По большей части они могли подделывать его, следуя формам и стилям и повторно используя кусочки из других источников. Это, действительно, просто прославленное редактирование.

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

Так что технические знания — это требование, но не единственное.

Есть два сценария, где можно спорить

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

  1. Общие документы конечного пользователя:
    • Документы, которые должны использовать люди, не являющиеся техническими специалистами, чтобы понять минимально сложную техническую систему. Примером этого может быть руководство пользователя для медицинской биллинговой системы. При написании материала такого типа требуется очень мало технических знаний.
  2. Документация по API
    • Документы, которые программисты используют для понимания интерфейса программирования части программного обеспечения. Плохо написанная документация по API может оказаться фатальной для усилий по интеграции. Это требует некоторых технических знаний, особенно понимания программирования. Вам не нужно быть программистом на полную ставку, но вы должны, по крайней мере, понимать основы программирования и все, что особенно важно для API, который вы документируете. Вам должен быть предоставлен программист или кто-то, кто очень хорошо понимает API, в качестве ресурса для такого типа проекта.

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

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

Я собираюсь отказаться от довольно хорошей контрактной роли технического автора (TA), пишущего API для компании, базирующейся в Гибралтаре - солнце, песок и сеньориты! Почему? Потому что я смог пройти интервью, основываясь исключительно на своей личности, а не на своих способностях к предмету. Я достаточно хороший ТА, чтобы знать свои ограничения, и у меня есть предыдущий опыт написания API, так почему я отказываюсь от контракта, который мне действительно нужен? Ответ заключается в том, что я не верю, что смогу отдать должное.

У меня нет «достаточно» глубокого понимания программирования ( JSON / Java / RESTful ), и мне пришлось бы сильно опираться на разработчиков, чтобы они объяснили каждую гайку и болтик кода, тем самым показывая, каким я был стеной, и в конечном итоге обескураживая разработчиков. или технические эксперты, предоставляющие технические материалы, которые я как автор должен разъяснять аудитории.

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

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

Нет, вам нужно знать ровно столько, сколько будет знать конечный пользователь.

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

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

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

Нет . Я был там и делал это с обеих сторон.

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

Контент должен исходить от инженера/программиста, которому может понадобиться помощь в переносе полезной информации на страницу для редактирования и перезаписи. Худшим случаем было бы взять у них интервью и создать для них первый черновик. Чаще всего это перепроверка, чтобы увидеть, что они на самом деле имели в виду, или заполнить пробелы в вещах, которые они пропустили, потому что «все это знают».

Как и в случае с обучением, техническое письмо можно описать как «искусство передачи информации без знаний».

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

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

Я думаю, это зависит. Для написания документов, ориентированных на конечного пользователя, таких как SAP, JDE, пошаговые рабочие инструкции о том, как сделать что-то, что вам действительно не нужно, техническая подготовка. Вам нужно быстро учиться.

Нет , вам не нужно посещать курсы или получать степень в вашей области. Что вам действительно нужно, так это ненасытное любопытство . Один из лучших известных мне примеров — Мартин Гарднер , который более 20 лет вел колонку в журнале Scientific American под названием « Математические игры » . Ему приписывают популяризацию развлекательной математики в 20 веке.

Согласно Википедии: «По иронии судьбы, у Гарднера были проблемы с изучением исчисления, и он никогда не посещал математический курс после окончания средней школы». Насколько я помню, Гарднер отчасти объяснял успех своей колонки отсутствием у него математической подготовки . Каждый месяц для своей колонки он должен был изучать тему, прежде чем преподавать ее своей аудитории.

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

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

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

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

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

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

Да! Но это не значит инженерное образование, а уровень технических знаний зависит от типа документации. Вам нужно больше технических и научных знаний, чтобы работать в инженерной или научной фирме. Вам может понадобиться дополнительная статистика и финансовая информация, чтобы работать в банке или писать заявки на гранты. Вот некоторые из технических областей, которые необходимо использовать большинству составителей документации и предложений: Математика: проценты, дроби, измерения, время, преобразование единиц измерения. Наука: физика (основы, такие как ускорение, сила). Инженерия: стандарты ISO, научные обозначения, инженерные чертежи и символы. Программное обеспечение: репозитории кода, операционные системы, базы данных, веб-технологии, программное обеспечение и методы публикации.

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