Подготовка технической документации *

«Это же бюрократия, у нас и так всё работает!» / «Документация — это отлично, но у нас есть задачи поважнее» / «Катя, я пришла на проект, а у них ничего, а у нас аудит». Эти фразы и еще много подобного я слышала так много раз, что кажется, время этой статьи пришло).

Мой путь от скептика к как меня в шутку называют коллеги «документатору‑злодею» и мысли о том, зачем же нам все таки нужно уметь и делать проектную документацию.

В инструкции приводится разбор процесса самостоятельной регистрации товарного знака в Роспатенте, в том числе:

1) определения объема правовой охраны товарного знака, подбор товаров и услуг, а также классов МКТУ;

2) особенности подготовки и подачи заявки по шагам через сервис «АРМ Регистратор» (самый надежный способ);

3) расчет и оплата пошлин за каждый этап регистрации;

4) общее описания процедуры: формальная экспертиза и экспертизы по существу;

5) ТОП-10 самых распространенных причин для отказа в регистрации.

Расширение, обработку или модуль для 1С можно зарегистрировать как самостоятельный программный продукт. Однако заявку чаще тормозит не процедура подачи, а неподготовленные документы: неоформленные права, формальное описание продукта, отсутствие инструкции, сайта и понятного жизненного цикла.

На Инфостарте опубликована пошаговая инструкция по включению решений 1С в Реестр отечественного ПО. В статье разобрано, какие продукты можно зарегистрировать, кто вправе подать заявку и как подтвердить, что программа существует, используется, развивается и поддерживается...

В статье рассматриваются ответы на следующие вопросы:

1) Что такое программа для ЭВМ с юридической точки зрения

2) Какие элементы программы для ЭВМ защищаются авторским правом?

3) Кто признается автором программы для ЭВМ?

4) Основные сценарии создания программы и распределения прав на нее

5) Личные неимущественные права автора программы для ЭВМ

6) Имущественные (исключительные) права автора программы для ЭВМ

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

8) Права законного пользователя программы для ЭВМ

9) Ответственность за нарушение прав на программное обеспечение

Привет, Хабр! Меня зовут Мария, я технический писатель в ИнфоТеКС. Представьте: вы запускаете новое приложение, тщательно проработанное, с инновационными возможностями и безупречным дизайном. Пользователь открывает описание функции и встречает ошибки. Например, «Выберите цепочку, содержаЩЕЕ правило».

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

Чтобы такие ситуации не доходили до пользователей, в ИнфоТеКС выстроена система ревью, где ошибки выявляются и исправляются до публикации. Однако мы решили пойти дальше и посмотреть на ошибки системно — чтобы не просто править, а предотвращать их ещё на этапе создания черновика. Именно для этого провели «работу над ошибками» и проанализировали, какие недочёты возникают чаще всего.

В какой-то момент у нас, как и у многих команд, появился соблазн проверить: а можно ли уже не просто просить AI «написать user story», а действительно встроить его в рабочий процесс аналитика? Например, дать агенту вводные по задаче, макеты в Figma, примеры документации и требования к оформлению, и получить на выходе нормальный Use Case, API-спецификацию, PlantUML-диаграмму и аккуратную страницу в Confluence.

Звучит красиво. 

Особенно если вы когда-нибудь вручную переносили сценарии из заметок в Confluence, сверяли шаги с макетами, оформляли вкладки с HTTP-запросами, проверяли коды ошибок и пытались не забыть все вопросы, которые «надо потом уточнить».

В статье расскажу, насколько мы близки к этой утопии — как протестировали работу ИИ в реальном аналитическом процессе в нескольких кейсах: для подготовки Use Case, аналитических артефактов, публикации в Confluence и в работе с Figma.

Документация умирает не от лени сотрудников, а из-за неудобства и потери доверия к данным. Разбираем «два кита» качественной базы знаний: удобство использования и контроль актуальности. Показываем на примере ONLYOFFICE Workspace, как превратить хаос в работающий процесс с помощью шаблонов, ролевой модели доступа и дисциплины пересмотра.

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

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

К моменту, когда заказ доходит до этапа формирования производственной панели, основная проверка данных уже проведена: слои проверены на соответствие технологии, выявлены и исправлены потенциальные проблемы. Теперь перед производителем стоит задача — объединить несколько заказов в одну панель и подготовить её к запуску в производство.

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

В предыдущей статье мы рассмотрели общий процесс работы аналитиков. 

Здесь подробнее остановимся на ключевых этапах подготовки постановки.

Разберём, как именно выстроена аналитическая работа внутри upstream: от преданализа до груминга, и какие практики помогают повышать качество требований и снижать риски на этапе разработки.

Аудит интеллектуальной собственности – это комплексная проверка всех нематериальных активов проекта: патентов и средств индивидуализации (товарных знаков, логотипов, коммерческих обозначений), авторских прав (ПО, дизайн, контент) и ноу-хау.

Главная задача аудита – понять, какие активы есть, кому они принадлежат, насколько корректно оформлены права и нет ли риска использования чужой интеллектуальной собственности.

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

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

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

Всем привет!

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

Сегодня я предлагаю перейти от слов к делу. Я проанализировала работу команды из четырех архитекторов контента за один месяц и подготовила детальный разбор без приукрашивания: покажу, как описанные ранее функции воплощаются в жизнь, к каким результатам пришли за 30 дней. Уверена, что такой отчет позволит вам увидеть реальную ценность архитектора контента для команды и оптимизации рабочих процессов. Запаситесь чашечкой кофе, будет много деталей!

Да не вопрос! На самом деле буквально три месяца назад у меня вообще не было никакого AGENTS.md. Он появился автоматом, когда я устанавливал code-review-graph.

История такая: я каждый день провожу стримы на Ютубе, где показываю процесс разработки своего проекта. И однажды в чатике мне посоветовали воспользоваться code-review-graph, чтобы сэкономить токенов в Codex. Я воспользовался советом, запустил установку через терминал — и в проекте автоматом появилась куча инструкций для разных агентов. Среди этих инструкций оказался и AGENTS.md.

Если вы, как и я поначалу, мало что понимаете в этих терминах и для чего они нужны, — сейчас объясню. А если вы полностью в теме — просто покажу кусочек своей «кухни».

В проекте пользователям регулярно нужно скачивать наборы документов в виде архива. Изначально архивы формировались только из файлов внутри системы, но задача усложнилась, когда потребовалось добавлять внешние источники. В статье я разбираю решение на базе nginx mod_zip и потоковой генерации архива, позволяющее собирать ZIP «на лету» с минимальной нагрузкой на сервер. Также я подготовил простое демо, где можно всё попробовать самостоятельно.

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

Структура статьи

1) В каких случаях программное обеспечение считается служебным?

2) В каких случаях у работодателя возникает обязанность выплатить авторское вознаграждение?

3) Может ли авторское вознаграждение быть включено в заработную плату?

4) Как определяется размер авторского вознаграждения?

5) Наиболее интересные судебные споры в РФ о выплате авторского вознаграждения

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

В текущий момент каждый IT-бизнес должен подавать такие уведомления после начала деятельности:

а) У Вас есть хотя бы один сотрудник или контрагент - физическое лицо?

б) У Вас есть сайт, мобильное приложение или любой программный продукт, в котором лицо указывает свое ФИО или номер телефона? адрес электронной почты при регистрации?

Вы уже оператор обработки персональных данных.

За отсутствие уведомления административная ответственность - ч. 10 ст. 13.11 КоАП РФ, штраф для физических лиц от 50 000 до 100 000, для организаций 100 000 до 300 000 руб.

В этой статье мы расскажем, как развивали систему документации, сохранив за техническими писателями привычный инструмент, какие трудности возникли с производительностью генератора сайта и как в итоге появился портал docs.eremex.ru. При этом привычный инженерам формат PDF мы сохранили: новый портал не заменяет его, а дополняет, и документация по-прежнему доступна в виде файлов для тех, кому так удобнее.

Недавно я решил перечитать рассказ «В исправительной колонии» Франца Кафки. Впервые я познакомился с ним еще студентом — задолго до того, как узнал о существовании профессии технического писателя.

Теперь я смотрел на него совсем иначе — глазами, которые видели тысячи страниц руководств, справочников и API-документации.

И в какой-то момент мне в голову пришла довольно абсурдная мысль: я читаю не просто рассказ Кафки — я читаю почти готовую техническую документацию.

В статье рассматриваются особенности патентование решений в сфере информационных технологий в РФ в 2026 с учетом актуальных требований, в том числе при:

а) патентовании дизайна (интерфейса, изделия)

б) патентовании технических решений: устройств, продуктов, способов (алгоритмов), систем (комплексов).

Приводятся конкретные примеры и описываются ограничения (почему так мало IT-решений можно запатентовать в РФ), раскрываются особенности требований к юридической и технической составляющей патентов.