문서로 요구사항을 정의하는 것은 한계가 있습니다.
요구사항 문서를 읽는 사람들이 똑 같이 이해할 수 있도록 작성하기는 힘듭니다. 모든 사람들이 똑같이 이해할 수 있는 메일이나 문서는 회식계획과 같이 간단한 내용 또는 건축도면과 같이 공학적인 기법으로 작성할 때 가능합니다.
구두로 설명할 때에는 논리가 다소 미흡해도, 약간 횡설수설해도 내용전달에 어려움이 없지만 문서로 작성자의 의도를 전달하는 것은 힘듭니다. 왜냐하면 글쓰기 자체가 어려울 뿐 아니라 글쓰기는 일방소통이고 대화는 쌍방소통이기 때문입니다.
문서나 메일을 읽고 이해하기 힘들 때 작성한 사람에게 “이게 무슨 말인지 잘 이해가 안됩니다”라고 문의하고 설명을 들으면 대부분 이해할 수 있습니다.
문서를 작성한 사람이 말로 설명해도 이해가 안 된다면 그것은 ‘표현의 문제’가 아니라 ‘이해의 문제’입니다.
잘 모르는 것을 명확하게 표현하는 비결은 없습니다. 요구사항 문서를 작성하기 위해 뛰어난 필력을 필요하지 않지만 요구사항과 관련된 이해관계자와 프로젝트 팀원이 같은 수준으로 쉽게 이해할 수 있도록 작성하기 위해서는 많은 노력이 필요합니다. As a/I want/So that, given/when/then의 형식으로 사용자 스토리를 작성하는 것도 요구사항을 정의하는 논리를 표준화하기 위해서입니다.
요구사항을 소통하는 과정에서 노이즈가 발생합니다.
오해는 전달하는 사람의 잘못 때문에 발생하기도 하지만 전달받는 사람의 잘못 때문에도 발생합니다. 앞서 설명한 요구사항 문서 작성이 어려운 것은 전달하는 사람 때문에 발생하는 오해입니다. 반면 소통과정의 노이즈는 전달받는 사람 때문에 발생하는 오해입니다. 소통과정에서 발생하는 노이즈의 예는 다음과 같습니다.
요구사항 문서를 읽는 사람의 관심에 따라 선택적으로 내용을 기억합니다.
요구사항 문서의 내용 중 개인이 관심 있는 주제가 있을 때 나머지 내용은 잊고 관심 있는 주제만 기억하는 현상입니다. 그 내용이 요구사항 문서의 핵심이라면 상관없지만 중요하지 않고 있으면 좋은 기능(nice to have) 또는 특정 조건에서만 해당하는 내용이라면 이야기는 달라집니다. 특히 영향력이 큰 이해관계자가 프로젝트 후반부에 본인이 관심 있었던 내용이 생각보다 작은 비중으로 구현된 것을 확인하고 이견을 제시한다면 프로젝트 관리자는 힘든 상황에 직면하게 됩니다.
요구사항 문서의 내용을 개인이 임의로 가정하고 이해합니다.
요구사항 문서를 받은 사람이 요구사항 문서를 읽고 궁금증이 생길 수 있습니다. 아예 모르는 내용이라면 물어보겠지만, 전반적인 내용은 이해할 수 있지만 요구사항 구현의 구체적인 방안 또는 해당 전제조건에 대한 설명이 부족하다면 전화나 메신저를 통해 확인하는 사람이 있는 반면, 본인이 이해하기 쉬운 대로 이해하고 넘어가는 사람도 있습니다.
이러한 상황은 요구사항 문서를 전달하는 사람과 전달받는 사람 모두에게 잘못이 있습니다. 요구사항 문서를 작성하여 전달하는 사람은 소통의 대상이 되는 사람들이 임의로 가정할 여지를 만든 잘못이 있고, 요구사항 문서를 전달받은 사람은 개인이 임의로 가정한 잘못이 있습니다. 이러한 오해는 개발자 또는 이해관계자 모두에게 흔히 볼 수 있습니다.
요구사항에 대한 배경지식의 편차가 존재합니다.
요구사항을 전달받는 사람들 간에 배경지식의 편차도 요구사항의 오해를 발생시키는 원인이 됩니다. 배경지식은 IT 지식이 될 수도 있고, 도메인 지식이 될 수도 있습니다. 배경지식이 없는 사람에게 요구사항 문서는 이해하기 어려울 뿐만 아니라, 구체적인 설명도 많이 부족합니다. 그렇다고 하나하나 물어보기도 부담스럽습니다. 주로 담당업무를 변경하고 업무 인수인계가 미흡할 때 이런 상황이 발생합니다.
개인의 상황에 따라 요구사항 소통에 집중하는 정도가 달라집니다.
요구사항 문서를 읽거나 요구사항에 대한 협의를 할 때 집중하지 않고 다른 생각을 하면 요구사항 내용을 잘못 이해할 수 있습니다. 개인이 컨디션이 좋지 않은 상황 또는 심리적으로 힘든 상황에서는 소통에 집중하기 힘듭니다. 그러나 요구사항 내용을 1:1로 소통하는 것이 아니라면 요구사항을 전달하는 사람이 이런 것까지 헤아려 소통할 수는 없습니다.
대면협의 없이 문서나 메일로만 소통합니다.
요구사항 문서는 소통의 결과이지 소통의 수단이 되어서는 안 됩니다. 요구사항을 협의하는 가장 좋은 수단은 회의실과 화이트보드입니다. 대면협의 없이 요구사항 문서로만 소통하면서 오해가 없길 바라는 것은 기적을 바라는 것과 같습니다. 요구사항 문서를 작성하는 사람에게는 그 내용이 중요하고 간절하지만, 요구사항을 전달받는 사람에게 요구사항 문서는 우선순위가 낮을 뿐만 아니라 요구사항 문서를 집중하여 읽을 이유도 없기 때문입니다. 요구사항과 관련된 사람들이 충분한 소통을 하지 않는 것은 아파트나 다리를 건설할 때 철근이나 시멘트의 양을 줄이는 부실공사를 하는 것과 같습니다.
요구사항의 구체화가 미흡하면 오해가 많아집니다.
구체화가 미흡한 대표적인 상황은 예외사항에 대한 대응을 고려하지 않는 것입니다. 예외사항에 대한 고려가 미흡할 때 발생가능한 문제는 예외사항에 대해 임의로 가정하고 요구사항을 개발하는 것과 예외사항에 대한 정의가 필요함을 뒤늦게 발견하는 것입니다. 소프트웨어 요구사항을 정의할 때 고려해야 할 예외사항의 예는 다음과 같습니다.
요구사항을 정의한 사람의 의도대로 프로세스를 수행하지 않는 경우
B2B 서비스의 고객지원을 위한 회원가입시 회사메일을 요청하는 것은 모든 사용자가 회사 메일이 있다는 가정을 한 것입니다. 만일 회사메일이 없는 중소기업의 사용자는 어떻게 해야 할까요?
보통 사용자들이 프로세스를 잘 따를 것이라는 성선설의 입장에서 시스템을 기획하고 개발한 뒤 프로세스를 잘 따르지 않는 사람들을 성악설의 입장에서 관리하는 경우가 많은데 반대로 하는 것이 좋습니다. 시스템을 기획하고 개발할 때에는 대부분의 사람들이 프로세스를 따르지 않을 것이라고 가정하고 시스템을 적용할 때 예외사항은 성선설의 입장에서 관리하는 것이 바람직합니다.
기 수행한 프로세스를 취소하는 경우
시스템을 기획할 때에는 대부분 정상적인 상황만 생각하기 쉽습니다. 예를 들어 결재의 경우 ‘결재상신 → 결재 → 통보’의 순서대로 진행하는 것입니다. 그러나 결재를 상신했는데, 내용을 잘못 기술한 경우가 발생할 수도 있습니다. 복잡한 단계를 진행하는 프로세스는 특히 기 수행한 단계의 데이터를 변경하거나 삭제하는 경우에 대한 대비를 해야 합니다. 현실에서는 프로세스를 거꾸로 거슬러가는 경우가 반드시 발생합니다.
요구사항의 구체화 수준이 미흡한 경우
요구사항을 개략적으로 정의할 수는 있어도 설계나 코딩을 개략적으로 할 수는 없습니다. 요구사항의 수준이 개략적이어서 설계를 진행하기에 정보가 미흡하면 앞서 설명한 요구사항을 전달받은 사람이 임의로 가정하여 요구사항을 구체화하는 오해 또는 오류가 발생할 수 있습니다. 이러한 상황은 시간에 쫓겨 전체 요구사항을 확정하는 폭포수방법론을 적용할 때 주로 발생합니다.
=======================================================
제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 <슬기로운 PM 생활>을 25년 1월 출간한 소식을 공유합니다.
https://product.kyobobook.co.kr/detail/S000215148133
다음 내용이 궁금하다면?
이미 회원이신가요?
2023년 11월 11일 오전 12:25
삭제된 사용자
2023년 11월 13일
요구사항문서만 보고 전화도 대면회의도 기피하면서 "적혀진대로 했습니다." 라며 본인이 이해한 대로 잘못 만드는 사람들이 있는데, 요구사항을 협의하는 가장좋은수단은 회의실과 화이트보드라는 말에 공감하고 반성하게 됩니다.
@김미수 공감 감사합니다. 저의 경험으로도 난상토론의 결론인 화이트보드를 촬영한 사진 한장은 어떠한 요구사항 정의서보다 강력했습니다.
1. '바쁘다'는 건 열심히 많은 일을 하고 있다는 뜻이다.
‘훌륭한 데이터 분석가란 어떤 사람인가?’에 대해
... 더 보기