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

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

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

https://habr.com/ru/companies/hostkey/articles/1037646/

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

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

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

https://habr.com/ru/companies/hostkey/articles/1037646/

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

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

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

https://habr.com/ru/companies/hostkey/articles/1037646/

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

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

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

https://habr.com/ru/companies/hostkey/articles/1037646/

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

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

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

https://habr.com/ru/companies/pt/articles/1035106/

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

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

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

https://habr.com/ru/companies/pt/articles/1035106/

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

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

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

https://habr.com/ru/companies/pt/articles/1035106/

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

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

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

https://habr.com/ru/companies/pt/articles/1035106/

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

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

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

https://habr.com/ru/companies/otus/articles/1029516/

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

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

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

https://habr.com/ru/companies/otus/articles/1029516/

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

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

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

https://habr.com/ru/companies/otus/articles/1029516/

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

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

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

https://habr.com/ru/companies/otus/articles/1029516/

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

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

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

https://habr.com/ru/companies/nlmk/articles/1000324/

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

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

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

https://habr.com/ru/companies/nlmk/articles/1000324/

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

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

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

https://habr.com/ru/companies/nlmk/articles/1000324/

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

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

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

https://habr.com/ru/companies/nlmk/articles/1000324/

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

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

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

https://habr.com/ru/companies/cloud_ru/articles/1014974/

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

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

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

https://habr.com/ru/companies/cloud_ru/articles/1014974/

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

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

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

https://habr.com/ru/companies/cloud_ru/articles/1014974/

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

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

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

https://habr.com/ru/companies/cloud_ru/articles/1014974/

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

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

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

https://habr.com/ru/articles/1015118/

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

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

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

https://habr.com/ru/articles/1015118/

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

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

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

https://habr.com/ru/articles/1015118/

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

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

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

https://habr.com/ru/articles/1015118/

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

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

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

https://habr.com/ru/companies/pt/articles/1013828/

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

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

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

https://habr.com/ru/companies/pt/articles/1013828/

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

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

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

https://habr.com/ru/companies/pt/articles/1013828/

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

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

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

https://habr.com/ru/companies/pt/articles/1013828/

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

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

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

https://habr.com/ru/companies/otus/articles/1005780/

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

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

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

https://habr.com/ru/companies/otus/articles/1005780/

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

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

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

https://habr.com/ru/companies/otus/articles/1005780/

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

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

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

https://habr.com/ru/companies/otus/articles/1005780/

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

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

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

https://habr.com/ru/companies/nanosoft/articles/1003446/

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

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

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

https://habr.com/ru/companies/nanosoft/articles/1003446/

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

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

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

https://habr.com/ru/companies/nanosoft/articles/1003446/

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

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

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

https://habr.com/ru/companies/nanosoft/articles/1003446/

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

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

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

https://habr.com/ru/articles/1002700/

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

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

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

https://habr.com/ru/articles/1002700/

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

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

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

https://habr.com/ru/articles/1002700/

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

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

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

https://habr.com/ru/articles/1002700/

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

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

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

https://habr.com/ru/articles/1000354/

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

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

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

https://habr.com/ru/articles/1000354/

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

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

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

https://habr.com/ru/articles/1000354/

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

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

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

https://habr.com/ru/articles/1000354/

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

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

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

https://habr.com/ru/articles/996526/

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

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

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

https://habr.com/ru/articles/996526/

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

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

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

https://habr.com/ru/articles/996526/

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

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

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

https://habr.com/ru/articles/996526/

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

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

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

https://habr.com/ru/companies/wildberries/articles/993160/

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

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

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

https://habr.com/ru/companies/wildberries/articles/993160/

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