Расскажу немного о себе. Начать надо с того, что я не очень хороший программист. За спиной 5 лет технического вуза, которые затёрлись двумя годами армейского контракта. После армии я задумался, куда пойти работать: мы с женой переехали в другой город на съёмную квартиру. Устроился на работу я почти сразу, без особого труда: выполнил тестовое задание (а вернее нагуглил решение) на программиста 1С. На собеседовании объяснить толком ничего не мог, пыкался и мыкал, но меня почему-то взяли. Начал потихоньку знакомиться с 1С, потому что раньше о ней слышал только краем уха. В этой же конторе работал мой друг, который уже тогда имел почти двухлетний опыт кодинга и был на хорошем счету у начальства. Его поставили надо мной старшим, и он стал натаскивать меня по всем вопросам. Обновления, печатные формы, обработки какие-то потихоньку что-то начало получаться, начали даже немного повышать в зарплате, отмечать тёплыми словами. Потом определили старшим на очень большой для меня проект переезда с одной конфигурации на совсем другую с многочисленными доработками "как было в старой", рассчитанный на полгода. Этому проекту я отдал год жизни и кучу нервов, в итоге вышел большой провал. И мне бы плюнуть да жить дальше, с работы не уволили, лишь пару месяцев я получал меньше, чем обычно. Дали задачу попроще. Но я уже заметил за собой одну особенность. Больше, чем кодить и придумывать алгоритм мне нравится потом красивыми фразами описывать его работу. За год неудачного проекта я писал километры отчётов: о первом этапе, о том, почему всё не готово в срок, расписывал претензии клиентов за самих клиентов, расписывал, что сделано и как сделано, какие трудности встретил. Отчеты достигали 30 и 40 страниц 12-того шрифта. Вскоре, начальство стало просить - пиши, пожалуйста, покороче. Я же должен разложить всё "по полочкам". Потом пришла мысль: может я не тем занимаюсь? Может я больше полезного мог бы сделать на другом поприще? Услышал, что существует такая работа как технический писатель, но вакансий по нему практически нет в нашем городе. Хочу спросить у форумчан, существует ли в наше время потребность в технических писателях? Мне кажется, что такая работа мне бы больше подошла, и среди 1С-ников стало бы одним "говнокодером" меньше.

http://catalog.mista.ru/job/vacancy/780349/

вот http://catalog.mista.ru/job/vacancy/780349/

(0) Специальность дефицитная. Особенно для разработчиков тиражных продуктов.

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

Есть еще технические рерайтеры.

На крупных внедрениях часто нужно писать юзердоки

(2) спасибо, откликнулся

Попробуй сперва написать документацию на систему, а потом (сам или другими руками) написать саму систему.

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

(0) попробуй себя в должности аналитик. Аналитик который умеет читать код может зарабатывать столько же сколько и хороший прог. Или больше.
Это конечно не технический писатель. Но за это платят.

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

Например, мне сейчас очень даже нужен толковый техпис со знанием ГОСТ 7.32-2017, ГОСТ 2.105-95, ГОСТ серии 15, ГОСТ серии Р 15, ГОСТ серии 34, ГОСТ серии 19, РД 50 (хоть и упразднили). Тот, кто знает, что такое лист утверждения, информационно-удостоверяющий лист, у кого нет проблем с составом документации по требованиям ГОСТ и структурой каждого документа, входящего в состав.

>Отчеты достигали 30 и 40 страниц 12-того шрифта
Это ни о чем. Комплект документации по этапу проекта у меня достигает 5000 страниц.

(10) 5000 страниц пишет 1 человек? сколько времени ему на это даётся?

(11) ну допустим, не один, а группа, но некоторые вещи из этой пачки делают индивидуально. Например, при наполнении разделов НТО по 7.32 командует научрук. Оформительской частью занимается техпис. Также техпис разрабатывает комплекты программной и эксплуатационной документации. Опять же не одну каску, а с привлечением админов, аналитиков, методологов и т.д. для сутевого наполнения разделов.
А вообще, 5000 это один только этап. Этапов обычно 3-4. Продолжительность этапа полгода-год. Засада случается, когда надо два этапа одновременно закрывать.

(10) Конечно, может быть я не прав, но мне кажется, что чтобы стать специалистом по ГОСТам, в которых расписываются правила оформления того или иного документа, состав документов, нужно их распечатать и держать перед глазами постоянно сверяясь.
Дипломы тоже ведь по ГОСТу писали...

(12) Интересная у вас работа)

(13) Никто же не отбирает шпаргалки. Держи под рукой хоть в электронном виде, хоть в бумаге. Главное - держи по рукой актуальные и полные версии ГОСТ-ов и иной нормативно-справочной документации. Это основа.

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

У техписа еще непростая задача - вот вывалили ему гору информации, он ее должен разгрести и разложить по полочкам, по разделам. Потом оформительская часть, что весьма немаловажно. Знать правила оформления таблиц в зависимости от вида документа. Какую разместить вертикально, а какую вынести на А3, например и понимать почему. Если ЕСКД, то где и какие рамки должны быть.

Вот еще - децимальные номера. Техпис четко должен знать порядок их присвоения.

Короче говоря, это сложная работа, требующая кучи навыков и знаний.

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

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

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

(17) Чем занимается ваша компания? Разрабатывает техническую документацию для всего?

В моей истории был момент, когда я решил внедрить такое новшество, как ИЭТР ( интерактивные технические руководства). Это когда почти вся техническая документация на сложные, наукоемкие изделия. На тот момент, а это 2008-2010гг ИЭТРы были только у Сухого. Да ещё моряки в Питере что-то устраивали. ( Потом мелькнула новость, что кого-то посадили за разбазаривание госсредств). Сделал стандарт, сделал платформу. Но этого мало. Надо , чтобы в РУК входило это ИЭТР, как документ. Начали вести переговоры с военными на изменение РУК. Сделали тестовые экземпляры руководств. Вот там то и понадобились компетенции технических писателей. Как сейчас обстоят дела- не знаю. Я ушёл, дело без движка заглохло. Так что ищи по аббревиатуре ИЭТР. Будет и интересно и нужно.

(18) Там 275-ФЗ. Беги от этого в любую сторону!

(16) Витя, ты извини, я наверное тебя напугал таким раскладом, но из песни слов не выкинешь.

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

А вот очень хорошие техписы выходят из конструкторских бюро, особенно закрытых КБ.

(19) оооо.... какое сладкое слово ИЭТР. Как давно я его не слышал. Это не просто техдокументация на сложные изделия, это чемоданчик с интерактивными руководствами, который берет свое начало из цифровой модели, разработанной в КБ. Были идеи по созданию продвинутого чемоданчика, которые еще и к АСУ технически-сложного объекта подключался с целью получения и последующего анализа данных о техническом состоянии узлов и агрегатов ТСО. Кстати, да, - хз чем там дело закончилось.

(2) ну не обязательно. Просто бывают изделия и технологии двойного назначения.

(21) -> (20) последняя строка

(0) Нет смысла писать доукментацию которая устаревает раньше чем допиливаемый/обновляемый софт.

В лучшем случае FAQи с видеоинструкциями.

(23) Смотря что называть софтом. Обновления обычно не сильно-то и затрагивают архитектуру и бизнес-процессы системы. В конечном итоге выпускают обновленную программную документацию типа "Издание 2. Дополненное и скорректированное".
А если речь про какую-то поделку, то не называйте ебулду софтом.

нашёл ещё вот такую вакансию
ни одного ГОСТа в требованиях)
https://tensor.ru/about/career/vacancies/yaroslavl/tehnicheskiy-pisatel-1

(7) Задумался

(25) Дык матчасть знать надобно. Это СБИС.

(24) Обновления иногда сильно затрагивают и архитектуру и бизнес-процессы.
Например внедрение маркировки взять.

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

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

(28)+ Короче документация нужна для коробочных продуктов или короткие мануалы на пару страниц.

А ТС пора идти в консультанты или продвиженцы. С попыткой вырасти до не играющего РП.

(26) не там задумался, если честно. Тебе в (9) дали очень дельный совет. Вот над ним задумайся. Сам же пишешь, что интересно поэмы сочинять, вот и сочиняй. Но учти, что аналитики тоже разные бывают и профиль у них разный.
У меня через кабинет сидят аналитики по внедрению. Они заточены под конкретную задачу - обследование предприятия перед внедрением АИС. У них выработанные методики, шаблоны, планы, схемы и т.д. при этом они не могут сделать шаг в сторону. Никакой другой анализ они провести не в состоянии. Даже бизнес-процессы не смогли смоделировать и отрисовать. Пришлось нанимать соисполнителей под эту задачу.

(28) поправь меня: скрум этот ваш - это же работа в условиях неопределенности? а агил охватывает только этап жизненного цикла ПО, как развитие. Верно? Вот только зачастую бездари и бездельники РП сваливают свою некомпетентность в скрум и ебстись дальше, как можешь. На одном проекте пришлось сменить четырех РП пока не нашли толкового, который сходу врубился в требования заказчика.

(28) внедрение маркировки это не новый БП. Это новый операционный БП в составе старого основного БП - продажа. Ну и хрена там нового появилось? Дополнительный реквизит для хранения сведений о коде? Дополнительный операционный процесс получения кодов откуда-то? В инструкцию добавили пару разделов: как получить и присвоить код, как пиликнуть сканером при продаже. Все.

(31) К сожалению это не так совершенно.
Это именно слом всех старых БП и замена их новыми с учетом маркировки.

Кто думает что добавим маркировку а склад и прочие будут работать по прежнему - глубочайше заблуждаются.
Особенно если было несколько ЮЛ/ИП и прочие фишки или склад сложнейший с WMS и ТСД на каждом шагу.

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

(31) "Ну и хрена там нового появилось? Дополнительный реквизит для хранения сведений о коде? Дополнительный операционный процесс получения кодов откуда-то? В инструкцию добавили пару разделов: как получить и присвоить код, как пиликнуть сканером при продаже. Все."

Это как раз поверхностное мнение, на практике все сильно и сильно хуже.

(34)+ Первое:

Маркировка это замена количественного/суммового или даже партионного учета по сути ПОШТУЧНЫМ учетом.
Попробуйте дальше догадаться, когда каждая штука УНИКАЛЬНА.

(35)+ Чтобы легче догадаться, представьте что на каждую штуку товара (одного наименования и характеристик) заводится своя отдельная номенклатура со своим уникальным SGTIN.
А не как раньше одна номенклатура на наименование и еще характеристики/партии сбоку.

(36) Любезный, было время, я вводил учет спецухи на rfid-ах, поэтому что такое поштучный учет знаю, более того, комплектацию из поштучных фиговинок. И процессы меняются только операционные, а не основные, как я уже писал выше. Мало кого на верху волнует что происходит на складе, если выход и выход из процесса не изменился, главное, чтобы баланс сходился и инвентаризация не показывала серьезных расхождений. Раньше ходил кладовщик с журналом, сейчас с ТСД. Процессы изменились внутри склада. Облегчили работу в одном, усложнили в другом. Дело не в этом. дело в том, что в (0) крик души и нет информации почему он просрал годовой проект. Ну и на техписа он совершенно не тянет.

(37) С окончанием про ТС согласен, с началом есть тонкости.

По началу в упрощенном виде все так и есть, но дьявол в мелочах.
Если раньше применялась допустим схема "интеркампани" с товар закуплен и числится по маркировке на одном ЮЛ то как им образом его сможет продать /отгрузить другое ЮЛ?
А если операция по маркировке не прошла - хрен а не отгрузка!

(38)+ Если раньше отгруженный товар но не принятый просто возвращали покупатель без документов и просто переделывали доки отгрузки.
То сча хехе.

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

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

(0) Безусловно существует такая потребность. Дерзай!

(0) Я раньше думал, что писать инструкции довольно просто(для доработок и небольшого функционала, наверное да), но недавно попробовал написать инструкции - нелегкая это работа, я точно понял, что не хотел бы этим заниматься. Тот же современный Word или OpenOffice просто доводит до белого каления. Думаю, многим это близко, даже сама 1С не любит писать инструкции - по той же КА 2.4 всего две книжки на ИТС, и даже не пробуйте жать F1 в самой конфе - документированы только основные объекты. И найти что-то простое, навроде ведения оперучета по товарам в УТ11/КА2.4, без ордеров, без адресного хранения - в стиле ТиС или УТ10 - а нету! Догадайся сам по крупицам среди тонн инфы про адресное хранение и ордера. Ну ок, я то догадаюсь, но я ненавижу писать инструкции для тех, кто не такой сообразительный. Так что, думаю, найти применение навыкам в Мск можно.

(42) Безусловно можно, да и нужно

В качестве пограничной темы, описание бизнес-процессов в виде BPMN. Сама нотация в целом - ничего сложного. Если в инструкции добавлять картинки с BPMN, то ИМХО, это добавляет очков к этим самым инструкциям.

(0) У меня супруга тех.пис. При этом хороший техпис, с врожденной грамотностью (полная мне противоположность) и немецкою педантичностью (гены однако).
На сейчас опыт работы с системами написанными на... да на каких языках они только не писаны, и чего только не делают эти системы. Знания ГОСТ и умение их применять. Хотя основные, которые применяются 34 и 19. У вояк есть ещё специфика.
Но если честно, на мой взгляд, то все эти ГОСТ ровным счетом ничего не определяют. Это как конвенции в международном праве - что-то декларируют с возможностью в километр вправо и километр влево. Те же ТЗ, ЧТЗ, ПМИ и т.д. определен скелет (примерная структура) документа, в котором могут некоторые пункты и отсутствовать. Всё это на тоненького. Я в этом конечно не большой специалист, но вижу я это так...
Знания и хороший навык в работе: ARIS, ВР-WIN, ER-WIN, visio, и прочего.
Ранее работала и программистом (Делфи, джава, 1С и т.д.), поэтому читает и код практически на любом языке и SQL. И т.д. Казалось бы зачем это техпису - проекты бывают разные. На нормальных проектах совсем не к чему.

Но самое главное. Все эти знания и умения в основном нужно на реально больших проектах. А платят за это только если МСК, даже не СПб.
Потребность в этом есть, и есть достаточно большая, так специалистов хороших техписов реально не много. Но платить за это не готов никто, и не смотря ни на что. Только если МСК. Если удаленно на МСК, то 50% от ЗП МСК если не удаленно.
Хороший специалист отдела тестирования, на крупных проектах получает на 20-30% выше минимум.

И самая не хорошая специфика. Что-бы на выходе была качественная и своевременная документация, то необходимо переделывать внутренний порядок работы в 99% случаев. И только в 2% на это идут и на выходе что-то вменяемое получают. К документационному обеспечению же всегда относятся по остаточному принципу. И как итог тех.пис он последний в любой работе на проекте (кроме может быть ТЗ, ЧТЗ и т.д.), так как приступить к ней может за частую только, когда все работы или подходят к концу или закончены, сроки сорваны и т.д. Постоянное чувство что всё не успеваешь и т.д. Информацию на вход себе приходится постоянно выбивать.

(11) Норматив один рабочий день 4 страницы. :-)
Сам ржал когда узнал. Но по факту с переписыванием и дополнениями и т.д. Если взять полученные на выходе страницы и поделить на время в днях, то получается конечно больше 4 страниц, но не на много.
Скорость зависит не от техписа, а от того на сколько ему удалось необходимую информацию выудить. На сколько корректную и полную информацию ему дали. Сколько раз переделывали всё напрочь. Какие сроки были у документации и какие у программного комплекса на выходе. Бывают случаи, когда картинки с интерфейсом должны быть готовы сегодня и их на выходе дает техпис сегодня, а программисты нарисуют реальность через неделю и надо будет переделывать усё. И не факт что за одну итерацию что-то нарисуют. Проекты бывают разные. Чем больше беспорядка, тем больше переделывания и т.д. Скорость конечно же разная.
Если вся информация на входе есть и она хорошего качества, то несколько десятков страниц в день техпис может выдать. Но такое скорее из области фантастики.

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

(0) >> Отчеты достигали 30 и 40 страниц 12-того шрифта.

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

(47) Да. Да. Да.
Работал паралельно на проектах со специалистами SAP.
Методолог выдает 20-30 страниц и более текста как из консультанта+ со всякой ерундой и водой.
Консультант SAP выдает абаперу 2-3 страницы из каких таблиц и куда в какие и что рисовать и когда.
Абапер это дело быстро рисует и усё готово. От консультанта зависит на 100% успех проекта. Абапер это просто хороший кодировщик, а что он кодирует он за частую даже не знает. :-)

К (48) Выглядит этот как-то так:

Например для отчета:

Графа 1 Номер по порядку;
Графа 2 Наименование филиала – заполняется из организационного присвоения ИТ 0001, PA0001 HRP1001;
Графа 3 ФИО- заполняется из персональных данных сотрудника ИТ 0002, PA 0002 поле NACHN, VORNA, MIDNM;
Графа 4 Сведения (форма) - указывается код формы в соответствии с датой выхода на пенсию (поле ZHR_DATEGOSPENS) в ИТ 9050
...
Графа 9  Стаж работы в организациях системы РКС (полных лет) - рассчитывается, исходя из данных, указанных в ИТ 0294 «Трудовая книжка» для строки «Стаж в РКС» (z018) или «Стаж в МКС» * 0,75. (Z019) Если присутствуют оба стажа, то их необходимо суммировать, данный стаж должен рассчитываться на дату форм.  Данный стаж рассчитывается по формуле Z018 + (Z019*0,75).

Собственно: ИТ ххх - это номер инфотипа или языком 1С это имя метаданного (например Справочник.ФизическиеЛица), Z018 - зет объекты - похоже чем-то на расширения в 1С. и т.д.
Абаповец, читая такой документ видит, только имена таблиц, полей и что с ними делать. Остальной текст даже не читает.

(48) почему из SAP ушли, не секрет?

Полезная ветка.
.
Особенно прикалывает когда надо написать инструкцию на некий операционный процесс. Который во многом зависит от действий пользователя. И начинаешь описывать как заполнять документ с использованием универсального множественного фильтра, который может использовать другие универсальные множественные фильтры. Как это все описать? я херею.
.
В результате все сводится: если хочешь ехать быстрее - жми сильнее на педаль газа. очешь повернуть вправо - крути руль вправо. с каким усилием и когда - это не описывают в инструкциях. Это нарабатывается опытом.
.
а документация по проекту.. у... даже прсотой проект у меня сжирал столько времени на документирвоаниеи писаниниу и протоколы и проче... а все же хотят чбыстро дешево и качественно... а как качественно если мне для вас нужно 10 листов написать - а это 2 дня займет. потому что у вас народ "тупой" - в смартфоны он умеет тыкать а в ТСД - он блин запутается..?!

(51) блок-схемы и картинки есть же, не?

(50) Кто ушел? Если кто-то ушел, то я тут точно не при чем. :-)

Есть. Эта область цветет и пахнет. Правда не так много в среде 1С.
Вот например знакомая контора которая занимается только тех.писательством http://documentat.io/
Вот конференция по управлению знаниями (документация это значимая часть этой области) https://knowledgeconf.ru/2020

(51) Давать простому пользователю универсальный инструмент - это зло похуже Сатаны...