Comments 25
Ну вот, мальчика на целый комментарий из четырёх слов хватило :-)
Я периодически слышу такие заявления про нейросети и смерть профессий. Поделитесь пожалуйста, почему вы считаете, что это серьезный риск? И если не сложно расскажите, как вы связаны с документацией и/или нейросетями
Вы хотите тонко намекнуть, что если ты не разработчик нейросетей, то не имеешь права высказывать своё мнение?
Почему вы думаете, что я хочу вас задеть? Я ведь ничего о вас не знаю и вижу только юзернейм и аватар. Вот вы рассказали, что в айти 20 лет, и имеете какое-то отношение к написанию доки. Уже появилось какое-то понимание, на каком уровне можно говорить.
На данный момент, в программировании добавляет процентов 5-10. Но при написании документации, уже процентов 50.
Бывает много разных типов документации, не мне вам это объяснять. То что вы описали примерно сравнимо с идеей, что разработка сильно ускоряется за счет кодогенерации или печати вслепую. Предположу, что вы генерируете что-то вроде описаний методов и свойств АПИ, где все достаточно линейно, но я так себе экстрасенс.
Объясню, почему я отношусь к описанному вами именно так. Во-первых, вы уже владеете той информацией, которую собираетесь передать пользователю. Но знания чаще всего распределены между множеством экспертов и стейкхолдеров, и значительная часть работы писателя - добыть эти знания.
Во-вторых вы, видимо, точно знаете, какие проблемы будет решать пользователь с помощью этих знаний, и вам остается только перевести их в человекочитаемый формат.
Это наименее затратная часть работы, и если ваши задачи по документации заключаются только в этом - вы конечно же правы, такая работа легко автоматизируется. Просто в моей работе как техническикого писателя такие моменты занимают процентов десять от общего времени, и имеют тенденцию к снижению как раз за счет автоматизации.
Особенно если быть реалистом и понимать, что в 80% случаев написание документации, это пустая формальность. И никто, никогда её не будет читать.
Соответсвенно если у компании появляется возможность закрыть эту формальность
Я бы предположил что вы описываете процессы написания документации по ГОСТам, но как я сказал выше - я так себе экстрасенс. Я не первый день в писательстве, и пользуюсь аналитикой как посещаемости, так и обратной связи по документации. Также работаю в связке с спппортом и смотрю, какой докой пользуются они для ответов, иногда пишу доку на основе их ответов юзерам.
В целом у писательского сообщества с момента начала хайпа по нейросетям к теме огромный интерес, инструменты внимательно изучаются, новые подходы тестируются. Но пока что ничего кроме улучшения и корректировки уже написанных текстов, разворачивания скелета, суммаризации и автоматизации описаний АПИ просто нет. И это, собственно, и позволяет мне оценивать риск замены писателей как крайне незначительный, потому что этот инструмент просто помогает мне делать часть работы чуть быстрее, но никак не угрожает тому, за что на самом деле мне платят деньги.
Может быть конечно у профессионального писателя это занимает 10% от времени написания документа, у меня же как раз 50% или больше.
Да дело не в том, сколько времени занимает само написание текста. Это же просто фиксация результата, которую нужно облечь в слова. Да, когда я был джуном, я мог просидеть полдня над парой абзацев, потом потихоньку ускорялся. Просто с ростом грейда начинаешь решать большую часть времени другие задачи.
Условно можно сказать что есть две главные вещи – зафиксировать знания, распределенные между экспертами в нужном виде (то есть понять что ты описываешь, как это работает и какие есть ограничения) и разобраться, как эффективнее всего решить проблемы как можно большей части пользователей с помощью этих знаний (написать инструкцию, пост в блог, обзорную статью, практическое руководство, заметку в базу знаний и тд). И только после этого уже можно садиться за текст. И в данном случае, даже если представить, что текст будет писаться на порядок быстрее, это только на пользу — появится время на решение следующих пользовательских задач и более детальную проработку.
То есть главный мой вывод в том, что основная деятельность писателя не в написании текста как такового, а в управлении "сложностью" получившегося продукта и адаптация "сырых" знаний о нем, существующих внутри команды в удобный для пользователя вид. И эта задача должна решаться при создании запроса к нейросети, и если она решена – большая часть работы сделана, а решить ее в общем и целом может только человек.
Проблема же не в том что их не станет как класса, а в том за счёт увеличения производительности уменьшится потребность в количестве писателей.
Да, те кто не смогут адаптироваться и начать использовать эти инструменты в работе, могут столкнуться с трудностями.
Но даже если представить, что нейросети смогут и писать документацию по коду под запрос условного аналитика или архитектора, и предоставлять что-то типа нейроответов по конкретному продукту с приемлемым уровнем качества, все равно нужны будут люди, которые будут следить и за стилистикой, и фактической полнотой этих ответов, то есть проводить качественное ревью и соблюдать консистентность получившихся документов по всей документации. Такие люди также должны будут владеть полученными массивами сгенерированной информации чтобы, например, эффективно их обновлять при появлении новых версий и рефакторить при изменениях интерфейса или АПИ.
Я бы сказал, что это больше похоже на форсированное повышение культуры документирования, и это если принять как факт то, что нейросети действительно дойдут до такой планки качестве в течение пяти лет. Но с траекторией я в целом согласен, рутинные операции наверняка будут автоматизироваться. Просто я не согласен с выводами.
Если вы входите например в топ-10% своей профессии, то лично вам конечно смысла нету переживать. Но тем кто прочитает статью и решит запрыгнуть на этот поезд, надо понимать, что будущее может быть не таким радужным как оно представлено.
Хотелось бы, конечно, но я в этом совсем не уверен. Тем, кто читает этот комментарий, я бы предложил еще сильнее вкладываться в свое обучение как технологиям, так и языковой составляющей писательской деятельности. Учиться для адекватного ответа на вызов времени предстоит еще больше.
Если у вас примеры вашего творчества доступные всем желающим - дайте ссылку, интересно посмотреть на конечный результат.
Мне скрывать особо нечего, я работаю в команде документации Яндекс Облака, результаты моей работы доступны всем.
Я вашу позицию понял, время покажет кто прав. Но резюмирую перед завершением дискуссии несколько вещей, которые все так же дают мне основания не слишком сильно беспокоиться по озвученным вами поводам:
Нейросети не производят новые знания — они генерируют что-то на основе уже известных вещей. Чтобы нейросеть смогла заменить документацию, ей сначала нужно скормить соответствующую информацию, которая будет содержать инструкции и концептуальные описания в каком-то виде. Ну и я думаю понятно, что самый актуальный контент такого вида с наибольшей концентрацией знаний — документация. Если для этого писателям придется приобрести компетенции ai-тренеров — пусть так.
Сейчас неизвестны даже теоретические способы побороть галлюцинации нейросетей. То есть все равно нужен источник истины,
окончательная фиксация знаний от разработчиков. Да, это же относится к сгенерированному коду или конфигурациям.Речь выше идет о нюансах передачи знаний в направлении разработчик — пользователь. Теперь, собственно, о другой стороне — про покрытие сценариев пользователя, условно про сопоставление возможностей ПО и запросов пользователей. Нет нормального описания того, что умеет ПО в виде перечня сценариев/анализов кейсов/описаний интеграций в проприетарном ПО — пользователям может даже не прийти в голову, что такая возможность есть.
И в данном случае не важен сам по себе канал передачи информации. Печатали документацию на бумаге, собирали в Ворде/пдф, готовили оффлайн справку в какому нибудь .chm, пишут сейчас в онлайне, будут готовить какой-нибудь контекст для Retrieval-Augmented Generation для актуальных ответов, генерируемых в реальном времени — ВС се равно нужны будут люди, отвечающие за этот процесс от и до.
Я довольно много программировал с помощью нейросетей, хотя это конечно хобби-проекты, не промышленные вещи. Я столкнулся с таким количеством неопределенностей, что без документации и помощи сообщества по использованным библиотекам я бы точно не запустил эти проекты в прод. И я при этом не рисковал ничем кроме пары вечеров на переписывание несложных утилит, а в реальности полагаться на алгоритмы, являющиеся для абсолютного большинства черным ящиком — риск, выражающийся в серьёзных деньгах.
Это я все веду к тому, что кто-то должен нести ответственность за то чэкакие знания получают пользователи и за то, что пользователи получат из усвоенных знаний именно ту информацию, которая им нужна.
На этом с моей стороны точно всё.
не, спс
и еще раз спасибо за баны авторов. вот только кликбейтные названия статей забаненных авторов находятся и справа в "читают сейчас". было бы справедливо скрывать их и там =)
«Держатель профессии» — это хорошо, но можно лучше. Например, «местоблюститель позиции» или «поверенный по инструкциям».
Кроме шуток, статья очень «девочковая», скорее про коммуникации и прилежание, чем про технические нюансы профессии.
Прилежание только девочкам нужно?
Я бы назвала её не «девочковой», а вводной для тех, кто о профессии слышит в первый раз. В ней нет ничего нового для техписателей, скорее просто общие факты и биографии людей. Могу предположить, что у Хабра и была такая задумка — сделать что-то вроде развлекательной вводной
Хотела начать текст с шутки про то, что раз инструкции никто не читает, то и писать их не обязательно.
Пардон, но какая же это шутка? Это чистая правда. Никто не читает. Но наличие инструкции, особенно актуальной, позволяет пользователя послать ее читать, пока ты занимаешься другими более срочными делами, чем техподдержка этих тех, кто не читает...
Ну так если пользователь был успешно послан читать документацию, разве он её не читает?
По работе приходится иногда касаться техподдержки. Бывают такие пользователи, которые прямым текстом говорят, что ничего читать не будут, - с такими вполне срабатывает "Вам прочитать вслух то, что в документации написано? У вас есть пара часов времени? А если не запомните, вам снова читать?"
Если до пользователя донести, что либо он таки прочитает документ, либо он не сможет пользоваться купленным продуктом, и окажется, что он деньги потратил впустую, то обычно всё-таки доходит.
Он ее читает - но как правило после того, как уже налажал. И да, далеко не все пользователи оплачивают стоимость техподдержки и даже покупают продукт.
Если он не читал документацию, налажал, но при этом ничего не покупал, то чьи это проблемы?
Иногда это очень сложно сказать. Ну представьте что у вас пользователь и поддержка - это одна компания. Т.е. это внутренний потребитель. Даже если он платит деньги за поддержку и за продукт - эти деньги все равно в каком-то смысле перекладываются из одного кармана в другой.
Я в том смысле, что если это покупатель продукта - то ваш первый комментарий совершенно правильный. Просто бывают и другие варианты.
Варианты, конечно, бывают разные. Если пользователь продукта работает в той же компании, у него нет должностных обязанностей? Например, изучать документацию, чтобы уметь работать с продуктом. Или он по каждому "у меня не работает" сразу дёргает техподдержку?
Ну, а вы попробуйте его заставить? Вот я как 3 линия (и разработчик) что могу сделать такому пользователю? При этом я в целом понимаю, что у него есть куда других задач, как и у меня. Внутри компании деньги не работают. Учить, улучшать документацию, строить пользователей ровными рядами, улучшать процессы... это все можно, но особых пряников, как и кнутов, у меня для них нет. Его начальник просто скажет - у нас есть задачи поважнее. Впрочем, иногда и я им такое же скажу (что часто есть чистая правда - что важнее, делать новые фичи, или поддерживать/писать документацию? на это нет одного верного ответа).
Наличие инструкции, скорее, нужно самой же техподдержке. Не всегда возможно держать в голове вообще всё. Но если знаешь, куда посмотреть, если забыл - это же прекрасно.
А я диаграммы люблю.
Вот бы тех. писатели освоили трансформацию док в диаграммы.
Тогда и доки станут интересными. :)
Кстати, так и делаю - доки и исходники перегоняю в Mermaid syntax через LLM.
Вошёл в айти через техписательство (полгода админом-эникейщиком у отца на работе не в счёт) и вот уже 17 лет пишу )) Иногда про себя называю себя первородным техписом, по аналогии с вампирами ))
Профессия: технический писатель