мне кажется, спускаться с верхней полки будет неудобно. допустим, я лежу, лестница у меня в районе ног. дальше мне надо как-то перегруппироваться, чтобы начать спускаться. видимо, сначала мне надо сесть и свесить ноги, потом развернуться и поставить ноги на лестницу. для обеих эволюций мне нужны какие-то выступы, за которые я буду руками цепляться. делать это без "зацепов", сугубо прессом, физически сложно. а сейчас таких зацепов я не вижу. Внизу для таких эволюций есть лестница на верхнюю полку, я бы за нее держался. а вверху все сугубо гладенькое.
Если у вашего сервиса большая аудитория, то вы можете рассмотреть возможность покупки серверов on-premise для распознавания и генерации речи. их сложнее подключать в мобильные приложения, но экономически это оправдано. и это будет единичное вложение.
5М запросов по 4 сек это 10-15 on-prem каналов распознавания речи (взял с запасом), по 100 тр за канал (в среднем по рынку) + железо.
для сравнения, 5М запросов к ya.speechkit обойдутся примерно в 610 тр.
на наших тестах (которые ты поставил под сомнение как менеджер:) использовался SVM. word2vec показал результаты хуже. лемматизацию делали, конечно.
ну и, как мне кажется, в наших системах очень желательно:
— использовать фичи из контекста: кто, когда подал заявку, какие заявки он подавал раньше и т.д.
— выделять факты: номера телефонов, емэйлы, даты, номера чего-то еще.
— критически смотреть на набор классов/тематик: почти всегда там есть какая-нибудь фигня
получается, оператор должен ждать, пока сервис дозванивается до абонента? это же простой оператора. не говоря уже о том, что успешность дозвона абоненту вряд ли превышает 40%… неэффективно. проще нанять дополнительных операторов, чтобы они отрабатывали вызовы, когда они пришли, чем они потом будут тратить на обработку коллбэка в 2-3 раза больше времени.
моя фотка для привлечения внимания это что-то новое :)
только я не в колл-центре работаю, а занимаюсь разработкой ПО для контактных центров. есть некоторая разница :)
Есть одна проблема в этой истории. На мой взгляд, существенная.
Студии сказали важную цифру — 30% клиентов. С этой цифрой они никак не работают. Они не выясняют, как сейчас приходят клиенты, что это за клиенты, почему этот трафик после переработки сохранится и увеличится. Мне кажется, это как-то не айс. Или это чисто епархия партнеров по продвижению сайта?
Рекрутинг это всегда продажа и покупка одновременно. Профессиональный рекрутер должен понимать, в какой пропорции продажа и покупка сочетаются в каждом конкретном случае.
Кстати, уважаемые потенциальные слушатели конференции могут написать в комментариях, что или кого они хотели бы услышать в секциях. А программный комитет рассмотрит :)
Кстати, в serverside еще надеемся поговорить про новые клевые языки программирования (вы ведь уже пишите на них, правда?), про нестандартные архитектурные решения, про оптимизацию производительности и про загибание уголков, конечно.
если говорить о реализации, приведенной в статье, то ее вполне можно повторить на java. хотя, возможно, я не заметил какой-то особенный синтаксический сахар :)
я выше написал комментарий, зачем это хочется. я вполне серьезен, у нас в группе около 50 человек, которые взаимодействуют с задачами. визуализации не хватает, но она у нас все равно вокруг тасков будет. если будет.
посмотрите, как кавайно это сделано в yourtack www.jetbrains.com/youtrack/documentation/index.html
мы бы заплатили за такой инструмент вокруг нашего redmine
особенно с групповыми. без этой интеграции с redmine нашей (например) рабочей группе не имеет смысла использовать продукт.
нам не нужен альтернативный таск-менеджер, потому что redmine уже побежден, там масса задач с историей переписки, интеграция с git и ldap и прочие плюшки.
а вот визуализация нужна, потому что по доске бумажки двигать это не очень удобно, особенно в распределенной команде.
ну и хочется, чтобы автоматически считались скрамовские метрики типа burn-down. это порядка 1 часа времени скрам-мастера в итерацию у скрам-мастера, которые хочется экономить.
лично я привлекаю людей по-знакомству и как правильно это успешный рекрутинг. я склонен воспринимать знакомство просто как канал распространения информации о компании-команде-проекте и получение первого контакта. а дальше - стандартная процедура рекрутинга, с собеседованием. тогда, кстати, и всех этих проблем с ответственностью-обязанностью не возникает.
мне кажется, спускаться с верхней полки будет неудобно. допустим, я лежу, лестница у меня в районе ног. дальше мне надо как-то перегруппироваться, чтобы начать спускаться. видимо, сначала мне надо сесть и свесить ноги, потом развернуться и поставить ноги на лестницу. для обеих эволюций мне нужны какие-то выступы, за которые я буду руками цепляться. делать это без "зацепов", сугубо прессом, физически сложно. а сейчас таких зацепов я не вижу. Внизу для таких эволюций есть лестница на верхнюю полку, я бы за нее держался. а вверху все сугубо гладенькое.
5М запросов по 4 сек это 10-15 on-prem каналов распознавания речи (взял с запасом), по 100 тр за канал (в среднем по рынку) + железо.
для сравнения, 5М запросов к ya.speechkit обойдутся примерно в 610 тр.
ну и, как мне кажется, в наших системах очень желательно:
— использовать фичи из контекста: кто, когда подал заявку, какие заявки он подавал раньше и т.д.
— выделять факты: номера телефонов, емэйлы, даты, номера чего-то еще.
— критически смотреть на набор классов/тематик: почти всегда там есть какая-нибудь фигня
только я не в колл-центре работаю, а занимаюсь разработкой ПО для контактных центров. есть некоторая разница :)
Студии сказали важную цифру — 30% клиентов. С этой цифрой они никак не работают. Они не выясняют, как сейчас приходят клиенты, что это за клиенты, почему этот трафик после переработки сохранится и увеличится. Мне кажется, это как-то не айс. Или это чисто епархия партнеров по продвижению сайта?
Кстати, в serverside еще надеемся поговорить про новые клевые языки программирования (вы ведь уже пишите на них, правда?), про нестандартные архитектурные решения, про оптимизацию производительности и про загибание уголков, конечно.
я, правда, уже раза 4 играл…
посмотрите, как кавайно это сделано в yourtack www.jetbrains.com/youtrack/documentation/index.html
мы бы заплатили за такой инструмент вокруг нашего redmine
нам не нужен альтернативный таск-менеджер, потому что redmine уже побежден, там масса задач с историей переписки, интеграция с git и ldap и прочие плюшки.
а вот визуализация нужна, потому что по доске бумажки двигать это не очень удобно, особенно в распределенной команде.
ну и хочется, чтобы автоматически считались скрамовские метрики типа burn-down. это порядка 1 часа времени скрам-мастера в итерацию у скрам-мастера, которые хочется экономить.