'''ADVANCED''' (Все сообщения пользователя)

[QUOTE]Виктор Фигурнов пишет:
Во многих западных фирмах нет печатей, тем более гербовых. Да и в России печати скоро сделают необязательными.
[/QUOTE]Дополню...
Более того, в России уже есть электронные подписи и они активно используются. Ранее они назывались ЭЦП (электронно-цифровая подпись).
На сайтах некоторых бюджетных учреждений без ЭП ничего нельзя ни заказать, ни получить. Внести изменения в личном кабинете, что-либо продать/купить на бирже, документы по сделкам депозитария или брокера, оплата в банках, заказ автомобилей и покупка недвижимости...

Миллион примеров еще - все сопровождается ЭП или 3d-secure.  Авторизация и аутентификация с мобильного устройства с помощью IMSI-кода, Мобильный штрих-код и тому подобное. В это направлении надо смотреть, столько интересного впереди.

[QUOTE]Марина пишет:
ТЗ в виде сайта, да ещё и красочного, делать не приходилось, потому что заказчикам не приходило в голову требовать. Когда-то делала юзабилити-аудиты интерфейсов, тоже никто не предъявлял каких-то особых требований к формам отчетов, всем хватало документа в ворде или pdf, конвертированного из ворда. С заказчиком обсуждались содержание и доступность изложения, форма - только в начале работы, с непосредственным начальством, на уровне "сделайте титульный лист по нашим корпоративным стандартам".

Разбить текст ТЗ на смысловые блоки, соответствующие вебстраницам, смогу без проблем. Сверстать каждую в HTML, наверно, тоже (но это ведь уже работа верстальщика)? Смогу внятно нарисовать прототипы карандашом на бумаге или в Visio (в Axura - это к проектировщику интерфейсов). Собрать из этого готовый сайт и разместить на хостинге - это к веб-программисту. Чтобы сайт был ещё и красочный - к веб-дизайнеру.
[/QUOTE]Угу.
А можно просто в Confluence написать все требования, проставив ссылки на корпоративный глоссарий, на связанные задачи в Jira, на описание процесса приемки, тестирования и прочие особенности.

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

[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
При упоминании ТЗ, почему-то ассоциация о печатном документе. Оно может быть в HTML и им пользуются разработчики как им удобно. Один на планшете, другой на компе, третьему достаточно прочитать.
[/QUOTE]Конкретно у тебя такая ассоциация, а не у всех. "Печатный документ" - это документ, который может быть распечатан, и не более того.
[/QUOTE]Распечатан может быть скриншот с экрана мобильного, на котором открыт tooltip, являющийся частью справки. Распечатать можно что угодно, хоть статуэтку на 3D-принтере.

[B]Печатный документ - документ, выполненный непосредственно для печати на принтере.[/B] В основном это файлы в формате PDF.
В нашей стране в последнее время стали забывать о безопасности и подлогах документов и для печати и для обмена файлами вполне годятся файлы doc, которые [I]"проще на месте поправить если что" [/I]Когда-то недавно документы прошнуровывались с указанием количества листов, печатями и т.п. и к их хранению также предьявлялись требования. И часть таких требований прописана в ГОСТах.

Если техпис открыл MS Word и пишет текст, оформляя заголовки по ЕСПД, это не означает что документация подготовлена по требованиям ГОСТ.

[QUOTE]Гость пишет:
[QUOTE] ADVANCED пишет:
ТЗ ... не обязательно должно быть распечатано на принтере.
[/QUOTE]


Полный бред!
ТЗ - официальный юридический (в случае конфликта между Заказчиком и Исполнителем) документ, который должен быть утвержден подписями и гербовой печатью Заказчика и согласующими (утверждающими) подписями и печатью Исполнителя..
[/QUOTE]ТЗ не юридический документ. В гражданском праве нет такого основания (вида документа) возникновения обязательств.

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

Результат работ может сопровождаться актом выполненных работ, который подписывают обе стороны. Налоговые органы могут проверить договор и акт о выполнении работ, по которому перечислены деньги, с которых подлежит уплате налог. ВСЁ!

[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
Вы зациклились на Ворде.
ТЗ необязательно писать в ворде, оно не обязательно должно быть распечатано на принтере. Оно не обязательно должно быть по ГОСТ и тд.
При упоминании ТЗ, почему-то ассоциация о печатном документе. Оно может быть в HTML и им пользуются разработчики как им удобно. Один на планшете, другой на компе, третьему достаточно прочитать.

Книги тоже не обязательно должны быть на бумаге. Есть e-book со своими форматами. И в них тоже можно писать и ТЗ и другую документацию и ГОСТ можно забыть.
[/QUOTE]Предложи свой вариант ТЗ так, чтобы при этом печатного и электронного документа не существовало в природе. При этом ТЗ содержало все обоснования решений, ограничения и условия.
[/QUOTE]Заказчик на встрече с аналитиком ставит требование "чтобы адрес можно было выбрать из списка". Аналитик отправляет программисту СМС "надо сделать справочник КЛАДР, подробности в письме". Пишет письмо в электричке пока не забыл, или прикладывает аудиозапись с диктофона. Когда аналитик приезжает на свое рабочее место со встречи, прикладывает переписку из почты в JIRA. Программист в это время уже заканчивает справочник и передает на тестирование. Тестировщик читает весь ход мыслей от появления идеи, до завершения разработки и тестирует, писатель документирует. Доработка сдается заказчику патчем или в следующем обновлении.
Вообще так редко бывает, если честно, но бывает. Пример из опыта работы с госзаказчиком. Срок разработки сокращен до минимума, все все выполнили, заказчик доволен. Никто не растягивает договоры, печати, ТЗ по ГОСТ и т.п.

[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
Вопрос не в том, что нравится или не нравится. Должен и нравится - разные вещи.
[/QUOTE]Конкретно у вас кто занимается дизайном разрабатываемых справок?
[/QUOTE]На текущем месте работы я. На предыдущем мне дали набор картинок и сайт в качестве эталона, сказали подгонять дизайн под него, т.е. писатель+CSS

[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
Не ТЗ на сайт, а сайт, с структурированным изложением требований на разработку автоматизированной системы.
Не в DOC, не в RTF, не в PDF, а на HTML-страницах. Т.е. набор HTML-страниц, оформленных по ГОСТ34, имеющих разделы, отступы, шрифты и т.п.
[/QUOTE]Прототип сайта и есть набор HTML-страниц. Требования к конкретным полям, действиям, кнопкам описывается в ТЗ. По какому ГОСТу ты будешь писать это ТЗ, абсолютно без разницы.
[/QUOTE]Прототип сайта тут ни при чем 8) А прототип калькулятора - это что? А двигателя внутреннего сгорания?
Ладно проехали   :D

Вы зациклились на Ворде.
ТЗ необязательно писать в ворде, оно не обязательно должно быть распечатано на принтере. Оно не обязательно должно быть по ГОСТ и тд.
При упоминании ТЗ, почему-то ассоциация о печатном документе. Оно может быть в HTML и им пользуются разработчики как им удобно. Один на планшете, другой на компе, третьему достаточно прочитать.

Книги тоже не обязательно должны быть на бумаге. Есть e-book со своими форматами. И в них тоже можно писать и ТЗ и другую документацию и ГОСТ можно забыть.

[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
[QUOTE] techwriter пишет:
[QUOTE] ADVANCED пишет:
Продемонстрируй, пожалуйста
[/QUOTE]Что именно? Сайт или ТЗ?
[/QUOTE]ТЗ, выполненное в виде сайта. Второй раз уже повторил :)
[/QUOTE]Повтори третий, потому что непонятно, что имеется в виду.
ТЗ на сайт пишется на основании прототипов. Разработчики могут посмотреть сам прототип, заказчики тоже. Но, как правило, заказчикам нужна наглядность в виде документа. Какая разница, по какому ГОСТу или не по ГОСту пишется ТЗ? Оно в любом случае будет отражать одно и то же.
[/QUOTE]Повторяю сначала:
[QUOTE]Марина пишет:
Техническое задание отлично пишется по 34 госту, если использовать его в ситуации, для которой он и был предназначен - создание автоматизированной системы "под ключ", включая установку и настройку ПО на технике заказчика, возможно, поставку или апгрейд техники, обучение персонала.
[/QUOTE]
[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
Есть пример красочного сайта технического задания по ГОСТ34?
[/QUOTE]У меня есть : ))))
[/QUOTE]
Пример ТЕХНИЧЕСКОГО ЗАДАНИЯ в виде сайта.

[QUOTE]techwriter пишет:
ТЗ на сайт пишется на основании
[/QUOTE]
[B]Не ТЗ на сайт, а сайт, с структурированным изложением требований на разработку автоматизированной системы. [/B]
Не в DOC, не в RTF, не в PDF, а на HTML-страницах. Т.е. набор HTML-страниц, оформленных по ГОСТ34, имеющих разделы, отступы, шрифты и т.п.

[QUOTE]writer пишет:
Это в идеале, не все компании еще готовы технического писателя взять на должность, вот и вешают на него все. Тут или нужно соглашаться или не идти на такую работу. Лично мне нравится дист.курсы делать, поэтому я не прочь иногда отдохнуть от документации.
[/QUOTE]
Да, писатели делают учебные курсы, не спорю. Я будучи писателем не только делал, но и проводил обучение, и мне за это небольшую премию платили отдельно. Так как на тот момент не было возможности нанимать кого-то, а я больше всех по навыкам подходил на эту работу.
Вопрос не в том, что нравится или не нравится. Должен и нравится - разные вещи.

[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
Если тех.пис не слышал о PowerPoint или не знает как донести информацию до человека, который возможно станет пользователем, его нельзя критиковать за это. Это навык, а не обязанность.
[/QUOTE]Причем здесь вообще Power Point? Power Point такой же каменный век в разработке обучающих материалов, как MS Word в современном авторинге ;)
[/QUOTE]Power Point здесь упомянул, чтобы отличить от Word. ;)

[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
Продемонстрируй, пожалуйста
[/QUOTE]Что именно? Сайт или ТЗ?
[/QUOTE]ТЗ, выполненное в виде сайта. Второй раз уже повторил :)

[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
Писатель может и полы помыть и кондиционер заправить, но это не профессиональная деятельность. Возможно кому-то оплачивают подготовку материалов для обучения, но это оговаривается отдельно, учитывая навыки сотрудника. Я занимался этим в основной должности, до работы тех.писом.
Если тех.пис не слышал о PowerPoint или не знает как донести информацию до человека, который возможно станет пользователем, его нельзя критиковать за это. Это навык, а не обязанность.
[/QUOTE]А разработкой e-learning кто должен заниматься?
[/QUOTE]

[url=http://framedia-inc.com/blogs/i-want-to-become-an-instructional-designer-but-i-dont-know-how-to-start/]Педагогический дизайнер[/url].

Вырезка о навыках:
[LIST][*]Нужна теория: теория обучения, когнитивные теории, психология обучения и восприятия информации. И чем ее будет больше, тем ярче будет картинка того, что вы делаете. В какой-то момент станет понятно, почему что-то можно делать, а что-то нет, и для этого будет логичное и понятное объяснение.[*]Нужно знать инструмент, с помощью которого будет создаваться курс. Интересно, но в классическом учебнике по педагогическому дизайну есть целая глава про аналих медиа средств для доставки знаний. И в целом, его вроде бы все делают: выясняют, какой доступен интернет, есть ли звук, какой ПК. А вот проверить основной инструмент разработки - забываем.[*]Нужно читать про дизайн и смотреть примеры. И знать, что хорошо, а что плохо в оформлении курса. Электронный курс воспринимается визуально, и если внешне он кривой, то и восприятие его содержания будет не самым позитивным. И даже если у вас дизайнер, который будет рисовать графику, вы все равно должны представлять, что именно вы хотите получить в итоге.[*]Нужно много читать: про людей, про технологии, про развитие личности. Именно в таких книгах часто есть исследования и наработки, которые педагогическому дизайнеру помогают увидеть свою аудиторию и сделать для нее максимально эффективный курс.
[/LIST]

[QUOTE]Виктор Фигурнов пишет:
[QUOTE] ADVANCED пишет:
Для чего? Писателю администрировать вряд ли придется, ну только в личных целях что-то.
[/QUOTE]Может и придется. Например, если пишешь руководство по развертыванию интернет-сервиса, придется самому развернуть какой-то демонстрационный вариант. А значит, настроить сервера, используемые сервисом, и их взаимодействие.
.
[/QUOTE]Это - да. Но не обязательно сначала изучать, а потом устраиваться на работу техписом. Можно в процессе разворачивания изучать :)

[QUOTE]fs444 пишет:
Начал интересоваться Linux, и появился вопрос - насколько глубоко нужно знать эту систему?
[/QUOTE]Для чего? Писателю администрировать вряд ли придется, ну только в личных целях что-то. Настолько, насколько глубоко знаете любую другую ОС ;)

Если описываешь программу, будь любезен попробуй сам установить и по шагам описать, т.к. в линухе установка отличается от виндовой. Любой очевидный для винды шаг типа "нажми Y/N" не означает продолжение процесса  :)   То библиотеки не хватает, то прав на запись куда-то, то обновления.

Вообще зависит от ОС. В Ubuntu одно, в Debian или RedHat другое и т.п. Как минимум надо знать основные команды в терминале, установку пакетов и работа с репозиториями, сборка дистрибутива, работа с архивами, крон. Ну и по безопасности: изменение прав, SCP, mount и сетевые настройки и системные каталоги на предмет где что хранить, куда сохранять и где искать настройки. Шелл-скрипты тоже полезно знать.

[QUOTE]Марина пишет:
Кто-то должен привести все эти документы по одному проекту к единому виду - как минимум, чтобы терминология была сквозной. Кто этим должен заниматься?
[/QUOTE]Каждый, кто этим занимается в повседневной деятельности, но не один человек и не тех.писатель. Он конечно же может, на него могут спихнуть такую работу, но за это он не получает ни зарплату, ни несет ответственности.
В идеале, должна быть определена терминология, стили и шаблоны, которых должны придерживаться все роли: аналитики, тестировщики, разработчики, писатели, техподдержка и т.п.

Если создается новая терминология, то она сначала обговаривается между заказчиком и аналитиком, чтобы стороны понимали друг друга. Писатель - последнее звено в цепочке и он может не подозревать, что ведется разработка того или иного ПО, а может быть подключен к документированию на этапе тестирования или после. Тем более, ТЗ, по которому велась разработка, он увидит по факту.
[QUOTE]Марина пишет:
[url]http://techwriters.ru/forum/forum607/topic18101/[/url] - тема с нашего форума про обязанности техписателя. Во всех примерах должностных инструкций присутствует "техническое редактирование научно-технических, информационных и нормативных материалов предприятия на русском и английском языках".
[/QUOTE]Форум - не показатель и информация на нем всего лишь чья-то точка зрения, видение и рассуждение. [QUOTE]techwriter пишет:
Организация обучения довольно часто возлагается на плечи техписов. И это правильно.
[/QUOTE]Писатель может и полы помыть и кондиционер заправить, но это не профессиональная деятельность. Возможно кому-то оплачивают подготовку материалов для обучения, но это оговаривается отдельно, учитывая навыки сотрудника. Я занимался этим в основной должности, до работы тех.писом.
Если тех.пис не слышал о PowerPoint или не знает как донести информацию до человека, который возможно станет пользователем, его нельзя критиковать за это. Это навык, а не обязанность.


[QUOTE]techwriter пишет:
У меня есть :  ))))  
[/QUOTE]Продемонстрируй, пожалуйста :)

[QUOTE]Марина пишет:
актически 2 в 1, тех. писатель + аналитик. Но там, где должности разделены, мне кажется, всё равно все документы должны проходить через тех. писателя. Общая грамотность текстов, единство стиля, оформление - это все его работа.
[/QUOTE]Нет, к аналитикам требования к русскому языку, грамотности и умению излагать мысли должны быть не меньше, чем к писателям . Единство стиля, оформление также у аналитиков свое и может отличаться от писателей.

Это не его работа. Вы еще должностные инструкции, приказы, договоры и контракты туда влепите, чтобы после отдела кадоров/юристов писатель проверял запятые   :D  

[QUOTE]Марина пишет:
Не поняла вопрос. Сайта, ТЗ к которому писалось по 34 госту?
[/QUOTE]Нет, ТЗ, выполненному в виде сайта :) Когнитивный диссонанс?
ТЗ не обязательно в ворде писать, можно в вики-системах, в системах управления задачами и проектами. В блокноте на худой конец.

[QUOTE]writer пишет:
если говорить по теме развития технического писателя как специалиста, то почему бы ему не владеть такими навыками? Очень даже полезно
[/QUOTE]Да, полезно. Но речь была в сообщении про ГОСТ и печатную документацию ;) , что является бесполезным как навыком, так и занятием.

[QUOTE]Марина пишет:
У нас обычно под работой по 34 госту подразумевается разбиение проекта на этапы
1) техническое задание
2) технический проект
3) рабочая документация (2 и 3 часто объединяют)
4) ввод в действие
[/QUOTE] Если на то пошло, то писателю можно развиваться в направлении разработки проектной документации и расти к Системному или Бизнес-аналитику. Напомню, что ТЗ относится к проектной документации, а технический писатель может выступать в роли аналитика, только если есть знания, нывыки или желание. Но это не совсем правильно.

[QUOTE]Марина пишет:
Для конечного пользователя из этих документов предназначено полтора, и никакой гост не запрещает кроме них сделать ещё и онлайн-хелп.
[/QUOTE] Есть пример красочного сайта технического задания по ГОСТ34? :)


[QUOTE]techwriter пишет:
[QUOTE] ADVANCED пишет:
Методички и учебные пособия на курсах будут, но там смесь тех.док и маркетинга и делают такие доки не писатели.
[/QUOTE]Технические писатели их и делают во всех развитых странах.
[/QUOTE]Что-то мне подсказывает, что не технические писатели это делают ;) . Я подобным занимался лет 8 назад и назывался "специалист по подготовке учебных материалов и презентаций". Не нужно было вдаваться в подробности программной логики и функционала, описывались только юзкейсы, при этом нахваливая программу.

ГОСТ предполагает документацию в печатном виде (печатным способом) или файлы "на магнитном носителе". Хоть комиксы добавьте, хоть раскраски это не станет полезным пользователю. Ему пофиг на однообразные заголовки и рамки. Нужна доступная справка.

Процитировать сообшения не могу щас (с телефона.,Если отвечать на вопрос по ГОСТ И вакансии с ними - да, в топку. Для таких вакансий найдется свой персонал с консервативными взглядами и исполнительностью.

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

Представьте  чела с шестым айфон в одной руке и  200-страничным толмутом инструкции (черно-белой с рамочками) в другой руке.   )))))))

Украинские коллеги, работающие в ворде этой зимой будут востребованы. Газа мало, топить можно распечатанной документацией. Прям по номенклатуре брать, чтобы не путаться.

[QUOTE]fs444 пишет:
Наверное, ГОСТ можно использовать в качестве образца "как можно написать" (например, для написания руководств пользователя, администратора, программиста).
[/QUOTE][B]В качестве образца его нельзя использовать[/B]. ГОСТ придумали для однообразия "ведения учета по децимальным номерам" и "складирования" документации в подземных хранилищах с черт знает каких времен. Последние обновления были в 70-х годах. В 90-х что-то поправили, но суть не изменилась.
Ни одно руководство, выполненное по ГОСТ, не будет удобным для пользователя, даже скорей будет бесполезным и вредным для лесного массива страны.

[QUOTE]writer пишет:
Если хотите быть хорошим техническим писателем, конечно, чтение и написание документации на английскомбудет очень хорошим плюсом и подспорьем в работе.
[/QUOTE]Если хотите быть хорошим КЕМ УГОДНО, устный и письменный английский нужен как в России, так и за рубежом.

Я не сталкивался с ними никак, кроме [url=https://wiki.openoffice.org/wiki/RU/document_formats/ooxml]этого[/url].

Windows+Word+ГОСТ = тупиковая ветвь развития  wall-smile .

Linux+XML = whole world +  beach-smile

Linux, Docbook, LaTEX, DITA   :)  
Лень никак не пересилит необходимость английского.   :(