Баги и критичное отношение клиентов к ошибкам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Смотрите также:

SQL-инструмент для создания личных кабинетов на сайте

Суть подхода и история создания Falcon Space
Веб-платформа для создания личных кабинетов

Платформа Falcon Space

Это снижение стоимости владения

за счет меньшего количества людей для поддержки

Это быстрое внесение изменений

по ходу эксплуатации программы

Это современный интерфейс

полная адаптация под мобильные устройства

Веб-приложения на MS SQL. Партнерская программа для разработчиков и веб-студий

Вы можете разрабатывать самостоятельно или сотрудничать с нами в плане веб-разработки на платформе Falcon Space, используя только SQL и HTML.
Смотреть примеры с кодом SQL
Документация по платформе
Работа на MS SQL Server
Демо-стенд компонентов
На стенде можно посмотреть различные компоненты в действии: таблицы, формы, модальные окна, диаграммы, карта и т.д.
Демо-сайт решений
Базисные решения, которые можно гибко адаптировать под себя: менять внешний вид, бизнес-логику и даже структуру базы данных.
Получить оценку проекта
Создайте концепцию проекта на основе нашего шаблона и получите оценку проекта в виде КП.