Закон о техническом регулировании №184-ФЗ, принятый Россией при вступлении в ВТО, требует достоверной информации о продукции для: «предупреждения действий, вводящих в заблуждение приобретателей, в том числе потребителей» (ст. 6, 46 184-ФЗ). Двухуровневая система разделения техрегламентов и ГОСТов, с их обязательным и добровольным характером, согласно статье 46 184-ФЗ, становится в России одноуровневой. ГОСТы теперь являются обязательными стандартами. Анализ и сравнение множества терминов юридически обоснованы. Цель создания словаря - облегчить работу по выбору терминов.
Подготовка технической документации *
Всё о деятельности технических писателей
Словарь-справочник юридических терминов из ГОСТов для сферы IT. Часть 6 — В-Ва
Участие России в ВТО потребовало стандартизации терминов и определений. Это сделано для: «предупреждения действий, вводящих в заблуждение приобретателей, в том числе потребителей» (ст. 6, 46 184-ФЗ). Общепринятая двухуровневая система разделения на обязательные техрегламенты и добровольные ГОСТы становится одноуровневой после требований ст.46 184-ФЗ, при создании описаний и в контрактах на поставку и, соответственно, для используемых терминов и интерпретации их определений. В данном словаре представлены десятки тысяч определений, чтобы эффективнее реализовывать различные задачи в IT отрасли.
Словарь-справочник юридических терминов из ГОСТов для сферы IT. Часть 5 — Ба-Бя
При формировании договоров, технических заданий и проектов, термины приобретают статус важных, юридически обязывающих условий. В нынешней ситуации, когда положения статьи 46 закона 184-ФЗ “О техническом регулировании” и ГОСТы становятся обязательными к исполнению, возникает потребность в использовании и сравнении тысяч терминов. С целью упрощения работы с данными понятиями был создан данный словарь.
Словарь-справочник юридических терминов из ГОСТов для сферы IT. Часть 4 — Ас-Ая
Стандартизация терминов и определений в рамках страны-участницы России в ВТО направлена для: «предупреждения действий, вводящих в заблуждение приобретателей, в том числе потребителей» (ст. 6, 46 184-ФЗ). Общепринятая двухуровневая система разделения на обязательные техрегламенты и добровольные ГОСТы становится одноуровневой после требований ст.46 184-ФЗ, при создании описаний и в контрактах на поставку и, соответственно, для используемых терминов и интерпретации их определений. В данном словаре представлены десятки тысяч определений, чтобы эффективнее реализовывать различные задачи в IT отрасли.
Истории
Системная ошибка рынка труда или почему не хватает технических писателей со знанием языков разработки и API
Hola, Хабр! Я — технический писатель и за свою длинную карьеру в ИТ, нигде и никогда не сталкивался с ситуацией переизбытка в командах технических писателей. Наоборот, почти повсеместно в компаниях есть множество продуктов и проектов, в которых документация неполная, неточная, устаревшая и покрытая паутиной, а самих «техписов» хронически не хватает. Опытные спецы, умеющие читать код, документировать алгоритмы, описывать БД и API — это вообще люди уровня «ошибка выжившего». И, возможно, я нашел ответ на этот вопрос.
Словарь-справочник юридических терминов из ГОСТов для сферы IT. Часть 3 — Ан-Ар
Действующий 184-ФЗ «О техническом регулировании», принятый Россией при вступлении в ВТО требует, чтобы любая продукция была безопасна и не вводила людей в заблуждение.
Для реализации этих требований вводятся технические регламенты, которых в настоящее время 54 (прогнозируется необходимость около 2000). Бывшие в СССР ГОСТы, СНиПы и СанПиНы есть и сейчас, но в 184-ФЗ сказано, что они принимаются на добровольной основе. При этом в статье 46 184-ФЗ написано, что если какая-то вещь касается безопасности и правдивости, то необходимо применять существующие ГОСТы, СНиПы и СанПиНы (по нормам ст. 309 ГК РФ).
То есть, если Вами использовано слово «рубильник» вместо «переключатель», то Вас могут признать нарушителем 184-ФЗ и применить ст. 14.4 КоАП РФ.
Представленный нами словарь станет Вашим помощником в выборе правильного термина и оградит Вас от некоторых проблем.
Интерактивные и документированные диаграммы для сложных систем
Мой первый on-call выдался нелегким. Недели тренингов и обучения не подготовили меня к тому что придется бегать по Slack каналам различных команд и искать того, кто может что либо знать о какой-то из частей системы. Оказалось что многие страницы в корпоративной Wiki уже не обновлялись несколько лет. Команды хранили свою документацию кто где хотел: кто в Wiki, кто в Google Docs, кто в GitHub и т.д. Наш on-call был не идеален: 2 человека выходили на дежурство 24/7. Один был ответственен за всю инфраструктуру (MySql, Cassandra, Kafka, ElasticSearch, Nomad и т.д.), второй же был Developer on-call и отвечал за все микросервисы и различные легаси системы, что в сумме давало около 300 различных сервисов от 7 команд на самых различных стеках и фреймворках (Java, Scala, Node, Go). Но что меня больше всего раздражало - так это невозможность быстро оценить на высшем уровне как проходит и обрабатывается запрос от пользователя. Диаграммы для разных бизнес частей точно также были либо устаревшими, либо без прилегающей документации, либо для какой-то бизнес логики не было ничего. И вот тогда мне пришла идея, что было бы неплохо иметь диаграммы, в которых можно не только нажать на любой элемент и добыть о нем более детальную информацию, но также получить ссылки на другие диаграммы и динамически их подгружать. Мне хотелось иметь возможность быстро разобраться в неизвестной распределенной системе, не переключаясь между диаграммой и документацией в Google Docs или Wiki. Именно так я начал работать над проектом Schem.io.
Предупреждение: в статье содержится большое количество GIF-изображений.
Словарь-справочник юридических терминов из ГОСТов для сферы IT. Часть 2 — Аг-Ам
При составлении контрактов, технических заданий, проектов термины становятся юридически значимыми определяющими условиями. В текущих условиях, когда требования ст. 46 184-ФЗ «О техническом регулировании», ГОСТы являются уже не добровольной, а обязательной нормой. Возникает необходимость использовать и сопоставлять тысячи терминов. Для облегчения работы с этими понятиями и создан этот словарь.
Как инжиниринговые компании организуют в TDMS Фарватер хранилище и обмен документацией. Опыт «Аквапрув»
Почему инжиниринговые компании предпочитают работать в специализированных решениях для ведения технического документооборота и комплексного управления проектами? На что стоит обратить внимание при выборе подходящего инструмента и как построить системное управление, которое очень высоко ценится в проектном менеджменте, повышая доверие заказчиков и подрядчиков? Компания ООО «Аквапрув» поделилась своим опытом эффективного управления проектами в строительстве в среде TDMS Фарватер.
Словарь-справочник юридических терминов из ГОСТов для сферы IT. Часть 1 — А-Ав
Участие в ВТО потребовало стандартизации терминов и определений, для: «предупреждения действий, вводящих в заблуждение приобретателей, в том числе потребителей» (ст. 6, 46 184-ФЗ). Общепринятая двухуровневая система разделения на обязательные техрегламенты и добровольные ГОСТы становится одноуровневой после требований ст.46 184-ФЗ, при создании описаний и в контрактах на поставку и, соответственно, для используемых терминов и интерпретации их определений. В данном словаре представлены десятки тысяч определений, чтобы эффективнее реализовывать различные задачи в IT отрасли.
Синкерим, хешайдим, терминируем: 6 утилит, чтобы ускорить ваши локализации
Наша команда Mobile Doc&Loc «Лаборатории Касперского» занимается подготовкой документации и локализации B2C-продуктов компании для мобильных устройств. Основная сложность (и одновременно фишка) нашей работы заключается в том, что необходимо регулярно подготавливать переводы на 34 языка в крайне сжатые сроки.
Меня зовут Юлиана Соломатина, я — Doc&Loc-инженер, и в этой статье я расскажу про инструменты-автоматизации, которые помогают нам справляться с наплывом задач и укладываться в дедлайны, не жертвуя при этом качеством. Кстати, многие из этих инструментов мы разработали сами.
Как создать хороший FAQ
Привет, Хабр! Я Евгения Береснева, технический писатель в X5 Tech, и я считаю, что классный раздел вопрос-ответов нужен любому продукту. В статье как раз расскажу о том, как его создать.
Управление документацией в растущей компании: DocFX + Gitea + «Этос»
По мере увеличения кодовой базы любая компания начинает испытывать потребность в упорядочивании разрозненной документации, иными словами — создании собственной «базы знаний». О чём стоит помнить при выборе конкретных инструментов и как сделать их одинаково удобными для разработчиков и техписателей, попробуем разобраться в сегодняшней статье.
Ближайшие события
Профессия: технический писатель
Хотела начать текст с шутки про то, что раз инструкции никто не читает, то и писать их не обязательно. Однако 14 лет работы в IT-сфере доказывают, что это всё же довольно глупая шутка. В современных компаниях (не только в IT, но и особенно в IT!) на документации завязаны практически все процессы от проектирования ПО и ведения бэклога до эксплуатации и поддержки пользователей. Люди со стороны часто не догадываются, что в командах кроме суровых разработчиков, дотошных тестировщиков, внимательных сисадминов, осторожных безопасников и продвинутых девопсов трудятся технические писатели. Как правило, они одновременно суровые, дотошные, внимательные, осторожные и продвинутые, потому что именно на них лежит ответственность как за внутреннюю документацию, так и за корректные, грамотные, лаконичные и точные инструкции для пользователей. И писать желательно без девяти прилагательных в одном предложении, как строчкой выше 🙂
Сегодня поговорим об этих ребятах, о профессии, о людях в ней и о том, стоит ли войти в айти именно через вакансию техписа?
NB И да, обязательно читайте цитаты членов сообщества техписов — они рассказывают о самом актуальном в профессии из первых рук.
Disaster Recovery Plan: Как правильно заваривать чай, когда горит серверная
Компания у нас на full-remote, поэтому заседание кружка параноиков мы проводим как-то так. Иногда под банджо в углу.
В жизни любого проекта наступает катастрофа. Мы не можем заранее знать, что именно это будет - короткое замыкание в серверной, инженер, дропнувший центральную БД или нашествие бобров. Тем не менее, оно обязательно случится, причем по предельно идиотской причине.
Насчет бобров, я, кстати, не шутил. В Канаде они перегрызли кабель и оставили целый район Tumbler Ridge без оптоволоконной связи. Причем, животные, как мне кажется, делают все для того, чтобы внезапно лишить вас доступа к вашим ресурсам:
Макаки жуют провода. Цикады принимают кабели за ветки, и расковыривают их, чтобы отложить внутрь яйца. Акулы жуют трансатлантические кабели Google. А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.
Короче, рано или поздно, кто-то обязательно что-то сломает, уронит, или зальет неверный конфиг в самый неподходящий момент. И вот тут появляется то, что отличает компании, которые успешно переживают фатальную аварию от тех, кто бегает кругами и пытается восстановить рассыпавшуюся инфраструктуру - DRP. Вот о том, как правильно написать Disaster Recovery Plan я сегодня вам и расскажу.
Взгляд НСИ на VBA в Excel и не только
Салют! На связи Ганзюк Владимир. Тружусь инженером по нормативно-справочной информации (НСИ) в компании Bimeister.
Хочу поделиться с вами опытом работы с Excel: расскажу, как можно ускорить выполнение рутинных задач при работе с составлением наименований согласно нормативно-технической документации (НТД).
Собираем DOCX из ADOC
Статья про то, как можно собрать docx-файл из git(adoc)-дерева.
По мнению автора, статья может быть интересна тем, кто хочет уйти от стандартных методов хранения документации. Ведь техническая документация всегда лежит на стыке кода, практик devops_а и нас, простых читателей.
Как HRlink сэкономил 6,5 млн в год на внедрении базы знаний
Расскажу, за счет чего поддержка не пробила дно, а стабильно вывозит 25 000 обращений в месяц, экономя при этом 6,5 млн рублей в год. Расскажу, как мы этого добились.
Хотели велосипед, а получили мопед по цене автомобиля: как управлять изменениями и ожиданиями заказчика
Делюсь своим опытом организации процесса управления изменениями RFC (Request for Comment) и подключения к нему заказчика. Это помогает не разочаровываться в продукте, сравнивая ожидания с реальностью, и исключает ситуации, когда задачи приходят со сроками «вчера». В тексте вы найдёте пошаговую инструкцию по подготовке к проектированию и разработке продукта, а также лайфхаки для решения возможных проблем. Статья будет полезна тем, кто работает на переднем крае команды разработки: руководителям проектов, аналитикам и Product owner.
Вклад авторов
beliakov 267.0DemetrNieA 189.0Nurked 187.0AKlimenkov 179.0makushevkm 138.0tatdudo 121.0volkov-kb 110.0Spiralhead 96.0ringova 86.2fiddle-de-dee 86.0