То, что соединение с общей сетью и дальнейшие маршруты — это разные вещи, я примерно понимаю. Признаюсь, я просто не понял посыл статьи.
Если для потенциальных клиентов, что-то вроде «вот смотрите какие возможности есть», то, по-моему, не плохо бы описать их с точки зрения клиента, а не связиста.
Если для технарей, то статья из серии «Привет, Мир!»
Это просто мои размышления/наблюдения по теме и к ДоксВижин не имеют отношения.
А если говорить именно о системе, где пользователь выбирает воздействие инцидента (как у вас в статье описано), то вы сами в первом абзаце привели пример почему это не всегда работает. С другой стороны, у меня нет предложений как это исправить.
Лично я (как участник тех поддержки, а не клиент) работал только по двум моделям:
1. Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет;
2. Все тикеты валятся в кучу, а специально обученный человек (или сами инженеры) их разгребает. Т.е. примерно так: посмотрел все необработанные заявки -> принял наиболее важную -> решил -> посмотрел все необработанные заявки. Но это для маленькой компании, разумеется.
Так же стоит упомянуть, что можно не только принимать входящие звонки на 8-800, но и подставлять его как Caller ID при исходящем вызове (не телефонист — поправляйте, если неправ).
Всегда немного озадачивала возможность дать инциденту приоритет. По-моему это актуально только для «жесткого аутсорсинга», когда менеджеры одной компании управляют сотрудниками другой. Необходимость в таком аутсорсинге сильно специфична.
По своей сути приоритет диктует внутренние условия работы специалистов внешним клиентом. А вот выбор отдела или тип инцидента (с обязательной возможностью выбора «Другое») как-то более понятен.
Вот здесь разве не об этом же речь шла?
Несколько лет уже прошло, я точно не помню. Но то что уже несколько раз видел все основные тезисы Рыбака из этого доклада — это точно.
И да, в 2014 занимался другим направлением и точно не читал.
Если говорить о конкретном докладе и конкретных докладчиках, то я был примерно в 2011 году на этом же самом докладе с этими же самыми докладчиками. На ютубе это появилось ещё раньше.
Так-то я не то что бы против :) Просто хотелось бы чего-нибудь действительно новенького и с большим уклоном в конкретную реализацию. Даже суть доклада можно оставить ту же, только один раз рассказывать про шардинг с Consul'ом, другой — с Eurek'ой, а потом вообще какое-то кастомное решение. Вот тогда было бы интересно.
Очевидно, автор комментария предостерегает вас от использования Angular 2 в продакшене :)
На самом деле, если учесть как выходили релиз-кандидаты и планы на будущее, то можно с уверенностью сказать, что Angular 2 и Angular 2 в следующем году — это будут немного разные вещи.
Справедливости ради, управление такими вещами как круиз контроль, аудио и т.п. уже давно научились дублировать на руль. Сенсорный экран в данном случае не мешает, а дополняет.
А вот я не могу не похвастаться, что не только видел мини-диск, но и работал с ним на радио — были портативные диктофоны с мини-дисками у журналистов. Точную модель не вспомню, но вот это очень похоже.
DCC ни разу не видел и не знал о ней. Интересно, у miniDV не от туда корни растут?
То, что соединение с общей сетью и дальнейшие маршруты — это разные вещи, я примерно понимаю. Признаюсь, я просто не понял посыл статьи.
Если для потенциальных клиентов, что-то вроде «вот смотрите какие возможности есть», то, по-моему, не плохо бы описать их с точки зрения клиента, а не связиста.
Если для технарей, то статья из серии «Привет, Мир!»
А если говорить именно о системе, где пользователь выбирает воздействие инцидента (как у вас в статье описано), то вы сами в первом абзаце привели пример почему это не всегда работает. С другой стороны, у меня нет предложений как это исправить.
Лично я (как участник тех поддержки, а не клиент) работал только по двум моделям:
1. Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет;
2. Все тикеты валятся в кучу, а специально обученный человек (или сами инженеры) их разгребает. Т.е. примерно так: посмотрел все необработанные заявки -> принял наиболее важную -> решил -> посмотрел все необработанные заявки. Но это для маленькой компании, разумеется.
По своей сути приоритет диктует внутренние условия работы специалистов внешним клиентом. А вот выбор отдела или тип инцидента (с обязательной возможностью выбора «Другое») как-то более понятен.
А как это тогда происходит?
Несколько лет уже прошло, я точно не помню. Но то что уже несколько раз видел все основные тезисы Рыбака из этого доклада — это точно.
И да, в 2014 занимался другим направлением и точно не читал.
Так-то я не то что бы против :) Просто хотелось бы чего-нибудь действительно новенького и с большим уклоном в конкретную реализацию. Даже суть доклада можно оставить ту же, только один раз рассказывать про шардинг с Consul'ом, другой — с Eurek'ой, а потом вообще какое-то кастомное решение. Вот тогда было бы интересно.
На самом деле, если учесть как выходили релиз-кандидаты и планы на будущее, то можно с уверенностью сказать, что Angular 2 и Angular 2 в следующем году — это будут немного разные вещи.
Хотя я с теплотой вспоминаю
DCC ни разу не видел и не знал о ней. Интересно, у miniDV не от туда корни растут?
А вот функционал групп, по-моему, неплохо бы расширить.
Например, добавить туда тот же Issue Board и статистику по коммитам.