Цена одной ошибки в сервисе

Вряд ли существует такой отель, персонал которого никогда не ошибается, и как бы мы ни старались делать все идеально, время от времени будут возникать проблемы.

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

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

Жалобы могут возникать по нескольким причинам: технические сбои и неполадки, форс-мажор и ошибки, связанные с нестабильным качеством сервиса. Сколько же стоит ошибка? Цена может оказаться высокой: отель потеряет гостя, а вместе с ним – инвестиции в рекламу и маркетинг, которые были выделены на его поиск.

Почему гость не вернется?

Хорошо, когда все хорошо, но истинный уровень сервиса проявляется именно тогда, когда гость сталкивается с проблемами. Как отмечал американский специалист в области культуры сервиса Джон Шоул: «Сервис – это не то, что компания заявляет в своих лозунгах. Это то, как клиент оценивает уровень сервиса компании». Что может помешать успеху? Одной из причин может стать отсутствие трех составляющих:

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

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

Крупные гостиничные сети уже осознали, что именно линейный персонал обычно решает проблемы гостя и им часто приходится принимать удар на себя, поэтому не только разрабатывают четкие инструкции и инвестируют в систематическое обучение команды, но и наделяют работников необходимыми полномочиями. 50-70 % гостей становятся лояльными и возвращаются, если остаются довольными решением своего вопроса. Этот показатель может увеличиться до 90 %, если проблема будет решена меньше чем за час (источник данных: «Первоклассный сервис как конкурентное преимущество», Дж. Шоул).

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

Парадокс возмещения

Парадокс возмещения, или Service Recovery Paradox, заключается в том, что именно гость, который столкнулся с проблемами во время пребывания и остался доволен их разрешением, становится более лояльным к бренду, нежели гость, у которого все было просто хорошо.

Решение проблемы должно состоять из двух этапов: исправления ошибки и компенсации. Но почему недостаточно только исправления ошибки? Любой негативный опыт оставляет неприятный эмоциональный осадок, и если не удается его устранить и вернуть гостя из состояния «минуса» в «плюс», то негативная эмоция будет окрашивать в серые краски все остальные впечатления, связанные с пребыванием в отеле. Цель компенсации – предотвращение потери клиента, так как поиски нового обойдутся компании намного дороже.

Отказ – не самое лучшее решение в индустрии гостеприимства. Можно выиграть спор, но при этом потерять гостя. Безусловно, бывают ситуации, когда мы не можем пойти против правил и установленного порядка, но даже в таких случаях зачастую можно найти альтернативное компромиссное решение. Важно помнить, что 50 % успеха в исправлении ошибки – это уважительное отношение к потребностям гостя и желание персонала быть «за», а не «против» поиска оптимального решения.

6 сентября 1989 года парижанам запомнилось надолго — в этот день более 41 тысячи жителей французской столицы получили из полиции официальные письма о том, что они совершили жестокие убийства и грабежи, хотя на самом деле адресаты всего лишь нарушили правила дорожного движения.

Ни одна программа в мире, за исключением, пожалуй, “Hello World!” полностью не застрахована от ошибок. А что уж говорить о больших приложениях, состоящих из миллионов строк кода, разработкой которых занимаются целые команды программистов. Да, прежде чем попасть в продакшен, такие программные продукты тщательно документируются и проходят через заботливые руки тестировщиков, но суровая реальность все равно вносит в логику их работы свои коррективы.

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

Крупнейшая банковская ошибка в истории Америки

Тёплым майским днем 1996 года инкассатор частной чикагской компании по обслуживанию газового оборудования «Peoples Gas Light and Coke» Сильвестр Дорси отправился на обед. По пути он решил завернуть к ближайшему банкомату, чтобы проверить остаток на счете своей банковской карты. Получив чек с выпиской, Дорси не поверил собственным глазам. Он оказался владельцем скромного состояния размером 924,8 миллионов долларов США. «Я показал чек другу, который находился рядом, и мы просто закричали от восторга», — вспоминал потом этот случай Дорси.

Еще одним счастливчиком стал компьютерный инженер из компании «Zenith Electronics» Джеф Феррера, который позвонил в банк в пятницу утром в попытке уточнить свой баланс. Прослушав сообщение автоматического информатора, Джеф перезвонил еще раз, записал голос робота на диктофон и установил эту запись в качестве приветствия на своем телефоне. Теперь каждый звонящий Феррере абонент слышал в трубке следующее сообщение: «доступный остаток на вашем основном счете в настоящее время составляет 924 844 208 долларов США и 32 цента…». Можно только представить, какие чувства испытывал сам Джеф, когда автоинформатор впервые произнес эти слова.

Такая же участь постигла 825 других клиентов «Первого национального банка Чикаго» — все они неожиданно стали мультимиллионерами. Правда, счастье длилось недолго: всего один день. К вечеру которого сотрудники банка выяснили, что источником неимоверного богатства владельцев счетов стал досадный компьютерный сбой. Обслуживавшая дебетовые карты программа неправильно рассчитала параметры последних транзакций и перевела клиентам ошеломляющую сумму денег — 763,8 миллиарда долларов, что более чем в шесть раз превышало общую стоимость всех активов «Первого национального банка Чикаго».

Уже к вечеру счета новоявленных миллионеров были заморожены, а ошибочно зачисленные суммы — благополучно списаны. По словам представителей банка, никто из клиентов не успел сбежать с неожиданным кушем на острова Карибского архипелага, поэтому реальные финансовые потери компании оказались минимальными. Но этот инцидент и по сей день считается крупнейшей банковской ошибкой в истории США, к которой привел сбой в компьютерной программе.

К слову, за два года до описываемых событий нечто подобное случилось в нью-йоркском Chemical Bank, правда, с обратным математическим знаком. Заглючивший компьютер ополовинил все депозиты и вклады, информация о которых хранилась в базе данных головного офиса, и вместо нескольких сотен счастливых миллионеров банк получил целую армию разгневанных клиентов. Последствия этого сбоя технические специалисты разгребали несколько дней.

Но это же палка!

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

Как и многие другие американцы, Крис Рейнольдс пользовался платежной системой PayPal, и наивно считал ее лучшим финансовым сервисом в мире. Его высокое мнение о достоинствах и возможностях PayPal многократно укрепилось, когда однажды утром 30 июня 2013 года он обнаружил на своем счете 92 233 720 368 547 800 долларов США.

Еще раз: 92 квадриллиона долларов. Для торговца подержанными автозапчастями на eBay это была довольно приличная сумма: состояние самого богатого человека планеты того года — телекоммуникационного магната Карлоса Слима — слегка не дотягивало до богатства Рейнольдса, и насчитывало всего лишь жалкие 67 миллиардов долларов.

Крис даже распечатал на память выписку по своему счету. Однако после того как он воспользовался мудрым советом из телесериала «Компьютерщики», а именно, «попробовал выйти и снова войти», чудесное наваждение рассеялось. На его балансе снова числилось 145 баксов и 25 центов, а Карлос Слим вновь вернулся на почетное место главного богатея Земли. Сказка закончилась, и несметные сокровища превратились в тыкву.

В PayPal признали сбой своего серверного ПО, и в качестве компенсации предложили расстроенному Рейнольдсу перечислить любую разумную сумму на какие-нибудь благотворительные цели. Когда журналисты ВВС спросили несостоявшегося квадриллиардера, на что он потратил бы эти деньги, если бы получил их в реальности, тот ответил: «погасил бы внешний долг США».

Вам счёт, сэр!

Впрочем, финансовые ошибки допускают не только компьютеры банков, в чем смогла лично убедиться семья Бразертон из графства Ланкашир, что расположено в Англии на берегу Ирландского моря. Линда и Найджел Бразертон решили сменить поставщика электроэнергии: раньше они пользовались услугами компании Scottish Power, но однажды подумали, что выгоднее будет покупать электричество у фирмы Npower. Однако они ошибались.

Сотрудник Npower осмотрел установленный в доме Бразертонов электросчетчик и обнулил его показания. Но компьютер компании посчитал, что значение «0» на индикаторе означает: с момента последней передачи сведений об израсходованной электроэнергии счетчик открутил полный цикл, и доступные ему цифры просто закончились. В следующем месяце почтенное семейство получило квитанцию, гласившую, что их платеж за электроэнергию слегка увеличился — с 87 фунтов стерлингов до 53 480 062 фунтов, что составляет примерно 90 миллионов долларов США.

Проведенное расследование показало: в используемом Npower программном обеспечении просто не была предусмотрена такая операция, как обнуление показаний электросчетчика вручную, а представитель компании этого не знал. Ошибка программистов стоила Найджелу Бразертону и его жене изрядного количества нервных клеток, но 53 миллиона фунтов им платить все-таки не пришлось.

Минус 460 миллионов за 45 минут

В среду, 1 августа 2012 года офис инвестиционной компании Knight Capital как всегда начал работу в 8 утра. Включив компьютеры, сотрудники первым делом проверили электронную почту, и среди спама обнаружили автоматические сообщения о том, что запущенная на сервере программа Power Peg настроена неправильно. Никто не обратил внимания на эти предупреждения, потому что Power Peg не использовалась уже без малого 10 лет, с 2003 года. И совершенно напрасно.

В 9 утра открылась нью-йоркская фондовая биржа, и автоматические системы трейдинга Knight Capital начали создавать заявки на покупку и продажу активов. Уже спустя 45 минут компания потеряла более 4,5 миллионов долларов, а вскоре общий убыток, полученный фирмой благодаря заключенным бездушными программами сделкам, достиг 460 миллионов долларов США, поставив Knight Capital на грань банкротства. Автоматические алгоритмы других игроков использовали возникшую ситуацию, из-за чего акции некоторых компаний на нью-йоркской бирже подскочили в цене аж на 300%.

Проведенное позже исследование показало: накануне этого злополучного дня на серверы Knight Capital было установлено обновление ПО, которое по недосмотру разработчиков включило устаревшее приложение Power Peg, уже давно отключенное за ненадобностью. В тестовом режиме это приложение продаёт акции по текущей цене и тут же покупает их обратно по рыночной ставке (которая обычно выше цены продажи), совершенно не обращая внимания на стоимость ценных бумаг — в его задачу входит провести как можно больше сделок в единицу времени. После вывода этой программы из эксплуатации разработчики удалили из ее кода проверку того, запущено ли приложение на тестовом сервере в локальной сети, или оно действует в реальной рабочей обстановке.

Как оказалось, установленное обновление запустило Power Peg на сервере, подключенном к нью-йоркской фондовой бирже, после чего программа заработала в тестовом режиме и начала регистрировать огромное количество безумных сделок, стремительно сливая капиталы компании. Чуть позже комиссия по ценным бумагам еще и оштрафовала Knight Capital на 12 миллионов долларов за нарушения правил управления финансовыми рисками.

Яблочные карты

Некоторые ошибки в софте вроде бы не приводят к возникновению прямых финансовых убытков, но иногда влекут за собой косвенные. На первых моделях iPhone использовались карты и навигация от Google, но в борьбе со своим главным конкурентом корпорация Apple решила избавиться от приложения Google Maps. В 2012 году в Купертино разработали собственную версию карт для iOS, однако в отличие от Google, которая потратила на создание своего сервиса много лет и миллионы долларов, в Apple решили, что задачу можно решить быстрее и намного экономнее. Информация о дорогах, мостах, архитектурных объектах и достопримечательностях стекается в Google из тысяч различных источников, хранится в нескольких распределенных базах данных, а сборку всех этих сведений воедино выполняет мощный программный комплекс. У Apple на начальном этапе не было всех этих ресурсов.

В результате на экранах iPhone и iPad многие озера, мосты и вокзалы отсутствовали на своих привычных местах, монумент Вашингтона переехал на соседнюю улицу, супермаркет Publix в городе Джексонвилл, штат Флорида, стал больницей, а главный вокзал столицы Новой Зеландии, города Окленд, и вовсе очутился посреди океана. В трехмерном представлении некоторые участки карт и вовсе выглядели фантастически: шоссе складывались гребёнкой, устремлялись вертикально в небо и скручивались лентой Мебиуса, мосты уходили под воду, а здания громоздились посреди водной глади.

Безусловно, никто из пользователей карт Apple не нырнул на своем автомобиле с оклендской набережной в попытке догнать уходящий поезд, но доверие к программам этой компании все же было слегка подорвано. А репутация в наши дни стоит очень дорого.

Заключение

Чаще всего от ошибок в программах страдают не только компании, но и обычные пользователи. Иногда разработчики пытаются загладить свою вину и компенсировать людям доставленные неудобства. Правда, порой они делают это весьма странным образом. Например, звонок в службу поддержки клиентов «Первого национального банка Чикаго» стоил целых три доллара. После инцидента с ошибочным зачислением на дебетовые карточки 924,8 миллионов руководство банка сделало задушевные беседы со своими сотрудниками бесплатной услугой. Но только для тех клиентов, которые сами сообщили в учреждение о свалившемся на них нежданном богатстве и добровольно вернули деньги. Неслыханная щедрость, не правда ли?

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

Цена ошибки: как экономия приводит к повышенным тратам

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

Экономия затрагивает самые разные сферы проекта и специалистов. В этой статье рассмотрим обеспечение качества (QA). Бизнес нередко считает, что тестирование – та часть проекта, на которой можно сэкономить, что за качество должны отвечать разработчики, а QA-специалистов иногда можно и не привлекать. Наш коллега Андрей на конкретных примерах покажет, к каким последствиям приводят наиболее популярные случаи экономии на QA.

Вариант 1. Отсутствие тестирования на ранних этапах

Начнем с классического случая экономии на проекте – отсутствия тестирования на ранних этапах жизненного цикла ПО.  

Первоначальная выгода от такого решения кажется очевидной – пока не накопилось достаточного объема кода для тестирования, подключение QA-специалистов некритично. Однако оправданность такого решения при детальном рассмотрении оказывается сомнительной.  

Многие слышали фразу «Чем раньше найден баг, тем проще и дешевле его исправить», давайте разберемся, почему это так и насколько дешевле. Поскольку баги появляются в фичах, представим упрощенный жизненный цикл фичи, который существует в большинстве проектов: 

1. Идея

2. Написание технического задания (далее – ТЗ)

3. Реализация

4. Тестирование

5. Выход в релиз

Обратите внимание, что на этой схеме QA подключаются довольно поздно – на этапе тестирования. Используя этот алгоритм, легко вычислить, что: 

• Если в фиче нет дефектов, то каждый участник жизненного цикла затрачивает свое время 1 раз, таким образом разработка стоит 5 условных часов.

• Если баг допущен на этапе реализации и найден на этапе тестирования, то разработчик и QA затрачивают по одной дополнительной единице времени: на фикс бага и на повторное тестирование (ретест) исправленной фичи, соответственно. В итоге получается: 5+2=7 единиц времени. У вас может возникнуть вопрос, почему мы считаем 5 часов, а не 4, если после тестирования фича не пошла в релиз? Потому что после исправлений и повторного тестирования все равно наступает релиз.

• Если баг допущен на этапе написания ТЗ и найден на этапе тестирования, то единиц времени будет 8 (5+3 на: исправление ТЗ, фикс бага , ретест)

• Если баг допущен в самой идее фичи и выявлен на этапе тестирования, то будет затрачено 9 единиц времени (5+4 на: коррекцию идеи, исправление ТЗ, фикс бага, ретест исправлений)

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

Тестирование постановок (ТЗ) – одно из популярных решений тренда на раннее тестирование или, как это называют некоторые компании,  «shift left».

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

 Начнем с возникновения дефектов. Мы собрали статистику со 117 проектов в различных сферах и анализ показал, что 66 % багов возникают на этапе реализации (написания кода), 31% — на этапе постановки задачи и 3% дефектов содержатся в идеях фич.

Возникает вопрос: «А как же интеграционные баги?» Фича рассматривается как самостоятельная сущность, а интеграционный баг – это либо проблема внешнего сервиса и ее не решить силами команды, либо фича неправильно взаимодействует с исправным внешним компонентом.  

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

Переходим ко времени, которое затрачивается на тестирование требований.

Практика показывает, что тестирование требований на одну фичу (именно требований, а не фич) в среднем занимает от 25 минут до 6 часов. Значения более 2,5 часов встречаются крайне редко, а 4 и более часа ревью свидетельствуют о том, что фича перегружена требованиями и ей требуется декомпозиция.

Теперь рассмотрим время, затрачиваемое на корректировку ТЗ.

Исправления ТЗ занимают от 10 минут в случае мелких опечаток до 9-10 часов, если нужна серьезная переработка логики, получение дополнительной информации, созвоны, согласования, ожидание ответов и т.д.

И наконец, изучим распределение времени, которое тратится на исправление кода.

На фиксы дефектов в коде уходит от 20 минут до 8 часов, в зависимости от сложности багов и если при исправлении не возникает критических противоречий с существующим кодом, стенды работоспособны, а ТЗ достаточное для работы. 

Анализ диаграмм позволяет сделать несколько выводов:

• Весомая доля (около 31%) дефектов зарождается на этапе создания ТЗ

• Типичное время тестирования ТЗ меньше, чем типичное время исправления кода (багофикса)

Обогащение модели жизненного цикла фичи реальными данными было бы не полным без сравнения затрат времени на реализацию. Однако, тут прикладывать какие бы то ни было диаграммы распределения времени сложно, поскольку информация получена с разных проектов, где фичи сильно различаются по размеру и трудоемкости. Значит, без объяснения, что делалось при реализации задачи, трудно понять затраты времени на нее. Более показательна статистика с проектов, где внедрили тестирование требований, как один из вариантов тестирования на ранних этапах разработки. 

На графике видно, что среднее время жизненного цикла фичи снизилось на величину от полутора до семи часов.

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

Например, на тестирование требований не обязательно подключаться всем QA команды. Это могут делать отдельные сотрудники. Кроме того, в результате проверки требований часто происходят мелкие правки ТЗ, которые делают его более понятным и однозначным, что в итоге сокращает время, которое  уходит на вопросы и пояснения при разработке. 

Вариант 2. Тестирование силами разработчика

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

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

Наши QA-специалисты нередко подключаются на проекты, где не было тестирования как процесса,  выполняемого отдельными людьми. Приемочный аудит таких проектов показывает, что отношение количества багов критичности major и выше к общему количеству фичей составляет 26,4 % 

После подключения профессиональных QA этот процент сокращается до 1,3 %. Небольшой процент сохраняется, так как в выборке присутствуют проекты, где допустимо выкатывать релизы с определенным количеством major багов.

Еще один аргумент против тестирования силами разработчика – экономическая нецелесообразность. Пока он тестирует, процесс создания новых фич стоит на месте. А если принять во внимание стоимость рабочего часа, то вывод напрашивается сам собой: использовать разработчиков для полноценного тестирования ПО – дорого, медленно и малоэффективно. При этом мы еще не учитываем упущенную выгоду из-за пользователей, которые обнаружили пропущенные дефекты в продукте и отказались от его использования, репутационные потери и прочее.

Вариант 3. Отказ от регресса

Регрессионное тестирование (далее – регресс) – проверка ранее протестированного ПО или его отдельных компонентов, которая позволяет удостовериться, что последние внесенные изменения не повлекли за собой появления дефектов в неизмененной части программы.

Важная особенность регресса – в его регулярности. При этом может возникнуть вопрос: зачем тестировать то, что уже протестировано? Это непонимание впоследствии перерождается в отказ от проведения регрессионного тестирования.

 Необходимость и польза его проведения становится очевидной при детальном изучении жизненного цикла ПО.

Практически все современные проекты после выхода в релиз к пользователю продолжают развиваться: наполняться новыми функциями, переезжать на более современные технологии, оптимизироваться и т.п. Кроме того, приложения часто зависят от «внешней среды» стороннего ПО, которое тоже меняется, и не про все изменения вы можете знать. 

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

 Интеграционное тестирование предназначено для проверки связей между компонентами ПО, а также взаимодействия со сторонними программами. При этом функциональность продукта, которую пользователь ожидает видеть исправным, не должна пострадать.

Для таких случаев и существует регресс. Он позволяет убедиться, что незатронутые изменениями части ПО или всё в целом работает корректно. О важности проведения регресса говорит статистика возникновения регрессионных багов – ошибок, которые возникли в результате изменений в смежном функционале.

Для исследования мы выбрали 46 проектов, каждый из которых был выпущен в релиз и просуществовал не менее полугода.

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

Анализ частоты возникновения регрессионных дефектов позволяет выделить два факта:

• Появление регрессионных дефектов с развитием проекта неизбежно.

• Чем сложнее и крупнее проект, тем больше вероятность появления регрессионных багов.

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

Кроме технических решений, разумно применять оптимизацию процессов тестирования и разделять регрессы по количеству производимых проверок на:

– крупные, которые будут проводится после изменений в ключевых компонентах;

– средние – в зависимости от серьезности внесенных изменений;

– мелкие, прогоняемые после каждого изменения в ПО.

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

Таким образом, проведение регрессионного тестирования – необходимый процесс в современной разработке приложений, который позволяет предотвратить встречу пользователя с дефектами. Грамотная оптимизация этого процесса помогает существенно сократить затраты при сохранении общей эффективности. 

Вариант 4. Отказ от тестовой документации

Тестовая документация – совокупность документов, которые создаются перед началом тестирования, а в некоторых случаях и в процессе. Она описывает покрытие требований тестами, а также процесс выполнения проверки ПО. В документации указывается вся информация, необходимая для тестирования. С точки зрения процессов она используется для структурирования работы QA.

Тестовая документация бывает низкоуровневая, в которой описаны непосредственно проверки (тест-кейсы, тест-сьюты, чек-листы и т.д.) и высокоуровневая – с описанием процесса тестирования, необходимых ресурсов, критериев завершения тестирования и требований к качеству релиза. Все это позволяет повысить вероятность отсутствия дефектов и предоставления качественного ПО для конечных пользователей.

Разумеется, создание тестовой документации требует времени, на котором часто экономят. Бытует мнение, что тестовая документация – это неоправданная трата времени и можно тестировать ПО без нее. Такое суждение складывается из-за непонимания последствий её отсутствия и неумения применять оптимальные виды документации в зависимости от особенностей проекта.

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

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

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

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

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

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

Исходя из вышесказанного, тестовая документация – не пустая трата времени, а инвестиция в качество проекта. Грамотное применение различных видов тестовой документации и их комбинаций оправдывает затраты и позволяет минимизировать риск попадания к пользователю дефектного ПО.

Вместо вывода

Сегмент онлайн-торговли продуктами питания набирает обороты. Цена ошибок в клиентском сервисе в e-grocery очень велика. Треть клиентов даже после первой ошибки ритейлера не оставляют ему ни единого шанса на продолжение партнерства.

За последние годы высокую динамику роста показал рынок продуктовых онлайн-ритейлеров.

По данным

Data Insight, в 2018 году в России количество заказов продуктов на дом увеличилось на 49%. Это можно объяснить не только ростом индустрии онлайн-ритейла в целом, но и появлением большого количества подобных сервисов. От них не отстают и крупные ритейлеры, которые под давлением рынка развивают онлайн-продажи. 

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

 
Анна Ставнийчук, директор по развитию бизнеса Teleperformance Russia Group, рассказала New Retail, как изменилась индустрия торговли продуктами с появлением доставки на дом и как это влияет на клиентский сервис. 

Люди привыкают заказывать продукты на дом

Рынок продуктового онлайн-ритейла, безусловно, один из самых динамичных в России. Что ни неделя (а то и день), так открывается новая Яндекс.Лавка, запускается новый сервис по доставке продуктов или очередной «традиционный» ритейлер осваивает нишу, или же какие-то игроки уходят с рынка. 

По данным

Nielsen Connected Commerce

, 90% россиян за последние годы хотя бы раз совершали покупки онлайн. Заказывают на дом по многим причинам: у кого-то нет времени ходить по магазинам, кто-то не хочет носить тяжелые пакеты, а кто-то элементарно привык к доставке на дом чего угодно. Могут быть и иные причины, но это не умаляет преимущество доставки до двери — экономию времени и сил.

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

Почему ритейлерам нужно задуматься о клиентской поддержке? 

Поскольку ритейлеры предлагают относительно одинаковый ассортимент и услуги, фокус постепенно смещается в сторону опыта, который получают покупатели. 

По оценке исследования Teleperformance Customer Experience Lab (CX Lab), доля атрибутов клиентского сервиса составляет 44% от общего объема факторов, влияющих на лояльность российских потребителей продуктовых онлайн-ритейлеров. Среди атрибутов, которые упоминались чаще других: идентификация предыдущих обращений, эффективная коммуникация, последовательность информации. 

По данным CX Lab, в 2018 году 70% российских потребителей обращались в контактный центр продуктовых онлайн-ритейлеров. Чаще всего вопросы были связаны с процессом покупки или доставкой. 

Однако тематика обращений – не единственная причина обратить внимание на клиентский опыт. 13% потребителей заметили, что перейдут к конкуренту из-за плохого клиентского сервиса онлайн-магазина. Более того, на российском рынке цена ошибки слишком высока: лояльность потребителей, у которых был негативный опыт взаимодействия с клиентским сервисом продуктового онлайн-ритейлера, снижается на 31%. 

Особенности клиентского сервиса в индустрии продуктового онлайн-ритейла

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

Клиенту будет намного проще закинуть в корзину те же продукты, что он покупал ранее. Для операторов контактного центра знание о предпочтениях потребителя – это источник идей для персонализированного предложения. Под рукой у оператора контактного центра всегда должен быть доступ к информации: предыдущие покупки, обращения, предпочтения и география потребителя. 

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

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

Читайте также: Как взломать ритейл через эмоции клиентов: два кейса сегодня и четыре кейса для завтра

Одним из ключевых факторов, влияющих на лояльность, российские потребители назвали безопасность онлайн-транзакций.

В исследовании

Nielsen на вопрос «Уверены ли вы, что информация на сайте онлайн-продавца защищена и хранится в безопасности?» только 38% ответили, что полностью уверены или в определенной мере уверены. 

Подобные опасения вполне оправданы. Каждый раз, когда клиент вводит данные банковской карты в интернете, он может столкнуться с уязвимостью в системе онлайн-ритейлера. Чтобы потребитель был уверен в процессе оплаты онлайн-покупки, платежная страница должна соответствовать стандартам безопасности банковских транзакций, а вводимые на ней персональные данные не должны быть видны третьим лицам или храниться в незашифрованном виде.

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

* * *

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

Анна Ставнийчук, 

директор по развитию бизнеса Teleperformance Russia Group

Эту историю я услышал на первой неделе моей летней практики в Гугле, во время ознакомления с компанией. Рассказывал ее один бывалый инженер имя которого я теперь не вспомню, как и не вспомню мелких деталей истории, например конкретные числа. Однако, посыл этой истории очень важен, и показывает как «нетрадиционные» методы менеджмента могут оказаться довольно продуктивными. Речь пойдет об ошибке стоимостью в несколько сотен тысяч долларов, и о ее последствиях.

Инженер (назовем его Майк) проработал в Гугле около десяти лет. Эта история приключилась с ним давно, когда он был у истоков своей карьеры в поисковом гиганте. Теперь он часто рассказывает эту историю новобранцам, вроде меня, когда они только приходят в компанию.
Не вдаваясь в детали и подробности, скажем, что все началось с того, как Майк запустил в продакшн свой код. Неожиданно аналитические тригеры забили тревогу: Гугл (а вернее какой-то его департамент) терял по $70 000 каждые пять минут. Вскоре на утечку отреагировали, и откатились к предыдущей стабильной версии. Однако, к тому времени было потеряно несколько сотен тысяч долларов. Стали всем отделом выяснять в чем дело. Майк проверил свой код, и понял, что ошибка была именно в нем. Его расстройству не было границ: Майк знал, что его уволят, а возможно и потребуют компенсацию за халатность. Возможно, где-то еще так бы и поступили, но не в Гугле. Майка не уволили, Майку не предъявили штрафа, Майка попросили написать пост-мортем — изложение своей ошибки с целью сохранения его для будущих поколений, в виде назидания: не делайте так!

Многие из нас, особенно люди с СССРским менталитетом, постарались бы наказать нерадивого сотрудника. Однако, в неинтуитивном поступке Гугловского менеджмента есть масса преимуществ:
1. Дорогостоящее обучение
Да, Гугл потерял под миллион долларов. Но посмотрим на это как на стоимость обучения этого сотрудника. Только что мы отдали миллион за его учебу, за его ошибку, которую он, будучи адекватным и рациональным человеком, больше никогда не допустит! Эта трата была инвестицией в его учебу, и глупо будет увольнять этого человека, отдавать его другой компании, после такого дорогостоящего обучения.
2. Повышение лояльности
Майку действительно было жаль, что он допустил такую дорогостоящую оплошность, и он готовился к увольнению. Снисхождение руководства не могло не затронуть его до глубины души. Тем, что его простили и оставили в Гугле, компания увеличила его лояльность и преданность. В Кремниевой долине, где «текучка» хороших инженеров высока, повышение лояльности — важная статья расходов.
3. Внутренний маркетинг
Майк каждый год с высокой трибуны рассказывает эту историю новобранцам Гугла. И, так как я здесь ее пишу, многие не остаются равнодушными к ней, и ценят мудрость и щедрость своего нового работодателя еще больше.
4. Исправление ошибок, вместо их сокрытия
В конце истории Майк призывает не скрывать своих ошибок, ибо этим можно только навредить. Если кто-то из нас допустил бы ошибку стоимостью в миллион долларов, больше всего мы бы хотели чтобы никто и никогда не узнал, что виновны именно мы. Однако, Майк сказал: лучше скажите, что вы оплошали, бейте в колокол, проэскалируйте эту проблему на высшие уровни как можно быстрее — чтобы оперативно ее устранить. За ошибку вас наказывать не будут — но могут за ложь, сокрытие и некомпетентность. Мораль этой части истории побуждает новых сотрудников Гугла, действительно, не скрывать своих ошибок, а решать и исправлять их — вместе, если потребуется.

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