Support. Откуда и зачем?

[itsmonline]

Когда же компания понимает необходимость выделения отдельной структурной единицы для поддержки пользователей?

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

Проекту очень повезет, в том случае, если студент Петя не редиска, и отнесётся к работе серьёзно и поймет, что он теперь не просто мальчик на телефоне, а будущий руководитель отдела, о чем в большинстве случаев просто забывают упомянуть. В большинстве случаев происходит наоборот: Петя считает (не потому что он такой плохой, а потому что так объяснили работодатели), что он сидит на телефоне и в ус не дует, его обязанности - отвечать юзерам. Не справляюсь с растущим количеством заявок юзеров, да и хер с ним - гори оно всё синим пламенем. Юзер жалуется на багу - ну и что? Я человек маленький - пускай программисты думают - они умные. Приводит это к плачевным результатам. Недовольны все: юзеры - качеством сервиса, Петя - количеством юзеров, с которым ему уже не справится, начальство - имиджем проекта, о котором красноречиво написали обиженные пользователи на просторах интернета.

Все было бы наоборот, если нашему Петру объяснили при приеме на работу, что он не шлагбаум между сервисом и его пользователями, а Главный Юзер, который имеет непосредственное влияние на сервис. Разница - огромна. Саппорт - представитель всех пользователей внутри компании, защитник униженных и оскорбленных, заказчик доработок и исправления багов. Как правило, руководство компании об этом забывает, закрывая основной и самый важный канал фидбэка.

А всего-то и надо было, понять зачем проекту саппорт. Обозначить цели его создания и описать должностные обязанности, которые ну никак не состоят в посылании в прекрасное далеко бедных юзеров.

http://nick.kugaevsky.ru/