пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Семантическое управление версиями (или семвер) – это формальное соглашение для определения номера версии новых выпусков программного обеспечения. Стандарт помогает пользователям программного обеспечения понять серьезность изменений в каждом новом дистрибутиве.
Проект, использующий семантическое управление версиями, объявляет основной номер версии (major), дополнительный номер версии (minor) и номер исправления (patch) для каждого выпуска. Строка версии 1.2.3 указывает на основную версию под номером 1, дополнительную версию под номером 2 и исправление под номером 3.
Номера версий такого формата широко используются как программными пакетами, так и исполняемыми файлами конечных пользователей, такими как приложения и игры. Однако не каждый проект точно следует стандарту, установленному semver.org.
Спецификация была создана для решения проблем, вызванных несовместимостью методов управления версиями между программными пакетами, используемыми в качестве зависимостей. Под «пакетом» и «зависимостью» мы подразумеваем библиотеку кода, предназначенную для использования в другом программном проекте и распространяемую диспетчером пакетов, таким как npm, composer или nuget. Это именно то применение семантического управления версиями, которое мы рассматриваем в этой статье.
Major, Minor и Patch
Важно понимать значение трех задействованных компонентов. Вместе они намечают путь разработки проекта и соотносят влияние каждого нового выпуска на конечных пользователей.
Major number (основной номер версии) – основной номер указывает на текущую версию общедоступного интерфейса пакета. Он увеличивается каждый раз, когда вы вносите изменения, которые требуют от существующих пользователей вашего пакета обновления их собственной работы.
Minor number (дополнительный номер версии) – дополнительный номер указывает на текущую функциональную версию вашего программного обеспечения. Он увеличивается всякий раз, когда вы добавляете новую функцию, но не меняете интерфейс вашего пакета. Он сообщает пользователям о том, что были внесены значительные изменения, но пакет полностью совместимым с предыдущими версиями с предыдущим дополнительным номером.
Patch number (номер исправления) – номер исправления увеличивается каждый раз, когда вы вносите какое-то незначительное изменение, которое не влияет на общедоступный интерфейс или общую функциональность вашего пакета. Его чаще всего используют для исправления ошибок. Потребители всегда должны иметь возможность не задумываясь установить последнюю версию исправлений.
Семантическая структура версии выпуска лучше всего моделируется в виде дерева. Наверху у вас изменения общедоступного интерфейса, каждое из которых отображается на основном номере. Каждая основная версия имеет свой собственный набор дополнительных версий, в которые добавляются новые функции без нарушения совместимости с предыдущими версиями. И наконец, дополнительные версии могут время от времени отлаживаться путем исправления некоторых ошибок.
Откуда начинать?
Большинство проектов должны начинаться с версии 1.0.0. Вы публикуете свой первый общедоступный интерфейс и первоначальный неизмененный набор функций. И поскольку вам еще не приходилось вносить никаких исправления, то и версия исправления – 0.
Теперь давайте посмотрим, что же происходит, когда вы вносите изменения в свой пакет. После вашего первоначального выпуска вы получаете отчет об ошибке от пользователя. Когда вы выпустите исправление, то правильный номер версии уже будет 1.0.1. Если бы вы затем выпустили еще одну версию с исправлением ошибок, то вы бы увеличили номер исправления до 2, т.е. номер версии уже был бы 1.0.2.
Тем временем вы также работали над новой интересной функцией. Это совершенно необязательно, поэтому пользователям не нужно ничего делать для обновления. Вы выпускаете эту версию как 1.1.0. – создана новая функциональная среда, но ее еще ни разу не исправляли. К сожалению, скоро приходят отчеты об ошибках, и среди ваших пользователей начинает распространяться версия 1.1.1.
Несколько месяцев спустя вы решили провести реорганизацию кода всего проекта. Некоторые функции были удалены или теперь доступны через объединенный интерфейс. Если вы выпустите эту работу, то люди, использующие текущую версию вашего пакета, должны будут внести серьезные изменения в свой проект. Пришло время опубликовать 2.0.0. в вашем репозитории пакетов.
Поддержание старых веток
Увеличение какого-либо номера в вашей строке версий не создает точку невозврата. После публикации 1.1.1 вы могли обнаружить ошибку, присутствующую в 1.0.2. Используя ветки в вашей системе контроля версий, вы можете произвести исправления в обеих версиях. В итоге вы получите 1.1.2 и 1.0.3.
Точно также вы можете поддерживать ветку 1.х вашего проекта, несмотря на выпуск 2.0.0. Может показаться странным публиковать 1.1.2 после 2.0.1, но это вполне нормальная практика. Семантическое управление версиями не создает линейный постоянно увеличивающийся номер версии; наоборот, оно предназначено для использования в качестве части модели разработки ветвления, которое использует простоту установки исправлений, предлагаемую системами управления исходным кодом, такими как Git.
Опубликованные версии должны быть неизменяемыми. После того, как вы создали версию 2.4.3, вы не можете «обновить» его, просто добавив дополнительный код в ту же строку версии. Вы должны присваивать новый номер версии каждому выпуску, чтобы пользователи всегда могли получить доступ к каждой конкретной версии вашего пакета.
Обработка пакетов, находящихся в стадии разработки
Как правило, вы всегда обновляете основную версию своего пакета всякий раз, когда вносятся изменения, несовместимые с предыдущими версиями. Когда вы находитесь в стадии разработки, то ваша кодовая база может дорабатываться очень быстро, что приводит к публикации множества основных версий.
Вы можете этого избежать, рекламируя свой проект как 0.y.z. Значение 0 в качестве основной версии означает, что ваш пакет неустойчив. Обычные правила в отношении совместимости с предыдущими версиями тут не применяются, поэтому вы можете выпускать новые версии, увеличивая только дополнительный номер и номер исправления. Это значит, что вы можете использовать 1.0.0 для обозначения первой «завершенной» версии вашего программного обеспечения.
Вы также можете добавить дополнительные «идентификаторы» в конец строки версии, используя дефис в качестве разделителя: 1.0.0-alpha.1. Вы можете использовать такой вариант для того, чтобы четко обозначить альфа- и бета-версии. Точно также вы можете включить метаданные сборки, добавив символ +: 1.1.0-alpha.1+linux_x86.
Заключение
Согласованное использование семантического управления версиями помогает пользователям быть уверенными в вашем проекте. Они могут четко видеть, как развивается ваша кодовая база и нужно ли им самим провести какую-то работу, чтобы идти в ногу со временем.
Объявление строки семантической версии необходимо при публикации в диспетчере наиболее популярных пакетов. Тем не менее, в конечном счете, вам решать, какие номера вы устанавливаете для каждого нового выпуска. Соблюдение стандарта четко сообщает о ваших намерениях пользователям и сводит к минимуму риск непреднамеренного нарушения чужой работы.
Всем привет! Мы продолжаем рассказывать про операционную систему Cisco IOS, и сегодня рассмотрим какие команды можно использовать для просмотра информации об устройстве, а также для выявления неполадок (troubleshooting).
Основная команда, которая нам в этом поможет, это команда show и различные ключевые слова. Существует много различных вариантов этой команды, и чтобы получить список всех доступных в данном режиме или контексте команд следует использовать вопросительный знак “?” после show.
Switch# show ?
Типичная команда show может предоставлять информацию о конфигурации, работе и статусе частей коммутатора или маршрутизатора Cisco. Очень часто используемая команда show - это демонстрационные интерфейсы. Эта команда отображает статистику для всех интерфейсов на устройстве. Там будет показано состояния интерфейсов и протоколов, их использование, ошибки, MTU и прочее. Чтобы просмотреть статистику для определенного интерфейса, введите команду show interfaces, за которой следует конкретный тип интерфейса и номер слота или порта.
Например:
Switch# show interfaces fastethernet 0/1
И если эта команда кажется длинной, то ее можно сократить до такого вида:
Switch# sh int fa 0/1
Одной из наиболее часто используемых команд на коммутаторе или маршрутизаторе является show version.
Эта команда отображает информацию о текущей загруженной версии IOS, а также информацию об оборудовании и устройстве. Если вы подключены к маршрутизатору или удаленному коммутатору, команда show version является отличным средством быстрого поиска полезной сводной информации о конкретном устройстве, к которому вы подключены.
Из вывода этой команды можно получить следующую информацию:
Software version - версия программного обеспечения IOS (хранится во флэш-памяти);
Bootstrap version - версия Bootstrap (хранится в Boot ROM);
System up-time - время после последней перезагрузки;
System restart info - информация о перезапуске системы - способ перезагрузки (например, цикл питания, сбой);
Software image name - имя файла IOS, хранящееся во флэш-памяти;
Router type and processor type - номер модели и тип процессора;
Memory type and allocation - Тип и распределение ОЗУ;
Software features - Поддерживаемые протоколы /наборы функций;
Hardware interfaces - Интерфейсы, доступные на устройстве;
Configuration register - Устанавливает параметры загрузки, настройку скорости консоли и связанные параметры;
Если команда выводит больше данных, чем может отображаться на одном экране, в нижней части экрана появляется сообщение --More--. Когда появится строка --More--, нужно нажать пробел, чтобы просмотреть следующую часть вывода. Чтобы отобразить только следующую строку, нужно нажать клавишу Enter. Если нажать какую-либо другую клавишу, то вывод будет отменен.
В таком случае если выводится много информации можно использовать фильтры, которая поможет вычленить необходимую информацию из общего вывода. Для этого после команды show и ее аргумента нужно поставить символ “|” (pipe), указать фильтр и регулярное выражение, по которому будет произведен поиск.
Например:
Switch# show run | include ip dhcp pool
Где include это фильтр, а ip dhcp pool это регулярное выражение.
Использовать можно такие фильтры:
include – отобразит те строки из выдачи, в которых есть регулярное выражение;
exclude – отобразит все те строки из выдачи, в которых нет регулярного выражения;
begin – отобразит все строки, начиная со строки, где находится регулярное выражение;
section – отобразит раздел с регулярным выражением в названии;
Также рассмотрим другие часто используемые команды, которые могут быть полезны
show running-config Отображает содержимое текущего запущенного файла конфигурации
show startup-config Отображает сохраненную конфигурацию, расположенную в NVRAM
show ip interface Отображает статус IP протокола и его сервисов на всех интерфейсах. Для вывода краткой информации можно использовать команду show ip interface brief
show ip route Отображает таблицу маршрутизации роутера, где показаны все доступные сети, используемые протоколы маршрутизации и их метрики
show arp Показывает ARP таблицу
show mac-address-table Показывает таблицу mac адресов
show cdp neighbors Показывает соседние устройства Cisco, использующие протокол CDP
show spanning-tree Отображает информацию о протоколе STP
show vlan Показывает информацию о всех VLAN’ах в системе. Для краткой сводки можно использовать команду
show ip dhcp binding Отображает информацию о адресах, выданных DHCP сервером
show ip nat translations Показывает таблицу NAT трансляций
show history Показывает введенные ранее команды
show inventory Отображает информацию о продукте в виде UDI. UDI представляет собой комбинацию из трех отдельных элементов данных: идентификатор продукта (PID), идентификатор версии (VID) и серийный номер (SN).
show hardware Отображает информацию “железе”
show power Отображает информацию о питании
show processes Отображает активные процессы системы
show protocols Показывает используемые протоколы
show flash Показывает содержимое флеш памяти
Стоит заметить, что команды могут отличаться в зависимости от типа и модели устройства, а также версии IOS. Поэтому информацию о командах для конкретной модели лучше всего уточнять на сайте производителя.
Инструменты анализа речи (speech analytics) разрушают единственную защиту от роботов, захватывающих мир: представление о том, что машины не могут понять чувства людей. Выходя далеко за рамки разделения звонков на "хорошие" или "плохие", эмоционально интеллектуальный ИИ (искусственный интеллект) в инструментах речевой аналитики анализирует настроения клиентов, чтобы сказать, предоставляете ли первоклассный "customer service" и действительно ли счастлив ваш клиент.
Средства анализа речи могут дать представление о том, по каким вопросам чаще всего ваши клиенты звонят, обеспечить аналитику поведения агентов в реальном времени и отслеживать изменения "тончайших" метрик.
Мы поговорили с двумя ведущими разработчиками на рынке речевой аналитики чтобы узнать больше о том, как работает аналитика речи и почему эти инструменты стоят вашего внимания.
Максимальный результат
Сборщики долгов (коллекторы), которые стали одними из первых, кто применил в своей практике программное обеспечение анализа речи, используют его не только для того, чтобы убедиться соблюдаются ли агентами нормативные требования (закон), но и для улучшения качества обслуживания клиентов.
Вы будете удивлены, но да, даже сборщики долгов заботятся о том, как вы себя чувствуете в эмоциональном плане так как от этого зависит, смогут ли они уговорить вас оплатить долг.
В некоторых компаниях в начале звонка агенты должны предоставить заявление о соответствии, например, поставщик медицинских услуг, разъясняющий пациенту политику конфиденциальности. Программа анализа речи может извещать агента напоминанием, если он не сделал этого в течение определенного времени.
"Алгоритм основан на отсутствии коммуникационных фраз в диалоге. Речевая аналитика в реальном времени позволяет как раз отслеживать этот триггер, пока нужная фраза не будет озвучена. " - пояснил наш собеседник.
Возможность отслеживать звонки в режиме реального времени еще важнее для организаций, которые предоставляют юридические консультации или, скажем, рекомендации по страховым льготам. Говоря о кейсах, наш собеседник сослался на менеджера по контролю качества в компании, которая предоставляет предприятиям HR консультации. Так, клиенту компании, было поручено контролировать агентов, которые должны очень точно предоставлять информацию или нести ответственность за ущерб, если клиент пытается подать страховую претензию и есть проблема с зачислением или соблюдением.
"Одна из проблем заключается в том, что мы действительно ведем сложные с точки зрения процесса диалоги. У нас 19 различных бизнес - сценариев, представленных в формате скриптов, которые должны быть последовательно отработаны операторами".
Большинство средств анализа речи предоставляют полные транскрибации (стенограммы, расшифровки) и записи вызовов, а также анализ после звонка, который оценивает качество обслуживания. Ведущие платформы предоставляют аналитику в режиме реального времени, которая может посылать предупреждения менеджеру или управляющему, или извлекать определенную статью из базы знаний для агента.
Например, если агент пытается продать продукт, а клиент ссылается на продукт конкурента или рекламную акцию, программное обеспечение может выдвинуть соответствующее предложение из CRM-системы, чтобы агент мог сделать встречное предложение: "Ну, мы можем сделать вам предложение получше. Вот наша последняя кампания...".
Помимо помощи КЦ в оценке обычных KPI, таких как FCR (First call resolution, решение вопроса с первого звонка), речевая аналитика обеспечивает глубокое погружение в вопрос, который мы все просто не можем удержаться, чтобы не задать нашим клиентам: "Как я вас обслужил? Остались ли вы счастливы?"
Живой кейс: после использования инструмента речевой аналитики, известный игрок на рынке потребительских товаров обнаружил продуктовый дефект после того, как программное обеспечение речевой аналитики КЦ в качестве основной причины резкого увеличения объема вызовов отметило повторяющуюся жалобу на вполне конкретную проблему.
"Отметив всплеск обращения в КЦ по конкретному продуктовому дефекту, компания провели исследование в социальных сетях и проблема подтвердилась".
Когда речь идет о продажах, компании постоянно оттачивают процессы и скрипты продаж. Используя инструменты речевой аналитики для просмотра звонков, которые закончились успешной продажей, один из крупнейших продавцов систем инфраструктурной безопасности создал проект, чтобы помочь продавцам увеличить продажи.
"Они просто проанализировали звонки, которые закончились продажей. По итогам анализа, в разговорах успешных продавцов были выявлены паттерны и вполне понятные закономерности. Это позволило значительно улучшить процесс и бустануть отделу продаж."
Средства аналитики также могут помочь компании устранить внутренние недостатки в работе службы поддержки клиентов, такие как пробелы в знаниях/компетенции или чрезмерные переводы вызовов.
"Используя аналитику, можно провести конкретные измерения: почему переводятся звонки клиентов, почему агентам требуется больше времени для решения их вопроса"
Человеко - ориентированный подход к клиентскому сервису
Речевая аналитика не только хранит и анализирует данные, но и дает проактивные рекомендации агентам по обеспечению качества обслуживания. ПО может "пушить" агентам автоматизированные предложения и подсказки в реал тайме и даже немного потренировать их.
Важно не переборщить с роботизацией этого процесса. Люди останутся благодарны и счастливы от человеческого отношения к ним и к их вопросу. Поэтому, дальновидные компании стремятся к более ориентированному на человека подходу к обслуживанию клиентов, предоставляя своим агентам тренинги по развитию эмпатии, а на основными метриками успеха работы агента становятся "софт - метрикс" (мягкие), такие как эмоциональный контакт, открытость и дружественное отношение.
Логичный вопрос: разве автоматизация процессов голосовой поддержки клиентов не противоречит человеко - ориентированному подходу?
По словам нашего собеседника, один из первых клиентов компании использовал ручную оценку вызовов, где менеджер контроля качества отмечал пункты из контрольного списка, прослушивая каждый разговор отдельно (скоркарды, ну вы знаете).
Компания внедрила инструмент речевой аналитики, что позволило агентам стать самим собой: более никакого жесткого соответствия скрипту разговора, где в случае чего, "шаг вправо, шаг влево - снижение премии". Агенты стали более искренними и естественными, что позитивно отражалось на их премии. ПО трекало тонкое соответствие процессу обслуживания, определяя тематики и понятия в разговоре, без жесткой привязки к конкретным словами, которые агент обязан был сказать. Все - клиенты, агенты и сама по себе компания стали счастливы.
Фактически, обратная связь от анализа речи может даже заставить организации развернуть свою стратегию CS.
На самом деле, речевая аналитика порой приносит весьма шокирующие "инсайты", которые мотивируют компании на кардинальные изменения в процессе клиентского сервиса и продаж.
"Мы видели, как несколько клиентов находили неожиданные инсайты, которых они совершенно не ожидали. Например, как оказалось, измеряя AHT (average handle time, среднее время обработки вызова) как метрику и традиционно пытаясь ее уменьшать, ребята поняли, что более длительные звонки (по измеренной когорте клиентов) по времени разговора звонки приводят к увеличению LTV (life time value) в денежном эквиваленте".
Масштабирование контроля качества в КЦ
Перегруженные менеджеры по контролю качества (супервайзеры) в КЦ слушают и проверяют 5 - 10 вызовов на одного агента в месяц. В среднем по отрасли, соотношение количества супервайзеров к агентам это 1 к 20, а среднее время одного вызова около 4 минут.
"Даже если взять минимальное значение вызовов для контроля на супервайзера (5 штук), то получается, что супервайзер 4,16% своего рабочего времени тратит просто на то, чтобы сидеть в наушниках и слушать голоса агентов."
Для компаний в сфере консалтинга, среднее время обработки может быть намного больше, что еще больше утяжеляет процесс контроля качества. Например, сложные звонки юридической тематики часто длятся по 25-50 минут.
После реализации речевой аналитики, анализу подлежат 100 процентов вызовов. Не это ли масштабирование контроля качества до его предела?
Геймификация КЦ для агентского импульса
Система анализа речи помогает геймифицировать процесс клиентского сервиса. Например, один из клиентов установил дашборд реального времени в опен спейсе КЦ, в котором в формате ежедневного первенства между операторами показывался рейтинг по совокупности звонков. Условно говоря, рейтинг формировался инструментом речевой аналитики, проставляя оценки каждому из звонков по соответствие тем или иным метрикам.
Тем самым, сопровождая такие геймифицированные процессы вполне осязаемой материальной мотивацией, агенты соревнуются в качестве обслуживания, тем самым, ускоряя процесс обучения и повышая лояльность клиентов. Бинго.
Топовые компании на рынке речевой аналитики
Мы составили небольшой рейтинг платформ по речевой аналитике для КЦ уровня энтерпрайз на Российском рынке.
NICE
NICE inContact - один из лидеров по разработке платформ улучшения клиентского опыта взаимодействия с компаниями. Помимо популярного продукта речевой аналитики, вендор имеет ряд решений для омниканальнго обслуживания, WFO и богатую ML/AI экспертизу.
Почитать больше: www.niceincontact.com
Verint Speech Analytics
Продолжаем экскурсию по энтерпрайзным КЦ решениям. Verint Speech Analytics позволит транскрибировать и анализировать миллионы звонков, чтобы находить клиентские инсайты улучшать производительность контактного центра.
Почитать больше: www.verint.com/ru/speech-analytics
ZOOM (Eleveo) Speech Analytics
В РФ у ZOOM (Eleveo) сильно популярная система записи, известная под названием ZOOM CallRec. Однако, чешский производитель имеет в своем портфеле достаточно мощный инструмент речевой аналитики.
Вендор предоставляет следующие преимущества своего продукта:
Быстрая скорость работы, как следствие богатой экспертизы ML/AI команды разработчика;
Легкость в использовании;
Анализ эмоций
Интеграция с подсистемой записи сразу;
Инсайты по работе КЦ в удобной форме.
Почитать больше: www.zoomint.com/solutions/speech-analytics