Size: a a a

technicalwriters

2020 May 16

SP

Sergey Protsenko in technicalwriters
Noname
Спасибо,я его очень активно изучаю.Но ещё много пробелов у меня лично,чтобы понять весь курс
прямо моя любимая тема с API) я бы еще рекомендовал посмотреть в сторону swaggerHub.

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

https://idratherbewriting.com/learnapidoc/docapis_finished_doc_result.html
источник

SP

Sergey Protsenko in technicalwriters
и не переживайте, больше общайтесь с командой, спрашивайте, читайте, API - это не ракеты в космос запускать, все у вас получится)
источник

FM

Fox Mulder in technicalwriters
Andrey
Ясно. Это хард. Я с таким на радость не сталкивался😁
Я тут подумал на досуге, сделал анализ требований и пожеланий к техписам со стороны крупных работодателей и пришел к выводу: Всё чаще и чаще команда ищет разработчики или девопса на роль техписа, как законченного специалиста по стеку продукта.
Пример: мы разрабатываем Облако и нам надо писать документацию. Нам проще нанять devops_а, который знает про openstack, разворачивал облако, писал yml-конфиги и т.п., чем нанимать техписа, который будет еще n_ое время погружаться в проблематику и то не факт.
Тоже самое, например, в командах, которые пилят софтварный продукт. Такой команде проще взять мидла уже с умением кодить и который желает писать (и любит). Пример - JetBrains, который сразу пишет в требованиях к кандидатам умение кодить, например, на Kotlin.
==================
Второе наблюдение в том, что всё чаще и чаще, разработкой документацией занимаются сами продакты и/или аналитики, либо продуктовнеры, как лица , которые максимально глубоко погружены не только в продукт но и окружение этого продукта.
==================
В итоге, что мы имеем.
1. Обычный техпис не умеет в код
2. Обычный техпис не сможет развернуть среду
3. Обычный техпис не может в аналитику
4. Обычный техпис не может в QA
5. Обычный техпис не может в математику (для частных случаем техдокументации)
—-
Как итог, ситуация на рынке нерадостная. )
источник

SP

Sergey Protsenko in technicalwriters
добавлю, обычный кодер, девопс и тд не может в техпис, как показывает практика)
источник

FM

Fox Mulder in technicalwriters
Sergey Protsenko
прямо моя любимая тема с API) я бы еще рекомендовал посмотреть в сторону swaggerHub.

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

https://idratherbewriting.com/learnapidoc/docapis_finished_doc_result.html
Кстати, а очень неплохо сделан сайт
источник

SP

Sergey Protsenko in technicalwriters
да, это синиор техпис амазон
источник

A

Andrey in technicalwriters
Fox Mulder
Я тут подумал на досуге, сделал анализ требований и пожеланий к техписам со стороны крупных работодателей и пришел к выводу: Всё чаще и чаще команда ищет разработчики или девопса на роль техписа, как законченного специалиста по стеку продукта.
Пример: мы разрабатываем Облако и нам надо писать документацию. Нам проще нанять devops_а, который знает про openstack, разворачивал облако, писал yml-конфиги и т.п., чем нанимать техписа, который будет еще n_ое время погружаться в проблематику и то не факт.
Тоже самое, например, в командах, которые пилят софтварный продукт. Такой команде проще взять мидла уже с умением кодить и который желает писать (и любит). Пример - JetBrains, который сразу пишет в требованиях к кандидатам умение кодить, например, на Kotlin.
==================
Второе наблюдение в том, что всё чаще и чаще, разработкой документацией занимаются сами продакты и/или аналитики, либо продуктовнеры, как лица , которые максимально глубоко погружены не только в продукт но и окружение этого продукта.
==================
В итоге, что мы имеем.
1. Обычный техпис не умеет в код
2. Обычный техпис не сможет развернуть среду
3. Обычный техпис не может в аналитику
4. Обычный техпис не может в QA
5. Обычный техпис не может в математику (для частных случаем техдокументации)
—-
Как итог, ситуация на рынке нерадостная. )
По 1. С этого все и начиналось!

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

SP

Sergey Protsenko in technicalwriters
быть способными это одно, не спорю мы все умеем писать и читать. Но есть нюанс и он в том, что будет перекос или в сторону одной отрасли или другой. И рано или поздно где-то задач становится больше, а работы над документацией меньше.

Так можно же вообще не заморачиваться и собирать swagger файл, зачем тот техпис?)
источник

SP

Sergey Protsenko in technicalwriters
Определите стандартного техписа) может и не нужен
источник

A

Andrey in technicalwriters
Профессия же только появилась, а вы с такими вопросами
источник

SP

Sergey Protsenko in technicalwriters
но вы и я это же не весь рынок)
источник

SP

Sergey Protsenko in technicalwriters
и да, вакансий в КуА и фронт больше, очень так больше)
источник

A

Andrey in technicalwriters
Ну на западе может.
Но там же и задачи другие!
источник

FM

Fox Mulder in technicalwriters
источник

SP

Sergey Protsenko in technicalwriters
к вопросу документирования АРІ. Посмотрите как пишется rest сервисы, на java например, станет более понятно, какие слои вашего приложения для чего и вообще порядок написания - что за чем разрабатывают и как оно потом работает
источник

A

Andrey in technicalwriters
Ага. Убедил
источник

A

Andrey in technicalwriters
Так продуктовой разработки во всем мире имхо все меньше.

А в заказной разработке немало российских компаний, которые работают на топовом мировом уровне. Правда, они на рос рынок почти не работают.
источник

A

Andrey in technicalwriters
Просто в СНГ имхо большинство техписов заняты тем чтобы по ГОСТам документы писать.
источник

FM

Fox Mulder in technicalwriters
Вот вакансия в Амазон
https://www.amazon.jobs/en/jobs/1046923/technical-writer
источник

FM

Fox Mulder in technicalwriters
То естЪ, без знания кода ни тудЫ и не сюдЫ.
источник