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

В статье рассматриваются особенности патентование решений в сфере информационных технологий в РФ в 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 — решения СберТеха для управления контейнерными приложениями.

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

Нейросеть может помочь составить договор быстрее и безопаснее. Юридические организации все чаще признают пользу ИИ в правовой работе. ABA в чек-листе для юрлиц пишет, что нейросети используют для писем, резюме документов, правового анализа и анализа договоров, но разница между пользой и риском зависит от выбора инструмента, контроля и проверки результата. 

Мы подготовили 5 промптов, которые помогут составить договор через нейросеть осознанно — рабочий документ под конкретную сделку.

Практически в каждой свой статье, в которой прямо или косвенно идёт речь о важности соблюдения Закона о персональных данных, я упоминаю риск получения административного штрафа по ст. 13.11 КоАП РФ. Теперь давайте поговорим не про «очередные страшилки для бизнеса», а про реальную судебную практику.

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

Основная позиция ФЫВА — ОЛДЖ считается базовой во всех известных мне системах. Однако последующее движение рук и пальцев может значительно отличаться.

Привет, Хабр! Сегодня мы часто говорим про разные тренды в разработке — ИИ‑агентов, тестирование на ранних стадиях, прослеживаемость изменений, автоматизацию пайплайнов… Все эти тренды звучат убедительно, пока не упираются в реальность: требования лежат в на общих дисках, схемы — в картинках, контракты — в разных версиях, а история изменений размазана по инструментам.

Что делать с этим?

Лев Немировский, руководитель направления по развитию инструментов внедрения ПСБ, рассказал, чем полезен в этом случае подход GitOps и о том, как и в каких случаях это может упростить жизнь команде.

Некоторое время назад я обнаружил набор скриптов, помогающих собирать операционную систему GNU из исходников. К моему сожалению, в исходниках не содержалось указание на лицензию, под которой они распространяются. Я написал их автору, что отсутствие указания лицензии делает скрипты проприетарными, а это противоречит духу проекта GNU. Ответа я не получил…

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

Ещё двадцать лет назад понятия свободного программного обеспечения и открытых исходных текстов были неведомы чуть менее чем всем пользователям компьютеров, да что там говорить, самим программистам. Linux, BSD, OpenOffice, Gimp были диковинкой и вызывали удивление. Но Мир изменился. Опубликованным исходникам нет счёта, и мало кому из, по крайней мере, программистам, нужно объяснять, что это такое. Мир изменился, но люди нет. Невежество и чванство никуда не делись. Изучая чужие разработки в исходниках, не перестаю замечать, как много проектов игнорируют необходимость указания лицензии и копирайта.

Почему указание лицензии важно? Лицензия даём нам, как пользователям программ, так и программистам, изучающим чужие исходные тексты и использующим их в своих программах, чётко обозначенные права (разрешения) и ограничения (запреты). Отсутствие же лицензии означает одно: вам не предоставлено никаких прав, вообще.

Давайте разберём типовые ошибки авторов программ, и поджидающие их пользователей проблемы.

У нас было 120 процессов, 9 областей управления, более 100 авторов из 60 компаний, 3 ветки на каждый репозиторий и ещё по одной на каждую задачу, AI-агент, таск-трекер, толстый клиент редактора и три портала документации. Не то чтобы всё это нам было нужно, чтобы описать методологию управления в ИТ. Но когда однажды начинаешь собирать серьёзную базу знаний — возникает тенденция разогнаться так далеко, как только сможешь.

Единственное, что меня по-настоящему беспокоило — это конфликты слияния. Нет в мире ничего беспомощнее и безответственнее, чем методолог, пытающийся разобраться, что такое конфликт слияния. И я знал, что скоро мы в эту дрянь попадём.

Если вы когда-нибудь пробовали в одиночку причесать чужой Word-документ, в котором двадцать комментариев на полях и три уровня правок разными цветами — вы поймёте, с чего начнётся эта история. Только умножьте на 100 авторов из 60 компаний и 120 процессов. И добавьте ноль бюджета: всё это люди делают по вечерам, потому что им не всё равно, как будет выглядеть управление ИТ в стране.

Это не туториал и не обзор инструмента. Это история о том, как я полтора года уговаривал себя, что Wiki — нормальный выбор, потом ещё полгода уговаривал команду, что пора слезать. И как после переезда на Docs as Code половина того, чего я ждал, не случилась, а половина случилась не так. И почему мне всё равно нравится, что вышло.

Разбираем, как в отделе документации построили LLM-агента для автоматизированного перевода Markdown-документации. Архитектура, пайплайн, валидация, работа с Ollama, OpenWebUI и Qwen, плюсы и ограничения подхода. 

С 2024 года в российской промышленности менялся подход к инвестициям в ИИ. Если еще недавно компании были готовы экспериментировать с цифровыми инициативами «на вырост», то теперь инвест‑бюджеты сокращены (а кое‑где просто порезаны), при этом требования к проектам стали кардинально жестче. Деньги выделяются на то, что дает измеримый эффект «здесь и сейчас» — на проекты с горизонтом более года года советы директоров финансирование просто не дают. При этом направлений, где ИИ окупается за 6–12 месяцев, немного, но они есть. И эта статья — про обобщение проектного опыта команды SSP SOFT в промышленности.

Если вы из тех владельцев сайтов / интернет-сервисов, которые:
• взяли образец пользовательского соглашения из интернета 
• разработали пользовательское соглашение самостоятельно без привлечения юриста
• считаете, что публикация пользовательского соглашения на сайте – это формальность
то этот материал точно для вас!

Благодаря ему вы сможете:
01 понять, в каких случаях нужно использовать пользовательское соглашение, а в каких иной документ
02 понять реальную цель и ценность данного документа
03 проверить, насколько хорош ваш документ с юридической точки зрения и требуется ли его замена / доработка.