Support. Откуда и зачем?
Когда же компания понимает необходимость выделения отдельной структурной единицы для поддержки пользователей?
Обычно, это выглядит так: небольшой стартап разрастается, набирает жирок. Количество юзеров потихоньку увеличивается, и программист (менеджер проекта, админ), ранее уделявшие общению с ними некоторое количество рабочего времени, уже не успевают отвечать на входящую почту/звонки. Или просто надоедает отвечать на “Почему не работает?” и “А чо это ваще такое?“. Надо вводить разделение обязанностей и организовывать отдел саппорта. Обычно, растущие проекты подходят к этому довольно-таки наплевательски. Ну а чо? Посадим студента Петю, пускай за n вечнозеленых единиц в почту смотрит и на звонки отвечает. Работёнка не пыльная – квалификации особой не требует. Расскажем ему за полдня что такое наш сервис/программа и вперёд!
Проекту очень повезет, в том случае, если студент Петя не редиска, и отнесётся к работе серьёзно и поймет, что он теперь не просто мальчик на телефоне, а будущий руководитель отдела, о чем в большинстве случаев просто забывают упомянуть. В большинстве случаев происходит наоборот: Петя считает (не потому что он такой плохой, а потому что так объяснили работодатели), что он сидит на телефоне и в ус не дует, его обязанности – отвечать юзерам. Не справляюсь с растущим количеством заявок юзеров, да и хер с ним – гори оно всё синим пламенем. Юзер жалуется на багу – ну и что? Я человек маленький – пускай программисты думают – они умные. Приводит это к плачевным результатам. Недовольны все: юзеры – качеством сервиса, Петя – количеством юзеров, с которым ему уже не справится, начальство – имиджем проекта, о котором красноречиво написали обиженные пользователи на просторах интернета.
Все было бы наоборот, если нашему Петру объяснили при приеме на работу, что он не шлагбаум между сервисом и его пользователями, а Главный Юзер, который имеет непосредственное влияние на сервис. Разница – огромна. Саппорт – представитель всех пользователей внутри компании, защитник униженных и оскорбленных, заказчик доработок и исправления багов. Как правило, руководство компании об этом забывает, закрывая основной и самый важный канал фидбэка.
А всего-то и надо было, понять зачем проекту саппорт. Обозначить цели его создания и описать должностные обязанности, которые ну никак не состоят в посылании в прекрасное далеко бедных юзеров.
Но об этом далее.
Ага ага.
Буду обратно тырить
ты всю эту шляпу сам написал?))))
или спиздел откуда-т?)))
зы. кста после того как отдает ошибку, при откате не сохраняет введенные данные))))
Копирайты не забудь.
Я и сам с усам.