Да, работа проделана крутая, получилось красиво и мощно. Но если бы я был заказчиком этой работы, меня бы результат
Тимлиды, юнит-лиды и аналитики могут оценить по графикам общую картину продуктивности команд, увидеть проблемные места и скорректировать рабочий процесс. Сами команды смотрят на график Velocity, чтобы при планировании следующего спринта понимать, какую нагрузку они могут взять.
не устроил. И вот почему:
в статье написано, какая крутая работа была проделана, но не показан интересный бизнесу результат. Смотреть графики - прикольно, но надо повышенную предсказуемость. Вот как она изменилась?
Bug policy: баг багу рознь. Мне как заказчику не очень интересно, насколько быстро команда баги закрывает. Гораздо интереснее, какие из багов заметили клиенты и как они повлияли на бизнес-метрики. Если релиз выходит с большим количеством багов, которые клиенты не замечают и клиентам они не вредят и метрики не падают, то и славно. Можно потом неспешно их поправить. Просто замечу, что в своё время Chrysler (если память мне не изменяет) закрытие своих заводов начал с завода-победителя соревнования по внутренней эффективности. Соответствие bug policy - это внутренняя (!) эффективность.
А так работа крутая. Пойду с инженерами нашими обсуждать, что можно из этого хорошего перенять.
Именно поэтому и говорю о колл-центровых наушниках. Они рассчитываются на смену до 12 часов. Ну и узконаправленный микрофон решает. :) Я не знаком с геймерскими наушниками и их особенностями, но ради интереса попробовать можно.
Ну вот как работают антивирусные компании: они следят за своей клиентской базой и анализируют исполняемый у клиентов код. Если код проявляет признаки вредоносности, да еще и распространиться пытается, то его активность блокируется, а системы в антивирусной компании в подавляющем большинстве случаев автоматически (вручную очень немного вещей обрабатывается) снимают так называемую «сигнатуру» вредоноса и заносят его в базы, которые поставляются другим пользователям в виде обновления или через облако. Как итог: есть небольшая часть пострадавших, которые помогают защитить остальных пользователей антивируса. Для борьбы со спамом нас сходным образом все устроено. Формат поставки — отдельная услуга.
Идентифицировать голос нам помогают партнеры. Глубоко в деталях не скажу, но в общем это происходит примерно так: из аудиозаписи выделяются голосовые фрагменты (отсеиваются шумы, музыка и прочие «неголоса» -считается ли за голос пение — не знаю, надо спросить у коллег :) ). Для голосовых фрагментов вычисляется около 100 характеристик, которые и считаются «цифровым отпечатком» голоса. Важно, что параметры не зависят от длительности аудиофрагментов. Точность верификации коллеги заявляют в 97% (примерно 3% — ошибки обоих родов) — но мы прямо сейчас это перепроверяем, поэтому за цифру пока не поручусь. Но даже если точность будет 90% — нормально. Потому что голос — это не единственный критерий. Их у нас около 20. Жулик выдает себя не только голосом, а ещё и рядом других признаков. По отдельности каждый из них не значит ничего, но когда несколько из них появляются на том же самом звонке, то можно уже делать выводы. И наша цель не в том, чтобы заявить «вот у этого клиента точно было 287 бесполезных звонков», а скорее показать, какие звонки в потоке — подозрительные и предложить их переслушать и принять свое решение. Это существенно облегчает задачу контроля.
От того, что я начну «правильные» слова использовать для названия тех же самых сущностей, суть проблемы и сложности с её решением никак не меняются. А за нас не бойтесь, у нас все хорошо. ;)
Подразумеваю, что «замена живого человека роботом» — это «вид автоматизации». Можно ли назвать это подменой понятий? Наверное, можно. Имеет ли это для сути статьи принципиальное значение? Не уверен. В статье делюсь, как телефонист, своими наблюдениями за результатами своих действий и действий партнеров и конкурентов. Если кратко, то вы правы: пока не взлетает по причине технологических ограничений, которые делают получающееся предложение малоюзабельным, а значит и малополезным.
Ну шум сейчас — это не вот прям какая серьезная проблема. А вот приватность и удобство (в том числе и скорость решения своих проблем через автоматизированную голосовую систему) — да, существенные сдерживающие факторы.
Справедливо. Но вопрос в том, как это делать? Можно (и нужно, навреное) встраивать инструкцию в само голосовое меню, но надо с одной стороны клиенту дать возможность его как-то прослушать, а с другой — не грузить человека тем, что он уже знает, и не тратить его время на ненужные подсказки. В этом и есть большая сложность с голосовыми интерфейсами. Из-за необходимости обучения они становятся малоюзабельными, и из-за обучения они тоже малоюзабельны. Отсюда есть выход в виде ассистента, понимающего естественную речь, но тут мы упираемся в технологические ограничения. Собственно, об этом и статья: несколько попыток уже видели создания замены IVR «барышней», но пока из 100% наблюдаемых все 100% провалились и тихонько вернулись к обычному меню с DTMF.
Именно такую задачу мы в текущей реализации не решаем. Более того, постановка задач же где-то должна делаться? В CRM, например? То есть требуется ещё и интеграция с внешней системой. Мы сами именно эту задачу решать не планируем, однако в следующей версии будет возможность «подписаться» на определенные слова и расшифровку разговора использовать для генерации задачи во внешней системе.
Давайте с другого конца зайдем. А вы какую задачу хотите решить? Обещаю в ответ на вопрос показать скриншот и честно изложить все, что мне самому известно на этот момент. :)
Мне в первую очередь важно было показать, как мы выбирали. А выбирали мы по назначению движков распознавания и особенностям эксплуатации: мы хотели иметь решение in-house, а не отдавать в другое облако. И потребительские свойства «SDK» я выписал честно: SDK по факту не является и платой за «правильное» для нас предназначение является просто ужасающая негибкость и стоимость внедрения.
Да, работа проделана крутая, получилось красиво и мощно. Но если бы я был заказчиком этой работы, меня бы результат
не устроил. И вот почему:
в статье написано, какая крутая работа была проделана, но не показан интересный бизнесу результат. Смотреть графики - прикольно, но надо повышенную предсказуемость. Вот как она изменилась?
Bug policy: баг багу рознь. Мне как заказчику не очень интересно, насколько быстро команда баги закрывает. Гораздо интереснее, какие из багов заметили клиенты и как они повлияли на бизнес-метрики. Если релиз выходит с большим количеством багов, которые клиенты не замечают и клиентам они не вредят и метрики не падают, то и славно. Можно потом неспешно их поправить. Просто замечу, что в своё время Chrysler (если память мне не изменяет) закрытие своих заводов начал с завода-победителя соревнования по внутренней эффективности. Соответствие bug policy - это внутренняя (!) эффективность.
А так работа крутая. Пойду с инженерами нашими обсуждать, что можно из этого хорошего перенять.