Качество программного продукта — важный критерий. Однако не каждый способен его четко обозначить, а тем более объяснить, как его достичь. Как правило, у каждого члена команды свое представление о качестве. Это связано с тем, что в оценке в большей степени учитываются субъективные мнения. Правильнее сказать, что качество представляет собой набор критериев или параметров. И этот набор может отличаться в зависимости от личного опыта или профессиональной деятельности участника команды: пользователя, разработчика, тестировщика, аналитика, заказчика или др.
Например, выбор автомобиля. Разные люди придерживаются разных точек зрения. Для некоторых пользователей главное безопасность и надежность, в то время как для других важны внешний вид и комфорт. Это отражает субъективное представление о качестве.
Однако существуют и объективные критерии, которые являются универсальными. Например, основная функция автомобиля — доставка человека из пункта А в пункт Б. Этот критерий объективен для всех групп пользователей.
Пример с автомобилем хорошо демонстрирует разницу между субъективными и объективными критериями качества. Эта концепция применима не только к транспортным средствам, но и к другим товарам, услугам и даже к людям.
Дадим определение качеству на основании вышесказанного.
Качество — это комплексная характеристика объекта, основанная на субъективных и объективных критериях (атрибутах, параметрах).
Критерии отражают желания людей, которые взаимодействуют с объектом.
Переходя к программным продуктам, можно выделить следующие атрибуты качества:
функциональность;
надежность;
эффективность;
безопасность;
удобство использования.
Нужно понимать, что определение каждого из них неодинаково для разных специалистов в команде разработки.
Команда разработки включает таких специалистов, как аналитики, разработчики, тестировщики. Получается, что отсутствует понимание критериев качества относительно продукта, над которым работают эти люди. Можно спросить у аналитика, разработчика и тестировщика — для каждого критерии будут разные.
Можно ли считать продукт качественным при таком подходе? В определенном смысле да, потому что каждый вложил в него «свое» качество. При этом можно столкнуться со следующими проблемами:
Конфликты и недопонимания
Каждый член команды будет добиваться своих целей в отношении качества продукта. Некоторые из них могут противоречить целям других.
Снижение эффективности
Когда у каждого свое понимание качества, общее понимание становится менее явным или пропадает вообще, что ведет к снижению эффективности, а самое главное — качеству продукта.
Отсутствие коллективной ответственности
Если цели качества не установлены для всей команды разработки, это приводит к незаинтересованности в общем успехе.
Потеря мотивации
Люди могут чувствовать, что их их силы тратятся зря. Это приводит к потере вовлеченности.
Ошибочное распределение ресурсов
Каждый будет тратить имеющиеся ресурсы на достижение своих целей качества, при этом не обращая внимания на цели других.
Чтобы избежать проблем, необходимо установить общие критерии качества продукта для всей команды. Они должны быть четко обозначенными и понятными для каждого сотрудника. Команда разработки будет взаимодействовать, и у каждого участника будет общее представление, над чем он работает.
Важными моментами в разработке должны стать инициативы, предложенные членами команды. Необходимо дать возможность сотрудникам высказаться о своем видении качества продукта, обозначить субъективные критерии. Как правило, работа, которая придумана самостоятельно, выполняется охотнее. Инициативы должны быть донесены заинтересованным лицам (например, заказчику). По итогу они могут перерасти в цели. Тем самым улучшится качество готового продукта.
Нужно быть аккуратным в формировании множества целей по качеству, так как это может привести к многозадачности, что негативно отразится на продуктивности команды. Необходимо найти ритм работы, при котором будет возможность постоянно улучшать продукт, не теряя в продуктивности, а самое главное — в качестве.
Исходя из вышесказанного, можно сформировать правила:
Установить общие критерии качества для продукта.
Регулярно напоминать об установленных критериях качества.
Дозировать количество целей по качеству продукта.
Дать возможность членам команды разработки предлагать инициативы по улучшению качества.
Если инициатива не установлена как цель, то ее нельзя брать в работу.
Обязательно публично фиксировать инициативы.
Быть последовательными и постоянно улучшаться.
Комментарии (7)
avf48
12.12.2023 16:19
"Однако не каждый способен его четко обозначить, а тем более объяснить, как его достичь."
Вот и у вас, без ГОСТа, не получилось...
Занимайтесь тестированием, а не управлением качеством, не вводите людей в заблуждение!
raiSadam
12.12.2023 16:19Поддержу Ваш комментарий. Добавлю ссылку на стандарт по качеству https://docs.cntd.ru/document/1200121069
VladimirFarshatov
Столько раз повторено слово "качество" а никаких примеров критериев в статье нет и в помине.. "договариваться", "разные интересы".. есть но всё же, давайте попробуем:
Функциональность и .. "качество". Кмк, несколько странное сочетание, т.к. функциональность задается в основном ТЗ на тот или иной кейс, особенно что отдельно выделен п.3 - "эффективность". То есть тут или пункт избыточен вовсе или речь должна идти о качестве реализации заданного функционала в части "полноты", а не эффективности или красивости решения.. Но, неполностью реализованное ТЗ разве можно считать "выполненным"? Кмк, нет.
Надежность и "качество".. Надежность работы ПО напрямую связано с покрытием решения тестами, особенно с контролем "за" и "по" граничных решений. В идеале, каждое ветвление в функционале должно быть покрыто тестом. Каждый элемент входного набора покрыт как допустимыми, так и заграничными значениями.. Если это сделано, то надежность решения, как правило "работает годами и не требует поддержки" ибо "всё учтено могучим ураганом".. то есть, этот пункт фактически сводится к .. качеству (и количеству) тестов.
Эффективность и качество. Вот как раз тут и проявляется, кмк, "качественность" принятого решения, архитектуры данных, алгоритмов .. одно и то же ТЗ может быть решено разными способами, можно решать "в лоб", а можно взять какой-нибудь суперовый алгоритм Ухо-Пескарика и получить профит типа logN вместо O^3 "в лоб".. Но, тут возникает "дилемма" ибо далеко не каждый сеньор знаком с Ухо или Пескариком и откатывает на коде-ревью, т.к. "не качественно" в части "не понятно как это вообще работает" .. и тут мы вступаем в пропущенный пункт:
Эффективность как легкость восприятия (а есть ещё легкость сопровождения, расширяемость..). А восприятие как раз может быть самым разным, и оно у джуна, да в его первой команде - одно, у сеньора со стажем - совсем иное и то, что "тривиально" для первого, синьор ещё 100лет назад отказался применять и забыл как страшный сон.. и упс, ему снова "не понятно"!
Кмк, но это тот самый пункт где можно и нужно "договариваться" промеж коллег, вкупе с предыдущим: к чему стремимся? К эффективности по п.3 - кейс должен отрабатывать за минимальное время, иметь наименьшую сложность как алгоритмическую так и по данным (команда процессора имеет стоимость - hiload) или мы пишем "простой и понятный для джуна кот" а то что он О^3 как алгоритмически, так и по данным .. "бизнес раскошелиться на новый сервер" делов-то.. зато любой новый сотрудник разберется в процессе полета между отделом кадров при приеме на работу и кофемашиной на кухне, даже не погружаясь в транс раздумий..
Кмк, как обычно, истина где-то посередине, но возможность договариваться вижу только в этой части озвученного .. не всё озвучено, ну да ладно. И так неплохая замена статье по объему.. ;)
EvgeniiGerasin Автор
Ну вы из тех, кто не знает что такое качество
VladimirFarshatov
Да, точно! А в каком "разрезе" не знаю, можно уточнить? .. смишно..
David_Osipov
Автор, тут я поддержу @VladimirFarshatov с его критикой. У вас статья "за всё хорошее против всего плохого", "давайте делать хорошо, а нехорошо делать не будем".
Продуктовой команде постоянно приходится балансировать между "херак-херак и в продакшен, иначе конкуренты обгонят, или клиенты уйдут" и "перерабатываем легаси, а то новые фичи в среднем впиливаются в старый код по 3 месяца", а ваша статья совсем не помогает принимать решения.
VladimirFarshatov
Ещё хотел затронуть пропущенный пласт "коде-ревью и качество", начиная с вопроса "А сколько времени выдается сеньору на коде ревью?" и не из-за сего ли сеньоры часто требуют dif а не полный текст метода?
Так, вставка item = New(..) может и решает проблему тикета, но .. попадает во внутренний цикл, а "умный" компилятор текущего ЯВУ вполне может (и такое сеньор знать - обязан!) воткнуть malloc(), что приведет к существенному изменению скорости исполнения .. но, видя только dif спокойно аппрувит мердж, ещё и лайк не забывает поставить автору.. Ясен пень, что потом возникнет новый тикет .. но вот что с "качеством"?