Комментарии 18
Я сталкивался с техническими писателями - с ними не о чем разговаривать. Это не программисты, не разработчики. Они просто берут какой-то стандарт RFC, криво переводят его на русский язык, а разработчики даже и не читают эту локализованную техническую документацию.
У меня был смешной случай с VK, когда технический писатель в документации пишет про PKCE, а по факту это даже и не реализовано - "в Киеве бузина, в огороде дядька". Я и смотрю что без PKCE и с PKCE с шифрованием SHA256 - результат один и тот же. Бывает тимлиду "в падлу" организовать написание технической документации, он нанимает на фрилансе какую-нибудь безграмотную девочку, которая ничего не понимает в разработке. Она переводит, никто это не читает, не тестирует, что там написано и всё - дыру заткнули, у нас есть техническая документация по проекту. Все молодцы.
Такая ситуация действительно имеет место в некоторых компаниях, и она скорее указывает на организационные проблемы, а не на профессию технического писателя как таковую. Хорошая техническая документация — это не просто перевод стандартов или формальное заполнение требований. Это часть пользовательского опыта, которая помогает разработчикам, тестировщикам, инженерам и даже конечным пользователям работать с продуктом.
Случаи, когда документация оказывается оторванной от реальности, как ваш пример с PKCE, чаще всего говорят о слабом взаимодействии внутри команды. Технический писатель не обязан быть экспертом в программировании, но он должен быть интегрирован в процессы, чтобы понимать продукт и его особенности. Это, в свою очередь, зависит от менеджмента: привлекли ли писателя к обсуждению технических требований, дали ли доступ к тестированию, проверяется ли документ специалистами до публикации?
Если "дыры затыкают" без реальной проверки, проблема в подходе, а не в профессии. С хорошими писателями и грамотной организацией вы бы не заметили разницы между документацией и продуктом — всё бы работало как часы.
Ну и к слову: утверждение, что с техписами "не о чем поговорить", — это тоже стереотип. Многие писатели — это люди с инженерным или ИТ-фоном, они способны обсуждать архитектуру, стандарты и фреймворки. Всё зависит от конкретных специалистов и задач, которые перед ними ставят.
А чем разработчики отличаются от программистов?))
Может быть, от того, что вам "не о чем разговаривать" с техписами, им и приходится "брать какой-то стандарт RFC и криво переводить его на русский язык"....
Так что, если у вас есть желание разбираться в сложных вещах и делиться этим знанием с другими — добро пожаловать в профессию!
Желание в профессию не этим должно определяться, и не определяется после рождения детей. Так и в учители можно уйти.
Плох техпис, который не мечтает в менеджеры или погромисты. Во-первых, это карьерный тупик, во-вторых, при тренде "а давайте-ка заменим <примерно всё, что сможем, или хотя бы попытаемся> ИИ", с реакцией топ-менеджмента на подобные предложения в диапазоне от аплодисментов до гримасы восторга со слюнями - профессия вымрет, как вымерла профессия переводчика.
Советую все же ближе к коду, UX, дизайну, или бизнес-логике. Писательство ОЧЕНЬ неблагодарная профессия, профессия падальщика - ты от всех зависишь, а от тебя - никто.
Еще и в комментах обосрут: "разговаривать с ними не о чем". Ну, милай, не разговаривай. За тебя тимлид поговорит. А мудаков эффективных менеджеров всегда хватает, техписы-то тут причем.
Ну что ж, комментарий как артхаус — читаешь и ощущаешь сразу весь спектр эмоций. Давайте разберём по частям.
Про "карьерный тупик". Это смотря как смотреть. Если техпис видит себя исключительно как "падальщика", который только и делает, что пишет под диктовку, то да, перспектива так себе. Но современный техпис давно уже не про копирование RFC. Это и UX-исследования, и взаимодействие с продуктовой командой, и настройка CI/CD для документации, и работа с API. Ближе к коду? Да это уже давно рядом, просто под другим углом.
"ИИ всё заменит." Вы знаете, как и переводчики, техписы адаптируются. ИИ умеет генерировать тексты, но он не умеет проверять, работает ли оно, и делать так, чтобы разработчику и юзеру было понятно. А ещё у топ-менеджеров иногда и на ИИ реакция «восторг со слюнями», а потом выясняется, что документацию всё равно нужно — и качественную, а не автогенерацию.
"Зависимость." Да, техпис зависит от команды. Но и команда от техписа зависит, если только не хочет тонуть в макулатуре багрепортов, недоумении новых сотрудников и хаосе с API. Это больше про взаимную выгоду, а не "зависимость".
"Обсуждения с техписом." Тут каждый проецирует своё. С кем-то и поговорить приятно, а кому-то, может, и с собачкой общаться тяжело. Но это скорее про личное восприятие, чем про профессию.
"Советую ближе к коду." Отличный совет! А теперь угадайте, сколько техписов уже этим занимаются: пишут скрипты, автоматизируют, мейнтейнят собственные проекты. Техпис XXI века — это практически междисциплинарный специалист, и если вы думаете иначе, возможно, просто не повезло встретить хорошего.
Ну и, конечно, всегда можно уйти в менеджеры. Главное, чтобы это было не из-за усталости от «эффективных».
Мне не надо объяснять и гадать, я в индустрии, на полях, дольше, чем Хабр существует. Я не говорю, что профессия ненужная или не требует квалификации и компетенций. Но ROI низкий, лучше время и усилия вложить в другую область. Документация всегда вторична-третична по приоритету в глазах стейкхолдеров. Скриптопис так и не будет оценен - менеджер скажет на викли "кудос" и всё, "для себя ж автоматизировал". Снаружи это "достижение" никому не видно, кроме пиэма, которому на тот же скрипт не хотелось на пару часов инженера привлекать, пока техпис пару дней потратил. Что, говорите? У вас техписы за час пишут? А что ж они еще не инженеры?
это карьерный тупик
Чёт орнул, так тогда можно и про остальных IT спецов сказать))) аналитики, тестировщики привет)
только ворд и gdocs, только хардкор
С этого всё и начинается в 99.9999% случаев :) Тут главное - не упустить момент, когда хардкор уже начался и стал мешать всей компании. Часто ведь мы привыкаем к чему-то и считаем это само собой разумеющимся. Нужно выныривать из этого "привычного болота" иногда и смотреть - не пора ли что-то менять? А ворд и google docs хороши в начале - легко, просто, наглядно, на выходе PDF получили, выложили на сайт или включили в пакет установки и радуемся. Вот только через пару лет этот PDF весит 150 мегабайт и перестаёт открываться на мобилках, так как память кончается :))
Мифы не то чтобы очень распространенные, ну в плане, не помню чтобы ко мне подходили люди на улице или коллеги и говорили: "а ты знаешь техписы не участвуют в разработке и только пишут" (хотя кстати многое зависит от процессов а компании).
Но если компания не забюрократизировалось на столько что каждый человек прям вот винтик с единичной функцией. То сказанное в статье справедливо. Именно поэтому из инициативных техписов со временем вырастают аналитики.
Так что за статью ставлю лайк.
Если так подумать, из любых инициативных сотрудников со временем вырастают очень интересные персонажи :) А из техписов кто только не вырастает, с учётом навыков внятно писать, внятно говорить и объяснять, вовлечённости в технические вещи, вовлечённости в кросс-командные процессы, в построение взаимоотношений с клиентами, и т.д. Это очень верно ещё и для тех. поддержки, которая имеет сходный профиль вовлечённости. Так что роль техписателя зачастую не тупик, а трамплин.
Сама технический писатель, работаю в сфере электронных устройств. Так вот - из инструментов только Word или LibreOffice. Мы по ЕСКД оформляем всю документацию и в архив через нормоконтроль сдаём.
По поводу того, что на текст непосредственно уходит 20% времени - полностью согласна. Только о работе с ГОСТами как-то не написали (в ИТ этого нет?). У меня 30% или больше уходит на них, потом ещё 50% - на работу с инженерами (это приятно) и со сторонней, часто китайской, документацией. Вот последнее - ужас ужасный. Поэтому техническое образование считаю необходимым. Надо как минимум уметь разобраться в кривой документации, а как максимум - пинать инженеров, чтобы они при разработке учитывали требования всех необходимых стандартов 😁, и менеджеров продукта, чтобы ахинеи и фантазий в технических характеристиках продукта не было.
По профессиональному росту - да. На текущем месте работы предложили подучиться и переходить работать программистом. Вот он, мой свет в конце тоннеля😄
О! ГОСТы это вообще отдельная тема, особенно когда стандарты идут вразрез с реальной документацией от китайских производителей.
Что касается профессионального роста, ваш "свет в конце тоннеля" звучит мотивирующе. Главное, чтобы он оказался не встречным поездом из бесконечных требований программирования. 😄 А если серьёзно, умение адаптироваться между такими разными сферами — мощный навык, который точно пригодится в любой карьере.
P.S. Менеджеров продукта пинать — это, похоже, у всех техписов стандартный soft skill. 😁
P.S. Менеджеров продукта пинать — это, похоже, у всех техписов стандартный soft skill. 😁
Ну вот и спрашивается - фейхоа настолько вылезать за зону своей ответственности и бесплатно, не имея при этом никаких средств влияния, (пытаться) пинать умолять стоящих выше в иерархии господ с зряплатой выше писательской в Н раз? Я ж и говорю, вахтерша тетя Маша из пятого цеха - вот кто техпис.
И да, в местах, где ГОСТам/ЕСКД денег нет для писателей.
Вахтером, к сожалению, тоже бываю. Застопорить старт продаж из-за отсутствия достоверных характеристик либо несоответсвия китайской продукции обязательным стандартам - пожалуйста. И куча говнистых писем, что вставляем палки в колеса и прочее. Основная проблема в том, что менеджеры ПРОДУКТА свой продукт зачастую не знают и знать не хотят. Для таких тех.параметры - просто набор цифр, который желательно должен быть лучше, чем у конкурента. Другой перегиб той же проблемы - уникумы, которые пытаются свалить ответственность. Недавно было письмо: посмотри, все ли в порядке с чертежами, которые фабрика прислала, можем по ним заказ размещать?
Зарплата моя на уровне инженера-конструктора 1 категории. У нас не оборонка, поэтому уровень зп в конструкторском отделе не очень высок. Готова с этим мириться, чтобы не общаться с китайцами и сохранять нервную систему. Но особо юркие ПМ пытаются и это на меня спихнуть. При том что зп у них и правда в разы выше моей.
Эх, накипело, выговорилась)
Учите кодинг/скриптинг, с китайским и английским, если знаете, вообще неплохо можно устроиться. Уходить с производственного предприятия в финтех, банкинг, IT, B2C, и поближе к нулевому меридиану, или наоборот, к 180-му.
Верно, писатель виноват всегда. В блок релиз поставил - виноват. Нет доков вчера из-за молчаливого пиэма-ревьюера, который же сам и запросил обновление - тоже виноват.
Про неадекватные задачи: было как-то - CEO на писателей спустил выяснить, нормально ли определенное поведение а случае сочетания (метафорической) розетки X и (метафорической же) вилки Y. Специфика могла быть и не в сочетании конкретной вилки и розетки, а лишь на стороне розетки (или розеток) или вилки (вилок) - никто не знал. Вилок условно 500, розеток 20. Такое видение, к сожалению, транслируется вниз по вертикали и отражается в кадровом отборе.
Правда или вымысел? Разоблачаем мифы о профессии технического писателя