Максим Панфилов, Евгений Кукареко
Ведение общей конструкторской документации
Ведение документации по производимым изделиям для серийного производства с малой степенью конфигурируемости изделий
Ведение документации по производимым изделиям для производства с относительно небольшим циклом изготовления и средней или высокой степенью конфигурирования изделий под заказ
Ведение документации по производимым изделиям для мелкосерийного или единичного производства с длительным циклом изготовления
Одним из важнейших критериев соответствия системы ведения электронной документации по изделиям требованиям CALS-технологий является создание документации для каждого произведенного на предприятии изделия. Такая связь между электронной документацией и конкретными произведенными изделиями может быть обеспечена с помощью интегрированных системы управления данными об изделии и системы учета изделий в производстве и на постпроизводственном этапе их жизни. При этом для каждого из видов производства, будь то массовое, серийное либо позаказное (единичное и мелкосерийное), характерна своя специфика ведения документации по изделиям и учета изделий.
На построение системы ведения электронной документации, адекватной производимым изделиям, влияют серийность производства, длительность производственного цикла изделий, наличие на предприятии практики конфигурирования изделий под заказ. По этим признакам можно выделить следующие виды производства в машино- и приборостроении:
• серийное производство с небольшим циклом изготовления изделий и малой степенью конфигурируемости изделий под заказ;
• производство с относительно небольшим циклом изготовления и средней или высокой степенью конфигурирования изделий под заказ;
• мелкосерийное или единичное производство с длительным циклом изготовления.
В данной статье рассказывается о возможностях и опыте использования системы Omega Production по ведению электронной документации для производимых на предприятии изделий.
В настоящее время Omega Production предлагает развитые инструменты для формирования и ведения электронной документации по изделиям для всех вышеперечисленных видов производства. Функционал системы для данной области представлен несколькими дополняющими друг друга способами ведения документации во взаимосвязи с системой производственного учета.
Как правило, конструкторы, если только они не разрабатывают документацию под единичный заказ, который не будет повторяться, постоянно совершенствуют свои изделия, изменяя документацию с течением времени. Такую документацию можно условно назвать общей конструкторской документацией. В следующих разделах статьи будут рассмотрены возможности по ведению в Omega Production общей конструкторской документации и то, как эта документация связана с производимыми изделиями.
Omega Production обладает развитыми функциональными возможностями по ведению общей конструкторской документации. Конструкторская документация в системе ведется в виде электронных документов, для каждого из которых может быть построен свой жизненный цикл.
В системе предоставляются гибкие возможности по созданию и ведению данных о структуре и составе изделий. При этом поддерживается соответствие данных по спецификациям, ГОСТам, но с обеспечением автоматизированных расчетов по составу изделий.
Поддерживаются как единичные, так и групповые конструкторские спецификации и комплекты. Групповые документы в соответствии с действующими ГОСТами могут представляться в формах А или Б с преобразованием одной в другую. Обеспечивается связь между групповыми и составляющими их единичными спецификациями, при этом связь может быть более или менее строгой, в зависимости от устанавливаемых возможностей редактирования и продвижения единичных спецификаций, входящих в состав групповых.
В зависимости от используемых правил описания структуры изделий спецификации делятся на точные и общие. Точная спецификация однозначно описывает структуру и состав изделия или исполнения изделия в групповой спецификации. Общие спецификации применяются в том случае, если изделие имеет большое количество вариантов комплектования, которые невозможно или нецелесообразно определять как отдельные исполнения изделия. То есть общие спецификации это конструкторские документы, которые описывают структуру и состав совокупности комплектаций изделия (рис. 1). Для выбора конкретной комплектации изделия из общей нужно задать условия выбора или совокупность функциональных признаков, по которым производится выбор комплектации.
Рис. 1. Ведение общей конструкторской документации
В системе реализована возможность различного структурирования спецификаций с учетом соответствующих признаков: конструкторское, производственное и структурирование для сервиса. Конструкторское структурирование предполагает объединение элементов в спецификации по функциональному признаку; производственное объединение элементов по месту их изготовления на предприятии; структурирование для сервиса представляет собой ведение электронных каталогов изделий.
Система имеет удобный и наглядный интерфейс ввода и отображения данных. Для многих списков и отчетов пользователю предоставляется доступ к иерархии и структуре составных объектов, таких как единичные и групповые спецификации. Также пользователь может самостоятельно создавать формы представления данных с помощью контекстных отчетов, присоединенных к основному окну.
Для всех видов спецификаций имеются редакторы содержимого, позволяющие вводить структурированные и вместе с тем приближенные к представлению спецификаций данные при выводе на печать. Среди множества функций отметим такие, как добавление текстовых и пустых строк в содержимое спецификации, вставка разрывов страниц, сортировка строк с сохранением результата.
Изменения в конструкторской документации производятся через электронные извещения на изменения. При этом возможно параллельное проведение изменений по одному конструкторскому элементу. Система поддерживает различные виды наследования по конструкторским элементам. Все сделанные изменения датируются, что позволяет получать структуру и состав изделий не только на текущий момент, но и на любую заданную дату.
Если изделия производятся серийно в большом количестве и не имеют множества вариантов комплектования, то в этом случае адекватными являются традиционные, определенные в ЕСКД способы ведения данных о структуре и составе изделий.
Структура и состав таких изделий описываются точными единичными спецификациями или комплектами, которые при наличии нескольких исполнений могут объединяться в групповые спецификации или комплекты.
В этом случае связь произведенных изделий со спецификациями, описывающими их структуру и состав, в системе Omega Production производится по дате.
В подсистеме учета по произведенным узлам и изделиям ведутся и хранятся данные о дате производства и конструкторском обозначении спецификации/комплекта, по которому были произведены изделия. По этой информации система всегда выдаст такие структуру и поэлементный состав изделия, какими они были во время производства, несмотря на то, что они могут отличаться, и значительно, от структуры и состава изделия, имеющего в данный момент то же самое обозначение (рис. 2).
Рис. 2. Спецификация произведенного изделия
В системе хранятся данные не только об имевших место конструкторских изменениях, но и обо всех изменениях в технологической документации, в трудоемкости и ценах. Это позволяет проводить любые технико-экономические расчеты и анализировать влияние изменений на экономические показатели, например на затраты и себестоимость изделий.
Что касается учета заказных изделий, Omega Production предоставляет возможность ведения конструкторских данных о сотнях и тысячах вариантов исполнения или комплектации изделия. При этом обеспечивается хранение структуры и состава данных для партий сконфигурированных изделий на определенную дату в общей документации. Данная схема ведения документации характерна для позаказного производства с конфигурированием изделий под заказ.
Заказчика, обращающегося в службу маркетинга, и, следовательно, службу маркетинга, конечно же, интересуют функциональные свойства заказываемой продукции, а не конструкторские обозначения деталей и узлов, принятые на предприятии. Представленный в Omega Production функционал позволяет автоматически формировать спецификации комплектаций на основе требований заказчика. Требования оформляются в виде функциональной заказной спецификации, формируемой на изделие на основе заранее созданной конструктором общей функциональной спецификации изделия.
Вследствие огромного многообразия интересующих заказчика функциональных свойств изделия поддерживать все возможные варианты точных спецификаций изделия нецелесообразно и невозможно. Конструктор ведет лишь общие конструкторские спецификации и информацию о функциональных свойствах изделия. Он определяет, какие составные части обеспечивают те или иные свойства готового изделия. Данная информация вводится с помощью матриц собираемости, которые можно подразделить на два вида: матрицы свойств и матрицы выбора. Последние предназначены для определения зависящих от входимости свойств элемента. Таким образом достигается наибольшая гибкость при формировании заказной комплектации. Все варианты свойств готового изделия сводятся в общей функциональной спецификации на изделие.
Для удобства работы с общими конструкторскими спецификациями, матрицами собираемости и общими функциональными спецификациями в системе Omega Production реализованы входимость элементов в матрицы выбора и свойств, указание функциональных свойств элементов прямо в содержимом общей конструкторской спецификации, просмотр иерархии состава полученных заказных комплектаций в списке отчета. Также в системе имеется ряд функций, позволяющих конструктору самому контролировать правильность формирования комплектаций.
На основании договора с заказчиком в системе формируется заказ на изготовление заказного изделия. В нем фиксируется сформированная заказная спецификация, которая впоследствии всегда может быть просмотрена на дату ее создания (рис. 3).
Рис. 3. Ведение заказных комплектаций
В мелкосерийном и единичном производстве необходимо хранить документацию на каждое изделие. Естественно, это связано со спецификой производства, где каждый объект живет своей жизнью. Он может находиться в эксплуатации, возвращаться в ремонт или дорабатываться (например, в случае опытного производства). Состав каждого изделия может меняться с течением времени. Какими бы незначительными ни были изменения, они должны быть зафиксированы в документации. Вместе с тем независимые, но одинаковые объекты могут производиться по одной общей документации. Для решения такого рода задач в системе Omega Production введено понятие экземпляров объектов (рис. 4). Экземпляр сочетает в себе свойства документа и объекта производства и формируется на основе общей документации. Однако состав экземпляра в дальнейшем уже не зависит от изменения общей документации. Экземпляры, так же как и общая документация, являются электронными документами, для которых определяется свой жизненный цикл, не заканчивающийся производством, а имеющий п остпроизводственные этапы, такие как эксплуатация и утилизация.
Рис. 4. Экземпляры изделий
Для экземпляров могут проводиться изменения документации, составляющих их элементов и другие касающиеся их изменения.
Предоставляется возможность просмотра иерархии состава экземпляра прямо из списка отчета.
Таким образом, система Omega Production обеспечивает возможность ведения документации для каждого из произведенных на предприятии изделий. Поддерживается адекватность документации на всех этапах жизненного цикла изделия, что является необходимым условием CALS-технологии.
Более подробную информацию о системе Omega Production можно найти на сайте www.omegasoftware.ru.
«САПР и графика» 6’2004
Привет, Хабр! Меня зовут Татьяна Шуравина, я системный аналитик Innovative People, работаю на проекте в банковском секторе. Вместе с командой оптимизируем и автоматизируем операции сотрудников банка для обслуживания юридических лиц. В своей первой статье я рассказывала, как стать системным аналитиком без специального образования. Сегодня хочу поделиться с теми, кто начал свой путь в аналитике, тонкостями магического процесса ведения проектной документации. Не для кого не секрет, что зачастую бывает такое, что система есть, а документации, чтобы понять, как она работает, нет. В статье расскажу, какие есть подходы к ведению документации, зачем это нужно и поделюсь практическим опытом.
На протяжении всего проекта команда в соответствии со своими компетенциями ведет разного рода документацию, которая содержит информацию о каждой вехе проекта. Это несколько этапов от подготовки проекта до внедрения в промышленную эксплуатацию. Их структура и суть должны быть отражены в соответствующем виде и доступном для заинтересованных лиц месте.
При использовании разных методологий ведения проектов названия этапов могут отличаться, но перечень работ сохраняется вне зависимости от подхода.
Итак, на первом этапе ведется предпроектная документация, которая описывает подготовку для запуска проекта и крупными мазками — план‑график проекта.
Далее — этап проектирования, на котором рождаются и разрабатываются проектные решения на основании входных данных с этапа предпроектной подготовки.
Едем дальше: этап реализации проекта. К этому этапу относится документация, с которой работает команда разработки. Тест‑кейсы и данные для проведения функционального, интеграционного и бизнес‑тестирования. В своей статье я подробно остановлюсь на ведении документации, необходимой для системного анализа и разработки.
Завершающим этапом является подготовка и переход к ОПЭ, реализованного проекта, в соответствии с документацией на всех предыдущих этапах продукта. Инструкции пользователей и регламенты процессов — выходные документы заключительного этапа.
Редко встретишь человека, которому нравятся бюрократические замашки, оформление документов в соответствии с придуманными кем‑то стандартами и шаблонами. Всегда что‑то не нравится и хочется изменить под себя. Но, исходя из опыта работы на проектах, понятное и удобное ведение документации, для всех членов команды и потомков, имеет следующие преимущества:
1) сокращение сроков первичных согласований на предпроектном этапе;
2) быстрый онбординг новичков и адекватная оценка сроков проекта;
3) легкость в передаче экспертизы коллегам в соответствии с разными компетенциями, представлении продукта заинтересованным лицам;
4) прозрачность и понимание для коллег, сопровождающих систему после внедрения.
Для начала системного анализа в моей команде аналитику достаточно иметь 3 основные составляющие:
согласованный вижн;
бизнес‑требования;
макеты интерфейсов.
Вижн — документ‑изложение проектного решения и основа для разработки. На вижне, обычно, отображена архитектура проекта, т. е. взаимодействия реализуемой или дорабатываемой системы с другими системами и данные, которыми обмениваются потребитель и поставщик. Также указаны флоу процессов, которые реализуются, в соответствии с данным вижном.
Бизнес‑требования могут приходить в аналитику в разных вариантах: в виде оформленного документа в ворде или user‑story, в которой описано поведение системы сейчас (as is) и как должно быть, в соответствии с требованиями заказчика (to be).
Макеты ui также важны для проработки функционала, описанного в требованиях бизнеса и для оценки трудоемкости задач для разработки.
На проектах применяются разные подходы к ведению и оформлению документации, также как и места хранения информации. Зачастую рабочее пространство выбирать не приходится, так как приходя на проект, заказчик уже использует конкретные инструменты для организации проектной работы.
Рассмотрим два распространенных метода ведения проектной документации на моей практике:
1) ведение спецификаций требований к АС (СТАС) по ГОСТу в электронном виде с загрузкой документа в электронный архив;
2) ведение документации в электронном виде в рабочем пространстве, которое используется на проекте в соответствии с определенной структурой;
Сравним описанные выше подходы на предмет удобоваримости формата работы с каждым.
Универсального рецепта нет, поэтому наиболее удобный и эффективный формат ведения документации, команда вправе выбирать сама с учетом особенностей проекта.
В данный момент я работаю на проекте, где вся информация хранится на Confluence в соответствующем проектном пространстве. Команда проекта делится на подкоманды, которые сопровождают определенные модули, которые взаимодействуют между собой. Для нас было важно создать такой подход для ведения документации, который позволяет структурированно и в едином формате отражать информацию по каждому модулю.
В какой‑то момент остро встал вопрос о том, как сделать документацию понятной, полезной и без лишней лирики. После нескольких встреч и понимания, что важно и нужно учитывать при ведении проектной документации для всех членов команды на разных этапах мы пришли к определенному результату. Для структурности и единого подхода команда разработала шаблоны для описания бизнес‑требований, системного анализа и процесса тестирования. Эти шаблоны положили в общий репозиторий в рабочем пространстве проекта.
Для аналитики мы разбили информацию на несколько разделов и подразделов:
архитектура;
описание процессов;
подраздел метрики;
база данных.
В разделе «Архитектура» отображена общая схема взаимодействия модуля с разными сервисами и сторонними системами через api. Аналитик описывает контракты для интеграции с другими системами, рисует UML‑диаграммы с последовательностью вызовов для получения данных.
Для изображения процессов используем макеты ui и описываем сценарии работы пользователя в системе с разрабатываемым функционалом, поведение системы и обработку ошибок. В этом разделе также упоминаем про ролевую модель, т. е. какие роли и права должны быть у пользователя для доступности функционала. При необходимости, если в процессе работы в системе формируются печатные формы или отчетные документы, то отражаем логику формирования и шаблон печатки.
В разделе «Метрики» описываем места, где логируются действия пользователя, названия метрик, как они интерпретируются при выгрузке отчётности. Раздел используются при необходимости.
База данных это тоже не обязательный раздел, но мы ведём его для команды сопровождения. На проекте используется в нереляционная БД — MongoDB. На страничке для БД описываем коллекции данных, которые используются для работы функционала.
Помимо корректного ведения документации не маловажным аспектом является поддержание документации в актуальном состоянии. Для этого раз в квартал мы используем перекрёстный аудит. Системные аналитики из смежных команд заполняют специально разработанные чек‑листы на соответствие документации определенным критериям. Если есть какие‑то замечания, то ответственный аналитик устраняет. Ели объем документации, которую необходимо актуализировать/добавить, слишком большой, то заводится техдолг по документации, который постепенно устраняется.
Чтобы не доводить ситуацию до критической точки, нужно придерживаться простого правила: сделали доработку — и сразу актуализировали документацию. В процессе это занимает мало времени, но эффект от такого подхода очевиден. Если не обновлять информацию в срок, то на большой дистанции можно потерять кучу времени, чтобы вспомнить все и корректно занести информацию.
Проекты разные и универсальных рецептов точно нет — надо делать то, что удобно и эффективно с точки зрения коммуникации для команды, которая используем документацию в своей работе. При этом не надо изобретать велосипед, на мой взгляд, нужно использовать инструменты разных подходов и пробовать, что подходит для конкретного проекта.
Полная, доступная и единообразная документация должна работать как навигатор. Мне очень нравится фраза «Порядок в голове — порядок везде». Это я к чему: структурированная определённым образом документация, которая вовремя актуализируется, может дать только положительные эффекты.
Начинающим аналитикам, хочу порекомендовать список самых используемых инструментов для ведения документации:
Google Drive для хранения разного вида файлов с общим доступом и редактированием онлайн.
Dropbox, как замена Google Drive. Если, кто‑то из сотрудников потерял телефон, то в Dropbox можно отключить доступ к этому устройству.
Confluence — общее рабочее пространство, база знаний для создания, хранения, редактирования документов.
Notion — «википодобный» ресурс. Хорошо работает для базовой документации, особенно о каком‑то продукте. В целом, можно использовать как замену Confluence и сильно экономить, потому что Notion дешевле.
Miro помогает сделать быстрое ревью документа. Похож на большой lite‑board или Paint, куда можно вставлять различную информацию: ретроспективу, анонсы, согласование дизайна со стейкхолдерами, превью дизайна с разработчиками.
Важно, какими бы инструментами вы ни пользовались, соблюдайте базовые правила:
1. Документация должна быть актуальной. Для удаленных команд с десятью часами разницы во времени онлайн оборот особенно актуален: можно быстро редактировать документ и все это видят.
2. Документация должна быть доступной. Перепроверяйте права доступа.
В течении всего жизненного цикла проекта:
выбирайте правильные инструменты для хранения и работы с документами;
создавайте навигацию, в которой сможет разобраться даже новичок;
делегируйте работу и проверяйте сделанное другими.
Так же полезными ссылками на интересные статьи:
Документация в порядке
Подход к ведению документации на ОС: наш опыт
Как научиться создавать полезную проектную документацию ИТ‑систем
Успехов всем начинающим и помните, ведение документации — это непрерывный процесс: «Вы можете откладывать, но время этого не сделает». — Бенджамин Франклин
Перейти к основному содержанию
Поиск по сайтуГлавное меню
Главное меню
Niels Lund
Это название будет доступно весной 2023 года. Вы можете разместить заказ, и товар будет отправлен, когда он станет доступен. Покупатели за пределами Северной Америки (США и Канада) должны связаться с Facet Publishing для получения информации о покупке.
Добавить в корзину
Цена:
66,99 $
Член ALA
60,29 $
Документация всегда имела решающее значение в человеческом обществе. Сегодня почти все сообщения хранятся в цифровом виде. Чтобы систематически и последовательно иметь дело со старыми и новыми медиа в современном мире, вы должны иметь дело как с физическим, так и с социальным и культурным контекстом. Наряду с этим в настоящее время растет интерес к теории и науке о документации, и изучение документации стало ярко выраженной областью исследований, а также основой для профессиональной практики в библиотеках, архивах и музеях.
Эта новаторская новая книга представляет и демонстрирует ценность и актуальность нового подхода к документации, коммуникации и информационной сфере, дополняющего традиционные библиотечные, информационные и архивные науки. Он предлагает введение в исследования документации, новую дисциплину в рамках общей концепции изучения информации, и дает широкую и общую теорию документации. В нем излагаются исторические предпосылки и теоретическая основа дисциплины, давая представление о проблемах и процессах документации от раннего современного общества до сегодняшней цифровой эпохи: не только в контексте академических исследований, но и в практике документирования, как в повседневной жизни и в профессиональной жизни. Основные затронутые темы включают:
Этот уникальный текст описывает основную научную цель и задачу науки о документации; изучить документацию в обществе. Также описаны основные навыки документалиста в 21 веке; иметь возможность выбирать, собирать и делать доступной всю документацию, представляющую возможный интерес для широкой публики, а также для исследований.
Эта книга будет основным чтением для студентов (продвинутых бакалавров и аспирантов), исследователей и преподавателей в области библиотечного дела, информатики, делопроизводства, издательского дела, медиа-исследований, культурологии, архивоведения и информационных систем. Он также будет интересен вдумчивым специалистам в области библиотек, архивов, документации и средств массовой информации.
Экзаменационные копии доступны для инструкторов, которые заинтересованы в принятии этого названия для использования в курсе.
1. Пролог: человеческая жизнь в перспективе документации
Часть I Документ в теории
2. Документ: концептуальная археология
3. Дополнительная теория документа
4. Модель анализа документа
Часть II Документация на практике
5. Музыка: Реквием K626 В. А. Моцарта
6. Литература: «Индейский лагерь» Эрнеста Хемингуэя
7. Наука: «Датская революция» Торкильда Кьергорда
8. Администрация: Карта социального обеспечения
9. Политика: Марш за гражданские права
10. Субкультуры: Домашняя страница байкера
11. Документация в обществе
12. Наука и профессия Документация
13. Эпилог: Общество в Перспектива документации
14. Литература и другие источники
Нильс Лунд стал первым сотрудником и профессором документоведения на факультете документоведения Университета Тромсё, Норвегия. Д-р Лунд был адъюнкт-профессором Королевской школы библиотечных и информационных наук в Дании и дважды был приглашенным профессором Калифорнийского университета в Беркли. В 2001 году д-р Лунд основал The Document Academy, международную сеть по изучению документации, организующую ежегодные конференции DOCAM в Северной Америке и летние школы в Норвегии в Университете Тромсё. Он по-прежнему работает в качестве почетного профессора, курирует аспирантов и участвует в исследовательских проектах.
Также представляет интерес:
Литература для молодежи: от романтики к реализму, четвертое издание 002 $59,99
Номер товара:
978-0-8389-4747-0
Год публикации:
Издатель:
ALA Neal-Schuman
Количество страниц:
Ширина0:
Формат:
Мягкая обложка
AP Категории:
A, C, E, I
Как управлять обработкой в архивах и специальных коллекциях: введение
Pam Hackbart-Dean
Elizabeth A. Slomba
Детали:
Цена:
$70,00
Издатель:
Количество страниц:
Ширина:
Высота:
Формат:
Мягкая обложка
Управление знаниями: введение 0003
Доктор Кевин С. Desouza
Scott Paquette
Детали:
Цена:
$82,00
Артикул:
978-1-55570-720-0
Количество страниц:
Ширина:
Высота:
Формат:
Мягкая обложка
Имеют ли ценность архивы?
Добавить в корзину
Посмотреть всю страницу товара
Авторы:
Майкл Мосс
Дэвид Томас
Детали:
Цена:
90 000 90 000 90 000
90 039 Номер: 0 $86,99 90 03978-1-78330-332-8
Год публикации:
Издатель:
Facet Publishing, Великобритания
Количество страниц:
Ширина:
Высота:
Формат:
Мягкая обложка
Аутрич-услуги для подростков: руководство для начинающих
В корзину s Снег
Детали:
Цена:
49,99 $
Артикул:
978-0-8389-4815-6
Год публикации:
Издатель:
ALA Издания 9002 из 900 002 Ширина:
Высота:
Формат:
Мягкая обложка
AP Категории:
A, C
Введение в организацию знаний
Клаудио Ньоли
Детали:
Цена:
$70,99
Артикул:
978-1-7833-0465-3
Год публикации:
Издатель:
UK Publishing 9Facet Количество страниц:
Ширина:
Высота:
Формат:
Мягкая обложка
Электронные библиотечные программы для библиотек и архивов: создание, управление и поддержание уникальных цифровых коллекций
В корзину с:
Aaron D. Purcell
Детали:
Цена:
85,00 $
Номер позиции:
978-0-8389-1450-2
Год публикации: 90 03
0003
ALA Neal-Schuman
Количество страниц:
Ширина:
Высота:
Формат:
Мягкая обложка
AP Категории: 0 0 I
90,002 Практические знания и управление информациейДобавить в CART
Просмотр Полного продукта Страница
Авторы:
Кэтрин Шопффин
Мэтт Уолш
Подробности:
Цена:
$ 86,99
Номер.78-1-78330-335-9
Год публикации:
Издатель:
Facet Publishing, UK
Количество страниц:
Ширина:
Высота:
В этом ознакомительном модуле вы узнаете, как начать работу в группе документации OpenOffice.
Чтобы завершить этот модуль, прочитайте материалы на этой странице, включая ссылки. Вам также нужно будет выполнить некоторые начальные задачи, такие как регистрация учетной записи на нашей вики.
Ваша первая задача — подписаться на нашу рассылку документации. Вы можете подписаться, отправив электронное письмо по адресу [email protected].
Затем вы можете представиться, отправив письмо по списку. Мы хотели бы услышать, кто вы, откуда вы, каков ваш опыт и т. д. Кроме того, когда вы работаете с элементами на этой странице, если у вас есть вопросы или проблемы, пожалуйста, не стесняйтесь обращаться за помощью, отправляя примечание к этому же списку.
Примечание. Параллельно с элементами, относящимися к Doc, на этой странице, вы можете также ознакомиться с ознакомительными модулями уровня 1 и уровня 2. В них есть полезная справочная информация о The Apache Way, этикете списка рассылки, принятии решений в проекте и т. д. Быстрый обзор — хорошая идея, особенно если вы новичок в работе с проектами с открытым исходным кодом в стиле Apache.
Теперь, когда знакомство завершено, давайте начнем!
Будучи популярным продуктом для конечных пользователей, Apache OpenOffice используется миллионами людей по всему миру с самыми разными навыками и опытом. Некоторые используют OpenOffice десятилетиями. Другие просто переходят с Microsoft Office. Некоторые хорошо знакомы с компьютерами и их операционными системами. Другие могут использовать компьютер впервые. Некоторые делают только базовое редактирование. Другие являются «опытными пользователями» и создают сложные приложения на базе OpenOffice.
Когда у пользователей возникает вопрос, когда они застревают, у них есть широкий выбор вариантов:
Документация, которую мы пишем, помогает как конечным пользователям, так и тем, кто их поддерживает. Мы стремимся предоставлять авторитетные и актуальные материалы по Apache OpenOffice и помогать пользователям всех уровней квалификации. Если мы делаем наши задачи хорошо, пользователи более удовлетворены и более продуктивны.
Мы поддерживаем документацию в различных формах:
Вся документация OpenOffice размещена на вики OpenOffice для облегчения обслуживания добровольцами, за исключением файлов справки, которые интегрированы с самим продуктом OpenOffice.
В нашей работе с документацией мы должны помнить о следующих целях и ограничениях:
Мы ищем волонтеров с опытом написания технических работ, хорошим знанием OpenOffice или, в идеале, с обоими. Требуется возможность сотрудничать с другими на письменном английском языке в списке рассылки, но вам просто нужно быть понятным. Для фактического написания у нас есть редакторы-добровольцы, которые просматривают и редактируют черновики, чтобы исправить любые языковые ошибки. Таким образом, вам не нужно владеть английским языком на уровне носителя.
Для некоторых специализированных областей также пригодятся навыки графического дизайна и программирования.
Добровольцы из группы документации работают над различными задачами, включая:
С группой документации проще всего начать работу. Всего несколько основных шагов:
Об авторе