Что может скрывать ваш подрядчик при сдаче проекта?
За красивой обёрткой только что переданного продукта могут скрываться сюрпризы, о которых вам лучше узнать заранее. Давайте разберёмся, что же может таиться в этом «идеальном», по словам разработчиков, продукте
Недостаточное тестирование: главное — побыстрее сдать
Тестирование? Кто-то на это тратит время? Разработчики ведь итак умные ребята, и код работает. Возможно. Наверное. Ну может небольшие «косяки» могут всплыть уже после запуска, но это мелочи…
Ну например:
Подрядчику важно одно — успеть сдать проект до дедлайна. А уж тесты… ну, их ведь никто не увидит, если не проведёт, верно?
Тестирование? Кто-то на это тратит время? Разработчики ведь итак умные ребята, и код работает. Возможно. Наверное. Ну может небольшие «косяки» могут всплыть уже после запуска, но это мелочи…
Ну например:
- Ваша программа крашится на половине устройств;
- Данные теряются в процессе обработки;
- Уязвимости в безопасности.
Подрядчику важно одно — успеть сдать проект до дедлайна. А уж тесты… ну, их ведь никто не увидит, если не проведёт, верно?
Игнорирование редких сценариев. Вдруг прокатит?
Кто бы мог подумать, что пользователи будут вести себя как-то нестандартно? Зачем тестировать ситуации, когда они делают что-то необычное? Все ведь и так будет работать, если действовать по инструкции, правда?
Конечно, только если:
Подумаешь, мелочи. Главное — уложиться в сроки и доставить «работающее» решение. Ведь если проблема не обнаружена сразу, то её и нет, правда?
Кто бы мог подумать, что пользователи будут вести себя как-то нестандартно? Зачем тестировать ситуации, когда они делают что-то необычное? Все ведь и так будет работать, если действовать по инструкции, правда?
Конечно, только если:
- Ваше приложение ломается при плохом соединении;
- Нетипичные действия приводят к сбоям;
- Не работает в нестандартной среде, например, на старом оборудовании.
Подумаешь, мелочи. Главное — уложиться в сроки и доставить «работающее» решение. Ведь если проблема не обнаружена сразу, то её и нет, правда?
Задержки релиза и технический долг
Зачем решать сложные задачи сегодня, если можно сдать проект, а потом уже пусть кто-то другой разбирается с последствиями? Подрядчик завершил свою работу, получил оплату, и все счастливы.
Ну, кроме вас, когда выяснится, что:
Но это всё завтра. А сегодня — урааа, проект сдан!
Зачем решать сложные задачи сегодня, если можно сдать проект, а потом уже пусть кто-то другой разбирается с последствиями? Подрядчик завершил свою работу, получил оплату, и все счастливы.
Ну, кроме вас, когда выяснится, что:
- Каждая новая функция вызывает кучу багов;
- Система тормозит при малейшем увеличении нагрузки;
- Любое изменение требует переделки половины проекта.
Но это всё завтра. А сегодня — урааа, проект сдан!
Недокументированные функции и «костыли». Не баг, а фича!
Документация? Зачем это нужно? Всё ж работает!
Порой благодаря весьма креативным решениям, о которых разработчики «забыли» вам рассказать, может случиться такое:
Но ведь проект был сдан вовремя и без лишних вопросов. Документация? Это для слабаков
Документация? Зачем это нужно? Всё ж работает!
Порой благодаря весьма креативным решениям, о которых разработчики «забыли» вам рассказать, может случиться такое:
- Новые разработчики ломают голову, пытаясь понять, почему что-то работает именно так;
- Система выходит из строя при малейших изменениях;
- Вы получаете головную боль на годы вперед.
Но ведь проект был сдан вовремя и без лишних вопросов. Документация? Это для слабаков
Скрытые дефекты производительности. Зато красиво на демо
На презентации всё летает, круто! Никто же не будет загружать систему по полной, да? Но за прекрасной презентацией продукта, может скрываться следующее:
На презентации всё летает, круто! Никто же не будет загружать систему по полной, да? Но за прекрасной презентацией продукта, может скрываться следующее:
- Недостаточная оптимизация кода;
- Проблемы с масштабируемостью;
- Высокое потребление ресурсов (памяти, процессора).
Несоответствие ожиданиям пользователей
Ваши пользователи чего-то там хотели? И что теперь? Главное, что технические требования выполнены.
Если интерфейс неудобный, функции не те, а юзабилити оставляет желать лучшего, от вас утаили что-то, что привело к:
Вы же сами утвердили техническое задание, верно?
Ваши пользователи чего-то там хотели? И что теперь? Главное, что технические требования выполнены.
Если интерфейс неудобный, функции не те, а юзабилити оставляет желать лучшего, от вас утаили что-то, что привело к:
- Сложностям в освоении интерфейса и его дальнейшем использовании;
- Отсутствию учёта ожиданий целевой аудитории;
- Интерфейс не соответствует пользовательским сценариям и потребностям.
Вы же сами утвердили техническое задание, верно?
Как не попасть в ловушку?
Если вам не хочется столкнуться с этими «приятными» сюрпризами, стоит задуматься о независимом приёмочном тестировании.
Это позволит вам:
Мы эксперты в приёмочном тестировании, и знаем наверняка, где искать все те подводные камни, которые подрядчик предпочёл бы скрыть
Если вам не хочется столкнуться с этими «приятными» сюрпризами, стоит задуматься о независимом приёмочном тестировании.
Это позволит вам:
- Обнаружить все эти скрытые проблемы до релиза;
- Сэкономить кучу времени, нервов и денег;
- Убедиться, что продукт действительно готов к запуску.
Мы эксперты в приёмочном тестировании, и знаем наверняка, где искать все те подводные камни, которые подрядчик предпочёл бы скрыть