Как улучшить сервис

Ни для кого не секрет, что качество сервиса во многом определяет его успех.

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

Итак, вы владеете или управляете некоторым сервисом. У вас есть клиенты. От степени их удовлетворенности зависит прибыль вашего продукта и успех в целом. Вы решаете сделать его лучше. Стоит заметить, что вы уже создали продукт, руководствуясь какими-то вашими внутренними установками или с помощью книг, статей, друзей. Это огромная работа, ведь вы создали настоящую ценность, что-то реально работающее.

Сначала вам стоит понять какого рода изменения необходимо внести в первую очередь для увеличения прибыли/рентабельности/посещаемости (выберите сами). Учтите, что каждое изменение стоит денег и занимает время. И каждое изменение имеет потенциал, в некоторой степени влияющий на показатели, увеличение которых вы ставите себе в цель.

К примеру, вы можете пригласить копирайтера и исправить все грамматические ошибки на своем сайте, в приложении и рекламных материалах. Но какую ценность это добавит? Да, я и такие же представители граммар-наци не будут ворчать при использовании вашего продукта. Но вряд ли это позволит заметно увеличить прибыль.

Вы также можете затеять глобальную переработку сервиса, нанять для этого людей, переделать буквально все. Да, это даст эффект, но какой ценой и когда?

Именно поэтому я предлагаю вам определить несколько категорий изменений.

Вы можете разложить их на карте вроде приведенной ниже.

Здесь 1 - минимальное время, низкая стоимость и наименьшее влияние на результат; 10 - максимальное время, высокая цена и максимальное влияние на достижение цели.

И далее "пускать в работу" те изменения, которые соответствуют текущим возможностям - бюджету, трудовым ресурсам, требуемой скорости увеличения отдачи.

Лично я обычно наряду с выбранными задачами подмешиваю простые и не очень важные. По нескольким причинам. Во-первых, есть высокая вероятность, что вы никогда не дойдете до исправления мелких косяков и они так и будут мозолить глаза пользователям. Во-вторых, это полезно для исполнителей - они отвлекаются и отмечают маленькие победы гораздо чаще, чем постоянно работая над тяжелыми, продолжительными и важными задачами. Ну и, в третьих, я же бывший перфекционист. И для меня часто таблица, описанная выше, превращается в таблицу из двух столбцов - "Изменение" и "Важно". И при этом во втором столбце стоит "100 по десятибалльной шкале" :)

Вы можете использовать и другие способы ранжирования задач - как более простые, так и более сложные. Вот пример более простого списка приоритетов:

Это может быть применено, когда все разработчики у вас в штате и у них есть свой лидер, который выстроит их работу должным образом.

Можно, наоборот, сделать более подробную карту задач. Например, такую:

Конечная цель такова - все участники должны понимать ЧТО надо сделать, КОГДА это надо сделать и ДЛЯ ЧЕГО это надо сделать. Да, именно ВСЕ участники. Даже айтишники, даже те, которые на аутсорсе, даже дизайнер должен понимать для чего делается резервное копирование на серверной стороне. Хотя бы в общих чертах. Это может показаться лишним, но, поверьте, на практике вы все равно не дойдете до этого. Это гипертрофированная цель. Но очень важно, чтобы команда реализовывала изменения максимально осознанно. Все мы люди и каждому важно понимать ценность его вклада. Плюс внутрикомандные коммуникации способствуют вовлечению в совместную работу. И часто в результате такого общения у сотрудников появляются стоящие идеи, относящиеся к другому направлению. Свежий взгляд, так сказать. Поэтому не надо изолировать направления (отделы) без особой необходимости.

Отдельно хочу описать способы формирования самого списка изменений. Как понять что нужно менять, что вообще здесь не так?

Первое, что приходит на ум - это записать в эту графу все известные баги. Верно, записывайте.

Второе, это опросить всех сотрудников, что они изменили бы. Опросите и запишите все, что они скажут. Потом отфильтруете на свежую голову.

Далее можно провести несколько мозговых штурмов. Как их провести грамотно описано много где. Погуглите. Свой опыт я расскажу в отдельной статье.

Если у вас есть "Банк идей", "Книга для предложений" или что-то вроде, прочешите их и выпишите стоящие идеи в список.

Если вы работаете с внешними консультантами или тестировщиками - получите список от них. Их взгляд снаружи может открыть много нового.

Фокус-группы. Никогда их не любил, но это тоже вариант получения списка изменений.

В итоге у вас получится простыня на много страниц. Вот тут то вы и включите фильтры по столбцам "Время", "Цена", "Важность" и выберете то, что будете делать на первом этапе, на втором и далее.

Если в ходе работы появятся новые строки в вашей таблице, то вам следует их отранжировать и обновить список, исходя из ресурсов. Вполне может так случиться, что вы "вспомните" что-то очень важное не в первую очередь. Просто подвиньте менее важные пункты ниже.

Ну вот, вы получили "живой" список изменений. Надо начинать их реализовывать.

Тут вам потребуется какая-нибудь система управления задачами. Их много на любой вкус - Jira, Asana, Slack, Microsoft Project… Я пользовался разными для разных проектов. В корпорациях больше любят Jira и Microsoft Project, в более гибких компаниях - Asana, Wrike и Slack.

Работу с этими системами оставим на вас. Я же расскажу о том, что следует помнить в ежедневной работе.

Раз мы занимаемся внесением изменений, направленных на рост показателей, то первое, что следует контролировать так это, чтобы показатели не падали. Да, такое бывает. Взялись рьяно за обновления и сломали систему. Это крайность, но также стоит следить за текущими параметрами и выстраивать работу максимально незаметно для пользователей. Если вы вносите существенные изменения, обязательно встаньте на сторону клиента и убедитесь, что все в порядке. Если вы старый клиент, то вам должны быть понятны изменения. Или же вы должны быть проинформированы о них заранее. Или вам должен быть показан туториал, описывающий нововведения. В общем, ответ на вопрос "Как сделать клиенту хорошо?" не должен звучать "Сначала надо сделать плохо, а потом как было." Следите за этим.

Следующий момент - тестирование. Постоянное. Неправильно делать предрелизное тестирование и пострелизное. Тестирование должно стать частью корпоративной культуры. Также как здороваться при встрече. Сделал что-то - проверь. Проверил? Проверь снова.

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

Роль тестировщиков в том, чтобы свежим взглядом перепроверить. Если тестировщики выдают много замечаний, это значит, что не все в порядке с разработкой. Но правда и в том, что если они выдают мало замечаний, то это, как правило, не означает, что разработка идеальна. Скорее всего, у вас фиговые тестировщики. :)

Опять же без отсылок к научным методикам. Чисто из опыта.

Тестирование - одна из важнейших функций при создании хорошего продукта. Никто не может "писать начисто" сразу. И первое, что стоит сделать, так это привить правильное отношение к тестировщикам. Разработчики не должны воспринимать результаты тестов, как оскорбления или как-то еще, кроме как "здесь не все идеально, надо еще поработать". Это очень важно. Иначе дальше могут начаться уже межличностные взаимодействия. Например, если тестировщик юн и зелен, а программист уже давно с бородой и в свитере, первый может начать "замыливать" мелкие косяки, чтобы не видеть испепеляющих взглядов второго. Это также важно и для того, чтобы баги удалялись из списков только в случае их полного устранения или осознанного закрытия по факту оценки по вышеописанным методикам, но не после разговоров один на один в коридоре.

Теперь несколько мыслей непосредственно для тестировщиков.

Вы должны быть внимательными, это понятно. Но никто не может быть всегда сконцентрированным. Поэтому записывайте. Записывайте все. Скриншотьте, делайте видеозаписи экранов. Многие ошибки трудно описать словами. Некоторые проявляются "не в тот момент". Вы можете забыть, как вы это воспроизвели. Вы можете забыть где это было или когда. А все это очень важно для быстрого и качественного исправления.

Ваша работа циклична. И количество вложенных циклов может быть огромным. Так что вполне оправдано делать программы тестирования. Опять же в любом приемлемом виде.

Например, если вы тестируете мобильное приложение "Личный кабинет", ваша карта может выглядеть так:

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

Следующий момент. "Защита от дурака". Она должна быть. И многие разработчики уже на уровне подсознания ее ставят. Но именно ваша задача это проверить. Поэтому на этом этапе выключаете мозг и вперёд! Вводите цифры в поле для номера телефона, кликайте сразу на три кнопки, переворачивайте телефон во время авторизации, оставляйте обязательные поля пустыми, а в необязательные вставляйте ссылки, отвечайте на звонок во время загрузки приложения. Это мой любимый момент. Настоящая отдушина от рутины. Ниже более полный список на случай, если ваш мозг здоров и не способен придумать таких кейсов. Поверьте, каждый из них однажды проявлялся в моей практике.

В сети вы можете найти множество чек-листов от гуру. Со временем вы дополните их своими кейсами и ваша ценность как специалиста будет расти.