Ответ клиента на ошибку. Как отвечать на недовольство клиента в веб проекте

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

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

Как нам с этим жить и реагировать? 

Меры по повышению качества продукта

Нужно постоянно шлифовать процесс в сторону улучшения качества: 

• проводить дополнительные тесты.
• строго следовать процессу на этапе проекта, не пропуская или оптимизируя процедуры качества.
• делать приоритет на баги. В идеале баги не должны жить больше 24 часов. Не всегда это возможно, но понимание, что любой баг очень быстро правится на проекте все же снижает степень критичности бага. 
• улучшать качество ТЗ. Чем более конкретно и точно написано ТЗ. Важно не просто хорошо написать ТЗ, но и чтобы заказчик и исполнитель его однозначно понимали. Чем все более конкретно описано в ТЗ, тем меньше повода для возможных претензий со стороны заказчика. 
• простота - как главный императив разработки. Не нужно делать сложных решений. Бывает такое, что заказчик накрутит очень сложный функционал с кучей интеграций и кастомом, а потом недоумевает, что возникают неполадки при тестировании. Чем сложнее решение - тем сложнее его поддерживать, тем более оно хрупкое. Нужно всегда разрабатывать с учетом сложности решения, а не только уповая на удобство пользователя. Система должна работать быстро, без ошибок и быть понятной для пользователя - это самое  главное, а не новомодный узкий scrolling, куча неочевидной бизнес-логики при изменении отдельных полей или показ в одной таблице большой кучи данных единоразово. 

 Итеративно работайте над качеством. Встраивайте по возможности качество в продукт: инструменты диагностики, логи, отслеживание нехороших ситуаций (например, множество однотипных запросов с одной страницы в секунду) и т.д.

Как снизить стресс при работе с клиентом в плане ошибок 

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

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

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

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

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

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

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

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

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

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

Заключение

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

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