home.social

#техническая_документация — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #техническая_документация, aggregated by home.social.

fetched live
  1. Structurizr Cloud закрылся 30 сентября. Что осталось и куда переносить C4-модели

    30 сентября 2026 года облачный сервис Structurizr прекратил работу. Для команд, которые хранили там C4-модели, это не просто закрытие ещё одного SaaS: вместе с хостингом исчез привычный способ публиковать архитектуру, раздавать доступ коллегам и встраивать диаграммы в другие системы.

    habr.com/ru/articles/1098118/

    #архитектура_по #системная_архитектура #техническая_документация #c4 #selfhosted #structurizr #architecture_as_code #c4_model #архитектурная_документация #structurizr_alternative

  2. Как писать текст для нейросети, чтобы она сослалась на сайт: в 60 ответах она чаще брала абзацы от 30 слов

    Допустим, вы ведёте документацию или блог и хотите, чтобы куски текста попадали в ответы ChatGPT, Perplexity или Алисы AI. Я проверил на ответах Perplexity простой совет — не начинать абзац с «это», «он» или «поэтому». Такие начала одинаково редки у абзацев, которые нейросеть взяла, и у тех, что пропустила. Заметно отличается другое: взятые абзацы длиннее. Совет появился потому, что нейросеть с поиском берёт со страницы не всю статью, а один-два абзаца, и они должны быть понятны без соседей. Но если чистить только «это», можно потратить вечер на правку и не изменить ничего.

    habr.com/ru/articles/1094484/

    #python #geo #техническая_документация #chatgpt #llm #perplexity #ответы_нейросетей #как_писать_текст_для_нейросети #попасть_в_ответы_нейросетей #длина_абзаца

  3. Сравнительный анализ рамановских усилителей от РТК-Сервис. Вендор Т8

    Друзья, команда техподдержки РТК-Сервис стартовала серию разборов рамановских и гибридных усилителей разных поколений и производителей. Рассмотрим основные технические и прочие характеристики от популярных отечественных и западных вендоров. Если хотите освежить память, что за зверь такой Раман, вам сюда . А мы начнем с российского DWDM-оборудования Т8.

    habr.com/ru/companies/rtk_serv

    #телекоммуникации #телекоммуникационное_оборудование #телекоммуникации_и_связь #dwdm #усиление_сигнала #сетевое_оборудование #сетевые_технологии #сетевая_инфраструктура #техподдержка #техническая_документация

  4. Управляем VMware Cloud Director через MCP-сервер: от API к текстовым командам

    Каждый раз управляя облаком, мы совершаем повторяющиеся действия: создаем сеть, виртуальную машину, настраиваем правила Firewall и NAT… Все это интересно и удобно первые несколько раз, а потом тебя начинает напрягать не самый отзывчивый интерфейс и кликов по UI набегают сотни, а то и тысячи в месяц. Но ведь можно же делегировать все эти рутинные приседания ИИ-агенту? Да, именно так мы и сделали у себя в Облаке VMware, но спокойствие, в этой статье мы его вам продавать не будем. Здесь расскажем тем, кто администрирует свой дата-центр или облачный тенант на базе VMware, как прикрутить к нему Claude Code, Open Code или любого другого MCP-совместимого агента без написания собственной обертки над API. Ну и само собой, мы сделаем это так, чтобы разбушевавшийся агент не смог наворотить лишнего, даже если очень захочет.

    habr.com/ru/companies/cloud_ru

    #техническая_документация

  5. RAG, поиск и LongContext: почему сложные пайплайны не всегда нужны

    В 2023 году RAG был единственным способом засунуть знания в LLM — контекстное окно было маленьким, часто были галлюцинации. RAG постепенно стал одной из самых популярных технологий, чтобы получить базу знаний, по которой можно искать данные через натуральный язык. Но с другой стороны — RAG-пайплайн тяжёлый и трудозатратный. Компания хочет чат по своей документации. Разработчик говорит: нужен пайплайн — чанкинг, эмбеддинги, векторная база, реранкер. Два-три месяца работы плюс сервис, который надо вечно поддерживать, ради 400-страничной документации. И всё это занимает месяцы, тратит ресурсы ради не такой уж и большой выгоды. Сегодня многие модели держат 1M токенов, а то и больше, а в это окно контекста чаще всего спокойно влезает вся документация. Но если не влезет — то обязательно ли сразу строить весь RAG самому? А как понять, когда есть альтернатива RAG, а когда нет? В этой статье мы разберём, почему RAG стал выбором по умолчанию (и почему это было оправдано), посмотрим, как падает качество при Long Context, сравним подходы и узнаем, что, как и когда использовать.

    habr.com/ru/companies/bothub/a

    #документация #техническая_документация #RAG #LLM #longcontext #AI #ИИ #arxiv #эмбеддинги #поиск

  6. Как мы автоматизировали перевод технической документации через инструменты вокруг модели

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

    habr.com/ru/companies/bitrix/a

    #техническая_документация #документация #технический_писатель #перевод_документации #машинный_перевод #локализация #llm #python #markdown #автоматизация

  7. Умный калькулятор для техписателей: как мы сбалансировали нагрузку в команде с помощью ИИ

    Всем привет! Меня зовут Евгения Красильникова, я технический писатель в команде Russtech (разработчики IT-решений ведущего российского оператора рекламы вне дома Russ, входит в RWB). Сегодня я хочу рассказать, как мы пришли к единой системе оценки задач и с помощью нейросети создали удобной инструмент, который помог ввести подсчет наших трудозатрат и заметно оптимизировал рабочие процессы.

    habr.com/ru/companies/rwb/arti

    #техническая_документация #документация_проекта #искусственный_интеллект #планирование_ресурсов #трудозатраты

  8. Айсберг по Confluence: открываем спрятанное на самом видном месте

    Привет, Хабр! На связи старший технический писатель РТЛабс Фёдор Пеплин. Команда РТЛабс — коллектив из 2500+ человек. Объём контента для такого количества сотрудников может исчисляться миллионами знаков, а количество пространств, используемых для хранения информации и работы с ней, — несколькими сотнями. При этом всем нам нужно хранить информацию и обмениваться ею. Один из инструментов, который мы используем для этого, — Atlassian Confluence . В этой статье я поделюсь некоторыми лайфхаками, которые позволят значительно упростить работу с ним.

    habr.com/ru/companies/rtlabs/a

    #технический_писатель #простанство #confluence #макросы #метки #шаблоны #оформление #техническая_документация

  9. Мы мигрировали сотню страниц документации через MCP-сервер, а не скриптами

    У каждого опубликованного сайта GitBook уже есть MCP-сервер. Мы узнали об этом случайно и вместо конвертеров просто дали агенту ходить в документацию напрямую — сотня страниц переехала на Diplodoc за четыре дня. Что агент сделал сам, где проходит граница его возможностей и какие десять вещей пришлось доделывать руками.

    habr.com/ru/articles/1071650/

    #MCP #AIагенты #документация #docsascode #Diplodoc #GitBook #миграция #markdown #техническая_документация #YFM

  10. Browser Policy Manager: документация

    К релизу Browser Policy Manager 0.9.5 подготовлен документационный портал: четыре руководства на шести языках, локальный поиск, контекстная помощь из интерфейса и фундамент для будущего безопасного RAG-помощника. Рассказываю, как он устроен и почему документация здесь — часть безопасной работы с политиками Firefox.

    habr.com/ru/articles/1069842/

    #browser_policy_manager #firefox_enterprise #policiesjson #управление_политиками_браузера #техническая_документация #dita #локализация #rag #MPL20

  11. Реестр отечественного ПО без юридического квеста: инструкция для авторов решений 1С

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

    habr.com/ru/companies/infostar

    #1С #Реестр_отечественного_ПО #российское_ПО #Минцифры #разработка_1С #программный_продукт #техническая_документация #правообладатель #регистрация_ПО #импортозамещение

  12. Как мы показываем клиентам документацию по проекту из приватного репозитория, не пуская их в репозиторий

    Сразу дисклеймер: это рассказ про инструмент, который мы написали для себя и используем каждый день. Ссылку дам в конце, продавать не буду — расскажу про проблему и как её решали, потому что упираемся в неё, возможно, не только мы. За последний год мы переписали почти всю проектную документацию в markdown и положили в тот же git, где лежит код. Причина простая: после перехода на Cursor и Claude Code так было удобнее работать. Модели нормально обрабатывают markdown и не лопатят десятистраничный google-док, диффы видно в PR, доки лежат рядом с кодом, который описывают. Всегда можно обратиться к инфе по проекту, внести обновления - короче пользоваться документом, а не хранить его для красоты. И тут вылезла проблема, о которой лично мы заранее не подумали: документацию читает не только тот, кто её пишет. Её читают клиенты, менеджеры, дизайнеры, эйчары. А они в репозиторий не полезут никогда. Дать клиенту доступ в GitHub/GitLab — так себе затея сразу по нескольким причинам: там лежит то, что ему видеть не надо, это лишний разговор про безопасность, да и сам интерфейс гитхаба человека не из айтишки отпугивает. Плюс требуется регистрация. В итоге мы делали то же, что, по-моему, делают все: копировали markdown в google docs, чтобы клиент мог прочитать и покомментировать, а потом при каждом изменении заново выгружали и сводили комментарии руками. Год так жили. Что смотрели, прежде чем пилить своё: GitBook и Mintlify хотят, чтобы ты писал в их редакторе. Ради шеринга пришлось бы бросить тот самый workflow, ради которого мы в git и переехали. Плюс ценник.

    habr.com/ru/articles/1061946/

    #документация #docsascode #markdown #git #MCP #GitHub #GitLab #техническая_документация #комментарии_к_документации #AIагенты

  13. Можно ли аналитику в 2026 году положиться на ИИ и агентов или ещё нет?

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

    habr.com/ru/companies/alfa/art

    #системный_анализ #системный_аналитик #AIагенты #ИИ_в_аналитике #Use_Case #OpenAPI #APIспецификация #Confluence #Cursor #техническая_документация

  14. Анатомия облачных дыр: почему растет стоимость облака

    Закрытие периода. Вы открываете инвойс: видите счет за облако и ловите приступ паники от увиденной цифры. Обещали же, что будет меньше, почему так много? Дальше начинается охота на ведьм: кто-то из инженеров поднял лишнее, кто-то забыл выключить виртуалку. Может показаться, что это единичный случай, аномалия у одной-двух компаний. А мы, как провайдер, скажем: это повторяющийся паттерн. В статье расскажу, почему.

    habr.com/ru/companies/cloud_ru

    #finops #devops #техническая_документация

  15. Kafka без брокеров: как я из художественного текста сделал современную техническую документацию

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

    habr.com/ru/companies/pt/artic

    #ии #языковые_модели #техническая_документация #llmмодели #llm #кафка #промпт

  16. Как ИИ навёл порядок в инженерном хаосе прототиписта: кейс с кабельной разводкой

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

    habr.com/ru/articles/1044598/

    #искусственный_интеллект #notebooklm #прототипирование #промышленная_инженерия #кабельная_разводка #техническая_документация #компьютерное_железо #голосовой_ввод #автоматизация #инженерный_хаос

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

    Я техписатель, чьи тексты принимают за ИИ-шные. И вот что выяснилось… Так случается: пишешь текст сам, вычитываешь, вычищаешь, убираешь воду – а потом коллега спрашивает: «Это ChatGPT?»

    habr.com/ru/articles/1043516/

    #технический_писатель #техническая_документация #ИИтексты #генеративный_ИИ #авторский_стиль #стилометрия #AIдетекторы #ChatGPT #контент #редактура

  18. Как мы в отделе документации создали LLM агента для автоматизированного перевода с английского на другие языки

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

    habr.com/ru/companies/hostkey/

    #LLM #автоматизация_перевода #техническая_документация #Python #валидация #Markdown #OpenWebUI #Qwen #оркестрация #hostkey

  19. Почему без архитектора контента невозможно масштабировать документацию компании

    Привет, Хабр! Меня зовут Алиса Комиссарова, я руководитель отдела автоматизации и поддержки документирования Positive Technologies. Если вы работаете техническим писателем, скорее всего, ваши задачи ограничиваются разработкой пользовательской документации для одного продукта или направления. Вы привыкли пользоваться популярными инструментами документирования, знаете их основные функции и умеете писать и публиковать руководства. Но что меняется, когда перед вами стоит задача поддерживать документацию для всех продуктов компании, охватывающую множество подсистем, версий, платформ, аудиторий и все этапы жизненного цикла продуктов. Достаточно ли будет знания руководства по стилю и общих принципов написания текстов? Еще десять лет назад команде технических писателей Positive Technologies поставили именно такой вызов — компания активно росла и требовалось построить единую систему документирования. В этой статье я собрала практические рекомендации, которые помогут вам перейти от «локального» к «корпоративному» подходу, а также понять, для чего нужна роль архитектора контента.

    habr.com/ru/companies/pt/artic

    #управление_продуктами #техническая_документация #cms #docasacode #контентстратегия

  20. [Перевод] Man pages, которыми хочется пользоваться: как сделать их удобными

    Man-страницы часто остаются главным способом разобраться с CLI-инструментом, но в реальной работе быстро найти нужную опцию или пример бывает непросто. В статье разберем практичные приемы, которые делают такую документацию удобнее: сводки опций, группировка по сценариям, шпаргалки, примеры, таблицы и нормальная навигация в HTML-версиях. Всё на примерах Git, rsync, strace, curl, OpenBSD и GNU. Перейти к статье

    habr.com/ru/companies/otus/art

    #man_pages #manстраницы #документация #терминал #CLI #Linux #Unix #примеры_команд #техническая_документация

  21. От хаоса к гармонии: роль ИИ-ассистента в проектной трансформации

    Работая над большими проектами рано или поздно сталкиваешься с типовой проблемой: меняются команды, приходят новые люди, требования плывут, правки копятся в разных файлах и комментариях в Confluence. В одном разделе — одна версия ролей, в другом — другая. Описания функций разорваны, шаблоны не соблюдаются, а критичные решения записаны «на полях». Так и рождается хаос. Не потому, что кто-то плохо работал, а потому что в большом проекте с долгой жизнью и множеством участников документация неизбежно расползается. Поэтому мы сделали своего ИИ-ассистента «ДокАрхитектор» — и в этой статье расскажем, как обучить нейросеть корпоративным стандартам, сократить время проверки ТЗ с 10 часов до 3–4 и перестать бояться унаследованных проектов.

    habr.com/ru/companies/nlmk/art

    #ииассистент #архитектура #техническая_документация

  22. Как организовать профессиональное сообщество техписателей в компании. Часть 1

    Привет! На связи Наталья Нефедова — менеджер продукта и head of сообщества техписателей в

    habr.com/ru/companies/cloud_ru

    #техническая_документация #сообщество #карьера_в_ит #технический_писатель

  23. Нужен ли синопсис технической документации? Личный опыт разработки

    Разработка документации на создаваемые ИТ-продукты – это не только «правила хорошего тона», но и насущная необходимость. Ведь без технического задания невозможно зафиксировать требования к продукту, без руководства пользователя сложно грамотно продуктом пользоваться, без технической документации, описывающей продукт, сложно будет искать и исправлять ошибки и проводить необходимые доработки, когда в них возникнет необходимость, и т.д. Обычно документацию делают по одному из двух путей – либо используют стандарты, описывающие требования к составу, структуре и содержанию документов (например, ГОСТ 19-й и 34-й серий – ЕСПД и КСАС), либо самостоятельно разрабатывают документ, создавая его на основе собственного опыта или по существующим образцам, в т.ч. взятых из интернета. Но как же её правильно сделать? Мой ответ - начинать надо с синопсиса документов.

    habr.com/ru/articles/1015118/

    #Синопсис #документация #документирование #документация_проекта #разработка_документации #техническая_документация #технический_писатель #техническое_задание

  24. Техпис на зоне: нужна ли свобода при написании документации

    Документацию можно готовить где угодно и как угодно. Писать инструкции в многочисленных CCMS, публиковать сайты через генераторы наподобие Sphinx, применять сложные разметки вроде DITA, вести базы знаний в Confluence или вообще собирать файлы в Word. У каждого инструмента и подхода есть свои плюсы и минусы. Выбор зависит от множества факторов: сложности, требований к результату, потребителя контента, бюджета отдела, объема накопившегося легаси — да и просто моды в профессиональной среде. Но что если посмотреть на вопрос с другой стороны? Что если выбирать и проектировать систему документирования исходя из того, сколько свободы предоставляется техническому писателю? Давайте выкрутим регулятор свободы на максималку сначала в одну сторону, когда техпис не имеет абсолютно никаких рамок и ограничений, а затем в противоположную, когда он тотально несвободен. Какие преимущества будут у каждой из этих двух крайностей и какие выводы можно будет сделать по итогу такого мысленного эксперимента — об этом моя статья.

    habr.com/ru/companies/pt/artic

    #технический_писатель #гайды #техническая_документация

  25. Как писать документацию, которую разработчики будут читать

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

    habr.com/ru/companies/otus/art

    #DEVREL #документация_для_разработчиков #техническая_документация #справочник_API #developer_experience

  26. Реализация принципов BIM для проектирования комплексных технологических процессов на примере ПО «PROMPROEKTOR»

    Введение Привычные нам проекты в области технологии производств обычно представляют собой некую комбинацию из графической составляющей и документации, не имеющие общей базы. Чертежи и документы проекта формируются отдельно друг от друга, что зачастую приводит к высокому проценту ошибок разработчика при переносе данных. Не говоря уже о количестве ресурсов необходимых для формирования документации. ПО «PROMPROEKTOR» – это принципиально новый подход к разработке проектной документации. Можете убедиться в этом сами на примере Процесс сборки технологической схемы... Убедиться

    habr.com/ru/companies/nanosoft

    #bimмоделирование #информационное_моделирование #проектирование #параматическое_моделирование #инженерия #nanocad #нанософт #трубопровод #автоматизация_документации #техническая_документация

  27. Хватит покупать курсы. Соберите портфолио на реальных кейсах. 3 разбора + чек-лист

    Я не умею учиться на курсах. Серьёзно. Когда встала задача собрать портфолио, я пошла в поле: взяла документацию трёх продуктов, прошла путь пользователя, нашла проблемы, посчитала их цену в деньгах и спроектировала решения. Что получилось: 📌 Bpium — документация вокруг функций, а не задач. Готовый шаблон CRM спрятан в подвале сайта. По моей оценке 90% пользователей его не найдут. Предложила задаче-центричную архитектуру и 5 тикетов в Jira. 📌 DirectAdmin — гайд по миграции с cPanel заставляет администратора импровизировать в 80% шагов. Для почты и DNS инструкций нет вообще. Нашла 5 системных проблем, спроектировала структуру Plan→Do→Check и скрипты-помощники. 📌 AmoCRM — разработчик тратит 48 минут вместо 5 на типовую интеграцию. 860% лишнего времени. От 275 тысяч до 3+ миллионов рублей в год оценочных потерь вендора. Предложила раздел со сценариями, визуальные маркеры и перекрёстные ссылки. Моя методика (7 шагов): выбрать интересный продукт, найти сценарий пользователя, пройти путь с секундомером, искать паттерны (не опечатки!), посчитать цену в деньгах, спроектировать решение, упаковать в историю. Главное: я не собирала портфолио под вакансии. Я собирала ответ на вопрос «нравится ли мне эта работа?». А кейсы получились сами. В статье — полный разбор каждого кейса, схемы «было/стало», BPMN-диаграмма (упрощенная), таблица пяти проблем и чек-лист, по которому вы сможете собрать такое же портфолио.

    habr.com/ru/articles/1002700/

    #анализ_документации #портфолио_аналитика #системный_анализ #техническая_документация #информационная_архитектура #карьера_в_IT #как_стать_аналитиком #аудит_документации #метрики_качества_документации #пользовательский_опыт

  28. Четыре провала за четыре года — и четыре человека с AI, которые переписали всё за два месяца

    Четыре года мы пытались переписать нашу платформу для проведения IT-соревнований Codenrock. Четыре раза отступали. На пятый — два разработчика, тестировщик и UI-дизайнер справились за два месяца. У каждого — Claude Code на максимальной подписке. Это история о том, как технический долг накапливает проценты, как мы выбирали стек для новой платформы и что на самом деле значит «80% кода пишет AI».

    habr.com/ru/articles/1000354/

    #react #nextjs #миграция_бд #монолит #aiагенты #aiагенты_в_работе #рефакторинг #техническая_документация #legacyкод #cicd

  29. SDD (Spec-Driven Documentation) – фреймворк для разработки технической документации в репозитории

    По мере роста сложности программных систем документация становится не “сопроводительным текстом”, а инженерным активом, она участвует в принятии решений, согласовании требований, проектировании архитектуры, тестировании и эксплуатации. Однако на практике документация часто создаётся разрозненно, несколькими авторами, в несогласованных форматах. Это приводит к потере целостности и росту транзакционных издержек на коммуникации. В такой распределённой среде параллельно растёт применение AI-ассистирования при подготовке технических материалов, что повышает требования к формализации процесса и контролю качества создаваемых артефактов [1]. В программных проектах техническая документация представляет собой совокупность различных артефактов – требований, сценариев, диаграмм, описаний архитектуры и данных – распределённых между участниками и стадиями жизненного цикла. В условиях активного уточнения целей и решений, особенно на стадии исследовательско-опытных работ (research and development, R&D; далее – R&D), такие артефакты развиваются неравномерно, одни быстро детализируются и пересматриваются, другие остаются на уровне ранних гипотез. Это приводит к утрате целостности документационного контура, возникают противоречия между документами, различается уровень абстракции, дрейфует терминология, а изменения становятся трудно сопоставимыми друг с другом. Одновременно ослабевает трассируемость и затрудняется восстановление причинно-следственной цепочки “исходные данные → допущение → решение → требование → сценарий/диаграмма → проверка”, что увеличивает стоимость ревью и повышает риск ошибочных инженерных выводов [2–5].

    habr.com/ru/articles/996526/

    #техническая_документация #docsascode #SpecDriven_Documentation #спецификации #трассируемость_требований #жизненный_цикл_артефактов #критерии_готовности #управление_неопределённостью #Architectural_Decision_Records #AIагент

  30. Онбординг аналитика в новый проект

    Всем привет! Меня зовут Татьяна Цикунова, я работаю системным аналитиком уже более 5 лет и за это время получила опыт в 4 проектах, а также долгое время имела честь онбордить новых аналитиков в разных командах. Тема онбординга важна для любого IT-специалиста. Поэтому сегодня разберёмся, как провести онбординг системного или бизнес-аналитика в новую команду не только успешно, но и эффективно. Начнём с того, что я кратко расскажу, из чего состоит статья. Мы поговорим о сложностях, с которыми сталкивается аналитик на новом проекте, расскажем лайфхаки для качественного онбординга, а в конце заправим это дело практическим чек-листом.

    habr.com/ru/companies/wildberr

    #онбординг #бизнесанализ #техническая_документация #работа_в_IT #карьера_в_IT #аналитик #системная_аналитика #системный_аналитик

Share on Mastodon

Enter the server where you have an account.