Оставить заявку

Виктор Фигурнов (Все сообщения пользователя)

Форум » Пользователи » Виктор Фигурнов

Внимание! У нас сбои с почтовым сервером! Если не пришло письмо о регистрации или смене пароля напишите нам на info@techwriters.ru! 
@twriters
 obmen_soobsheniyami.pngчат для технических писателей в Telegram

 Зарегистрируйтесь
Выбрать дату в календареВыбрать дату в календаре

Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 12
Что происходит на рынке разработки технической документации, Ситуация с удаленной работой для технического писателя, рынок разработки технической документации
 
Цитата
jeff_dowson пишет:
делаем CRM-системы... нужны ли удаленные тех писатели, насколько это услуга сейчас востребована?
Рынок очень узкий. Например, если надо делать руководство пользователя по простым в использовании программам или системам, а заказчик это небольшая фирма, которая не может принять писателя в штат, т.к. не сможет его загрузить.

А когда надо описывать сколько-либо сложные и не очевидные системы, то работодатель понимает, что это не разовая работа, и обычно желает принять сотрудника в штат. И писателю в этом случае удаленно работать трудно, так как надо входить в курс дела, изучать предметную область, постоянно общаться с разработчиками, тестировщиками, менеджерами и другими специалистами. Что трудно делать из прекрасного далёка.
Терминология мобильных приложений, Разыскивается стандарт (руководства по стилю)
 
[QUOTE]Elanor пишет: может кто видел гайды для Microsoft Windows Phone? [/QUOTE]http://www.microsoft.com/Language/en-US/StyleGuides.aspx

Выбрать "Russian (Windows Phone)", нажать Download
ТЭО, Что писать в разделе: Требования к характеристикам реализации функций?
 
Используйте всё, что подходит, а писать там надо то, что указано в названии раздела.
Например, описываемая вами система может иметь функцию: "доступ пользователей к такой-то информации". А требованием к реализации может быть "доступ пользователя к такой-то информации должен осуществляться не более чем за 5 секунд". Вот все такие требования там и надо перечислить.
Радиокнопка или переключатель
 
[QUOTE]ADVANCED пишет: Для супер тупых начинающих можно попробоватьназвать "кружочек" или "квадратик"  :)  
[/QUOTE]Не рекомендую. Разработчики могут поменять библиотеку используемых ими графических элементов, и вместо кружочков или квадратиков в один прекрасный день появятся например, галочки или плюсики. И документация станет непонятной.
Как правильно назвать выделение теста жирным, курсивом и подчёркиванием?
 
Так и называйте, как сказали. Например, "текст, выделенный курсивом". Или "курсивным начертанием", но это длиннее.

Выделенный жирным текст правильнее называть "выделением полужирным начертанием", или "выделение полужирным шрифтом" См., например, ГОСТ 7.32-2001. Так как то начертание, которое мы называем "жирным", у полиграфистов называется "полужирным", см. ГОСТ 3489.10-71. Но лучше выражаться понятнее, словосочетание "выделение полужирным начертанием" далеко не каждый поймёт.
Глоссарий в Help&Manual, Как создать глоссарий Help&Manual
 
[QUOTE]goodgrief пишет:  в контексте WebHelp'a, то это решение не самое удачное. Было бы лучше, если бы можно было навести курсор мыши на непонятный термин и появлялся бы tooltip с определением. В этом случае страница глоссария попросту не нужна.
[/QUOTE]Так сделано в Robohelp. И еще там можно выбирать, как показывается определение - в виде Tooltip, Popup или Expanding text, А во Flare, Doc-to-Help и Author-It, насколько я помню, можно еще вывести перечень элементов глоссария, они показываются в панели навигации (на месте оглавления). Если щелкнуть по элементу этого перечня (термину глоссария), то рядом показывается определение термина, и вдобавок может сразу же быть выполнен переход на место в справочной системе, где дано это определение термина...
.docx в .pdf
 
[QUOTE]Цахес пишет: Когда сохраняю в исходном формате, все проблемы остаются. Когда сохраняю в формате .ttf, все перечисленные мной проблемы решаются, но шрифт в Word отображается по-иному.
[/QUOTE]Тогда лучше сохраните в TTF.
У Adobe есть документы, в котором описаны тонкости встраивания шрифтов в PDF, например http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/FontPolicies.pdf
Думаю, что разобравшись в них,  можно внести нужные коррективы в шрифт так, чтобы сохранить его в исходном формате, но разрешить его встраивание в PDF.
Но вряд ли стоит в этих премудростях разбираться. Экспериментировать можно долго, и шрифт при этом можно испортить.
Небольшое отличие в показе на экране шрифтов разного формата — это нормальное явление.
.docx в .pdf
 
[QUOTE]Цахес пишет:
Я так понимаю, шрифт нужно сохранить в формате .ttf?[/QUOTE]Лучше сохранять в исходном формате шрифта.

[QUOTE]Цахес пишет:
Не подскажете, почему шрифт становится более округлым после сохранения в другом формате?[/QUOTE]Видимо, это возможно при сохранении шрифта, основанном на кривых Безье 3 порядка (Type 1 или Opentype-шрифт c Type-1 контурами) в формате шрифта, основанном на кривых Безье 2 порядка (TTF или Opentype-шрифт c TrueType контурами). Или при сохранении в обратном направлении. При этом происходит преобразование контуров символов шрифта, и возможны всякие эффекты, например, большая "округлость". Обычно на печати это не заметно.

Также возможно, что движок рендеринга шрифтов при выводе на экран устроен немного по-разному для разных видов шрифтов. Поэтому на экране шрифты разного формата могут показываться не совсем одинаково. Это наблюдается даже для разных вариантов одного и того же шрифта (например, TrueType и Type1), поставляемых производителем шрифта.
Разработка типовых сценариев работы с системой, Обсуждаем разработку типовых сценариев работы с системой
 
[QUOTE]techwriter пишет:
А что из себя представляет типовой сценарий работы с ПО и чем он отличается от инструкции или руководства?
[/QUOTE]Сценарий использования описывает один способ, с помощью которого продукт (или система) может быть использован для достижения определенной цели. Как правило, сценарий использования содержит пошаговое руководство по выполнению необходимых для этого действий. Более подробно смотрите здесь:

http://deseng.ryerson.ca/dokuwiki/design:usage_scenario
http://www.redline-software.com/eng/products/surfcop/scenarios/

Сценарии использования также широко используются на этапе проектирования. См., например, A. Cockburn "Writting Effective Use Cases" http://alistair.cockburn.us/get/2465

Сценарии, которые пишутся на этапе проектирования, должны описывать, что именно система должна сделать, чтобы пользователь (актер) достиг своей цели; не затрагивать деталей реализации, иметь достаточный уровень детализации и не описывать пользовательские интерфейсы, экраны и т. д. (т. к. это делается впоследствии — при дизайне пользовательского интерфейса).

Иногда различают "usage scenario" и "use case" - первый вид сценариев более персонализированный и конкретный, а второй - более общий, в котором может рассматриваться не конкретная задача, а класс задач, и в котором могут описываться различные варианты (ответвления) сценария.
.docx в .pdf
 
[QUOTE]Цахес пишет: Да, шрифты очень странные. Но придумала их не я, а компания, в которой я работаю. Отменить использование этих шрифтов не в моих силах. Как их можно "исправить"?[/QUOTE]Загружаете шрифт в Fontlab Studio 5, заходите в свойства шрифта, режим Embedding меняете на "everything is allowed", генерируете шрифт.
.docx в .pdf
 
[QUOTE]Цахес пишет:
Я работаю в Word 2010. При создании .pdf средствами Word текст получается размытым, не работает поиск. И сам .pdf весит так, будто это - не документ, а небольшой фильм.
[/QUOTE]Наверное, используемые вами шрифты не содержат разрешения на встраивание в PDF. В результате они преобразуются в растровые картинки, что и порождает указанные вами эффекты. Применяйте другие шрифты или исправьте эти.
[QUOTE]Цахес пишет:
Очень хотелось бы найти утилиту, которая позволит создавать адекватные .pdf из .docx. Может ли кто-нибудь подсказать такую?
[/QUOTE]Adobe Acrobat http://www.adobe.com/ru/products/acrobat.html
CutePDF Writer http://www.cutepdf.com/products/cutepdf/writer.asp
PDF Creator   http://www.pdfforge.org/
PDF4Free     http://www.pdfpdf.com/pdf4free.html
Разработка типовых сценариев работы с системой, Обсуждаем разработку типовых сценариев работы с системой
 
[QUOTE]ADVANCED Это рассказывается в предыдущем шаге также в виде Вопрос-Ответ с названиями окон, кнопок и форм. И скриншоты тоже добавляются.
[/QUOTE]Я спросил "как создать" - а вы отвечаете на совсем другой вопрос: "где это должно быть описано". I-о

У меня рядом стоят две книжки о том, как составлять консолидированную финансовую отчетность по МСФО - одна на 370 страниц, другая - 720 страниц большого формата.

И я не могу сказать, что там есть что-то лишнее.

Вы уверены, что столь обширный и методически сложный предмет можно изложить в виде "предыдущего шага" с названиями окон, кнопок и форм, и скриншотов?  :D
Разработка типовых сценариев работы с системой, Обсуждаем разработку типовых сценариев работы с системой
 
[QUOTE]ADVANCED пишет:
А какая там структура может быть? Вопроc- ответ.

Как распечатать консолидированный отчет МСФО за 2014 год?
[/QUOTE]Лучше расскажите, как создать консолидированный отчет МСФО за 2014 год. Вопрос-ответ.
Распечатать-то не проблема, и вряд ли процедура его печати отличается от процедуры печати других документов.
Предметная область и тех. писатель, Можно ли знать все?
 
[QUOTE]techwriter пишет: Ваша задача - описать, как в автоматизированной системе выполнить нужное ему действие. Или вы считаете, что если бухгалтер печатает журнал проводок, то он не знает, что такое проводка и ему необходимо рассказывать, что это такое?[/QUOTE]В пользовательской документации по 1С:Бухгалтерии версий 4, 5 и 6, которую я в 1993-95 гг. писал для 1С, определение проводки было. И определения других базовых понятий тоже. Но тогда было другое время, и бухгалтерией очень часто занимались непрофессионалы. Сейчас я не уверен, что поступил бы так же.

Проблема в том, что вы должны не только рассказать, как выполнять действие, но и что это за действие. Часто также надо указать, когда и почему оно выполняется. Иногда также необходимо указать, в соответствии с какими  требованиями оно должно выполняться, какие имеются типичные ошибки при его выполнении, и т.д. Иногда надо объяснить, почему выбран именно такой способ выполнения этого действия, а не иной... В терминологии DITA - нужно описывать не только task, но до нее изложить concept, а после нее дать reference. Не зная предметной области автоматизированной системы, задач и потребностей её пользователей, вы сможете сделать документацию на уровне примитивного описания кнопок, не более. И если предметная область хоть сколько-либо сложная, то получившуюся писанину придется показывать специалисту, чтобы он нашел и вычистил все ляпы.
Предметная область и тех. писатель, Можно ли знать все?
 
[QUOTE]techwriter пишет:
[QUOTE] Виктор Фигурнов пишет:
Бизнес-аналитик изучает бизнес-ситуацию, чтобы определить проблемы и возможности бизнеса,
[/QUOTE]Бизнес-аналитик этим вообще не занимается. Этим занимается специальный эксперт, который пишет бизнес-план. Бизнес-аналитик изучает потребности пользователя.
[/QUOTE]Вы ошибаетесь.

http://en.wikipedia.org/wiki/Business_analyst
http://ru.wikipedia.org/wiki/Бизнес-аналитик
Предметная область и тех. писатель, Можно ли знать все?
 
[QUOTE]techwriter пишет: Но вопрос, по сути, в том, должен ли технический писатель знать предметную область уже на этапе собеседования? Или он, все-таки, должен изучать ее в процессе разработки документации? Я считаю, что однозначно - в процессе разработки документации. Допустим, я технический писатель, который ищет работу. За плечами опыт описания различных учетных систем. Но, вот, конкретно со складами дела не имела. Что ж теперь? Работодатель будет искать только технического писателя, который идеально знает складской учет?
[/QUOTE]
Специфика конкретной области может изучаться по ходу дела, но базовая подготовка должна быть. Если вы ничего не знаете о том, на основании каких документов производится отпуск товаров со склада, то основы учета вы в принципе не знаете, даже если имеете некий "опыт описания различных учетных систем". Учет это непростая область, и люди её по 5 лет в вузе изучают, а потом годы работают, и то бывает, что к ним приходят аудиторы и указывают многочисленные ошибки. А вы хотите за пару недель или месяцев освоить какую-то область учета так, чтобы правильно описывать учетные процессы и учить бухгалтеров и учетных работников тому, как им использовать программу для решения их задач. Извините, но это вряд ли получится.

[QUOTE]techwriter пишет: Работодатель будет искать только технического писателя, который идеально знает складской учет?
[/QUOTE]Это работодатель решит сам.

[QUOTE]techwriter пишет: Общие процессы учета как раз-таки изучаются довольно быстро, достаточно изучить нормативку.[/QUOTE]Крайне сомнительно. Учет нельзя быстро изучить, прочитав нормативку, юристом нельзя быстро стать, прочитав законы, и т.д. Не знаю ни одного исключения.

[QUOTE]techwriter пишет: Общие процессы учета как раз-таки изучаются довольно быстро, достаточно изучить нормативку. Во-вторых, технический писатель в таком случае должен быть переквалифицированным бизнес-аналитиком.[/QUOTE]Бизнес-аналитик изучает бизнес-ситуацию, чтобы определить проблемы и возможности бизнеса, и на основе их анализа предложить решения, позволяющие организации достичь своих целей. Технический писатель ничем подобным не занимается.
Предметная область и тех. писатель, Можно ли знать все?
 
[QUOTE]Андрей Орлов пишет:
Виктор Фигурнов , на самом деле на собеседовании в Российской Федерации интересуются знанием РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов".
[/QUOTE]У меня и у моих знакомых про документ РД 50-34.698-90 никто ни разу не спрашивал. Документ крайне устарелый, ему уже 25 лет, да и в 1990 году он уже устарел. Например, если вы на собеседовании в фирме, занимающейся разработкой СУБД, расскажете о том, что там написано про документацию СУБД, о вас вряд ли сложится положительное впечатление. :D
Литература для технических писателей
 
Книги для технических писателей

Alred G. J., Brusaw Ch.T., Oliu W.E. Handbook of Technical Writing, Tenth Edition / St. Martin's Press, 2011
Van Laan K. The Insider's Guide to Technical Writing / XML Press, 2012
Blake G., Bly R. Elements of Technical Writing / Longman, 2000
Gill G. (Author)How to Get Started as a Technical Writer / CreateSpace Independent Publishing Platform, 2012
Hackos J. Information Development. Managing Your Documentation Projects, Portfolio, and People / Wiley, 2007
O'Keefe S., Pringle A., Rockley A. Content Strategy 101: Transform Technical Content into a Business Asset / Scriptorium Publishing Services, 2012

Международные стандарты по программной документации

ISO/IEC 26514:2008 Systems and software engineering -- Requirements for designers and developers of user documentation
ISO/IEC/IEEE 26511:2011 Systems and software engineering -- Requirements for managers of user documentation
ISO/IEC/IEEE 26512:2011 Systems and software engineering -- Requirements for acquirers and suppliers of user documentation
ISO/IEC 26513:2009 Systems and software engineering - Requirements for testers and reviewers of user documentation
ISO/IEC/IEEE 15289:2011 Systems and software engineering -- Content of life-cycle information products (documentation)
IEEE 1063-2001 IEEE Standard for Software User Documentation
IEEE 829-2008 IEEE Standard for Software and System Test Documentation

Руководства по стилю

Microsoft Manual of Style, 4th Edition / Microsoft Press, 2012
Russian Style Guide / Microsoft, 2011
Read Me First! A Style Guide for the Computer Industry, Third Edition / Prentice Hall, 2009
The IBM Style Guide: Conventions for Writers and Editors / IBM Press, 2011

Руководства по редакционно-издательскому оформлению

Мильчин А.Э., Чельцова Л.К. Справочник издателя и автора, 4-е изд. / Студия Артемия Лебедева, 2014
Предметная область и тех. писатель, Можно ли знать все?
 
[QUOTE]Орлов Андрей пишет:
Типы разрабатываемых документов с переводом. (2 страницы)
[/QUOTE]Это к вопросу, заданному топик-стартеру на собеседовании, отношения не имеет. Техпис не пишет накладных, ведомостей на склад, лимитно-заборных книжек и прочих товарно-распорядительных документов, на основании которых кладовщики отпускают товары.

А типы документов в разных источниках указываются разные. Вот, например, классификация по международному стандарту ISO/IEC/IEEE 15289-2011 "Systems and software engineering — Content of life-cycle information products (documentation)":

[B]Description[/B]

- Concept of operations
- Database design description
- Interface description
- Proposal
- Service catalog
- Software architecture description
- Software design description
- Software unit description
- System architecture description
- System element description

[B]Plan[/B]

- Acceptance plan
- Acquisition plan
- Asset management plan
- Audit plan
- Capacity plan
- Configuration management plan and policy
- Development plan
- Disposal plan
- Domain engineering plan
- Improvement plan (process improvement plan, service improvement plan)
- Information management plan
- Information security plan
- Installation plan
- Integration plan (implementation plan)
- Maintenance plan
- Measurement plan
- Project management plan
- Quality management plan (quality assurance plan)
- Release plan
- Reuse plan
- Risk management policy and plan
- Service Availability and continuity plan
- Service management plan
- Training plan
- Validation plan
- Verification plan

[B]Policy[/B]

- Configuration management plan and policy (change management policy, release policy)
- Improvement policy
- Information security policy
- Life cycle policy and procedure
- Quality management policy and procedure
- Risk management policy and plan

[B]Procedure[/B]

− Audit procedure
− Capacity management procedure
− Configuration management procedure (change management procedure, release management procedure)
− Complaint procedure
− Implementation procedure
− Incident management procedure
− Life cycle policy and procedure
− Maintenance procedure
− Operational test procedure
− Problem management procedure
− Process assessment procedure
− Qualification test procedure
− Quality management policy and procedure
− Software unit test procedure
− Supplier management procedure
− Supplier selection procedure
− Training documentation
− User documentation

[B]Report[/B]

− Acceptance review and testing report
− Audit acknowledgement report
− Audit report
− Configuration status report
− Evaluation report
− Incident report
− Installation report
− Integration and test report
− Monitoring and control report
− Problem report
− Process improvement analysis report
− Product need assessment
− Progress report
− Qualification test report
− Review minutes
− Service report
− Software unit test report
− User notification
− Validation report
− Verification report

[B]Request[/B]

− Change request
− Customer satisfaction survey
− Request for proposal (RFP)
− Resource request
− Risk action request

[B]Specification[/B]

− Contract
− Service level agreement (SLA)
− Software requirements specification
− System requirements specification
− Validation test specification
Предметная область и тех. писатель, Можно ли знать все?
 
[QUOTE]убожетымой пишет:
Сегодня я была на одном собесе в компанию 1С, где меня загрузили вопросами по предметным областям (бухгалтерия, экономика и т.д.). Вопросы были из серии "На основании какого документа производится кладовщиком отгрузка продукции?" И подведением итога, что я вообще ничего не понимаю и не понятно, что я могла писать без этих сакральных знаний.
Я в документации не новичок: работала и в медицине, и в "нефти", и на предприятиях-производителях. Но никто не требовал от меня знание предметной области. Получается, чтобы писать про медицинское ПО я должна была 7 лет в Меде отучиться, чтобы писать "со знанием дела"? Иначе, "это простое описание кнопочек" (цитата чела из 1С)

А у Вас как с этим? Требуют знание предметной области? Или тех. писателю теперь надо в бухгалтерских законах разбираться, чтобы про проводки писать?[/QUOTE]А как иначе? Без знания предметной области можно только про кнопки писать. О том, что видно на поверхности и понятно дилетанту. А получившуюся писанину потом специалист в предметной области должен внимательно прочесть и все ляпы выловить. Но это если важен качественный результат (у компании 1С именно такая ситуация), а не отписка для "галочки", что некий документ есть в наличии. Там, где нужна отписка, можно халтурить - писать не зная и не понимая предметной области, и лишь кое-как владея терминологией.
ДСТУ ISO/IEC 15910:2012
 
ДСТУ ISO/IEC 15910:2012 это стандарт Украины. Скорее всего, это перевод отмененного международного стандарта ISO/IEC 15910:1999.

Перевод стандарта ISO/IEC 15910:1999 на русский язык - это ГОСТ Р ИСО/МЭК 15910-2002 "Процесс создания документации пользователя программного средства"
Ссылка на текст: http://www.rugost.com/files/15910-2002.pdf

Стандарт не про оформление, а про процесс создания документации. Документ довольно короткий и малосодержательный.

Намного более конкретные и полезные международные стандарты по документации пользователей программных средств - это принятые вместо отмененного ISO/IEC 15910:1999 четыре cтандарта ISO:

ISO/IEC 26514:2008 Systems and software engineering -- Requirements for designers and developers of user documentation
ISO/IEC/IEEE 26511:2011 Systems and software engineering -- Requirements for managers of user documentation
ISO/IEC/IEEE 26512:2011 Systems and software engineering -- Requirements for acquirers and suppliers of user documentation
ISO/IEC 26513:2009 Systems and software engineering - Requirements for testers and reviewers of user documentation

а также

ISO/IEC/IEEE 15289:2011 Systems and software engineering -- Content of life-cycle information products (documentation)

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

Но опять-таки, это [B]не [/B]стандарты по оформлению. Стандарты платные, купить их можно на сайтах ISO и IEEE.
Помогите с оценкой трудозатрат на поддержку нескольких форматов документации
 
[url=http://techwriters.ru/forum/user/14053/]tech_writer_1[/url]

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

Если стили и шаблоны разработаны и отлажены, то остальные трудозатраты увеличатся не столь существенно, примерно на 10-20%. Это связано с тем, что:
[LIST][*]некоторые элементы документации должны выглядеть красиво и читабельно и на печати, и на экране, и на мобильных устройствах, а это не всегда обеспечивается автоматически. Иногда что-то приходится настраивать руками;[*]вы можете захотеть использовать интерактивные возможности, обеспечиваемые в онлайн-документации, а для этого в исходном тексте придётся делать соответствующую разметку; [*]все выходные представления документации должны генерироваться и проверяться, и это тоже требует времени.
[/LIST]
Иногда разные выходные представления документации отличаются по содержанию. По практическим или коммерческим соображениям. Например, какие-то сведения могут публиковаться только в онлайн-документации. Это приходится настраивать вручную, и ссылки на такие сведения тоже надо настраивать вручную. Что тоже требует некоторого времени.
Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 12

Рейтинг@Mail.ru