Как стать автором
Обновить

Комментарии 9

разработчикам нужно больше концентрировать внимание на реализации новых фич для пользователей, нежели на постоянном исправлении ошибок
Ну тогда бизнесу следует определиться — что ему надо на начальном этапе разработки: бажный, но «дешевый» по всем параметрам MVP, слепленный на скорую руку для тестирования бизнес-идей, или тщательно спроектированный продукт с продуманной архитектурой?
Вот не было в моем опыте такого, когда бизнес положительно протестировав идеи на MVP, выкинул его в мусор и предложил разработчикам сделать на основе этого удачного MVP качественный продукт с нуля. Всегда просят добавлять новые фичи именно в первоначальный глючный MVP.
Во многих бизнес-продуктах, разработчики не имеют возможности воссоздать реальное окружение и реальные данные — им просто их не дадут, особенно в финансовых структурах. Там вообще боятся лишнюю информацию с продакшена выдать.
В результате идут фейковые таблицы, фейковые данные, фейковые нагрузки, которые не отражают реальность.
Ну и да, взаимодействие с внешними системами, которые пишут другие разработчики, которые тоже тестят их на фейковых таблицах и фейковых данных, а потом все это соединяется вместе.
Стоит упомянуть, что баг фиксинг продукта обычно финансируется из Operational budget, а разработка — из Capital Budget, и что по этой причине для компании часто имеет смысл запустить сырой продукт в продакшен, но потом фиксить его и по другой, гораздо более стабильной статье расходов.
А вообще конечно, про это и так известно любому айтишнику, можно было и не дёргать 386 человек на всякую ерунду.
Как-то, скорее, удивляет, что так мало, чем что так много.
Вероятнее всего из-за того, что это 1) забугорные реалии; 2) забугорые «интерпрайс» реалии (и скорее всего Java).
А что за бугром — багов меньше или отношение к ним более пофигистическое?
Наоборот. Более строгое. Ясное дело не везде. Но в целом мы по определению в роли догоняющих.
Не смог вспомнить область в которой обстоят дела иначе.
88% респондентов хотели бы иметь возможность во время разработки тестировать приложения на реальных данных.
В медицине эта цифра наверно несколько больше.
Интересна была бы корреляция с используемыми технологиями и опытом команды.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости