프로젝트 팀에서 자주, 쉽게 이야기하는 요구사항 변경은 주장하기는 쉬워도 상대방에게 인정받기는 힘듭니다. 요구사항을 협의하는 사람들이 요구사항 내용을 서로 다르게 이해했다면 사람에 따라 변경여부를 판단하는 기준이 달라지기 때문입니다. 그런 상황에서는 모두가 공감하는 객관적인 요구사항 변경은 존재하지 않기 때문에 변경의 크기에 따라 다툼이 커질 수밖에 없습니다. 반대로 프로젝트 팀과 이해관계자들이 요구사항을 구체적이고 동일하게 이해했다면 변경이 발생해도 변경여부에 대한  논쟁은 줄어듭니다. 

현실에서 ‘요구사항 변경’이라는 단어를 사용하는 상황은 크게 세 가지입니다. 첫째는 요구사항을 서로 다르게 이해한 상황, 둘째는 요구사항에 오류가 있는 상황, 셋째는 말 그대로 변심을 한 상황입니다. 세 가지 상황을 구체적으로 설명하면 다음과 같습니다. 

• 요구사항에 대해 쌍방이 다르게 이해한 상황 

요구사항 변경과 관련된 갈등은 대부분 서로 요구사항을 다르게 이해하는 오해 때문에 발생합니다. 프로젝트 팀은 주관적인 관점에서 변경이라는 단어를 사용하지만, 그 상황을 객관적으로 살펴보면 요구사항에 대한 오해를 바로잡는 과정이 대부분입니다. 오해로 인한 요구사항의 변경은 서로의 입장차이가 있기 때문에 쌍방이 합의하기 힘듭니다. 요구사항을 서로 다르게 이해하는 상황은 요구사항을 제시하는 고객 또는 이해관계자와 요구사항을 이해하고 구현하는 프로젝트 팀 모두의 잘못입니다. “당신은 정확하게 이야기했는데 제가 부주의해서 잘못 이해했습니다.”라고 말하는 사람은 거의 없습니다. 대부분 한쪽은 잘못 이해할 수 있는 단서를 제공했고, 다른 쪽은 자기가 이해하기 쉽게 판단한 결과가 오해나 착각입니다. 이처럼 요구사항의 오해는 쌍방과실인데 교통사고와 같이  과실에 대한 책임비율을 협의할 3자나 대리인들이 없기 때문에, 원만한 갈등해결이 힘들고 기울어진 운동장에서 힘으로 해결하는 경우가 많습니다. 

• 요구사항을 잘못 정의한 상황

오류로 인한 요구사항 변경은 부족한 정보 또는 개략적인 요구사항에 대해 어느 한쪽이 임의로 잘못된 가정을 했는데 상대방도 잘못된 요구사항임을 몰랐을 때 발생합니다. 예를 들어 정보시스템을 구축할 때 회사 내 외부 시스템에서 데이터를 받아 처리 후 결과를 다시 외부시스템에 제공해야 하는데 이를 누락한 상황입니다. 요구사항의 오해와 달리 오류는 틀린 요구사항을 관련된 사람들이 동일하게 이해합니다. 뒤에 설명할 변심은 정책, 개인의 선호도(예:화면디자인)의 변경이기 때문에 오류와 다릅니다. 

요구사항의 오류도 원인제공에 대한 책임이 모호할 경우에는 오류를 수정하기 위한 시간과 비용 부담에 대한 다툼이 발생합니다. 오류에 대한 책임이 모호한 경우는 이해관계자는 상위 수준의 요구사항을 정의하고, 프로젝트 팀에서 상세 요구사항을 정의할 때 주로 발생합니다. 이해관계자는 요구사항을 잘못 정의한 책임은 프로젝트팀에 있다고 하고, 프로젝트 팀은 이해관계자가 처음부터 요구사항을 구체화하지 않았기 때문에 상세 요구사항을 프로젝트 팀에서 정의했으며 그 내용을 이해관계자와 협의했기 때문에 요구사항 오류에 대한 책임은 이해관계자에게 있다고 주장합니다. 

• 요구사항 내용을 변경한 상황(변심)

변심은 당사자가 변심을 인정할 때 유효합니다. 영화대사처럼 ‘요구사항이 어떻게 바뀌나요?’라고 하소연해도 당사자가 인정하지 않으면 변심이 성립되지 않습니다. 당사자가 인정하지 않는 경우는 변심에 대한 깔끔한 근거가 없을 뿐만 아니라, 변심이라고 주장하는 사람의 오해나 착각일 가능성도 있습니다. 

=======================================================
제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 <슬기로운 PM 생활>을 25년 1월 출간한 소식을 공유합니다.

https://product.kyobobook.co.kr/detail/S000215148133