7 витаминов для сервиса. Как обеспечить сервис командой мотивированных сотрудников08.12.2015 15:37

Вот ряд проблем, которые рано или поздно встают перед сервисными командами:

1. задачи на сервисе бывают похожи одна на другую — надоедает;
2. «каждый пилит свой кусочек», нет живого общения, нет команды;
3. у работы нет развития и окончания — стагнация.

Мы с этим боремся примерно так:

1. В команду компании постоянно берут выпускников институтов. Нет, это не значит, что мы делаем поддержку студентами. Просто для многих наш проект — это точка старта в компании, возможность поучиться на чужом коде. Часть из них остается в команде, и через год другой становится качественными специалистами. Вообще надо понимать, что сервисный проект обычно подразумевает постоянную ротацию людей, и задача менеджера воспитать замену и поддержать знания, а не удержать людей как можно дольше. Я заметила, что программисты, работавшие на сервисе, когда пишут код, думают о том, что кто-то будет его поддерживать: трепетно относятся к комментариям и сложнее соглашаются на костыли. Ещё, некоторым нравится учить студентов, раскрывая педагогические таланты.
2. У всех есть план развития, не только у студентов. Мы вместе проговариваем, как человек планирует развиваться. Если в нашей команде нет возможностей для развития в нужном направлении, возможен переход в другой проект. Я за то, чтобы человек получал максимум от работы и не делал те задачи, из которых он уже вырос.
3. Взаимозаменяемость. Один участок проекта должны знать, как минимум, два специалиста. Так проще уходить в отпуск и брать новые задачи, если старые уже приелись.
4. Более, чем где-то ещё, на сервисе нужно давать людям время развивать свою разработку или позволять участвовать в каком-то другом интересном проекте. Разработка для мобильных устройств, внутренний портал — на все это нужно давать время. В большой компании подобные проекты как-то органично появляются сами, если у вас нет стороннего проекта — можно придумать.
5. Непрерывные улучшения. У нас был случай, когда время загрузки баз уменьшилось с нескольких дней до пары часов несколькими строками кода. Такие вещи нужно отмечать и постоянно просить команду об этом думать. Хорошо бывает ставить цели на улучшение определенных процессов. Например, если поставить цель уменьшить среднее время разрешения тикета, могут вскрыться интересные проблемы. У нас было так: выяснилось, что довольно часто пользователи из Германии обращаются к нам по-немецки, и нам приходится просить их снова описать проблему, но уже по-английски. Если в шапке формы написать «Пожалуйста, опишите проблему по-английски», можно улучшить показатели. Помозговать на тему «что может идти не так», бывает удивительно интересно.
6. Ежедневные стендапы. Не больше 15 минут на 10 человек. Когда я была разработчиком, я тоже думала что любой митинг — это пустая трата времени. Только мне, как менеджеру, много раз приходилось через 15 минут выгонять коллег из переговорки силком и говорить, что митинг кончился, а они, тем временем, ещё полчаса стояли и обсуждали проблемы, которые никогда бы не всплыли, если б не были подняты на обсуждение. Плюс подобные совместные решения проблем делают из группы людей команду и способствуют ротации знаний.
7. Гемификация. Включать взрослых людей в игру — это особый талант. Кому больше ночных звонков досталось, кто первый пришел на стендап и кто чаще всего опаздывал — из этого всего можно сделать шутливое соревнование с потешными призами.

Если обобщать, миссия менеджера на таком проекте, при отсутствии глобальной конечной цели — выявить и поставить перед людьми несколько локальных задач:

1. развитие каждого члена команды;
2. улучшение конкретных показателей сервиса и, как следствие, улучшение процессов;
3. поддержка и передача знаний, обучение новеньких;
4. получение удовольствия от работы. Я оставлю это здесь как цель, потому что это правда важно, особенно на сервисе.

Автор Fkleto4ku

• ↑

  —

  ↓

• 226

• Добавить в избранное 4