FM
ну это не пугает, упомянуть можно)
чтобы признать ПО импортозамещенным, данное ПО должно иметь 75% уникального российского кода.
Size: a a a
2021 March 03
J
Fox Mulder
чтобы признать ПО импортозамещенным, данное ПО должно иметь 75% уникального российского кода.
у нас не такие серьезные требования, главное чтобы буржуям ничего не платить, на это не пойдут, а если опенсорс, то нормально
J
DocFX
спасибо, посмотрю
FM
DOXYGEN - иностранная (GNU)
Swagger - иностранная (Apache License 2.0)
Javadoc - иностранная (GNU GPL 2 + «Classpath exception» (Sun Microsystems))
SPHINX - наша (GPLv2 и коммерческая)
NATURAL DOCS - иностранная (Affero General Public License)
DocFX - - иностранная (MIT license)
Swagger - иностранная (Apache License 2.0)
Javadoc - иностранная (GNU GPL 2 + «Classpath exception» (Sun Microsystems))
SPHINX - наша (GPLv2 и коммерческая)
NATURAL DOCS - иностранная (Affero General Public License)
DocFX - - иностранная (MIT license)
NV
Fox Mulder
чтобы признать ПО импортозамещенным, данное ПО должно иметь 75% уникального российского кода.
Думаю что вопрос не об этом
J
"100% импортозамещение т.е не платные буржуазные. " я вот так написал. У нас будет опенсорсный продукт, не коммерческий
J
т.е давайте вообще уберем имортозамещение и только опенсорсные продукты будем иметь ввиду)
FM
"100% импортозамещение т.е не платные буржуазные. " я вот так написал. У нас будет опенсорсный продукт, не коммерческий
Всё равно рекомендую почитать прилагаемые лицензии.
J
Fox Mulder
Всё равно рекомендую почитать прилагаемые лицензии.
так надо понять пока, какие вообще есть инструменты, вопрос в этом
NV
Коллеги, делаем большой проект на опенсорс для госзаказчика. Сейчас рассматриваем варианты и возможности автогенерации документации из кода. Какие технологии и инструменты сейчас актуальны? 100% импортозамещение т.е не платные буржуазные. Пока видел только jawadoc и swagger
В каких форматах нужен будет результат? Сайт, DOCX?
J
В каких форматах нужен будет результат? Сайт, DOCX?
Привет, Ник! Cайт и docx (это как вариант т.к госы пока еще любят бумагу)
J
смысла в docx я не вижу, если это будет тормозом, то будем отказываться от этого
ML
Коллеги, делаем большой проект на опенсорс для госзаказчика. Сейчас рассматриваем варианты и возможности автогенерации документации из кода. Какие технологии и инструменты сейчас актуальны? 100% импортозамещение т.е не платные буржуазные. Пока видел только jawadoc и swagger
Вам надо понять, есть ли формальные требования клиента.
Например чтобы войти в реестр российского по, критически важно иметь в России команду поддержки и разработки
Например чтобы войти в реестр российского по, критически важно иметь в России команду поддержки и разработки
J
Вам надо понять, есть ли формальные требования клиента.
Например чтобы войти в реестр российского по, критически важно иметь в России команду поддержки и разработки
Например чтобы войти в реестр российского по, критически важно иметь в России команду поддержки и разработки
сейчас нам просто надо предложить какие-либо варианты решения с автогенерацией, каких-то требований жестких нет
NV
Привет, Ник! Cайт и docx (это как вариант т.к госы пока еще любят бумагу)
Выбирайте из этих трёх вариантов:
— Sphinx
— Foliant
— AsciiDoctor
— Sphinx
— Foliant
— AsciiDoctor
J
Выбирайте из этих трёх вариантов:
— Sphinx
— Foliant
— AsciiDoctor
— Sphinx
— Foliant
— AsciiDoctor
хорошо, спасибо, посмотрю!
2021 March 09
NK
Есть такой подход к организации работы технической поддержки — KCS, knowledge-centered support, поддержка, основанная на знаниях. Строится на простых принципах:
1. Каждый запрос от клиента сначала ищем в базе знаний. Даже если решение вроде и так понятно.
2. Если находим статью с описанием решения — используем это решение. Дополняем статью, если есть чем.
3. Если не нашли — решение нужно выработать, применить и записать в базу знаний.
4. Публикуем все статьи, которые можем, чтобы клиенты могли сами найти и применить решение.
5. В базу знаний пишут все. Ведущие инженеры от новичков отличаются только тем, что решают и описывают самые сложные задачи.
Ведущие инженеры и так помнят решение любой проблемы или могут его выработать за полчаса. Но их не хватит, чтобы сделать всю работу. Часто они — "бутылочное горлышко" в конвейере поддержки. KCS помогает разгрузить их, сделать сложную работу простой и масштабируемой, отдав её младшим специалистам или даже клиентам.
Я вдруг понял, что применяю те же принципы в своей работе, хоть и в другом процессе. Расскажу об этом завтра.
А как у вас? Какие решения вы производите? Как сохраняете их, как делитесь с коллегами?
1. Каждый запрос от клиента сначала ищем в базе знаний. Даже если решение вроде и так понятно.
2. Если находим статью с описанием решения — используем это решение. Дополняем статью, если есть чем.
3. Если не нашли — решение нужно выработать, применить и записать в базу знаний.
4. Публикуем все статьи, которые можем, чтобы клиенты могли сами найти и применить решение.
5. В базу знаний пишут все. Ведущие инженеры от новичков отличаются только тем, что решают и описывают самые сложные задачи.
Ведущие инженеры и так помнят решение любой проблемы или могут его выработать за полчаса. Но их не хватит, чтобы сделать всю работу. Часто они — "бутылочное горлышко" в конвейере поддержки. KCS помогает разгрузить их, сделать сложную работу простой и масштабируемой, отдав её младшим специалистам или даже клиентам.
Я вдруг понял, что применяю те же принципы в своей работе, хоть и в другом процессе. Расскажу об этом завтра.
А как у вас? Какие решения вы производите? Как сохраняете их, как делитесь с коллегами?
TS
ID:0
Есть такой подход к организации работы технической поддержки — KCS, knowledge-centered support, поддержка, основанная на знаниях. Строится на простых принципах:
1. Каждый запрос от клиента сначала ищем в базе знаний. Даже если решение вроде и так понятно.
2. Если находим статью с описанием решения — используем это решение. Дополняем статью, если есть чем.
3. Если не нашли — решение нужно выработать, применить и записать в базу знаний.
4. Публикуем все статьи, которые можем, чтобы клиенты могли сами найти и применить решение.
5. В базу знаний пишут все. Ведущие инженеры от новичков отличаются только тем, что решают и описывают самые сложные задачи.
Ведущие инженеры и так помнят решение любой проблемы или могут его выработать за полчаса. Но их не хватит, чтобы сделать всю работу. Часто они — "бутылочное горлышко" в конвейере поддержки. KCS помогает разгрузить их, сделать сложную работу простой и масштабируемой, отдав её младшим специалистам или даже клиентам.
Я вдруг понял, что применяю те же принципы в своей работе, хоть и в другом процессе. Расскажу об этом завтра.
А как у вас? Какие решения вы производите? Как сохраняете их, как делитесь с коллегами?
1. Каждый запрос от клиента сначала ищем в базе знаний. Даже если решение вроде и так понятно.
2. Если находим статью с описанием решения — используем это решение. Дополняем статью, если есть чем.
3. Если не нашли — решение нужно выработать, применить и записать в базу знаний.
4. Публикуем все статьи, которые можем, чтобы клиенты могли сами найти и применить решение.
5. В базу знаний пишут все. Ведущие инженеры от новичков отличаются только тем, что решают и описывают самые сложные задачи.
Ведущие инженеры и так помнят решение любой проблемы или могут его выработать за полчаса. Но их не хватит, чтобы сделать всю работу. Часто они — "бутылочное горлышко" в конвейере поддержки. KCS помогает разгрузить их, сделать сложную работу простой и масштабируемой, отдав её младшим специалистам или даже клиентам.
Я вдруг понял, что применяю те же принципы в своей работе, хоть и в другом процессе. Расскажу об этом завтра.
А как у вас? Какие решения вы производите? Как сохраняете их, как делитесь с коллегами?
Часто возникают проблемы не с документированием решений проблем, а их поиском. В конфлюенсе, к примеру, поиск не всегда выдает релевантные результаты, либо результатов очень много, в котором может не быть нужного.
В итоге проще пойти к коллегам и спросить как решить эту проблему, что ведёт к хранению экспертизы в головах коллег
В итоге проще пойти к коллегам и спросить как решить эту проблему, что ведёт к хранению экспертизы в головах коллег
NV
Часто возникают проблемы не с документированием решений проблем, а их поиском. В конфлюенсе, к примеру, поиск не всегда выдает релевантные результаты, либо результатов очень много, в котором может не быть нужного.
В итоге проще пойти к коллегам и спросить как решить эту проблему, что ведёт к хранению экспертизы в головах коллег
В итоге проще пойти к коллегам и спросить как решить эту проблему, что ведёт к хранению экспертизы в головах коллег
Есть и такая проблема.
TS
ID:0
Есть такой подход к организации работы технической поддержки — KCS, knowledge-centered support, поддержка, основанная на знаниях. Строится на простых принципах:
1. Каждый запрос от клиента сначала ищем в базе знаний. Даже если решение вроде и так понятно.
2. Если находим статью с описанием решения — используем это решение. Дополняем статью, если есть чем.
3. Если не нашли — решение нужно выработать, применить и записать в базу знаний.
4. Публикуем все статьи, которые можем, чтобы клиенты могли сами найти и применить решение.
5. В базу знаний пишут все. Ведущие инженеры от новичков отличаются только тем, что решают и описывают самые сложные задачи.
Ведущие инженеры и так помнят решение любой проблемы или могут его выработать за полчаса. Но их не хватит, чтобы сделать всю работу. Часто они — "бутылочное горлышко" в конвейере поддержки. KCS помогает разгрузить их, сделать сложную работу простой и масштабируемой, отдав её младшим специалистам или даже клиентам.
Я вдруг понял, что применяю те же принципы в своей работе, хоть и в другом процессе. Расскажу об этом завтра.
А как у вас? Какие решения вы производите? Как сохраняете их, как делитесь с коллегами?
1. Каждый запрос от клиента сначала ищем в базе знаний. Даже если решение вроде и так понятно.
2. Если находим статью с описанием решения — используем это решение. Дополняем статью, если есть чем.
3. Если не нашли — решение нужно выработать, применить и записать в базу знаний.
4. Публикуем все статьи, которые можем, чтобы клиенты могли сами найти и применить решение.
5. В базу знаний пишут все. Ведущие инженеры от новичков отличаются только тем, что решают и описывают самые сложные задачи.
Ведущие инженеры и так помнят решение любой проблемы или могут его выработать за полчаса. Но их не хватит, чтобы сделать всю работу. Часто они — "бутылочное горлышко" в конвейере поддержки. KCS помогает разгрузить их, сделать сложную работу простой и масштабируемой, отдав её младшим специалистам или даже клиентам.
Я вдруг понял, что применяю те же принципы в своей работе, хоть и в другом процессе. Расскажу об этом завтра.
А как у вас? Какие решения вы производите? Как сохраняете их, как делитесь с коллегами?
Как вы ее решаете?