요구사항 변경의 착각과 진실

요구사항 변경은 PM을 힘들게 하는 요인으로 1위이다. 일감이 늘어나면 일정과 예산이 영향을 받는데 그것을 조정하기 힘들기 때문이다. 그 이유는 무엇일까? 고객은 ‘요구사항 변경’이 아니라고 판단하기 때문이다. 예를 들어 고객은 다음과 같이 이야기한다. • “그게 그 뜻이 아니었어요” • “이건 이렇게 정의한 게 아니었나요?” 고객이 위와 같이 말하는 것은 자신은 요구사항을 변경한 것이 아니라는 의미이다. PM은 일정 변경, 예산증가라는 결과를 생각하기 때문에 ‘요구사항 변경절차’를 적용해야 한다고 생각하고 고객은 PM이 잘못 이해한 것이기 때문에 요구사항 변경이 아니라고 생각한다. 현실에서 PM이 요구사항 변경으로 인식하는 것의 원인은 다음과 같다. • 오해: 같은 요구사항을 서로 다르게 이해 • 오류: 요구사항을 잘못 정의 • 변경: 합의된 요구사항을 변경 오해와 오류는 ‘요구사항 변경절차’를 바로 적용해서는 안되고 잘못된 것부터 수정해야 한다. 잘못된 것을 바로잡지 않고 “당신이 요구사항을 변경했으니 공식적인 변경 절차를 적용해야 합니다”라고 말하면 첫 단추를 잘못 꿴 것이다. 텍스트 중심으로 소통하면 요구사항을 오해하기 쉽다. 오해는 요구사항에 대해 서로 다른 이해를 한 뒤 각자 후속작업을 진행할 때 발생한다. 복잡하고 추상적인 개념을 예시, 다이어그램, 화면과 같은 시각화 자료를 사용하지 않고 텍스트로만 요구사항을 개략적으로 정의할 때 오해가 발생한다. 오해가 발생한 상황에서는 쌍방이 요구사항에 대한 이해를 같이 하는 것이 중요하다. 그 과정 이후 각자 상대방의 관점에서 왜 요구사항을 오해했는지 이해하고 일정과 예산에 미치는 부정적인 영향을 최소화하는 협의를 해야 한다. PM이 오해를 인정해야 고객도 요구사항을 오해하기 쉽게 설명한 것을 인정할 수 있고 그래야 타협안을 만들 수 있다. 개략적으로 정의하거나 검토가 부족하면 잘못된 요구사항을 정의하기 쉽다. 오류는 요구사항을 개략적으로 정의하거나 검토가 부족할 때 발생한다. 사용자가 요청한 내용을 취소하는 기능을 빼먹는 것이 대표적인 예다. 업무시스템이나 솔루션을 구축할 때 다양한 예외사항을 고려하지 못하면 잘못된 요구사항 정의를 하기 쉽다. 처음부터 고객이 잘못 정의한 요구사항이라면 뒤에서 설명할 ‘변경’으로 처리하면 된다. 오류가 발생한 상황에서는 잘못된 요구사항을 수정한 뒤 오류가 발생한 원인을 찾아야 한다. 오류도 쌍방과실인 경우가 많은데 서로 상대방을 탓하면 문제 해결의 실마리를 찾기 힘들다. 예를 들어 예외사항을 고려하지 못한 잘못을 고객 탓으로 돌리면 고객은 프로젝트 팀에서 그 정도 검토는 해야 하지 않느냐고 주장한다. PM이 프로젝트 팀에서 챙길 수 있는 것을 놓쳤다는 것을 일부 인정해야 고객도 귀책을 일부 인정할 수 있다. 어차피 잘못된 요구사항을 구현할 수 없는 것이니 중요한 것은 후속 대응이다. 요구사항 우선순위에 따라 일부 요구사항을 조정하는 것이 가장 바람직하지만 큰 변경이라면 일정이나 예산도 조정해야 한다. 요구사항 확정이후 시간이 지날수록 변경할 가능성이 높다. 세상의 모든 것은 시간에 약하다. 생각은 변하기 쉽고, 사물이나 물건은 쇠퇴하거나 소멸한다. 요구사항도 마찬가지이다. 요구사항을 확정한 이후 릴리즈까지 시간이 길수록 조직의 전략 변경, 외부환경의 변경, 이해관계자의 판단 변경이 있을 수 있다. 요구사항 변경을 고객이 인정하는 상황에서는 공식적인 ‘변경통제 절차’를 적용해야 한다. PM이 생각하는 요구사항 변경은 이번 경우에 해당한다. 오해, 오류, 변경모두 기존 요구사항 문서를 변경해야 한다. 협의나 합의로는 충분하지 않다. 시간이 지나면 기억이 달라지고, 협의에 참여하지 않은 사람도 있기 때문에 수정된 요구사항은 정확하게 문서화하여 이해관계자와 공유해야 한다. 지금까지 설명한 내용을 정리하면 아래 표와 같다. 기업 PM 교육 또는 프로젝트 관리 성숙도 향상에 관심이 있는 분께서는 아래로 문의하시면 연락드리겠습니다. https://www.notion.so/PM-2c23fcbfd93180539098fcbfeb39faf4