만족스러운 제품 생산을 원하는 경우 다음과 같은 두 가지 문제점이 생기게 됩니다.
-
제품이 충분히 만족스러운지 어떻게 판단할까?
-
제품 품질이 아직 만족스럽지 못한 경우 연관된 이해 당사자(stakeholder)를 어떻게 안심시킬 수 있을까?
첫 번재 질문에 대한 대답을 얻게 되면 제품을 릴리스하게 됩니다. 두 번째 질문에 대한 대답에 따라 품질이 좋지 못한 제품은 릴리스되지 않습니다.
"거의 괜찮은 정도의 제품을 출시하고 싶지는 않다. 우수한 제품을 출시하고 싶다"라고 생각할 수 있습니다. 자세히 들여다 보십시오. 높은 품질 표준이 있고 우수한 제품을 출시할 예정이라고 동업자,
관리자 또는 이해 당사자(stakeholder)에게 얘기하면 어떤 일이 발생할까요? 프로젝트 주기 초반이라면 고개를 끄덕이며 웃음을 지을 것입니다. 품질은 모두가 좋아하는 공통 주제입니다. 그러나 프로젝트 주기
종반부에서라면 프로젝트 완료에 대한 많은 중압감을 느끼고 있을 것입니다. 우수한 제품을 만들려면 아주 많은 테스트를 수행하고 많은 문제점을 해결하며(작은 문제점도 포함), 기능을 추가하거나 코드의 많은 부분을
버리고 재작성해야 할 수도 있습니다. 또한 좋은 품질에 대한 여러 가지 비전 논쟁도 해결해야 합니다. 우수한 제품을 만드는 것은 어려운 일입니다. 완벽해지는 것은 더더욱 힘든 일입니다. 결국, 프로젝트를 제어하는
사람들은 "완벽해지면 좋겠지만 그보다는 현실적이 되는 것이 좋다. 우리는 비즈니스를 하고 있다. 품질도 중요하지만 어떤 희생을 치뤄서라도 품질을 얻어야하는 것은 아니다. 이미 알다시피 모든
소프트웨어에는 버그가 있다."고 말할 것입니다.
우수성은 동기 부여 목적이 될 수 있습니다. 작업에 대한 긍지와 관련됩니다. 우수성 추구를 입증하는데 "품질이 좋다면 더 좋은 품질은 더 좋다"라는 식의 표현을 사용하는 것은 문제가 있습니다. 우선 이런 주장을
하면 자칫하면 균형 잡힌 사고를 가진 사람이 아닌 품질 환상에 빠져있는 것으로 비춰질 수 있습니다. 다른 이유로는 이렇게 되면 비용 요인을 무시하게 됩니다. BMW는 훌륭한 차이지만 Saturn을 구입하는 것보다
훨씬 많은 돈이 듭니다. Saturn은 운전자에게 최고의 경험을 줄 수는 없지만 비용 절감면에서는 훌륭합니다. 비용을 고려하지 않으면 많으면 많을 수록 좋다라는 주장에서는 수익 체감도
무시하게 됩니다. 제품이 더 좋아질 수록 이후에 제품 개선을 얻기는 더욱 힘들어 집니다. 제품의 일정 부분에 모든 노력을 기울이는 경우 해당 제품의 다른 부분 또는 다른 프로젝트에서 제공하는 잠재적 기회마저도
포기할 수밖에 없습니다. 비즈니스에서는 자원의 최적 활용을 위해 매일 선택해야 합니다. 여기에는 품질 이외에도 고려해야 하는 여러 가지 요인이 있습니다.
충분한 품질 개념(GEQ)은 역설적으로 많으면 많을 수록 좋다는 주장보다 효율적일 수 있습니다. 적어도 이는 달성 가능하거나 그렇지 않은 목표를 제공하여 프로젝트를
취소하거나 재계약하기 위한 사실상의 주장이 되기 때문입니다.
대부분의 비즈니스는 몇 가지 양식으로 제품의 품질이 충분한지 판단합니다. 이렇게 하지 않는 단 한 부류는 완벽함을 달성했다고 믿는 사람들로, 이들은 어떻게 제품을 개선할 수 있는지 보는 상상력과 스킬이 부족하기
때문입니다.
여기 지금까지 시도한 몇 가지 모델의 충분함이 있습니다. 상황에 따라 몇 가지는 다른 것에 비해 더 효율적입니다.
-
나쁘지 않음("우리는 아직 죽지 않았습니다.") - 품질이 충분한 상태이며 계속 비즈니스할 수 있습니다. 충분한 품질로 만들어 고소 당하지 않게 하십시오.
-
긍정적인 무과실성("무엇이든 잘할 수 있습니다.") - 우리 조직은 세계 최고입니다. 너무나 훌륭해서 무엇을 실행하든 자동으로 우수하게 됩니다. 성공을 생각하십시오. "부정적인"
생각은 품질 저하를 가져오므로 실패에 대해서는 생각하지 마십시오.
-
끝없는 노력("완벽하지 않으면 안됩니다.") - 만족스러운 제품이란 없으며 노력이 중요합니다. 끝없는 노력만이 충분한 수준의 노력을 판단하는 기준이 됩니다. 비즈니스 문제는 중요하지
않습니다. 완벽하게 만들기 위해 최선을 다할 것입니다. 우리는 개선을 위해 계속 노력할 것이므로 원하는 사람은 직접 와서 가져가야 할 것입니다. 그러면 품질 문제에 대한 불만은 우리가 아닌 그들의 책임이 될
것입니다.
-
고객이 언제나 옳습니다.("고객이 좋아하는 것 같습니다.") - 고객이 좋아하는 경우 충분한 품질 상태입니다. 물론 언제나 모든 사람을 만족시킬 수는 없습니다. 현재 또는 잠재적인
고객이 제품을 좋아하지 않는 경우 이를 우리에게 알릴지 여부는 고객에게 달려있습니다. 고객의 마음까지 읽을 수는 없습니다.
-
정의된 프로세스("좋은 프로세스에 따라 진행합니다.") - 품질은 제품 빌드에 사용하는 프로세스의 결과입니다. 좋은 자체 프로세스를 정의했습니다. 이 프로세스에 따라 진행하면 당연히
충분한 품질의 제품이 생산될 것입니다.
-
정적 요구사항("요구사항을 충족시킵니다.") - 객관적이고 정량적이며 논쟁의 여지가 없는 품질을 정의했습니다. 이 목적을 달성하면 아무리 다른 주관적이고 비정량적이며 논쟁의 여지가
있는 목적이 제안되더라도 충분한 품질의 제품을 얻게 됩니다.
-
책임("약속을 이행합니다.") - 품질은 계약으로 정의됩니다. 특정 작업을 수행하기로 약속했고 해당 목적을 달성합니다. 계약을 이행하면 이로써 충분합니다.
-
중재 ("가능한 모든 노력을 기울입니다.") - 우리는 최고를 향해 나아갑니다. 프로젝트 전반에서 문제점 예방 및 피할 수 없는 문제점을 찾아서 수정하기 위해 노력합니다. 훌륭한
일처리를 위해 열심히 작업했으며 이로써 충분합니다.
-
동적 절충("여러 가지 요인을 저울질합니다.") - 미션 및 현재 상황으로 볼 때, 제품의 수익성이 충분하고 심각한 문제가 없으며 수익성이 심각하지 않은 문제점보다 많고 계속
개선하려고 노력하면 유용하기보다 해가 될 경우 제품이 충분한 상태라고 볼 수 있습니다.
프로세스, 스킬, 기술, 도구, 환경, 및 문화와 같은 여러 가지 요인에 따라 같은 비용으로 훨씬 좋은 품질의 제품을 생산할 수 있습니다. 더 많이 테스트하고 유지보수할 수 있는 제품의 개선 비용이 덜 들게 되고,
기타 비용(예: 지원 비용 및 고객 비용)은 저품질 제품과 특정적으로 연관됩니다.
품질 비용은 복잡한 문제이며 모두에게 공통적으로 일반화하기는 어렵습니다. 그러나 더 나은 테스트, 더 많은 오류 처리 더 많은 오류 수정 또는 제품의 모든 파트를 재작성하는데 언제나 더 많은 시간을 들이게 되는
것은 당연합니다. 아무리 만족스러운 상태라도 비용은 들게 됩니다. 더 개선할 내용을 생각해낼 수 없는 경우 품질이 아닌 상상력의 한계에 다다른 것입니다.
소프트웨어 업계에서 GEQ는 제품을 충분히 빨리 릴리스하지 않았을 때의 특정 비용에 대한 응답으로 가장 많이 사용됩니다. 이 도전에 응하지 못하는 경우 시장의 형상 또는 외부 최종 기한으로 불이익을
받게 됩니다. 이 때문에 프로젝트 종결이 종종 격렬한 선택이 되는 것입니다. 조직에서 충분하다고 여기는 기준과 제대로 준비된 상태인지 알려면 6개월 동안의 소프트웨어 개발 프로젝트 중 마지막 3일을 지켜보십시오.
마지막 날에 새로운 문제점이 보고되면 어떤 일이 일어나는지 보십시오.
품질을 숫자로 산출하고 충분한 품질을 나타내는 숫자 임계값을 설정하고 싶을 수 있습니다. 그러나 이는 품질에 연관된 요인만 측정하고 품질 자체는 측정할 수 없으므로 문제가 됩니다. 이는 "품질"이라는
단어 자체가 사람과 물건 사이의 관계에 대한 이름이기 때문이기도 합니다. "제품의 품질이 좋다."는 "사용자가 제품의 가치를 인정한다"와 같은 의미입니다. 이는 제품에 대한 설명이면서 동시에 사람 및 연관된
컨텍스트에 대한 설명이기도 합니다. 동일한 제품에 대해서도 사람 및 환경이 변화하므로 하나의 진정한 정해진 품질 측정 방법은 없게 됩니다.
완벽하거나 객관적으로 측정할 수는 없지만 품질을 알아보는데 사용할 수 있는 여러 가지 측정 방법이 있습니다. 그렇지만 어떤 품질이 충분한 품질인가에 대한 질문에는 복잡한 판단이 필요합니다. 결국 사람이 생각하고
판단을 내려야 한다는 사실로부터 자유로울 수 없습니다. 하나의 단순한 제품에 대한 판단은 쉬울 수 있습니다. 복잡하고 사활이 걸린 제품에 대해서는 매우 어렵습니다.
제품 품질 평가에 도움을 주기 위해 다음 유형의 정보가 RUP에 포함되는 대부분의 중간 산출물에 대해 사용 가능합니다.
-
중간 산출물 가이드라인 및 체크리스트: 중간 산출물 개발, 평가 및 사용 방법에 대한 정보
-
템플리트: 컨텐츠 구조 및 안내를 제공하는 중간 산출물의 "모델" 또는 프로토타입
자세한 정보는 기법: 품질 측정 및 개념: 아티팩트, 아티팩트 가이드라인 및 체크포인트를 참조하십시오.
|