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

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

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

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

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

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

Всем привет!

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

Сегодня я предлагаю перейти от слов к делу. Я проанализировала работу команды из четырех архитекторов контента за один месяц и подготовила детальный разбор без приукрашивания: покажу, как описанные ранее функции воплощаются в жизнь, к каким результатам пришли за 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-решений можно запатентовать в РФ), раскрываются особенности требований к юридической и технической составляющей патентов.

Документацию не читают? Увы, но это действительно так. Достаточно вспомнить своё типичное поведение при покупке нового прибора: сначала включим в сеть, а уже когда не заработает, прочтём инструкцию.
Давайте вместе разберёмся, почему так происходит и что с этим делать.
Я — Мария Киселёва, начальник отдела разработки технической документации в РТЛабс. 12 лет в технической документации научили меня, что хороший текст начинается не с красивых слов, а с жёстких договорённостей. Глоссарии, стайлгайды, шаблоны и отказ от двусмысленности — без этого любая инструкция превращается в «письмо из Простоквашино»: то лапы ломит, то хвост отваливается :)

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

Всем привет! Я Антон, системный аналитик из команды трансграничных переводов в Uzum Fintech, и от меня уже два месяца ждут текст по результатам выступления на внутреннем митапе.

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

Как продакт-оунер в Exante выпускает сложные фичи в два раза быстрее благодаря AI — и почему продуктовые решения по-прежнему принимает сама.

Зачем регистрировать программу?

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

Однако, у Роспатента есть такая особенная государственная услуга как "Регистрация программы для ЭВМ", под ней подразумевают по сути своей депонирование (помещение кода в репозиторий с указанием декларируемых данных автора и даты помещения).

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

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

Команда CRM-платформы «Модус» от ИТ-холдинга Т1 переводит руководства пользователя и администратора из Confluence в Docs as Code. Задача — связать документацию с релизами продукта, сократить ручную сборку и сделать так, чтобы аналитики могли писать в Markdown без боли.

Подробно об этом мы поговорили с Екатериной, владельцем продукта «Модус», и Еленой, ведущим аналитиком, которая драйвила переход на новый процесс. В статье раскроем: что не работало в старой схеме, как команда выбирала инструмент, как прошел пилот и какого эффекта удалось добиться.

Всем привет, меня зовут Катя, я развиваю Gramax. Уже несколько месяцев мы делаем ИИ-агента для работы с текстом и документацией, поэтому много смотрим на реальные кейсы в разных компаниях. Один из самых сильных принесли друзья из SellOut+. Они делают аналитические системы для фармы и FMCG, быстро пробуют новые подходы и в какой-то момент взяли первую версию функции агентов в Gramax.

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

Простой туториал, о том как начать работу с $mol. Приятная новость для фронтендеров - настраивать придется по минимуму, обещаю

Если вы хоть раз программировали контроллер на реальном объекте, вы знаете этот ритуал. Перед вами лежит PDF на 180 страниц — «Техническое задание на разработку АСУ ТП». Рядом — Excel с IOLIST на 600 строк. Ваша задача, прежде чем написать первую строчку кода на ST или LAD, — разобраться, что куда относится: какие сигналы принадлежат вентиляции, какие — насосной станции, что за уставки у каждого узла, где аварии, где режимы. Это занимает полдня в лучшем случае, день — в среднем.

Именно эту боль закрывает PLC Smart Splitter — новый инструмент от российской студии plcstudio, опубликованный в открытом доступе на GitVerse и GitHub.

Я техписатель, чьи тексты принимают за ИИ-шные. И вот что выяснилось…

Так случается: пишешь текст сам, вычитываешь, вычищаешь, убираешь воду – а потом коллега спрашивает: «Это ChatGPT?»

И снова привет, Хабр! Я Артем Клещев, технический писатель в СберТехе.

Недавно я рассказал, как построить удобную архитектуру репозитория продукта и вести единый источник в Docs-as-Code вместо разрозненных комплектов документации. Сегодня хочу поделиться тем, как мы добавили к такой архитектуре новый для нас, модифицированный процесс ведения Git — Feature Branch Workflow — и значительно сократили время подготовки документации.

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

Объяснять буду на примерах из документации продукта Platform V DropApp — решения СберТеха для управления контейнерными приложениями.