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

Всем привет! Меня зовут Татьяна Цикунова, я работаю системным аналитиком уже более 5 лет и за это время получила опыт в 4 проектах, а также долгое время имела честь онбордить новых аналитиков в разных командах. 

Тема онбординга важна для любого IT-специалиста. Поэтому сегодня разберёмся, как провести онбординг системного или бизнес-аналитика в новую команду не только успешно, но и эффективно.

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

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для it-команд. В этой статье я расскажу, как мы решали довольно очевидную проблему связи знаний и случайно сделали штуку, у которой даже есть отдельное название.

Когда говорят «Semantic Wiki», обычно представляют что-то сложное: онтологии, RDF, графы и так далее. Но можно ли это сделать как-то проще и для людей? В этой статье разберем:

• Что делает вики «семантической».

• Как свойства и представления в Gramax решают эти задачи.

• Как быстро создать семантическую структуру, связать с ее помощью статьи и посмотреть по ним отчеты.

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

Сотрудники и студенты Московского Энергетического Института изучили и провели анализ различных способов остановки электрических двигателей, в данном случае мы расскажем вам про метод останова двигателя противовключением.

·         В чем заключается данный метод?

  Данная схема предназначена для быстрой остановки электродвигателя. Она работает таким образом, что, когда мы хотим остановить наш двигатель, вращающийся в одну сторону, мы начинаем вращать его в противоположную таким образом замедляя его движение и приводя к останову. Таким образом противовключение значит, что мы включаем наш двигатель в обратную сторону – в противоположную.

Привет, Хабр! Я являюсь тестировщиком компании TravelLine. Мы разрабатываем единую систему для гостиничного предприятия, которая помогает отелям, санаториям и другим средствам размещения автоматизировать свои бизнес-процессы. В этой краткой статье (я бы назвал её отзывом на инструмент) я не буду рассказывать о концепции встреч в формате “3 Амиго”, хочу лишь поделиться личным опытом внедрения таких сессий в процесс разработки требований в одной из своих команд.

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

Наш воркфлоу выглядел следующим образом:

Как быстро пролетели шесть месяцев! Продолжаю рассказывать о том, как решил сделать пет-проект: НормЦРМ. Сам я ремесленник-одиночка и пользовался ограниченным набором инструментов для ведения дел: Google Таблицы, да Windows-заметки. Решил все эти данные свести воедино в рамках собственной црмки.

Я не разработчик, а проектировщик интерфейсов (UX/UI-дизайнер). Опыта в программировании совсем немного. Поэтому пет-проект был мне особенно интересен. Я уже двадцать лет готовлю проектную документацию для других — а в этот раз для себя.

Сейчас расскажу, что сделал по проекту за последние полгода, как мне в этом помогли ChatGPT и Codex, как изменился процесс работы и почему это поначалу было скучно и грустно — а теперь с каждым днём жизни проекта всё интереснее и веселее.

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

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

Статья получилась большая, поэтому можно сразу сориентироваться по плану:

●      предпосылки и типичные проблемы в командах аналитиков;

●      подготовка к делегированию или масштабированию задач;

●      шаблоны для описания артефактов;

●      технология дизайна;

●      план внедрения технологии дизайна;

●      распределение артефактов по ролям в команде.

Что было интересного в 2025 году по безопасности ИИ? Помимо развития AI-агентов и их протоколов, гардрейлов, и появления фреймворков, для российского рынка важно отметить появление нескольких новых официальных документов. О них и поговорим, так как я искренне считаю, что они выводят нашу нормативно-правовую базу на уровень одной из самых развитый и проработанных в мире. Но этот пост - не просто обзор)
Я расскажу и о своих соображениях о том, как управлять доступом AI-агентов, данными для GenAI-систем, и уязвимостями таких систем.

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

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

Давайте разберемся, как сделать ее союзником, а не врагом.

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

Меня зовут Никита Бугуев — я бэкенд‑разработчик на Python в команде, которая разрабатывает открытое банковское API и пытается захватить контроль над всеми интеграциями наружу. В статье расскажу, как мы написали свои велосипеды для вебхуков и какие грабли собрали по пути.

Данный материал создан учеными Национального исследовательского университета "МЭИ" (НИУ "МЭИ") кафедры Автоматизированных систем управления тепловыми процессами (АСУТП). Представленные сведения основаны на результатах исследований и отражают профессиональное мнение авторов.

            Схема пуска и стопа с самоподхватом нужна для того, чтобы при нажатии на кнопку «Пуск» на контакторе, можно было не задерживать эту кнопку. При этом схема продолжит работать, так как контактор подхватил сигнал и теперь напряжение никуда не уйдет, пока не будет нажата кнопка «Стоп». Такая система позволяет надежно и эффективно управлять двигателем.

Лучший способ похоронить базу знаний — это спустить её сверху, обязать всех искать там информацию и бросить в таком состоянии. БЗ только тогда чего-то стоит, когда она вовремя пополняется и актуализируется, когда в ней на конкретный вопрос находится конкретный ответ, когда за информацией не надо бегать по куче ссылок, выискивая крупицы смысла. Когда база знаний не утрачивает своей пользы при росте числа пользователей — как авторов, так и читателей. Только тогда принятие решений на основе знаний будет точным, онбординг новичков будет проходить без задержек, а саппорт будет укладываться в SLA.

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

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

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

Одной из частых задач документирования является документирование баз данных. Это может быть документирование PostgreSQL, Clickhouse, MongoDB и других баз данных. Их все объединяет один простой факт — такую документацию сложно делать вручную. В этой статье я разберу, как создать описание базы данных PostgreSQL с помощью утилиты tbls.

Ситуация: открываете базу знаний и понимаете — что-то с ней не так, и каждый раз кто-то приходит с одними и теми же вопросами. Вы — тимлид/техлид/knowledge-менеджер, который знает ответы на все вопросы. Но времени на работу не остаётся как раз из-за разрешения всяких мелочей. Знакомо?

Привет, Хабр! Меня зовут Анастасия Граф. Я руковожу отделом разработки технической документации в Maxim Technology — компания делает Ride Tech сервис для такси Maxim. Мы первыми в России запустили цифровую платформу. Этот материал готовился по мотивам доклада для TeamLead Conf.

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

Markdown — популярный и удобный язык разметки, но это также и очень ограниченный формат. Поэтому задача написания в Markdown сложной технической документации по ГОСТ, научной статьи с автоматической настройкой оформления для заданного издательства или хорошо оформленного онлайн-учебника может показаться неосуществимой. В этой статье рассмотрим способ работы над научно-техническими статьями и книгами в формате Markdown на основе подхода Docs as Code с учётом строгих ограничений на оформление, используемый Петром Советовым и мной при подготовке учебных материалов в РТУ МИРЭА.

Способ заключается в применении утилиты pandoc для построения дерева абстрактного синтаксиса (AST) Markdown-документа с последующим переписыванием AST набором фильтров на Lua и трансляцией AST в форматы docx и pdf, соответствующие ГОСТ, а также в диалект markdown, совместимый с mdBook, для генерации онлайн-учебника.

Онлайн-версии книг, написанных с использованием описанного подхода, и репозитории с исходным кодом книг опубликованы на GitHub и GitHub Pages: книга по конфигурационному управлению, книга по разработке кроссплатформенных программмных систем.

У многих компаний, которые создают облачные SaaS-решения, рано или поздно может возникнуть запрос от пользователей: «Можно ли поставить ваш продукт у нас на собственной инфраструктуре?», то есть появляется запрос на on-prem версию. Но не каждый SaaS-продукт сразу готов к такому сценарию: чтобы он работал у клиента, его нужно корректно внедрить в инфраструктуру заказчика.

С таким вопросом столкнулась и компания Skillaz, которая предоставляет HR-платформу для автоматизации управления персоналом. Мы подключились к Skillaz, чтобы помочь выстроить этот процесс — от инфраструктурной части до организационной. Ниже мы расскажем, как формируется внедрение на железе клиента, а не в привычных и удобных для подобных развертываний облаках. А также о том, как мы вместе превращали эти внедрения в воспроизводимый и управляемый сценарий.

В статье разбирается техническая реализация SQLize Embed — легковесного JS-компонента для создания интерактивных песочниц прямо в тексте технических статей. Автор подробно описывает архитектуру решения: от использования MutationObserver для инициализации редакторов на фронтенде до обеспечения безопасности и изоляции запросов в Docker-контейнерах на бэкенде.

Вы узнаете, как реализована поддержка более 20 СУБД (включая PostgreSQL 18, MS SQL 2025 и Oracle 23ai) и как встроить «живые» примеры кода в свой проект всего парой строк HTML.

Всем привет! Я Елена Шустерман, ведущий писатель в РТЛабс. Более 20 лет работаю в сфере ИТ. Есть большой опыт работы программистом и аналитиком, сейчас я технический писатель.

Расскажу, как при подготовке отчётной документации оптимизировать работу с документами, в том числе в MS Word с использованием возможностей MS Excel. А ещё как упростить себе рутину при сборке списков сокращений и определений.

Делю статью на две части. Эта часть — первая. Позже будет вторая часть с описанием других возможностей расширенного фильтра MS Word.

Данный материал создан учеными Национального исследовательского университета «МЭИ» (НИУ «МЭИ») кафедры Автоматизированных систем управления тепловыми процессами (АСУТП). Представленные сведения основаны на результатах научных исследований и отражают профессиональное мнение авторов.

Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. В динамичных проектах тест‑кейсы часто превращаются в «мёртвый груз»: они быстро теряют актуальность из‑за изменений в функционале, интерфейсе или бизнес‑логике. Результат — устаревшая документация, на поддержку которой тратится больше времени, чем на реальное тестирование. Разберём принципы и техники, позволяющие создавать долговечные тестовые артефакты.