요구사항 변경? 변경이 아닌 경우가 더 많습니다.(1)
요구사항 변경의 세가지 유형
프로젝트 팀에서 자주, 쉽게 이야기하는 요구사항 변경은 주장하기는 쉬워도 상대방에게 인정받기는 힘듭니다. 요구사항을 협의하는 사람들이 요구사항 내용을 서로 다르게 이해했다면 사람에 따라 변경여부를 판단하는 기준이 달라지기 때문입니다. 그런 상황에서는 모두가 공감하는 객관적인 요구사항 변경은 존재하지 않기 때문에 변경의 크기에 따라 다툼이 커질 수밖에 없습니다. 반대로 프로젝트 팀과 이해관계자들이 요구사항을 구체적이고 동일하게 이해했다면 변경이 발생해도 변경여부에 대한 논쟁은 줄어듭니다.
현실에서 ‘요구사항 변경’이라는 단어를 사용하는 상황은 크게 세 가지입니다. 첫째는 요구사항을 서로 다르게 이해한 상황, 둘째는 요구사항에 오류가 있는 상황, 셋째는 말 그대로 변심을 한 상황입니다. 세 가지 상황을 구체적으로 설명하면 다음과 같습니다.
① 요구사항에 대해 쌍방이 다르게 이해한 상황
요구사항 변경과 관련된 갈등은 대부분 서로 요구사항을 다르게 이해하는 오해 때문에 발생합니다. 프로젝트 팀은 주관적인 관점에서 변경이라는 단어를 사용하지만, 그 상황을 객관적으로 살펴보면 요구사항에 대한 오해를 바로잡는 과정이 대부분입니다. 오해로 인한 요구사항의 변경은 서로의 입장차이가 있기 때문에 쌍방이 합의하기 힘듭니다. 요구사항을 서로 다르게 이해하는 상황은 요구사항을 제시하는 고객 또는 이해관계자와 요구사항을 이해하고 구현하는 프로젝트 팀 모두의 잘못입니다. “당신은 정확하게 이야기했는데 제가 부주의해서 잘못 이해했습니다.”라고 말하는 사람은 거의 없습니다. 대부분 한쪽은 잘못 이해할 수 있는 단서를 제공했고, 다른 쪽은 자기가 이해하기 쉽게 판단한 결과가 오해나 착각입니다. 이처럼 요구사항의 오해는 쌍방과실인데 교통사고와 같이 과실에 대한 책임비율을 협의할 3자나 대리인들이 없기 때문에, 원만한 갈등해결이 힘들고 기울어진 운동장에서 힘으로 해결하는 경우가 많습니다.
요구사항의 변경의 이해를 돕기 위해 가상의 프로젝트를 사례로 설명드리겠습니다.
가상의 프로젝트 개요는 다음과 같습니다.
프로젝트 관리를 위한 협업도구를 B2B SaaS로 서비스하는 ABC기업에서는 다음과 같이 고객지원 서비스를 개선하는 프로젝트를 추진 중입니다.
□ 프로젝트 명 : ABC사의 고객지원 시스템 개선
□ 추진배경
1. ABC사 상품에 대한 불편사항 또는 문의사항을 접수받는 시스템 개선
- 고객사 일반사용자를 대표해 SR(Service Request)을 등록할 수 있는 인가된 사용자 관리
- SR의 진행상태 변경 시 SR을 등록한 사람에게 모바일로 통보
- 고객사별로 특화된 포털을 구축하여 원스톱서비스(one stop service) 제공
- 파트너사에 등록된 SR을 ABC사의 고객지원 시스템에 연계
2. 사용자의 문의사항을 스스로 해결할 수 있도록 시스템 개선
- LLM(Large Language Models)을 활용한 검색엔진 개선
- FAQ 검색 편의성 개선 : 빈발 문의 노출, 검색 조건 개선(등록일, 조회수, 좋아요 수 등)
요구사항을 오해한 사례 : 파트너사 SR의 시스템 연계 시 첨부 포함여부
고객지원 시스템 개선 요구사항을 정의하는 ‘고객성공팀’에서는 API를 활용한 파트너사 SR 연계 시 첨부의 내용은 SR의 상세근거(예: 화면캡처)를 제공하기 때문에 당연히 연계 대상에 포함하는 것으로 생각했습니다. 반면 프로젝트 팀에서는 API 정보에 없는 첨부는 연계 대상이 아니라고 생각했습니다.
이 사실을 ‘고객성공팀’에서 경영층에게 중간보고를 앞둔 시점에서 발견했고, 서로 얼굴을 붉히는 상황이 발생했습니다. 그리고 SR을 관리하는 현 시스템에서는 첨부 파일을 외부와 주고받을 때 보안이슈가 있음을 발견했고 이를 해결하기 위해서는 3개월의 개발기간 연장이 필요함을 파악했습니다.
② 요구사항을 잘못 정의한 상황
오류로 인한 요구사항 변경은 부족한 정보 또는 개략적인 요구사항에 대해 어느 한쪽이 임의로 잘못된 가정을 했는데 상대방도 잘못된 요구사항임을 몰랐을 때 발생합니다. 예를 들어 정보시스템을 구축할 때 회사 내 외부 시스템에서 데이터를 받아 처리 후 결과를 다시 외부시스템에 제공해야 하는데 이를 누락한 상황입니다. 요구사항의 오해와 달리 오류는 틀린 요구사항을 관련된 사람들이 동일하게 이해합니다. 뒤에 설명할 변심은 정책, 개인의 선호도(예:화면디자인)의 변경이기 때문에 오류와 다릅니다.
요구사항의 오류도 원인제공에 대한 책임이 모호할 경우에는 오류를 수정하기 위한 시간과 비용 부담에 대한 다툼이 발생합니다. 오류에 대한 책임이 모호한 경우는 이해관계자는 상위 수준의 요구사항을 정의하고, 프로젝트 팀에서 상세 요구사항을 정의할 때 주로 발생합니다. 이해관계자는 요구사항을 잘못 정의한 책임은 프로젝트팀에 있다고 하고, 프로젝트 팀은 이해관계자가 처음부터 요구사항을 구체화하지 않았기 때문에 상세 요구사항을 프로젝트 팀에서 정의했으며 그 내용을 이해관계자와 협의했기 때문에 요구사항 오류에 대한 책임은 이해관계자에게 있다고 주장합니다.
요구사항의 오류를 늦게 발견한 사례 : 기존 회원의 개인정보 수정이 필요한 상황
ABC사는 기존에는 신규회원 가입 시 사용자가 고객사 직원인지를 검증하지 않았습니다. 그러나 인가된 사용자 관리를 강화하기 위해 신규회원 가입 시 고객사의 메일 도메인과 일치하는지 확인한 후 회원가입을 승인하도록 ‘고객성공팀’에서 회원승인 정책을 변경했습니다. 이때 기존회원은 이미 승인하였기 때문에 고객사 메일 도메인과 일치하는지 여부를 확인하지 않기로 결정했습니다.
프로젝트 진행도중 신규기능을 적용하기 위해서는 기존 고객도 모두 회사메일을 등록해야 한다는 사실을 발견했습니다. 기존회원의 등록정보를 확인해 본 결과 회사메일이 아닌 개인메일을 등록한 사람이 1,240명이었습니다. 개인메일을 등록한 개인들에게 개인정보 수정을 요청하면 고객들이 번거롭게 생각할 것이기 때문에 회원가입 시 고객사 소속여부를 확인하는 방법을 재검토해야 하는 상황이 되었습니다.
③ 요구사항 내용을 변경한 상황(변심)
변심은 당사자가 변심을 인정할 때 유효합니다. 영화대사처럼 ‘요구사항이 어떻게 바뀌나요?’라고 하소연해도 당사자가 인정하지 않으면 변심이 성립되지 않습니다. 당사자가 인정하지 않는 경우는 변심에 대한 깔끔한 근거가 없을 뿐만 아니라, 변심이라고 주장하는 사람의 오해나 착각일 가능성도 있습니다.
요구사항에 대한 정책을 변경한 사례 : 고객사 계약기간과 SR 등록권한 연계
인가된 사용자에게 SR을 등록할 수 있는 권한을 부여하기 위해서는 해당 고객사가 현재 당사와 서비스 계약 중인지 확인해야 합니다. 계약기간과 연동된 SR 등록권한 관리를 위해 ‘고객성공팀’은 계약기간 만료 1개월 전부터 매주 사용자에게 알람 메일을 보내고 계약기간 만료 1개월 이후부터는 SR을 등록할 수 있는 권한을 삭제하는 정책을 프로젝트 팀에 전달했습니다. 그러나 ABC사의 계약정보의 갱신관리가 미흡하다는 사실을 파악하여 계약정보의 신뢰성을 확보하기 전까지는 업무 담당자가 SR 등록권한 해지를 관리하도록 요구사항을 변경했습니다.
요구사항 변경이 발생하기 쉬운 원인, 결과, 갈등을 해결하는 방식을 요약하면 아래 그림과 같습니다.
요구사항 변경의 원인, 결과, 갈등해결 방식https://brunch.co.kr/@kbhpmp/160
