You Gotta Frontend. Використай YGLFLovesDOU та спілкуйся із провідними спікерами зi всього світу!

Technical writer: як потрапити в професію і що вчити

Робота техрайтера в Україні стає все затребуванішою. До прикладу, на момент написання цієї статті у розділі Technical writer на DOU міститься 56 вакансій. Парадоксальною особливістю цієї професії є те, що їй ніде не навчають. Спеціалізованих програм з technical writing немає ні в українських, ні в європейських університетах. Нібито такі програми все ж є в кількох університетах США, але навіть якщо і так, їх випускники навряд чи коли-небудь задовільнять попит на українському ринку праці.

Сьогодні в Україні налічується декілька сотень техрайтерів. Нещодавно з’явилася спільнота у Facebook Technical writers of Ukraine для обміну досвідом і організації зустрічей. Тож як вони потрапляють у професію? Де навчаються і як знаходять своє перше місце роботи? Про це ми запитали українських техрайтерів з різних IT-компаній.

Заряна Ніколаєва, Information Manager в NetEnt

3 роки в техрайтингу

Досвід роботи до техрайтингу. Я закінчила магістратуру у Київському лінгвістичному за спеціальністю «Переклад». Після інституту працювала п’ять років за фахом на телебаченні на «Першому національному». Робота була дуже різноманітною — від контрактів та сценаріїв до супроводу знімальних груп у відрядженнях та послідовного перекладу. Паралельно працювала у стартап-проекті, спочатку англомовним копірайтером, а потім контент-редактором, що координує копірайтерів і відповідає за єдиний стиль контенту. Це були дуже різні напрямки, але вони доповнювали один одного і дали базу для зміни професії.

Перша робота техрайтером. Дізналася я про професію, власне, коли мені запропонували роботу. Подруга порекомендувала мене на посаду техрайтера у геймдев-компанії, де вона працювала на той момент. Я розуміла, що подібний перехід вимагатиме опанування нових навичок і буде чималим викликом, але мені було дуже цікаво — зміна професії обіцяла багато нового досвіду.

Згідно з описом вакансії вимагали, перш за все, гарну англійську. Зрозуміло, що професії Technical Writer у нас не вчать і що більшість додаткових навичок опановуватиметься в процесі. Тестове завдання мало визначити все: мій рівень володіння мовою, вміння дотримуватись заданого стилю, увагу до деталей і творчий підхід. Воно складалось із завдання на опис функцій гри та завдання на аналіз існуючого опису. Досвід копірайтингу став у пригоді! Чимала складність для мене полягала в тому, що такі ігри (відеослоти) я ще не бачила, і тому спочатку аналізувала їх сама, а потім описувала, як для таких самих новачків — щоб точно все було зрозуміло :)

Після тестового я пройшла решту етапів співбесід, отримала офер і прийняла його без сумнівів — компанія була мені дуже цікава. Перші місяці півтора, як на будь-якій новій роботі, я знайомилася з людьми і процесами і дізнавалась купу нової інформації: перехід з державної компанії до IT за масштабом відмінностей — як переїзд до нової країни.

Професійне зростання. Є безліч варіантів, але мені наразі цікавіше розвиватися у професії, ніж ще раз міняти її — ще на цьому полі повно незібраних квітів, так би мовити.

Я намагаюсь популяризувати техрайтинг серед свого кола знайомих. Минулого року NetEnt разом зі спільнотою Girls in IT організували лекцію про цю професію, її плюси та мінуси та необхідність для бізнесу. Якщо вас цікавить Technical Writing, непогано буде про нього почитати або навіть розпитати знайомих, оскільки це дуже різноманітна сфера. Кожна компанія має свою специфіку — хтось пише інструкції для користувача, хтось правила гри, хтось описує функціонал програми. Треба знайти те, що буде цікаве саме вам.

Поради людям, які хочуть стати техрайтерами, але не знають з чого почати. Для цієї професії чи не основним must have є англійська — більшість компаній спирається саме на неї. Також варто мати досвід, пов’язаний з роботою з текстами, — журналістика, переклад, копірайтинг. Вам потрібно гарно володіти словом, адже ви станете каналом комунікації між компанією та її клієнтом, між продуктом та його користувачем. Ви станете тою ланкою, що забезпечує розуміння та обізнаність.

Евгений Чеканов, Technical writer в Betlab

2 года в техрайтинге

Опыт работы до техрайтинга. У меня самое техническое образование, как говорится, хардкор: автодорожный техникум и автомобильный университет по специальности «инженер-механик». Интерес к технической литературе появился классе эдак во втором, когда я попросил маму купить мне книгу по устройству автомобилей. Было интересно. После университета работа логистом, потом карьера от специалиста до ведущего инженера в областной дирекции одного из крупных банков. Там и был самый большой опыт общения с пользователями и заказчиками. Надо было понять, чего они хотят, и приходилось составлять инструкции для сотрудников. Но работа в банке, впрочем как все под луной, не вечна, и вот после 10 лет в банке пришло время переквалифицироваться. В помощь были курсы по тестированию ПО. Но всеми курсами, как и любым инструментом, надо уметь пользоваться, материал дают слабо и нет практики, зато есть направление, что читать. Прочитан Карл Вигерс и учебники по UML, для начала. После — опять поиски работы.

Первая работа техрайтером. Мне поступило предложение от компании, занимающейся разработкой оборудования и ПО для обеспечения безопасности на железнодорожном транспорте. Что делает Technical writer, пришлось гуглить и читать все, что могло в этом помочь, а такой литературы очень мало. Далее последовало тестовое задание, в основном на понимание стандарта CENELEC, так как ПО для систем повышенной отказоустойчивости на ЖД транспорте разрабатывается только по этому европейскому стандарту. Рекомендую к ознакомлению — там есть много информации о том, что должно быть и в каких документах на различных стадиях разработки ПО.

В компании был подробно изучен стандарт и возобновлено в памяти то, чему учили в техникуме, все стандарты оформления текстовых документов. В то время, когда я учился, стандарты надо было «прочувствовать», от руки чертить все рамки на листах дипломов и курсовых, уметь писать чертежным шрифтом и, само собой разумеется, чертить карандашом и кульманом без использования AutoCAD и SolidWorks. Занимался я в основном составлением SRS, и на данном этапе был приобретен опыт работы аналитиком, так как приходилось собирать и структурировать требования и описывать варианты использования. Пришлось разбираться в различных текстовых редакторах и разрабатывать схемы взаимодействия.

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

Профессиональный рост. Я вот уже год в продуктовой компании, осваиваю новые шаблоны документации (BRD и Concept), изучаю MadCap Flare (интересная и мощная вещь, но не без изъянов). В перспективе считаю, что при должном изучении процессов анализа и менеджмента райтер может без особых усилий расти в сторону бизнес-анализа и управления проектами. Работа на данной позиции обязывает вникать в весь продукт и во все его направления и нюансы, и зачастую бывает так, что райтер владеет большей информацией, хоть и верхнего уровня, по продукту в целом.

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

Олег Романенко, Technical writer у GlobalLogic

понад 5 років у техрайтингу

Досвід роботи до техрайтингу. З дитинства я любив мову й літературу, тому пішов учитись на філфак педагогічного університету. Там розказували про катахрезу, анаколуф і суплетивізм, але не розказували, де брати гроші. Гроші мені довелося шукати самостійно. Я розумів, що педагогом не протягну, тому став спочатку редактором у ЗМІ. Мені знадобилось багато часу, щоб запідозрити, що більшість ЗМІ, до яких я потрапляв, не заробляли гроші самостійно, а освоювали бюджети своїх політично активних власників. Це накладало такі обмеження на життєдіяльність редакції, з якими миритися було дедалі складніше. Оскільки з дитинства я любив не тільки слова, але й комп’ютери, то подумав, що хочу перепрофілюватися на айтішника.

Складно згадати, коли я вперше дізнався про професію техрайтера, можливо, нагуглив, але пам’ятаю розмову з моїм колегою в останньому ЗМІ, де я працював. Колега відповідав за розробку сайту нашого інформагентства. Він порадив мені спробуватись на техрайтера або бізнес-аналітика.

Перша робота техрайтером. На першу роботу техрайтером я влаштувався не зовсім з вулиці — мене порекомендувала подруга, котра сама нещодавно влаштувалась за рекомендацією подруги. Компанія набирала новачків і вкладала час у їхнє навчання. Тестовим завданням було описати російською та англійською мовою один із розділів програми, яку розробляла компанія. Після успішного виконання завдання були три етапи співбесіди. Коли я згадую саму роботу, завжди виникає асоціація з армією. Складнощі, з якими я стикнувся, будучи новачком: фрагментарні знання про процеси розробки ПЗ та про саму розробку, відповідальність за велику кількість продуктів та їхніх версій, обмежена технічна англійська.

Професійне зростання. Мені було би цікаво колись перейти в розробку ПЗ. Я вже понад рік програмую задля розваги.

Поради людям, які хочуть стати техрайтером, але не знають з чого почати. Учіть технічну англійську. Я почав з того, що роздрукував «Microsoft Manual of Style» і читав його з ручкою, зазубрюючи незнайомі слова. Забудьте про рідномовну локалізацію своїх додатків, завжди обирайте американську англійську. Читайте англійською, гугліть англійською. Учіть основи програмування та баз даних. Це дасть вам можливість спілкуватися з розробниками їхньою мовою.

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

Марина Кібченко, Technical Writer в AltaReturn

4 роки в техрайтингу

Досвід роботи до техрайтингу. За освітою я філолог української та англійської мови. Під час навчання я робила акцент на вивченні англійської, свідомо чи підсвідомо пов’язуючи свою майбутню професію саме з нею. Ще у магістратурі я отримала свою першу серйозну роботу — і одразу в ІТ, так що мені навіть не довелося пізнати поневірянь лінгвіста, який тільки-но вийшов зі стін університету. Подруга зі старшого курсу запропонувала роботу офіс-менеджером у стартапі, де вона працювала. Але природа стартапів мінлива: позицію чи то прикрили, чи то я не підійшла, однак відповіді не було. Десь за півроку подруга знову запропонувала пройти співбесіду, але на іншу позицію — спеціаліста служби підтримки.

Мене майже одразу взяли, і я занурилась у вир життя IT-компанії, де мене оточували технарі — люди з чітким, структурованим, але таким відмінним від образного філологічного, мисленням. Про засилля незрозумілих термінів і заплутаних робочих процесів годі й казати! Робота у суппорті мені не дуже подобалась, але вона дала загальне розуміння діяльності ІТ-компанії. Бонусом прийшла ще одна надважлива навичка: не боятися ставити питання колегам, навіть коли наперед знаєш, що не зрозумієш відповідь. І питати стільки разів, скільки потрібно, поки не стане зрозуміло.

Перша робота техрайтером. Під час написання магістерської роботи я паралельно допомагала колишньому колезі з домашнім завданням з технічної англійської, де треба було написати досить об’ємну інструкцію користувача до якоїсь програми. Подібного досвіду в мене не було, як, в принципі, і вимог до інструкції: більш-менш пристойного тексту було б достатньо, щоб закрити модуль. Проте завдання видалося мені цікавим, я ґрунтовно підійшла до справи, багато читала про технічну документацію. Оцінка за роботу була високою, і колега сказав: «А ти ніколи не думала працювати техрайтером? Мені здається, у тебе добре вийшло б. У нашій компанії є вакансія».

На той момент я вважала роботу в суппорті своїм максимумом, але резюме все-таки надіслала. Про досвід не брехала. На мою користь грала лише англійська і те, що під час роботи у службі підтримки я оформлювала типові відповіді клієнтам у FAQ статті — ось і все, що я мала в запасі. Мені надіслали посилання на демоверсію web-програми, яку розроблювала компанія, та тестове завдання: описати англійською мовою один із розділів. За декілька днів після того, як я надіслала виконане завдання, мене запросили на співбесіду з HR, техлідом техрайтерів та керівником відділу розробки. За тиждень я вже була частиною команди.

З кількох техрайтерів-початківців, яких узяли водночас, якнайшвидше були потрібні повноцінні робочі одиниці, тому задачі посипалися майже одразу. Чесно кажучи, голова йшла обертом. Роботи було вдосталь: окрім написання та перекладу текстових документів, ми займалися локалізацією web-рішень, створенням web-довідок, FAQ, навчальних відео для користувачів і т. д. Як я тепер розумію, далеко не в усіх компаніях техрайтер може робити і робить все це. Але для першого місця роботи, для «хрещення вогнем» — кращого годі й бажати. Та все ж найбільше я вдячна цій компанії за колектив техрайтерів. Саме він, без перебільшення, став визначальним у моїй історії. Колеги настільки щедро ділилися знаннями, що ще й досі, зізнаюся, мені важко прийняти той факт, що є люди з іншим підходом до співпраці, до навчання новачків. Користуючись нагодою, передаю віртуальний привіт і подяку моєму колишньому колезі, який теж ділиться своїм досвідом у цій статті.

Професійне зростання. Наразі я будую систему документації вже в іншій компанії. Оскільки робота мені подобається, хочу продовжити розширювати перелік інструментів, які я використовую, та збільшити команду техрайтерів. Також у найближчих планах — навчання на курсах QA, щоб посилити технічні навички та остаточно позбутися бар’єрів у спілкуванні з програмістами та тестувальниками.

Маю також невеличку професійну мрію — спробувати себе у якості комп’ютерного лінгвіста, проте для цього мені поки що бракує хоча б базових навичок програмування.

Поради людям, які хочуть стати техрайтером, але не знають з чого почати. Техрайтер-початківець має постійно розвиватися у трьох напрямках:

  1. «Як писати?» — опанування навичок техрайтингу (специфічні програми та додатки; стиль письма, формати тощо).
  2. «Про що писати?» — здобуття загальнотехнічних навичок, які зокрема допоможуть зрозуміти програму чи web-рішення, яке необхідно описати.
  3. «Що писати?» — робота з вузькоспеціальною англійською, моніторинг галузевої термінології.

Це все не так складно, як може здаватися. Раджу бути допитливим, кмітливим і уважним до деталей.

Карина «Карен» Сорей, Technical Writer/Editor в Cossack Labs

3,5 года в техрайтинге

Опыт работы до техрайтинга. Я получила высшее образование в Харьковском национальном университете им. В. Н. Каразина — переводчик английского и немецкого языков, менеджер медиа-коммуникаций. До того как стать техрайтером, я работала переводчиком, копирайтером — писала на технические темы, была PR-менеджером в компании, разрабатывающей хардверные и софтверные решения для шоу-бизнеса. Кроме того, всегда параллельно занималась музыкой. Сейчас, когда я пишу документацию к серьёзному криптографическому софту, занятия музыкой помогают держать в жизни ментальный баланс между «техникой» и «лирикой».

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

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

В Cossack Labs я попала благодаря DOU. Когда я на какое-то время решила отдохнуть от бешеного темпа работы в шоу-бизнесе и пофрилансить, меня спонтанно начали «хантить» рекрутеры в соцсетях. Активно я работу тогда не искала, но решила посмотреть, что вообще происходит на рынке вакансий для техрайтеров. И нашла на DOU вакансию от Cossack Labs, которая мне так понравилась, что cover-letter к формальному резюме у меня выглядел примерно как «Ааа! Чуваки, вы крутые, я хочу у вас работать!» (не рекомендую повторять в реальной жизни ;))

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

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

И не только жизнь, но и бизнес — скоро, например, вступит в силу Общий регуламент по защите данных (GDPR) пользователей в ЕС. Это сложный свод правил о защите информации частных лиц, и многие представители бизнеса не просто не понимают, как защищать данные своих пользователей, но даже и не знают о том, что такие правила грядут.

В этом случае моя задача — объяснять читателям нашей документации и блогов, как криптографические инструменты могут помочь подготовиться к GDPR и соблюдать требования к защите информации. Разъяснительной работы в планах очень много. Здесь чистое техрайтерство уже граничит и с PR-менеджментом, и с копирайтингом, и с Product management-ом, и с публичными выступлениями — это и есть зона профессионального роста.

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

Главная проверка на профпригодность — сможете ли вы объяснить что-то действительно сложное так, чтобы вас понял 5-летний ребёнок. И это — не просто упражнение, это работает и на реальных читателей. «Объясни мне Zero-knowledge Proof так, будто мне 5 лет» — до сих пор одна из самых популярных статей в Medium-блоге Cossack Labs.


Читайте также: Каково это — быть техрайтером.

LinkedIn

42 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Почему Вы стали техрайтером?

Над моими сообщениями об ошибках плачут и смеются миллионы людей.

Несмотря на то, что этой профессии нигде не учат, овладеть ею не особенно сложно.
К профессии техписателя можно прийти по-разному, (сам пришел так: технический перевод —> локализация —> техписательство), но теперь понимаю, что самый минимум для именно интересного и стабильного старта техписателем: Proficient English, HTML, Git, Jira. Все остальное вариабельно в зависимости от проекта и легко осваивается с учетом знаний вышеперечисленного.
Если еще и код понимаешь хотя бы поверхностно или сам потихоньку кодишь — вообще отлично — как для тебя, так и для команды.
Также, хороший техпис не только пишет контент, но и умеет сам его опубликовать, для чего необходимо знание базы (см. выше) плюс знакомство с наиболее известными тулзами для генерации/публикации доки.

а хтмл почему в списке маст хев?

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

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

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

Доречі, а вживати абревіатури без їх попередньгго розкривання хіба не моветон? ;-)

В документации — да, моветон )

В одном описании вакансии встретил такое: «Please do not apply if you are the type of Technical Writer who likes to pass around MS Word documents in email.» — хорошее и емкое уточнение, на мой взгляд, т. к. сам часто сталкивался с подобным ограниченным пониманием работы техписателя.

хз, не в курсе чем это мс ворд так не угодил тех писателям)

Гуглодок его вытеснил же ))

увольняют со свистом за гуглодок в больших корпорациях)

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

а я не зрозуміла, що вони мали на увазі під висловом

who likes to pass around MS Word documents in email.

поясніть, будь ласка, для тих хто в танку:)

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

Experience with modern documentation formats (asciidoc, docbook, markdown).

You know what version control is and have used Git before.

Sysadmin/DevOps skills on Linux and Windows.

Порадовали DevOps-скиллы в последней строке :) «Я ведь еще и немножечко шью».

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

а теперь немного горькой правды (да, я знаю, что гугл и анонимусы запомнят и не простят мне, но все же):
1. кто идет в техрайтеры?
1.1) неудачники (тупицы, ленивцы етц), которые не смогли в IT-технологии (но долларов хочется)
1.2) небуйные психопаты (нормальные люди физически не могут в типичные задачи техрайтинга из месяца в месяц)
1.3) свитчеры (не люблю этот новояз, но к контексту лучше не придумаешь), как правило — «зачаровані дівчата» (опционально — с покровителем/покрывателем из тимлидов/синьоров)
1.3.1) филологи-англоязы, вследствии тотальной ориентации галерного курса на аутсорс и фактического уровня английского у местных айтишников
1.4) карьеристы-переростки в IT, как разновидность пункта а), которые еще не смирились
2. что делают техрайтеры?
2.1) самый редкий вариант, «Шоколадная фабрика» — пишут человеческими словами то, о чем думает продакт/прожект/архитектор в формате бэклога/спецификации (ахтунг, техпись! это — твой единственный шанс хотя бы на одноклеточное развитие и сохранение психики и самоуважения)
2.2) ГОСТ-ДСТУ, гос.сектор, ТЗ/ТВ/ПМВ/"инструкции«. Следующая стадия 1.2) после арсенала средств советской психиатрии (не шучу).
2.3) инструкции пользователям. если задачи реальные (не «чтобы было») — работа скорее для прикладных психологов, воспитателей дет.садиков и прочих НЛП-истов
2.4) комментарии для кода и скриптов вместо ленивых и заносчивых разрабов/девопсов, со схемками. т.е. по факту — делают работу вместо их прямого руководства
2.5) грязная работа вместо бизнес-аналитиков, ключевое — «тех.писатель, который может в UML/BMPN/черталысого»
3. как стать тех.писом?
3.1) см. п. 1.2)
3.2) читать, оценивать, писать. Иногда давать читать другим (чревато увечьями и потерей добрых отношений). по сути — никто этого делать не будет (начинают все обычно с «первого заказа»).
3.3) из всех стандартов/технологий, супер-максимум — Markdown. если требуется что-то еще, что не учится в спокойном режиме на исп.сроке — «бегите, глупцы!»
3.4) инглиш, мазафака! но ты его не выучишь, нет.

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

P.S. Разрешают цитировать и перецитировать этот текст в ответах на многочисленные «а как стать», «а где найти», «а что должен уметь» и т.д.

Я думал у менеждера проекта есть работа...))) вот копия со станици linkedin, и жнец и швец...)))
«открыт для remote/part-time предложений по позициям — технический писатель (technical writer), бизнес-аналитик (business analyst), менеджер проектов (projects manager)
при заинтересованности, прошу принять во внимание текущую full-time-job — с 9.00 до 18.00 по GMT+2 (менять не собираюсь)»
и к слову про неудачников..работа невесть на какой позиции в непонятно каком (городском) инкубаторе)))))))

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

Администрации доу чем-то мой комментарий не понравился, но я все же повторю свой вопрос. В документации вместо точек и дургих знаков препинания вы тоже «))))» ставите?

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

А ви свій JS код також пишите російською мовою?:)
Ну реально, якась зачіпка на рівні 1 класу...:)

Естественно, javascript же поддерживает UTF-8. Да и есть yoptascript — довольно таки популярный ЯП, транслируемый в javascript.

LOL

ну это ты как-то с негативной точки зрения расписал без шанса на позитив.
давай я напишу с другой точки зрения:
ЭТИ ЗОЛОТЫЕ ЛЮДИ СПАСАЮТ НЕ ТОЛЬКО ДЕВЕЛОПЕРОВ ПМОВ НО И БА ОТ САМЫХ РУТИННО СКУЧНЫХ ЗАДАЧ (имхо конечно).
СПАСИБО ЧТО ЕСТЬ ЛЮДИ У КОТОРЫХ ПСИХИКА ЗАТОЧЕНА ПОД ТАКИЕ ЗАДАЧИ И КОТОРЫЕ ИХ С УДОВОЛЬСТВИЕМ ДЕЛАЮТ!!!

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

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

на том уровне, на котором она быть должна — хватит и несколько строк от ПМов-тимлидов + инфографика
на сервисы Гугл и Эйпл, всякие амазоны — неожиданно, действительно полезная информация исчерпывается несколькими абзацами текста среднего по сути качество. новое время, новые способы подачи инфы.
Это для продуктов, а для разработки — продакт бэклог + схемки всякие, для вменяемой команды на результат — хватает выше крыши.

Мануалы пользователям кто будет писать?
Ранбук по существующему функционалу?
Инструкции саппорту?

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

что все это отлично делают разрабы, девопсы, ПМы и даже тестеры. я, на самом деле, серьезно — наблюдал не раз.
ЭТИ ЗОЛОТЫЕ ЛЮДИ СПАСАЮТ НЕ ТОЛЬКО ДЕВЕЛОПЕРОВ ПМОВ НО И БА ОТ САМЫХ РУТИННО СКУЧНЫХ ЗАДАЧ (имхо конечно).
СПАСИБО ЧТО ЕСТЬ ЛЮДИ У КОТОРЫХ ПСИХИКА ЗАТОЧЕНА ПОД ТАКИЕ ЗАДАЧИ И КОТОРЫЕ ИХ С УДОВОЛЬСТВИЕМ ДЕЛАЮТ!!!

Вы меня простите конечно, но пишите Вы глупости какие-то. Я вообще не согласна с тем, что мануалы легко могут быть написаны кем-то другим, без участия технического писателя. Вы ведь ПМ, как я вижу, а про обязанности каждого конкретного члена команды имеете крайне скудные представления. Я Вам открою ОГРОМНЫЙ секрет, все что Вы пишите — чушь полнейшая, если выражаться культурно. Не работали Вы, видимо, на забугорные рынки и не знаете, что например в той же Америке очень востребована должность Technical Writer. Их очень ценят и, что немаловажно, доверяют им самое главное — познакомить юзера со всеми тонкостями предоставляемого продукта. Дать четкие инструкции и указания, направить на путь истинный. Гайди/мануалы (называйте как хотите) нужны не потому, что у проекта проблемы, а потому, что он может быть настолько огромным и включать в себя настолько много фич, что он ни в каком мире не может быть ИНТУИТИВНО ПОНЯТНЫМ. Та же история с количеством юзеров, которые будут использовать конечный продукт. На секунду представьте, что таких юзеров сотни и каждый (!) использует его по своему. Не потому, что юзер такой противный, а потому что главная задача конечного продукта — возможность использования этого самого продукта для самых разных целей и получать самый разный конечный результат. Как Вы думаете, как в таком случае продукт может быть ИНТУИТИВНО ПОНЯТЕН КАЖДОМУ ТАКОМУ КОНКРЕТНОМУ ЮЗЕРУ?
К Вам большая просьба, не сотрясайте, пожалуйста, воздух впустую. Ваше мнение крайне ошибочно и совершенно не обосновано.

Господи, что это за генератор «случайного бреда»? Начнем с того, что большинство наших «галерных» знают английский на уровне «I am job», поэтому изложить свои мысли не могут не только на бумаге но и в голове. А куда из Микрософта бежать, может расскажешь Joe Welinske что он что-то неправильно делает? Если у тебя был неприятный опыт говно-кода в говно-продукте, это не значит что профессия не нужная. Все серьезные и комплексные СRM и ERP системы требуют просто тонны документации и это не «how to» articles.

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

ни разу (!) за всю карьеру, я не видел юзабельной документации по ерп-срм-прочим бухгалтериям. НИ РАЗУ.

Чукча, очевидно, совсем не читатель. Хотя да, хорошая документация редка, и рука мастера в ней чувствуется.

«коридор» пишется с одним Р, ну в принципе твой уровень понятен. У тебя русский родной? Если ты безграмотен на родном языке, то я могу себе представить, что ты пишешь в техническом задании на английском. А технические писатели как раз разгребают тот горячечный бред что пишут так называемые «грамотные програмИЗДЫ». У меня за 18 лет такая «подборочка» насобиралась — буду вместо анекдотов внукам читать.

Вопрос надо ставить по другому — как часто ты сталкивался с ERP-СRM системами? И нет, я не про говняную «1С-Бухгалетрию», а про нормальные вроде Axapta, BMC Remedy, SAP, ServiceNow? Я уже понял что RTFM — это не твоя сильная сторона, но зачем сразу так расписываться в своем невежестве?

вся информация для работы передавалсь «из уст в уста», и неожиданно — все всегда работало ок

Вы неожиданно ошиблись планетой, никто тут в здравом уме не считает передачу из уст в уста нормальной практикой и никогда, абсолютно НИ РАЗУ, это не работало окей. А если вам кажется, что это работает окей — ну так некоторым тоже кажется, что их неюзабельное говно на палке это космософт будущего... А вы намеренно занижаете стандарт качества и рассуждаете на уровне «накрошил в водку укропа — получилось мохито!» )

«из уст в уста» — это нормальный технический процесс? А что будет если «технический гуру-толкователь из уст в уста» случайно свалит работать на другой проект?

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

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

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

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

Искренее ваш, тех.пис с семилетним стажем.

Дайте вгадаую: Ви працювали, в більшій мірі, на вітчизняного «виробника»?
Я бачив що і як роблять техрайтери, і як до них ставились колеги-програмісти. В жодної із сторін ненависті там не було.

Яка ж скотиняка так травмувала Вашу психіку?

P.S.: І не влом було стільки нісенітниць строчити?

Подписаться на комментарии