Главное Свежее Вакансии   Проекты
262 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Почему мелкие баги приводят к большим проблемам

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

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

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

1. Критика в социальных сетях


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

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

2. Небольшие ошибки наталкивают на мысль о больших проблемах


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

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

3. Ошибки в UI снижают производительность


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

Есть несколько способов улучшить UI, чтобы не допустить снижения эффективности работы и оттока пользователей:

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

4. Мелкие ошибки в расчетах влекут крупные потери


Баг финтех-приложения, из-за которого транзакция проходит с ошибкой в несколько центов, может привести к пропаже сотен тысяч долларов в год, если клиент ведет активную финансовую деятельность. При этом на этапе тестирования ответственное лицо может проигнорировать сигнал QA-инженера о том, что при транзакции в $1000 пропал 1 цент — ведь это всего 0.001%.

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

Заключение


Существует мнение, что главное — исправить до релиза существенные баги. А мелкие можно отдать на вылавливание пользователям. Вот только пользователи могут оказаться не в восторге от этой веселой игры.

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

Аутсорс-компании, такие, как Andersen, могут оперативно предоставить нужных специалистов, не только QA-инженеров, но и разработчиков, которые помогут исправить баги и довести приложение до приемлемого вида. Выход сотрудника на проект занимает максимум 10 дней — это очень удобно при работе в жестких дедлайнах. Инвестиции в защиту качества приложения, как правило, невелики, но польза от них очевидна — как минимум, недопущение ни одного из сценариев, описанных выше.

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем