Как QA помогает бороться с избыточной разработкой

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

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

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

Теперь первоначальная оценка разработки уже не отражает полный объём работ. Потребуются изменения нескольких компонентов, дополнительные проверки и согласование бизнес-правил, которые прежде никто не рассматривал вместе.

Именно здесь возникает риск избыточной разработки: команда начинает реализовывать требования, прежде чем выяснит, какой объём функциональности действительно необходим для решения бизнес-задачи.

Избыточность может проявляться по-разному. Иногда продукт получает функции с неподтверждённой востребованностью, иногда задача постепенно обрастает дополнительными условиями. Отдельная проблема — техническое переусложнение (overengineering), когда выбранная архитектура оказывается значительно сложнее, чем требуют текущие задачи и обоснованные планы развития.

Исследователи Офира Шмуэли и Боаз Ронен в работе Excessive Software Development: Practices and Penalties выделяют три направления избыточной разработки: превышение потребностей, запланированного объёма и доступных ресурсов. Эти явления могут пересекаться, но требуют разных управленческих решений.

Почему даже востребованная функция может оказаться избыточной

Исследование Pendo показало, что в анализируемой выборке 80% отмеченных функций использовались редко либо вообще не использовались, тогда как 12% обеспечивали 80% среднего ежедневного объёма использования. Данные были собраны за трёхмесячный период и опубликованы в отчёте 2020 года.

Эти результаты характеризуют конкретную выборку и методику измерения. Они не означают, что 80% функциональности любого продукта бесполезны.

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

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

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

Что именно QA может обнаружить до начала разработки

Когда специалист по обеспечению качества подключается к задаче после реализации, возможности повлиять на её объём ограничены. Противоречия уже превратились в программный код, а изменение согласованного решения потребует дополнительных трудозатрат.

Раннее участие QA помогает проверить требования до передачи в разработку. Его задача — исследовать поведение системы в разных условиях и выявить последствия, которые могли остаться за пределами первоначального описания.

В истории с системой скидок QA может сопоставить новые правила с существующими, проверить комбинации акций, возвраты, отмену заказов и обмен данными с платёжным сервисом. Результатом станет перечень конфликтов и зависимостей, влияющих на объём работ.

Владелец продукта вместе с аналитиком решит, какие сочетания скидок необходимы в первом выпуске, а какие можно отложить. Архитектор и разработчики оценят технические альтернативы.

QA предоставляет проверяемые основания для пересмотра решения, а ответственность за продуктовую ценность и приоритеты остаётся у владельца продукта.

Какие признаки указывают на лишний объём работ

Признак	Что проверяет QA	Основание для решения
Новая функция повторяет существующую	Совпадение пользовательских сценариев, данных и бизнес-правил	Можно ли расширить действующий механизм
Требование содержит множество исключений	Частоту условий, последствия ошибок и комбинации сценариев	Какие исключения обязательны для первого выпуска
Изменение затрагивает несколько систем	Зависимости, интерфейсы обмена данными и регрессионные сценарии	Оправдана ли стоимость изменения
Функция рассчитана на неподтверждённый сценарий	Наличие критериев приёмки и проверяемой гипотезы	Можно ли сначала проверить потребность
Решение рассчитано на неопределённое будущее	Какие требования к расширению действительно согласованы	Можно ли упростить архитектуру без существенного риска

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

Как проверять объём разработки без дополнительной бюрократии

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

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

Схема. Где QA помогает остановить избыточную разработку.

Потребность бизнеса

Какой результат необходим?

↓

Проверка требований с участием QA

Дублирование · исключения · зависимости · критерии приёмки

↓

Решение владельца продукта

Реализовать	Упростить	Отложить
Потребность подтверждена	Достаточен меньший объём	Требуется проверка гипотезы

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

Такая организация работы связана с бизнес-анализом: специалисты исследуют потребности, описывают процессы и формируют требования, на основании которых команда принимает технические решения.

Сколько ресурсов можно сохранить

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

Допустим, команда оценила реализацию расширенной системы скидок в 120 часов. После проверки сценариев было решено ограничить первую версию несколькими необходимыми правилами, снизив оценку до 50 часов. На дополнительный анализ потратили 8 часов.

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

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

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

Где опыт «Точки качества» помогает управлять лишними работами

В проекте QA-консалтинга для крупной компании электронной коммерции специалисты «Точки качества» обнаружили отсутствие формализованного сбора требований, недостаток метрик и проблемы с управлением рисками.

Два консультанта в течение четырёх месяцев анализировали процессы, проводили интервью, определяли проблемные участки и помогали внедрять изменения. По опубликованным результатам проекта удалось повысить прозрачность процессов, улучшить управление требованиями и наладить регулярный выпуск релизов.

Этот кейс показывает значение управляемого процесса требований: когда информация теряется между участниками проекта, команде сложнее оценивать последствия изменений и контролировать объём работ. При этом в описании отсутствует измеренная экономия от исключения ненужной функциональности.

Другой пример — бизнес-анализ для ПАО «Газпром нефть». Специалисты компании участвовали в нескольких корпоративных ИТ-проектах, выявляли и документировали требования, моделировали процессы и проводили экспертизу проектной документации.

Здесь особенно заметна роль совместной работы аналитиков и QA: обоснование потребности, описание целевого процесса и проверка поведения системы должны опираться на согласованные требования. Сам кейс подтверждает опыт бизнес-анализа, без отдельного количественного результата сокращения разработки.

Для компаний с фрагментированными процессами подобные задачи могут входить в QA-консалтинг — оценку организации обеспечения качества, управления требованиями и связанных рисков.

Чек-лист: есть ли в задаче избыточная разработка

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

Проверка перед разработкой

• Есть ли в продукте существующий сценарий с тем же результатом?\
• Можно ли выпустить первую версию без части дополнительных правил и исключений?
• Известно ли, какие пользователи и как часто будут применять новую функцию?
• Оценены ли зависимости от платежей, авторизации, данных и внешних систем?
• Понятно ли, сколько дополнительных проверок потребует изменение?
• Зафиксированы ли обязательные требования, которые нельзя исключить?
• Определено ли, как проверить результат после выпуска?

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

Как сделать контроль избыточности частью продуктовых решений

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

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

Для руководителя полезным критерием становится способность команды объяснить, почему выбран именно такой объём разработки, какие альтернативы были рассмотрены и что изменится при исключении части функциональности.

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