19 вопросов, которые стоит задать веб-разработчику на собеседовании
Наём новых сотрудников может оказаться настоящим кошмаром. Иногда, чтобы найти подходящего кандидата, приходится пройти долгий и трудный путь. Если вы ищете веб-разработчика, техническая сторона этой профессии значительно усложняет процесс поиска.
Адаптировали статью команды блога Codementor о том, что важно спросить у веб-разработчика перед тем, как его нанять.
Полина Кабирова
Коммерческий автор и переводчик
Подготовьтесь заранее
Есть такая поговорка: кто не планирует свою победу, тот планирует чужую. И она будет к месту, если вы ищете разработчика, особенно на удалёнку.
Вот главные советы.
Определите требования
Опытные веб-разработчики всегда очень заняты. Нужно определиться с вашими ожиданиями и объёмом работы кандидата. Чётко сформулируйте должностную инструкцию и особенности работы в компании. Соискатель должен ясно понимать рабочие обязанности и предлагаемые условия труда.
Выделите оптимальный бюджет
Помните, вы получите ровно столько, сколько заплатили.
Обязанности и уровень самоотдачи разработчика зависят от зарплаты, которую вы предлагаете. По статистике, ведущий разработчик в США в среднем получает $85 000 в год. Для удалённых сотрудников зарплаты разнятся от $60 до $120 в час и выше.
Сумма зависит от местоположения и требований к специалисту. Проанализируйте зарплаты перед тем, как определить окончательную цифру.
В России на первое полугодие 2018 года средняя зарплата ИТ-специалистов составляет около 100 тыс. рублей в месяц. При этом диапазон зарплат достаточно большой — от 14 до 350 тыс. рублей.
В целом зарплата по миру в сфере разработки может достигать 89 000 $ в год.
Установите реалистичные дедлайны
Разработчику может потребоваться время, прежде чем приступить к работе в вашей компании. Учитывайте это при отборе кандидатов, тем более вам тоже нужно время для поиска подходящего человека.
На срочный проект можно рассмотреть фрилансера. Он начнёт работу, а у вас появится время для поиска кандидата в штат. Убедитесь, что у выбранного фрилансера или подрядчика достаточно времени на ваш проект.
Подготовьтесь к собеседованию
У хорошего разработчика во время и после собеседования появятся вопросы. Будьте готовы объяснять, что именно вы ищете в кандидате и какую работу ему предлагаете.
Профессия
Веб-разработчик
Узнать больше
- Научитесь программировать на JavaScript и PHP
- 11 готовых проектов в портфолио по итогам обучения
Вопросы для собеседования с разработчиком
Процесс поиска разработчика зависит от его роли в команде и особенностей компании в целом. Вот несколько вещей, на которые стоит обратить внимание при поиске.
- Первое собеседование — по телефону или видеозвонку.
- Оценка компетентности специалиста или тестирование на профпригодность, если это одобряется культурой вашей компании.
- Тестовое задание. Практические вопросы и задачи, связанные с разработкой, которые помогут определить технические знания кандидата.
- Итоговое собеседование. Очное интервью. Если личное присутствие на собеседовании невозможно, проведите видеозвонок.
Основные вопросы для собеседования с разработчиком и ответы, которые следует от него ждать. Не забывайте делать заметки во время собеседования — это поможет точнее оценить кандидатов.
Вопросы об опыте
1. Расскажите о проекте, которым по-настоящему гордитесь. Что вы сделали для его успешной реализации?
Начните собеседование аккуратно, чтобы уменьшить волнение кандидата. Ответ на этот вопрос даст представление об амбициях специалиста, покажет его взгляд на успех и рабочий процесс. Обратите внимание, упомянул ли разработчик других членов команды или сосредоточился на своих стараниях.
2. Расскажите о проекте, который вас разочаровал. Что бы вы сейчас изменили при работе над ним?
Разработчик должен постоянно анализировать свою работу. Вы не захотите нанимать человека, который всё время повторяет ошибки.
3. Что в программировании для вас самое сложное?
Другими словами, какие слабые стороны видит разработчик в своих технических навыках.
4. Как проводите тестирование? И что вообще о нём думаете?
Хороший код — это минимум багов в работе приложения и мало ошибок в коде. Хороший разработчик уделяет много внимания тестированию качества. Так можно сократить количество бессонных ночей в поисках ошибок на ранних этапах работы.
5. Как следите за последними тенденциями в веб-разработке?
Другими словами, прикладывает ли кандидат усилия, чтобы оставаться востребованным специалистом. Например, спросите, какие технические издания он читает, какими авторами и личностями ИТ-сообщества восхищается и почему.
Сфера веб-разработки постоянно меняется, поэтому для специалиста важно интересоваться последними тенденциями и формировать своё мнение о них.
6. Какую среду разработки предпочитаете?
Не важно, где работает кандидат — вам необходимо найти человека, который может адаптироваться под разные технологии и делиться своим мнением. Ответ на вопрос также покажет его опыт работы с разными фреймворками, системами контроля версий, юнит-тестированием и так далее.
Курсы Нетологии
Soft Skills
Узнать больше
- Soft skills — это надпрофессиональные навыки, которые помогают любым специалистам в любой отрасли быть востребованными
- Сможете прокачать навыки, чтобы быстро решать задачи, убедительно аргументировать свою позицию, грамотно выстраивать коммуникацию — без лишних эмоций и стресса ?
Вопросы о коммуникативных и управленческих навыках
7. Расскажите, какие качества помогают вам в работе
Возможно, вы ищете человека, который быстро решает проблемы, отлично ведёт переговоры или любит учиться. Попросите кандидата привести примеры, как он применяет эти навыки.
В зависимости от вакансии, одни навыки будут приоритетнее других. Например, тайм-менеджмент и коммуникативные навыки будут более важны для удалённого сотрудника, чем для штатного разработчика.
8. Расскажите о проблеме, которую вы решили вне программирования
Проблема может быть какой угодно. Например, кандидат починил кофемашину или помог коллеге отремонтировать велосипед. Неважно, что именно он сделал. Главное — вы увидите его способность решать проблемы и взаимодействовать с людьми.
9. Как бы описали вас другие разработчики / менеджеры проектов, с которыми вы работали?
Это отличный способ понять, как кандидат оценивает себя и свои навыки, какую роль играет в команде и как проявлял себя на прошлых должностях.
10. Представьте, что не можете решить проблему, связанную с программированием. Что сделаете, чтобы найти решение?
Спросит ли он коллег, зайдёт на StackOverflow или другие ресурсы? Здесь нет правильных и неправильных ответов. Важно понять, как кандидат преодолевает рабочие трудности.
Читать также
11. Что вы думаете о парном программировании? Был ли у вас такой опыт?
Такой метод программирования не всегда подходит для повседневной разработки, но будет интересно узнать, готов ли кандидат сесть рядом с коллегой и разбираться в его коде.
12. Работали ли вы когда-нибудь напрямую с заказчиком или как-то взаимодействовали с ним? Если нет, хотели бы попробовать?
Ответ на этот вопрос даст представление, как кандидат реагирует на мнения других людей о его работе. Если вы ищете человека для разработки приложения или способного в будущем расти внутри компании, он неизбежно будет сталкиваться с критикой пользователей и коллег.
Вопросы для проверки технических навыков разработчика
13. Опишите, пожалуйста, процесс создания веб-страницы или приложения.
Это отличный способ оценить, как кандидат справляется с базовыми задачами. Он используют фрагменты кода для быстрого создания базовой HTML-страницы, добавляет jQuery и начинает программировать или использует вспомогательные инструменты для разработки, типа Bower или Yeoman?
14. Какие инструменты используете для поиска багов?
Ответ на этот вопрос будет зависеть от среды разработки, которую использует кандидат. Разные языки программирования используют разные профилировщики, а некоторые фреймворки имеют встроенные инструменты для устранения багов. Важно узнать не инструмент, а подход к решению проблемы.
15. Что знаете о CORS?
CORS (Cross-Origin Resource Sharing, с англ. — «совместное использование ресурсов между разными источниками») — основной элемент HTML5, который должен быть знаком большинству фронтенд-разработчиков. Технология позволяет запрашивать доступ к различным ресурсам другого домена (jQuery, библиотекам шрифтов).
16. Вы можете объяснить назначение каждого типа HTTP-запроса при соблюдении требований RESTful?
Знает ли ваш кандидат разницу между запросом GET и POST? Не забыл ли он упомянуть запросы PATCH и CONNECT? Это серьёзный вопрос для оценки базового понимания HTML.
17. У вас есть пять разных таблиц стилей, как лучше всего интегрировать их в сайт?
Этот вопрос проверяет понимание CSS. Объединит ли кандидат стили в один CSS-файл или объединит только стили для конкретного приложения? И как он использует библиотеки стилей, например, Bootstrap?
18. Как вы организуете JavaScript-код?
Ответ на этот вопрос покажет, как кандидат систематизирует свой код. Он разделяет JavaScript и HTML? JS разбит на логические блоки и хранится в отдельных файлах? Он использует скрипт для объединения этих файлов в один пакет? А пространство имён в JavaScript, чтобы не захламлять глобальное пространство имён?
19. Как вы учитываете SEO, производительность, безопасность и UX при создании приложения?
Это очень важный вопрос. Способность понимать и сочетать эти факторы в работе является ключевым навыком для любого веб-разработчика. Из ответа также будет понятно, чему кандидат отдаёт приоритет при программировании. Например, если вы — крупная финансовая компания, безопасность для вас будет важнее SEO. Если вы — интернет-издание, на первом месте производительность сайта и SEO.
Ваше собеседование не ограничивается перечисленными вопросами.
Узнавайте больше о техническом опыте кандидата, стеке технологий, который встретится ему на новой работе. Если вы сами не разработчик, лучше попросить опытного специалиста провести техническую часть собеседования.
Примеры вопросов для технической части собеседования и ответы специалистов:
После собеседования
Из-за нехватки специалистов веб-разработчики очень востребованы. Если вы ищите разработчика, действуйте быстро: оцените всех кандидатов и сразу же свяжитесь с теми, кто вам подходит. Хороший кандидат быстро найдёт работу.
Нет единой правильной схемы для поиска разработчика — важны детали. Чтобы найти идеальный вариант, ясно определите собственные ожидания и требования для разработчика. На Github есть целый список вопросов для интервью.
Читать также
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
Полина Кабирова
Коммерческий автор и переводчик
Как задать вопрос разработчикам
© Valve Corporation. Все права защищены. Все торговые марки являются собственностью соответствующих владельцев в США и других странах. #footer_privacy_policy | #footer_legal | #footer_ssa | #footer_refunds
Установить Steam
Все обсуждения > Форумы Steam > Русскоязычный Форум > Подробности темы
Тема закрыта
12 ноя. 2016 в 11:07
Где задать вопрос?
Где я могу задать свой вопрос и что бы на него ответили и помогли админы?
Сообщения 1 – 6 из 6
12 ноя. 2016 в 11:12
Админов тут нет, это форум пользователей.
На форумах игр можно задать вопрос разработчикам
В поддержке игр — вопросы по играм
В поддержке Steam — вопросы по аккаунту, и сервису Steam
12 ноя. 2016 в 11:13
Большое спасибо
13 ноя. 2016 в 2:28
Вот у меня проблема что я нажимаю на написать обращение и меня кидает на сайт поддержке стим
13 ноя. 2016 в 2:44
Логику работы поддержки изменили, теперь нужно выбирать в интерактивной поддержке варианты для автоматического решения, если нет готовых решений, должно вывести на кнопку ~написать обращение в поддержку.
Не все ветви имеют в конце такую кнопку, поскольку есть вопросы, на которые поддержка Steam не дает ответа, например, возврат вещей, снятие банов, ограничений выданных автоматическими системами или патрулем.
Вопросы, которые стоит задать разработчику до начала работы над дизайном
В мире адаптивного веб дизайна, ограничения могут подбираться к вам с разных сторон: от привычек вашей пользовательской базы, до навыков вашей команды разработчиков.
В этой статье мы пройдемся по четырем вопросам, которые стоит задать вашей команде разработчиков прежде, чем начинать работу над разметкой вашей программы. Это позволит вам убедиться, что все друг друга понимают.
Вопрос 1: В каком виде вы должны передать итоговые материалы?
Я всегда предпочитаю уточнять существует ли какая-то определенная процедура передачи материалов, к которой привыкли разработчики. Этот момент может повлиять на то, какую программу вы будете использовать для создания макетов.
Я очень часто видел, как дизайнеры, и я в том числе, делали предположения о том, как нужно передавать материалы своей работы только для того, чтобы переделывать всё заново. Последнее, что нужно вашей команде, это чтобы вам, в последний момент, пришлось пересохранять или переделывать файлы в другом формате.
Ниже, приведены вопросы и сценарии, которые стоит обсудить с командой разработчиков прежде, чем приступать к работе над дизайном.
Как подготовить материалы?
Предпочитают ли они, чтобы вы разделили, подготовили и сохранили материалы в разных папках одной директории?
Может им проще будет получить исходный файл со всеми слоями, из которого они бы сами извлекли изображения?
Если да, то в каком формате? PSD? AI, EPS или PDF? Sketch?
Одинаковые ли у вас версии программного обеспечения? (смогут ли они открыть файл?)
Как вам назвать и сгруппировать слои, чтобы помочь им найти и выделить необходимые материалы.
Хотят ли они, чтобы вы извлекли HTML в Dreamweaver, или другим WYSIWYG редактором?
Если это ваш нормальный рабочий процесс, то спросите разработчиков устраивает ли он их. В 9 случаях из 10 они откажутся от этого метода.
Код, сгенерированный из программ с графическим интерфейсом, обычно некрасивый, неорганизованный, и неудобный. По своему опыту могу сказать, что этот метод замедляет работу как дизайнера, так и разработчиков. Избегайте кода, сгенерированного из программ с графическим интерфейсом. Всегда обсуждайте этот момент с разработчиком, если вы считаете это приемлемым вариантом.
Должны ли материалы сопровождаться документом о передаче?
Как вы планируете документировать неочевидные элементы дизайна? Такие вещи, как цветовые коды, ширина\высота, размеры шрифтов, отступы, начальные значения, эффекты парения, анимация, и другие данные, должны быть определены и записаны для того, чтобы разработчику не пришлось гадать.
Некоторые полезные приложения, которые помогут на этом направлении:
Omnigraffle. Упрощает рисование стрелок, добавление символов, и других элементов, помогающих объяснить особенности дизайна.
Avocode. Лично я никогда его не использовал, но этот инструмент позволяет экспортировать цвета, элементы изображений, шрифты, текст, CSS, и размеры из Photoshop или Sketch.
Inspect от InVision. Inspect обещает стать еще одним отличным инструментом для передачи материалов. В нем присутствуют комбинации функций продуктов, о которых я написал выше. Он особенно полезен, если для прототипирования вы используете InVision.
Вопрос 2: На какой платформе будет создаваться сайт?
Существует множество популярных платформ, которые существенно упрощают процесс разработки и дизайна. Для того, чтобы правильно составить документацию вам нужно знать какая платформа используется.
Много популярных платформ, таких, как Bootstrap и 960 Grid используют 12-колоночную систему. Почему именно 12 колонок? 12 лучше всего делится на меньшие цифры. Вы можете получить 12, 6, 4, 3, 2, или одну равномерно расположенные колонки, что упрощает для вас принятие решений.
Такая структура платформы располагает к предустановленным размерам. Знайте значения размеров вашей платформы с самого начала.
Случалось так, что края, которые я установил на артборде в Sketch, были на 5px больше, чем края в Bootstrap. По этой причине, мне приходилось переконфигурировать и перекодировать дизайн, чтобы исправить проблему, которой могло вообще не быть. Узнайте, на какой платформе будет создаваться сайт, и сделайте соответствующие изменения на своем артборде или холсте.
В дополнение к сетке, много платформ идет в комплекте со встроенными элементами дизайна, такими, как кнопки, надписи в формах, и т.п. Если вы собираетесь модифицировать или переписывать эти предустановленные стили, то позаботьтесь о том, чтобы об этом узнал разработчик.
Каждый раз, когда я создаю форму, с определенным цветом границы, радиусом и шириной, разработчики всё возвращают к дефолтным установкам, потому, что я не указал в инструкциях противоположного.
Не ожидайте, что разработчик заметит разницу радиуса в 2px, которую вы так тщательно выбрали для своих кнопок чтобы передать более дружественное ощущение. Они не обучены замечать такую разницу, зато способны, как машина, следовать заданному направлению.
Несколько самых популярных платформ:
- Bootstrap
- Foundation от Zurb
- Pure от Yahoo
- Skeleton
- Semantic UI
…и десятки других
Узнайте, какую платформу используют ваши разработчики еще до того, как начинать работу над дизайном.
У большинства платформ есть ресурсы с шаблонами, которые вы можете легко найти и использовать чтобы подогнать под них ваш Sketch или Photoshop документ. Такой подход упростит всем жизнь.
Вопрос 3: Какие языки и библиотеки составляют среду разработки, и какие ограничения они несут?
Даже если вы сами не умеете писать код, то можете найти хороший виджет или плагин. Фрагменты кода упрощают добавление функциональности сайту. Уловка заключается в том, что плагины не универсальны.
Если вы захотите найти готовые плагины для своего сайта, то это вполне нормально, и довольно полезно. Только до этого, выясните, написанные на каком языке плагины вам нужно искать.
Каждый плагин или виджет пишется на том языке программирования, который выберет его автор. Может случиться так, что плагин или виджет, который вы выберете, будет написан на языке, не соответствующем языку или среде, на котором создается ваш сайт. Как вы понимаете, это может привести к проблемам, самой меньшей из которых будет сердитый разработчик.
Метеорологическое приложение, написанное на Ruby не будет работать, если ваш сайт работает на PHP. Слайдшоу плагин для WordPress не заработает, если ваш сайт создан на .NET.
Даже если вы найдете плагин, который совпадает с вашей средой разработки, то используйте его как пример, чтобы объяснить вашей команде какое поведение вы хотите увидеть. Разработчики могут предпочесть использовать его как есть, но вручение им ZIP файла, заполненного кодом, и просьба «вставить это в сайт», это, как если бы ваш клиент прислал вам письмо с несколькими миниатюрами, размером в 100px, и попросил бы сделать «одно из тех больших слайдшоу».
Вопрос 4: Какие браузеры мы должны поддерживать?
Новость: Не все браузеры созданы равными!
Ну ладно, это вы, наверное, знали, и если вы хоть раз встречали разработчика, то знаете, что Internet Explorer – это бич их существования.
К счастью для всего сообщества дизайнеров и разработчиков, различия браузеров, которые преследовали создателей онлайн контента в прошлом, быстро сужаются до узкого круга обидчиков. Даже Microsoft прекратил разработку Internet Explorer и занялся новым, дружащим со стандартами Edge.
Знание браузеров, которые вы должны поддерживать, может существенно повлиять на ваши решения. Вот список свойств CSS, которые не поддерживаются некоторыми старыми браузерами. Посмотрим, увидите ли вы тенденцию.
text-shadow: IE8, 9, Firefox 2, 3
box-shadow: IE8, Firefox 2, 3
RGBA (color transparency): ie8
Flexbox (more on this later): IE8, 9.
Multiple backgrounds: IE8, Firefox 2–3.5
SVG: IE8 (many others for specific things)
CSS Animation: IE8, 9, Firefox 2–4, Safari 3.1 – 3.2
CSS 2D transforms (rotation, scale): IE8, Firefox 2, 3
Media Queries: IE8, Firefox 2, 3
Если вы окажетесь в положении, когда вам нужно будет организовать поддержку IE8, или каких-нибудь особо старых версий Firefox и Safari – подумайте о том, как будут выглядеть элементы без добавления эффектов. Все ваши закругленные углы станут прямыми, анимация станет неподвижной, тени не будет видно, и т.п.
Создание дизайна с использованием новейших технологий, и в то же время сохранение его привлекательности и удобства в устаревших браузерах называется прогрессивным улучшением.
Я надеюсь, что эти вопросы помогут вам сформировать четкий путь общения с разработчиками в начале процесса проектирования. Понимание своих ограничений дает вам набор «правил», с которыми вы будете работать, и поможет решить множество, если не большинство проблем, возникающих в фазе сотрудничества дизайнера с разработчиком. Семь раз отмерь, один отрежь.
Перевод статьи Кевина Томассо
Как задать вопрос разработчикам
12 вопросов к технической поддержке АСКОН
Работа с ошибками в продукте, которая классически входит в сферу обязанностей техподдержки — лишь часть деятельности Службы технической поддержки АСКОН. Это подразделение помогает заказчикам с вопросами установки, использования нашего ПО, собирает замечания, сообщения об ошибках и предложения по улучшению с момента поставки КОМПАС первому заказчику, с 1989 года. Хотя служба называется технической, она ежедневно отвечает на множество не всегда технических вопросов наших пользователей и тех, кто только присматривается к продуктам АСКОН: как установить это ПО, какие у него есть возможности, то, что я вижу в продукте, это норма или ошибка. А еще это крайне полезный сервис, который помогает специалистам предприятий решать свои задачи еще эффективнее. Подготовили материал для тех, кто не знает, как устроена техподдержка АСКОН, и тех, кто думает, что знает. На самые главные вопросы о работе подразделения отвечает Владимир Липин, руководитель Cлужбы технической поддержки АСКОН.
Сколько человек работает в техподдержке? Что такое первый и второй уровни поддержки?
Владимир Липин: В АСКОН две линии техподдержки. Специалисты первой линии работают напрямую с пользователем. Сегодня на первой линии работают 131 человек. В это число входят выделенные сотрудники и те, кто параллельно занимаются другими направлениями (аналитика, преподавание, внедрение).
На второй линии работают 17 выделенных сотрудников и более 60 привлекаются по мере необходимости. Это специалисты в узкой области, которые работают в тесной связке с разработчиками и помогают сотрудникам первой линии разбираться со сложными вопросами пользователей: подсказывают способы диагностики проблемы и ее причины, подключаются к запросам, связанным с ошибками в ПО или развитием функциональности, видят общую картину по всем обращениям пользователей и запрашивают в разработке исправления для критичных проблем в приоритетном порядке.
При этом в нашу систему входят не только асконовцы. Так, часть приложений к КОМПАС-3D разработана компаниями-партнерами. И если, например, у вас возникнет вопрос по работе приложения для экспресс-расчетов APM FEM, то ваше обращение будет перенаправлено сотруднику НТЦ «АПМ», компании-разработчика приложения.
И еще четыре человека составляют Центральную Службу технической поддержки АСКОН, которая находится в Петербурге. Ее сотрудники отвечают за слаженную работу всей службы поддержки АСКОН, обеспечивают работоспособность автоматизированной системы управления службой ServiceDESK, разрабатывают сервисы поддержки, контролируют и работают над их совершенствованием, ведут методическое сопровождение работы службы, а также занимаются вопросами, связанными с техническими аспектами системы лицензирования программных продуктов.
Наша служба создана для того, чтобы помогать пользователям наших систем решать свои задачи эффективнее. В большинстве случаев можно решить вопрос самостоятельно с помощью инструкций и справочных материалов, в сложных случаях следует обратиться в техподдержку — так будет быстрее. При этом важно, чтобы пользователь хорошо владел ПО, потому как обучение не входит в задачи нашего подразделения.
Любой программный продукт может содержать ошибки или неочевидные моменты, когда сам пользователь делает что-то не так. И это как раз тот пул вопросов, с которым может помочь только наша служба.
Кроме того, обращение в техподдержку — самый верный способ донести свои пожелания до разработчика. Все обращения пользователей в службу поддержки в обязательном порядке регистрируются в ServiceDESK, каждому запросу присваивается индивидуальный номер. Если запроса нет, считайте, что разработчик вас не услышал. Поэтому, если вы действительно хотите, чтобы ваше пожелание было реализовано, пишите в техподдержку, а не на форумах и в соцсетях.
Александр Горевой и Анна Соколова – ядро техподдержки АСКОН, сотрудники второй линии поддержки по КОМПАС и приложениям
Лучше звонить или писать?
В. Л.: Несомненно, вы можете звонить. Но при звонке специалист по внутреннему регламенту всё равно оформит проблему с ваших слов в виде обращения в SD.
Кроме того, для решения многих проблем нужна дополнительная информация (скриншоты, файлы): для собственного же удобства лучше оформить запрос через ServiceDESK или написать по e-mail, а если вопрос срочный, то ещё и позвонить, сославшись на уже зафиксированное обращение. Это самый эффективный способ коммуникации.
Где находится сотрудник техподдержки, которому я звоню?
В. Л.: Не важно, позвонили вы, написали на https://ascon.ru/services/support/ или обратились с запросом в ServiceDESK — с вами будет работать сотрудник первой линии поддержки. При звонке по номеру 8-800-700-00-78 система автоматически определяет регион и переводит абонента на специалиста первой линии поддержки из ближайшего к вам офиса.
Этот сотрудник будет решать вашу проблему, при необходимости привлекая других специалистов офиса или специалистов второй линии поддержки. Вся информация по запросу доступна всем работающим с ним сотрудникам через внутренний интерфейс ServiceDESK вне зависимости от их фактического места работы.
Зачем мне заводить Личный кабинет?
В. Л.: Во-первых, в Личном кабинете хранится вся история взаимодействия и отображается статус актуального запроса. Вы всегда можете сослаться на запрос или вернуться к решению, предложенному специалистом, если столкнулись с проблемой снова.
При этом Личный кабинет (ЛК) «привязан» не только к конкретному пользователю, но и предприятию: сотрудник может видеть, кроме своих, запросы коллег. То есть это еще и база знаний для, например, нового сотрудника предприятия.
Сервис постоянно развивается и предлагает новые возможности — это уже давно не только история запросов, в нем публикуются новости по продукту, дистрибутивы и различные обновления, ссылки на полезные внешние ресурсы.
Личный кабинет сегодня — это своеобразная агрегация сервисов, которые предлагает АСКОН. В ЛК можно посмотреть, какие именно сервисы доступны пользователю по различным продуктам, исходя из выбранного уровня техподдержки, какие лицензии приобретены, получить информацию из системы дистанционного обучения АСКОН.
Результаты опроса пользователей по оценке качества работы службы поддержки. Опрос ведется постоянно с 2015 года
Какие уровни техподдержки существуют и в чем их принципиальные отличия?
В. Л.: В аудиторию техподдержки входят не только обладатели лицензий на ПО, любой человек может воспользоваться нашими сервисами и получить ответы на вопросы о программных продуктах, их возможностях и многом другом. Это так называемый начальный уровень техподдержки.
Следующий уровень — базовый. Предоставляется бесплатно всем обладателям лицензий ПО АСКОН. Если пользователь хотя бы однажды приобретал какой-либо наш программный продукт, то базовый уровень по данному продукту и версии закреплен за ним навсегда.
Гарантийная техническая поддержка доступна в течение одного года после приобретения продукта или обновления. Взаимодействие на этом уровне строго регламентировано: время первого ответа на запрос — не более 8 рабочих часов, время на закрытие запроса (предоставление содержательного ответа по существу проблемы) — 40 рабочих часов. После окончания гарантийного обслуживания пользователь переводится на обслуживание по базовому уровню.
Базовый и гарантийный уровни доступны пользователям коммерческих версий наших программных продуктов. Пользователи некоммерческих версий (КОМПАС-3D Home, КОМПАС- 3D LT, ВЕРТИКАЛЬ Учебная версия и КОМПАС-3D Viewer) получают поддержку начального уровня.
Предприятиям, приобретающим опережающие обновления, доступна расширенная поддержка: они первыми получают приглашение на бета-тестирование, первыми узнают о выходе новой версии.
Наши внутренние тесты показывают высокий уровень удовлетворенности качеством гарантийного сервиса поддержки. Тем не менее с каждым годом всё больше предприятий выбирают индивидуальный, по сути самый высокий, уровень поддержки.
Как правило, эту услугу выбирают крупные предприятия или предприятия с выделенной IT-службой, которая понимает, каких эффектов она хочет и может получить в случае выбора индивидуальной поддержки. Услуга крайне востребована предприятиями, которые приобретают ПО, подразумевающее кастомизацию (речь про ПО, составляющее Комплекс решений АСКОН). Вы всегда можете обратиться в ближайший офис и договориться об индивидуальных сервисах поддержки, исходя из запросов предприятия. Для этого заключается отдельный договор, где оговариваются все условия взаимодействия.
Могу ли я обращаться к вам в выходные и в нерабочее время? И как решается проблема с часовыми поясами?
В. Л. Мы не работаем в выходные и праздничные дни, просто потому что наши основные пользователи — это сотрудники предприятий и организаций. В общем, мы работаем по такому же графику, что и наши заказчики.
По поводу часовых поясов, как я уже говорил, первая линия поддержки является распределенной: разбираться с вашим запросом будет ближайший к предприятию офис, который работает в вашем часовом поясе. Если вы работаете в выходной или праздничный день, то оформляйте запрос через SD или пишите письмо на https://ascon.ru/services/support/, или заключайте договор на индивидуальную поддержку.
При этом мы отслеживаем активность наших пользователей: графики показывают практически нулевую активность в выходные и праздничные дни от пользователей коммерческих продуктов. Но если ситуация изменится и появится потребность, то мы будем корректировать время работы.
Если же предприятие по каким-то причинам работает круглосуточно, то всегда можно обратиться в свой офис и договориться об индивидуальных условиях. Такие случаи есть. Например, один из заказчиков занимался массовым обновлением наших продуктов, и мы выделили сотрудников, которые были доступны в выходные дни и по вечерам.
Кажется, про мой запрос забыли. Что делать?
В. Л.: У нас есть строгие правила, которые регламентируют время первого ответа на запрос и время, отведенное на его закрытие. В соответствии с действующими регламентами, не менее 75% должны решаться (и решаются) в установленное время, но понятно, что не все вопросы можно решить в эти сроки. Если выясняется, что проблема требует дополнительных исследований, то наш специалист держит пользователя в курсе и сообщает (примерно раз в два дня) о прогрессе.
Но, конечно, бывают и исключения. Если вам кажется, что про вас забыли или решение, предложенное специалистом, вас не устроило, первый вариант — обратиться в ближайший офис АСКОН и напомнить о себе. Менеджер может посмотреть внутреннюю переписку по вашей проблеме и сказать, на какой стадии решения мы находимся. Второй — обратиться в Центральную Службу технической поддержки АСКОН (https://ascon.ru/services/support/) или лично ко мне (lipin@ascon.ru).
 |
 |
Процент запросов с просроченным временем первого ответа.
Показывает оперативность предоставления первого ответа на поступающие в ServiceDESK запросы
Процент запросов с просроченным временем решения.
Показывает, насколько сотрудники поддержки успевают решать запросы в установленное время. По регламенту — не более 25% запросов могут решаться с превышением отведенного времени
Кажется, сотрудники техподдержки запрашивают слишком много дополнительной информации, а еще файлы, с которыми я работаю. Это правда нужно?
В. Л.: Да, вам может казаться, что запрашиваемая информация (параметры компьютера, окружения, логи нашего ПО и логи Windows) никак не относится к проблеме. Кроме этого, техподдержка может запрашивать чертежи, модели, спецификации, техпроцессы. И это тоже может кого-то насторожить, ведь эти файлы относятся к интеллектуальной собственности предприятия. В общем, встает вопрос конфиденциальности.
Первое. Чем данных больше, тем лучше. И обращаясь к нам, лучше уже на стадии первого запроса предоставлять базовую информацию. Понятно, что какая-то информация действительно излишняя. Но сотрудник не видит вашего компьютера и не может воспроизвести ситуацию искусственно, поэтому, чем больше у него будет данных, тем быстрее он сможет вам помочь.
Что касается безопасности предоставления информации. Есть наша собственная утилита SD_Info, которой мы иногда предлагаем воспользоваться, она собирает информацию и оформляет ее в отчет в формате sd. По сути, это zip-архив с текстовыми документами, вы можете его распаковать и посмотреть, какие именно сведения отправляются. Перед отправкой логов вы также можете с ними познакомиться и оценить, несут ли они угрозу информационной безопасности.
Второе. Все наши сотрудники понимают, что предоставляемая пользователями информация конфиденциальна. И внутренние инструкции запрещают передавать ее во внешний мир.
Кроме того, перед отправкой файлов (моделей, чертежей, техпроцессов), вы можете их обезличить. Нам не нужна вся информация, а нужны минимально необходимые данные, чтобы воспроизвести проблему. Если вы можете показать эту же проблему на каком-то искусственном файле, пожалуйста. Нам будет даже проще. Если же проблема присуща только конкретной модели, то вы можете ее обезличить: убрать элементы, связанные с секретной информацией и указывающие на конкретное предприятие. Также можно удалить части документа, которые не относятся к проблеме. Нет необходимости отправлять насыщенный чертеж или модель.
Ну и третье. В отдельном порядке мы можем заключить с вашим предприятием соглашение о неразглашении, в котором дополнительно гарантируем конфиденциальность получаемой информации.
Можно ли меня перевести сразу на специалиста второй линии?
В. Л.: Все сотрудники первой линии обладают высокой квалификацией и отлично разбираются в продуктах. При этом сотрудники второй линии как узкие специалисты действительно обладают исключительными знаниями. И да, скорее всего, сотрудник второй линии сможет диагностировать проблему быстрее.
В день к нам поступает в среднем 130 запросов, и далеко не каждый из этих запросов является критичным. Это во-первых. А во-вторых, если все будут общаться со «второй линией», минуя первую, то существенно увеличится загрузка этих специалистов, что в итоге повлияет или на качество услуг по поддержке (увеличится срок ожидания ответа), или на стоимость ПО (придется увеличивать штат специалистов второй линии).
Для решения сложных проблем привлечение специалистов второй линии возможно. Данный вопрос решается через эскалацию запроса на руководителя службы поддержки.
Процент запросов решенных без привлечения специалистов второй линии.
Показывает, насколько самостоятельно сотрудники первой линии поддержки справляются с решением запросов. Регламентированное значение — не менее 75% запросов
Я отправил запрос, техподдержка его закрыла, но проблема не решена. Что происходит?
В. Л.: Если запрос связан с пожеланием реализации какой-то функциональности или улучшением продукта (в нашей терминологии — предложения), то техподдержка не знает точного ответа, когда оно будет реализовано. Этого вообще никто не знает до того момента, пока предложение не будет проработано аналитиками, не будет оценена трудоемкость его реализации и оно не будет включено в план на очередную версию ПО. В любом случае все внятно сформулированные и обоснованные предложения регистрируются и передаются в разработку.
В Личном кабинете каждому предложению присваивается номер, по которому вы можете увидеть его состояние. Если оно попало в план по разработке, то вам сообщат. Если запрос кажется вам чрезвычайно важным, то не стесняйтесь интересоваться его судьбой (в разумных временных интервалах). Советую также добавлять к просьбе описание того, в каких именно практических ситуациях необходима запрашиваемая функциональность, это существенно влияет на сроки попадания предложения в план разработки.
Что касается ошибок. Есть понятие «блокирующей» (мешает использованию полезных свойств продукта) и «не блокирующей» ошибки. Конечно, блокирующие ошибки — первые в очереди на устранение. При этом важно понимать, что одна и та же ошибка может быть для кого-то блокирующей, а для кого-то совсем нет.
Например, есть какая-то специфическая операция, с которой пользователь работает постоянно. Если эта операция дала сбой, то он не может решить свои задачи. Цель специалиста техподдержки на первом этапе — выяснить, является ли проблема блокирующей или нет. И здесь важно отличать эмоции от объективной картины.
Не все проблемы имеют прямое решение. И в этом случае техподдержка предлагает обходной путь. Если этого не было сделано, то это повод открыть запрос снова и спросить, почему это произошло.
Есть ли вопросы, на которые не может ответить техподдержка?
В. Л.: Мы стараемся отвечать на все вопросы. Самостоятельно или передав вопрос коллегам, которые помогут на него ответить, если он не относится к нашим задачам. Даже если нас спрашивают про матрасы Ascona, мы ответим, что вопрос попал не по адресу.
Важно понимать, что в задачи техподдержки не входит обучение: нередко вопросы связаны с тем, что пользователи не до конца освоили функциональность продукта. Здесь мы бессильны: обучение через электронную почту или по телефону в принципе не может быть эффективно. Подобные обращения мы передаем куратору предприятия, который свяжется с пользователем и подскажет, какие материалы нужно изучить, чтобы снять вопрос, или поможет организовать обучение у квалифицированного преподавателя.
Что нужно сделать, чтобы мою проблему решили максимально быстро?
В. Л.: Здесь работают законы коммуникации. Если вы хотите, чтобы ваша проблема решилась как можно быстрее, формулируйте ее максимально детально и однозначно.
Вам может показаться, что из описания сотрудникам техподдержки очевидно, какую проблему вы хотите решить. Это не так. Поэтому я всегда рекомендую заканчивать любое обращение выводом о том, что вы хотите получить в итоге. Как минимум, в вашем запросе должно быть хотя бы одно предложение со знаком вопроса.
Второе — в диалоге с сотрудником техподдержки не упускайте из вида исходную, ключевую проблему вашего обращения. Чтобы не уйти в сторону, необходимо отслеживать, правильно ли специалист понимает, над решением какой проблемы мы работаем в данный момент. Если в процессе решения одной проблемы, появляются другие проблемы или вопросы — их необходимо выделять в отдельные запросы.