품질이란 무엇일까요?
위에서는 사장님부터 아래로는 사원들까지 밖에서도 안에서도 언제나 메아리 치는 소리..
품질...
하지만 품질이 무엇인지 정확히 말할 수 있는 사람은 많지 않습니다.
어떤 사람은 ISO 25000 표준을 얘기하는 사람도 있고, 어떤 사람은 사용성 같은 것을 이야기 하기도 합니다.
왜 그런걸까요?
여러분은 사랑을 정의 내릴 수 있나요? 가치관이나 부성애 같은 것은 어떠신가요?
꿈은 어떻습니까?
품질도 위와 같은 개념과 매우 비슷합니다.
품질을 정의하기 위한 노력을 지금 그만두는 것이 자원을 절약하는 지름길입니다.
왜냐하면 품질이란 매우 상대적인 가치관에 가깝기 때문입니다.
때문에 여러분 회사 제품의 품질이 낮다고 여겨진다면 고객의 불만이 크다고 생각된다면 대부분의 원인은 대화 부족인 경우가 많습니다.
소프트웨어 개발과 관련된 수많은 사람들 고객을 포함해서 개발자, 테스터, 기획, 그래픽, 경영진 등 많은 이해관계자들의 품질에 대한 가치과 우선순위가 틀리기 때문입니다.
서로 대화를 하지 않으면서 서로 다른 꿈을 꾸게 된다면 그 목적지는 전혀 다르게 됩니다.
개발팀에서는 기능의 풍부함을 품질로 보고 테스터는 기능의 정확성을 품질로 보고 경영진은 돈을 많이 벌어다 줄 제품을 품질로 보고 고객은 사용이 편한 제품을 품질로 여긴다고 가정할 때 각각의 이해 관계자의 의사소통이 없이 제품의 개발이 달려가게 된다면 그 끝은 자명한 일입니다.
품질의 정의와 가치에 대한 얘기는 탁상공론일 뿐입니다.
ISTQB에서는 이러한 개념을 '오류-부재의 궤변'으로 설명합니다.
품질은 매우 중요합니다. 하지만 무엇을 품질의 가치로 삼을 것이고 그 가치의 기준을 제공할 당사자가 누구인지에 대해 명확하게 정의할 필요가 있습니다.
그런 선행과정이 있어야 품질이 무엇이고 품질을 어떻게 측정할 것인지에 대한 논의를 시작할 수 있을 것입니다.
세상에는 결함은 별로 없지만 잘 팔리지 않는 제품이 있는가 하면 끊임없이 결함이 생겨나고 문제가 있다고 해도 불티나게 팔리는 아이폰 같은 제품도 있습니다.
시장은 공평하지 않고 고객은 변덕스럽습니다.
개인적으로 전 품질의 기준과 가치 정의의 시작점은 고객이라고 생각합니다. 기획팀이나 개발팀 또는 경영진에서 생각하는 품질은 그다지 쓸모가 없습니다. 그들의 품질에 대한 생각은 그냥 그들의 착각 쯤으로 남겨두는 것으로 족합니다.
정작 중요한 사람, 즉 고객을 우선으로 하지 않는다면 100만년이 지나도 품질은 개선되지 않을 것이고 그 전에 회사는 꼴딱 망할 겁니다.
여러분은 어떠신가요?
개인적으로 품질이 무엇이고 재미가 무엇인지 논의 하기 전에 먼저 어떠한 방법으로든 고객을 만나시기 바랍니다.
그리고 고객의 의견을 설계하십시오. 고객의 기준으로 설계를 하십시오. 그리고 그 설계를 구현할 수 있도록 최선을 다하시기 바랍니다.
개발팀이 이런 저런 이유로 구현을 거부한다면 짤라 버리십시오. 중요한 것은 개발 가능 여부가 아니라 고객의 꿈을 이루어 줄 수 있는가? 입니다.
테스터는 그러한 고객의 바람이 제품에 제대로 구현이 되었는지 확인하는 역할을 해야 할 것입니다.
소프트웨어 개발에서 가장 중요한 사람은 고객입니다.
위에서는 사장님부터 아래로는 사원들까지 밖에서도 안에서도 언제나 메아리 치는 소리..
품질...
하지만 품질이 무엇인지 정확히 말할 수 있는 사람은 많지 않습니다.
어떤 사람은 ISO 25000 표준을 얘기하는 사람도 있고, 어떤 사람은 사용성 같은 것을 이야기 하기도 합니다.
왜 그런걸까요?
여러분은 사랑을 정의 내릴 수 있나요? 가치관이나 부성애 같은 것은 어떠신가요?
꿈은 어떻습니까?
품질도 위와 같은 개념과 매우 비슷합니다.
품질을 정의하기 위한 노력을 지금 그만두는 것이 자원을 절약하는 지름길입니다.
왜냐하면 품질이란 매우 상대적인 가치관에 가깝기 때문입니다.
때문에 여러분 회사 제품의 품질이 낮다고 여겨진다면 고객의 불만이 크다고 생각된다면 대부분의 원인은 대화 부족인 경우가 많습니다.
소프트웨어 개발과 관련된 수많은 사람들 고객을 포함해서 개발자, 테스터, 기획, 그래픽, 경영진 등 많은 이해관계자들의 품질에 대한 가치과 우선순위가 틀리기 때문입니다.
서로 대화를 하지 않으면서 서로 다른 꿈을 꾸게 된다면 그 목적지는 전혀 다르게 됩니다.
개발팀에서는 기능의 풍부함을 품질로 보고 테스터는 기능의 정확성을 품질로 보고 경영진은 돈을 많이 벌어다 줄 제품을 품질로 보고 고객은 사용이 편한 제품을 품질로 여긴다고 가정할 때 각각의 이해 관계자의 의사소통이 없이 제품의 개발이 달려가게 된다면 그 끝은 자명한 일입니다.
품질의 정의와 가치에 대한 얘기는 탁상공론일 뿐입니다.
ISTQB에서는 이러한 개념을 '오류-부재의 궤변'으로 설명합니다.
품질은 매우 중요합니다. 하지만 무엇을 품질의 가치로 삼을 것이고 그 가치의 기준을 제공할 당사자가 누구인지에 대해 명확하게 정의할 필요가 있습니다.
그런 선행과정이 있어야 품질이 무엇이고 품질을 어떻게 측정할 것인지에 대한 논의를 시작할 수 있을 것입니다.
세상에는 결함은 별로 없지만 잘 팔리지 않는 제품이 있는가 하면 끊임없이 결함이 생겨나고 문제가 있다고 해도 불티나게 팔리는 아이폰 같은 제품도 있습니다.
시장은 공평하지 않고 고객은 변덕스럽습니다.
개인적으로 전 품질의 기준과 가치 정의의 시작점은 고객이라고 생각합니다. 기획팀이나 개발팀 또는 경영진에서 생각하는 품질은 그다지 쓸모가 없습니다. 그들의 품질에 대한 생각은 그냥 그들의 착각 쯤으로 남겨두는 것으로 족합니다.
정작 중요한 사람, 즉 고객을 우선으로 하지 않는다면 100만년이 지나도 품질은 개선되지 않을 것이고 그 전에 회사는 꼴딱 망할 겁니다.
여러분은 어떠신가요?
개인적으로 품질이 무엇이고 재미가 무엇인지 논의 하기 전에 먼저 어떠한 방법으로든 고객을 만나시기 바랍니다.
그리고 고객의 의견을 설계하십시오. 고객의 기준으로 설계를 하십시오. 그리고 그 설계를 구현할 수 있도록 최선을 다하시기 바랍니다.
개발팀이 이런 저런 이유로 구현을 거부한다면 짤라 버리십시오. 중요한 것은 개발 가능 여부가 아니라 고객의 꿈을 이루어 줄 수 있는가? 입니다.
테스터는 그러한 고객의 바람이 제품에 제대로 구현이 되었는지 확인하는 역할을 해야 할 것입니다.
소프트웨어 개발에서 가장 중요한 사람은 고객입니다.
품질의 기준은 고객이다. 정답 이라고 생각합니다.
답글삭제언제나 좋은글 잘 읽고 있습니다. 감사합니다.
감사히 읽고 있습니다~
답글삭제