Качество ПО: определение и постановка целей

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

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

Однако существуют и объективные критерии, которые являются универсальными. Например, основная функция автомобиля — доставка человека из пункта А в пункт Б. Этот критерий объективен для всех групп пользователей.

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

Дадим определение качеству на основании вышесказанного.

Качество — это комплексная характеристика объекта, основанная на субъективных и объективных критериях (атрибутах, параметрах).

Критерии отражают желания людей, которые взаимодействуют с объектом.

Переходя к программным продуктам, можно выделить следующие атрибуты качества:

• функциональность;

• надежность;

• эффективность;

• безопасность;

• удобство использования.

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

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

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

1. Конфликты и недопонимания

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

2. Снижение эффективности

Когда у каждого свое понимание качества, общее понимание становится менее явным или пропадает вообще, что ведет к снижению эффективности, а самое главное — качеству продукта.

3. Отсутствие коллективной ответственности

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

4. Потеря мотивации

Люди могут чувствовать, что их их силы тратятся зря. Это приводит к потере вовлеченности.

5. Ошибочное распределение ресурсов

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

Чтобы избежать проблем, необходимо установить общие критерии качества продукта для всей команды. Они должны быть четко обозначенными и понятными для каждого сотрудника. Команда разработки будет взаимодействовать, и у каждого участника будет общее представление, над чем он работает.

Важными моментами в разработке должны стать инициативы, предложенные членами команды. Необходимо дать возможность сотрудникам высказаться о своем видении качества продукта, обозначить субъективные критерии. Как правило, работа, которая придумана самостоятельно, выполняется охотнее. Инициативы должны быть донесены заинтересованным лицам (например, заказчику). По итогу они могут перерасти в цели. Тем самым улучшится качество готового продукта.

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

Исходя из вышесказанного, можно сформировать правила:

1. Установить общие критерии качества для продукта.

2. Регулярно напоминать об установленных критериях качества.

3. Дозировать количество целей по качеству продукта.

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

5. Если инициатива не установлена как цель, то ее нельзя брать в работу.

6. Обязательно публично фиксировать инициативы.

7. Быть последовательными и постоянно улучшаться.