На небесах только и разговоров что о качестве: часть 3 Пришло время продолжить серию постов про качество, его многообразие и многообразие определений оного. Как и обещал, в этом посте поговорим про насущный вопрос «а зачем это все?!», иными словами почему так сложно и что бы что? Зачем во всём этом копаться и какой профит это дает? Здесь есть несколько моментов. 1. Само по себе понимание этого многообразия полезно. И вам, и команде. Оно наглядно демонстрирует разные аспекты проблем, разные пласты работы над качеством и то, какую ценность каждый из них формирует для разных участников. Через это же понимание можно увидеть какие из аспектов качества выпадают из фокуса команды, над чем предстоит работать, да и вообще увидеть (и донести до других) всю объемность куа домена. 2. То, как воспринимается качество в рамках команды и в головах отдельно взятых людей формирует ожидания, с которыми мы работаем. Когда стейкхолдеры сходятся на том, что нам нужен более качественный продукт - это здорово. Но это не говорит о том, что их ожидания от нашей работы сходятся между собой. Просто потому, что под "качественным продуктом" каждый подразумевает что-то своё, и эти представления могут довольно сильно конфликтовать. А в нашем субьективном восприятии качество может вообще значить что-то третье. В итоге мы строим что-то совсем не то, что от нас ждали, хотя по факту делаем всё тот же "более качественный продукт". 3. Это позволяет синхронизировать команду. Прямое следствие двух предыдущих пунктов - возможность говорить на одном языке. Когда мы понимаем всё многообразние качества и разницу восприятий между участниками, мы можем договориться об общем понимании и представлении. Где ключевые точки интереса, что важно каждому из участников, как одно влияет на другое и пр. В итоге субьективное "продукт соответствует ожиданиям по уровню качества" становится чуть менее субьективным и все плюс-минус понимают, какой набор характеристик под этим кроется. 4. Сводит множество разных аспектов в единую картинку. Там где до этого бизнес заботился только о бизнесовом качестве, а разработчики о качестве кода - мы можем выстраивать цельную картину. Доносить до всех участников когда (и почему) важно пожертвовать одним в пользу другого, как одно аффектит другое и почему просто забить на один из кусочков не получится. Для работы над QA доменом это означает, что мы сможем осознанно (и прозрачно для остальных участников) балансировать между интересами и проблемами разных групп. Выстраивать работу над качеством так, что бы обеспечение планки качества в одном аспекте не рушило другие, потому что это неприменно приведет к обратному эффекту - лишь вопрос времени. Начинать выстраивать качество с того, что бы разобраться что именно от нас всё таки хотят, почему именно так и к какому результату каждый из участников хочет придти - казалось бы, довольно очевидная история. Тем не менее, стоит только начать в этом копаться, как всплывает огромное количество сложностей и нюансов. В канале это переросло в целую серию очень упрощенных постов, в рамках курса - в три полноценных модуля. Просто что бы понять "а что вообще за качество нам нужно строить?". Такие дела.