요구사항 변경? 변경이 아닌 경우가 더 많습니다.(2)
요구사항의 오해, 오류, 변심이 발생하는 이유
이전에 게시했던 (1)의 내용을 읽어야 이해가 쉽습니다.
1) 요구사항을 오해하는 이유
① 문서로 요구사항을 정의하기에는 한계가 있습니다.
요구사항 문서를 읽는 사람들이 똑 같이 이해할 수 있도록 작성하기는 힘듭니다. 모든 사람들이 똑같이 이해할 수 있는 메일이나 문서는 회식계획과 같이 간단한 내용 또는 건축도면과 같이 공학적인 기법으로 작성할 때 가능합니다.
구두로 설명할 때에는 논리가 다소 미흡해도, 약간 횡설수설해도 내용전달에 어려움이 없지만 문서로 작성자의 의도를 전달하는 것은 힘듭니다. 왜냐하면 글쓰기 자체가 어려울 뿐 아니라 글쓰기는 일방소통이고 대화는 쌍방소통이기 때문입니다. 문서나 메일을 읽고 이해하기 힘들 때 작성한 사람에게 “이게 무슨 말인지 잘 이해가 안됩니다”라고 문의하고 설명을 들으면 대부분 이해할 수 있습니다. 문서를 작성한 사람이 말로 설명해도 이해가 안 된다면 그것은 ‘표현의 문제’가 아니라 ‘이해의 문제’입니다. 잘 모르는 것을 명확하게 표현하는 비결은 없습니다. 요구사항 문서를 작성하기 위해 뛰어난 필력을 필요하지 않지만 요구사항과 관련된 이해관계자와 프로젝트 팀원이 같은 수준으로 쉽게 이해할 수 있도록 작성하기 위해서는 많은 노력이 필요합니다. As a/I want/So that, given/when/then의 형식으로 사용자 스토리를 작성하는 것도 요구사항을 정의하는 논리를 표준화하기 위해서입니다.
문서의 논리 외에도 요구사항 문서를 이해하기 힘든 또 다른 이유는 틀린 문장을 작성하거나 너무 긴 문장을 작성하기 때문입니다. 틀린 문장은 조사를 잘못 사용하고, 주어와 동사가 일치하지 않고, 중복되는 표현을 사용하여 읽는 사람이 글에 집중하기 힘들기 때문에 문서를 작성한 사람의 의도를 파악하기 위해서는 많은 노력을 해야 합니다. 3줄 이상 넘어가는 만연체의 긴 호흡의 문장 또한 읽기 힘듭니다. 쉽게 읽히지 않고 이해를 하기 위해 노력해야 하는 문서는 내용을 정확하게 이해하기 힘듭니다.
② 요구사항을 소통하는 과정에서 노이즈가 발생합니다.
오해는 전달하는 사람의 잘못 때문에 발생하기도 하지만 전달받는 사람의 잘못 때문에도 발생합니다. 앞서 설명한 요구사항 문서 작성이 어려운 것은 전달하는 사람 때문에 발생하는 오해입니다. 반면 소통과정의 노이즈는 전달받는 사람 때문에 발생하는 오해입니다. 소통과정에서 발생하는 노이즈의 예는 다음과 같습니다.
- 요구사항 문서를 읽는 사람의 관심에 따라 선택적으로 내용을 기억합니다.
요구사항 문서의 내용 중 개인이 관심 있는 주제가 있을 때 나머지 내용은 잊고 관심 있는 주제만 기억하는 현상입니다. 그 내용이 요구사항 문서의 핵심이라면 상관없지만 중요하지 않고 있으면 좋은 기능(nice to have) 또는 특정 조건에서만 해당하는 내용이라면 이야기는 달라집니다. 특히 영향력이 큰 이해관계자가 프로젝트 후반부에 본인이 관심 있었던 내용이 생각보다 작은 비중으로 구현된 것을 확인하고 이견을 제시한다면 프로젝트 관리자는 힘든 상황에 직면하게 됩니다.
- 요구사항 문서의 내용을 개인이 임의로 가정하고 이해합니다.
요구사항 문서를 받은 사람이 요구사항 문서를 읽고 궁금증이 생길 수 있습니다. 아예 모르는 내용이라면 물어보겠지만, 전반적인 내용은 이해할 수 있지만 요구사항 구현의 구체적인 방안 또는 해당 전제조건에 대한 설명이 부족하다면 전화나 메신저를 통해 확인하는 사람이 있는 반면, 본인이 이해하기 쉬운 대로 이해하고 넘어가는 사람도 있습니다. 이러한 상황은 요구사항 문서를 전달하는 사람과 전달받는 사람 모두에게 잘못이 있습니다. 요구사항 문서를 작성하여 전달하는 사람은 소통의 대상이 되는 사람들이 임의로 가정할 여지를 만든 잘못이 있고, 요구사항 문서를 전달받은 사람은 개인이 임의로 가정한 잘못이 있습니다. 이러한 오해는 개발자 또는 이해관계자 모두에게 흔히 볼 수 있습니다.
- 요구사항에 대한 배경지식의 편차가 존재합니다.
요구사항을 전달받는 사람들 간에 배경지식의 편차도 요구사항의 오해를 발생시키는 원인이 됩니다. 배경지식은 IT 지식이 될 수도 있고, 도메인 지식이 될 수도 있습니다. 배경지식이 없는 사람에게 요구사항 문서는 복합적인 이슈가 발생시킬 수 있습니다. 그런 사람에게 요구사항 문서는 이해하기 어려울 뿐만 아니라, 구체적인 설명도 많이 부족합니다. 그렇다고 하나하나 물어보기도 부담스럽습니다. 주로 담당업무를 변경하고 업무인수인계가 미흡할 때 이런 상황이 발생합니다.
- 개인의 상황에 따라 요구사항 소통에 집중하는 정도가 달라집니다.
요구사항 문서를 읽거나 요구사항에 대한 협의를 할 때 집중하지 않고 다른 생각을 하면 요구사항 내용을 잘못 이해할 수 있습니다. 개인이 컨디션이 좋지 않은 상황 또는 심리적으로 힘든 상황에서는 소통에 집중하기 힘듭니다. 그러나 요구사항 내용을 1:1로 소통하는 것이 아니라면 요구사항을 전달하는 사람이 이런 것까지 헤아려 소통할 수는 없습니다.
- 대면협의 없이 문서나 메일로만 소통합니다.
요구사항 문서는 소통의 결과이지 소통의 수단이 되어서는 안 됩니다. 요구사항을 협의하는 가장 좋은 수단은 회의실과 화이트보드입니다. 대면협의 없이 요구사항 문서로만 소통하면서 오해가 없길 바라는 것은 기적을 바라는 것과 같습니다. 요구사항 문서를 작성하는 사람에게는 그 내용이 중요하고 간절하지만, 요구사항을 전달받는 사람에게 요구사항 문서는 우선순위가 낮을 뿐만 아니라 요구사항 문서를 집중하여 읽을 이유도 없기 때문입니다. 요구사항과 관련된 사람들이 충분한 소통을 하지 않는 것은 아파트나 다리를 건설할 때 철근이나 시멘트의 양을 줄이는 부실공사를 하는 것과 같습니다.
③ 요구사항의 구체화가 미흡하면 오해가 많아집니다.
요구사항 구체화가 미흡한 것을 요구사항 오해로 구분할지, 오류로 구분할지 고민 끝에 오해로 구분했습니다. 구체화가 미흡한 대표적인 상황은 예외사항에 대한 대응을 고려하지 않는 것입니다. 예외사항에 대한 고려가 미흡할 때 발생가능한 문제는 예외사항에 대해 임의로 가정하고 요구사항을 개발하는 것과 예외사항에 대한 정의가 필요함을 뒤늦게 발견하는 것입니다. 소프트웨어 요구사항을 정의할 때 고려해야 할 예외사항의 예는 다음과 같습니다.
- 요구사항을 정의한 사람의 의도대로 프로세스를 수행하지 않는 경우
앞서 예를 든 SR 등록을 위한 회원가입 시 회사메일을 등록하도록 했는데 이는 모든 사용자가 회사 메일이 있다는 가정을 한 것입니다. 만일 회사메일이 없는 사용자에 대한 대응은 어떻게 해야 할까요? 그리고 사용자가 SR 등록권한 승인을 요청했는데 고객사 담당자가 장기간 승인을 하지 않는다면 어떻게 할까요? 승인을 기다리는 사용자에게는 어떤 피드백을 보내야 할까요? 보통 사용자들이 프로세스를 잘 따를 것이라는 성선설의 입장에서 시스템을 기획하고 개발한 뒤 프로세스를 잘 따르지 않는 사람들을 성악설의 입장에서 관리하는 경우가 많은데 반대로 하는 것이 좋습니다. 시스템을 기획하고 개발할 때에는 대부분의 사람들이 프로세스를 따르지 않을 것이라고 가정하고 시스템을 적용할 때 예외사항은 성선설의 입장에서 관리하는 것이 바람직합니다.
- 기 수행한 프로세스를 취소하는 경우
시스템을 기획할 때에는 대부분 정상적인 상황만 생각하기 쉽습니다. 예를 들어 결재의 경우 ‘결재상신 → 결재 → 통보’의 순서대로 진행하는 것입니다. 그러나 결재를 상신했는데, 내용을 잘못 기술한 경우가 발생할 수도 있습니다. 복잡한 단계를 진행하는 프로세스는 특히 기 수행한 단계의 데이터를 변경하거나 삭제하는 경우에 대한 대비를 해야 합니다. 현실에서는 프로세스를 거꾸로 거슬러가는 경우가 반드시 발생합니다.
- 요구사항의 구체화 수준이 미흡한 경우
요구사항을 개략적으로 정의할 수는 있어도 설계나 코딩을 개략적으로 할 수는 없습니다. 요구사항의 수준이 개략적이어서 설계를 진행하기에 정보가 미흡하면 앞서 설명한 요구사항을 전달받은 사람이 임의로 가정하여 요구사항을 구체화하는 오해 또는 오류가 발생할 수 있습니다. 이러한 상황은 시간에 쫓겨 전체 요구사항을 확정하는 폭포수방법론을 적용할 때 주로 발생합니다.
2) 요구사항을 틀리게 정의하는 이유
요구사항을 틀리게 정의하는 유형은 개략적으로 틀린 경우와 상세하게 틀린 경우가 있습니다. 개략적으로 틀린 경우는 방향성의 오류이고 상세하게 틀린 경우는 잘못된 요구사항을 상세하게 정의한 경우입니다. 요구사항을 틀리게 정의하는 이유는 요구사항을 정의하는 사람의 역량이 미흡하거나 너무 빨리 요구사항을 확정하기 때문입니다. 역량이 미흡하여 요구사항을 잘못 정의하는 것은 대응이 힘들지만, 요구사항을 빨리 확정하는 것은 프로세스나 방법론을 개선하면 해결 가능합니다. 요구사항을 정의하기 위한 정보가 부족하거나 구체화되지 않은 상태에서 요구사항을 확정하는 오류를 줄이기 위해서는 요구사항을 확정하는 시점을 늦추어야 합니다. 짧은 시간 동안 요구사항을 급하고 부실하게 정의하는 오류를 줄이기 위해서는 충분한 시간을 가지고 요구사항을 분석해야 합니다.
3) 요구사항에 대한 마음을 바꾸는 경우
요구사항에 대한 마음을 바꾸는 이유는 상황이 변했기 때문입니다. 조직외부의 상황이 바뀔 수도 있고, 조직내부의 정책이 바뀔 수도 있습니다. 상황이 변하는 가장 큰 이유는 시간의 경과입니다. 시간에 강한 것은 진화와 같은 자연의 법칙이며 대부분 시간에 약합니다. 사랑, 유행, 프로세스 등 영원한 것은 없습니다. 요구사항은 말할 것도 없습니다. 요구사항을 정의하고 개발까지 리드타임이 길어질수록 요구사항에 대한 마음을 바꿀 가능성이 증가합니다. 지금 요구사항을 정의하고 1년 뒤에 개발을 착수한다고 생각해 보시면 쉽게 이해할 수 있습니다.
https://brunch.co.kr/@kbhpmp/160
