요구사항 변경은 예방하기 힘듭니다
자연스러운 결과를 바꾸려면 부자연스러운 노력을 해야 합니다.
요구사항이 변하는 것은 생명체의 노화와 같이 자연스러운 현상입니다. 자연스러운 결과를 바꾸려면 부자연스러운 노력을 해야 합니다. 다이어트가 대표적입니다. 요구사항 변경도 예방하려면 많은 시간을 투입하고, 많은 노력을 해야 합니다. 공짜 점심이나 도깨비방망이와 같은 비법은 없습니다. 요구사항 변경이 발생할 가능성을 줄여주는 다섯 가지 방법은 다음과 같습니다.
– 요구사항 도출 또는 협의를 위해 대면소통을 자주 합니다.
– 중요한 이해관계자의 피드백에 공을 들입니다.
– 모든 팀원들이 한 장소에서 함께 작업합니다.
– 요구사항을 정의하는 템플릿과 기법을 적용합니다.
– 요구사항 정의 후 릴리즈까지의 리드타임을 짧게 합니다.
1) 요구사항 도출 또는 협의를 위해 대면소통을 자주 합니다.
회의실에서 얼굴을 마주 보고 요구사항을 협의하면 요구사항을 오해할 가능성을 줄일 수 있습니다. 그걸 모르는 사람은 없습니다. 많은 사람들이 한 장소에 모이기 힘들고 시간에 쫓기다 보니 대면 소통을 생략하거나 형식적으로 수행할 뿐입니다. 귀찮거나 힘들어 편한 방법을 선택하면 요구사항의 변경의 부작용을 받아들여야 합니다. 다음과 같은 촉매를 사용하면 대면소통의 효과가 더욱 높아집니다.
– 요구사항을 협의하는 워크숍 기법을 적용합니다.
한 두 사람이 요구사항을 정의하여 다른 부서의 사람들에게 요구사항을 전달하는 것보다, 여러 부서의 사람들이 한자리에 모여서 함께 요구사항을 도출하면 요구사항을 정확하게 이해할 가능성이 높아집니다. 사용자 스토리 매핑(user story mapping)이 대표적인 기법입니다.
사용자 스토리 맵이란 아래 그림과 같이 하나의 카드(또는 포스트잇)에 요구사항을 작성하여 고객경험 순서에 따라 왼쪽으로 오른쪽으로, 상세화 수준에 따라 위에서 아래로 배치한 것입니다.
사용자 스토리 맵, 출처:도서출판 인사이트사용자 스토리 맵은 여러 사람들이 모여 각자의 생각을 체계적으로 공유하는 도구로 사용하기에 훌륭합니다. 사용자 스토리 맵은 최상위 레벨에서 스토리의 얼개를 잡은 뒤 상위 스토리를 상세화하기 때문에 직관적이고도 논리적입니다.
또한 포스트잇으로 요구사항을 정의하여 벽에 붙이기 때문에 수정, 삭제, 이동이 간편하고 전체 그림을 볼 수 있기 때문에 누락된 프로세스나 요구사항의 식별이 용이합니다.
또한 온라인의 문서보다 각자의 필체가 담긴 포스트 잇은 훨씬 오랫동안 머릿속에 기억됩니다. 그것은 가족과 함께 한 여행사진에 담겨있는 추억과도 비슷합니다. 심한 논쟁이 있었거나 긴 시간 동안 재미있게 워크숍을 한 결과물일수록 기억은 강렬합니다.
사용자 스토리 맵을 작성할 때 유의할 사항은 다음과 같습니다.
• 초기에는 깊이보다 너비(행)에 집중합니다.
중요한 요구사항이 누락되는 것을 방지하려면 고객경험의 순서대로 전체를 나열하는 것이 중요합니다. 워크숍 도중 갓길 주행을 하는 사람 때문에 잠깐 세부 요구사항을 협의하더라도 퍼실리테이터는 다시 상위 수준의 요구사항을 먼저 논의하도록 유도해야 합니다.
• 요구사항에 따라 깊이(열)는 다르게 정의합니다.
요구사항을 상세화 할 때에는 요구사항의 분류(에픽, 사용자 스토리) 수준을 고민하지 않고 논리에 따라 깊이 내려가야 합니다. 돌멩이는 쪼개도 돌멩이인 것처럼 요구사항은 분할해도 요구사항입니다. 에픽이면 어떻고 사용자 스토리면 어떻습니까? 그건 중요하지 않은 논쟁이며 실제 요구사항을 이해하는데 크게 중요하지 않습니다. 요구사항을 동일한 수준의 계층으로 정의하려는 시도는 바람직하지 않습니다. 큰 요구사항은 3 레벨, 4 레벨, 5 레벨까지 분할할 수도 있습니다. 스토리 매핑을 할 때 요구사항은 공장에서 찍어내는 양산품처럼 균일하지 않고 다이아몬드를 채취하는 바위와 같이 크기가 다양합니다.
• 초기 스토리 맵을 작성 후 유사한 스토리는 묶어서 정제합니다.
초기 스토리 맵을 작성한 후 한발 뒤에서 스토리 맵 전체를 보면 묶어야 하는 스토리가 보입니다. 유사한 스토리를 묶어 이를 대표하는 포스트잇을 만들고 필요시 하위 요구사항을 조정합니다. 유사한 스토리란 비슷한 시기에 동일한 또는 유사한 역할자들이 수행하는 프로세스를 의미합니다.
– 요구사항과 관련된 이해관계자들이 내용을 공감할 때까지 소통합니다.
요구사항 워크숍의 기법은 요구사항 도출을 위한 촉매이지 본질은 아닙니다. 본질은 중요한 이해관계자들이 모두 참여했는지, 요구사항을 이해하고 공감할 만큼의 시간을 가지고 토의했는지입니다. 요구사항의 공감대 형성이 중요하거나 요구사항의 변경비용을 감당하기 힘들수록 요구사항 소통의 본질이 중요합니다. 중요한 이해관계자가 다른 일정 때문에 바빠서 워크숍에 참석하지 않거나, 본격적인 토의를 할만할 때 끝나는 1시간 협의로는 요구사항을 제대로 소통하기 힘듭니다. 중요한 것은 중요하게 다루어야 합니다. 말로만 중요한 ‘요구사항의 공감대 형성’은 립 서비스로 끝납니다. 감기를 치료하는 방식과 암을 치료하는 방식은 달라야 합니다. 요구사항 변경을 감당가능한 수준에 따라 예방을 위한 시간과 노력을 달리 해야 합니다.
2) 중요한 이해관계자의 검토에 공을 들입니다.
요구사항 도출 워크숍 이전 또는 이후에 프로젝트에 큰 영향을 주는 중요한 이해관계자의 검토를 자주 받으면 요구사항 변경의 리스크를 줄일 수 있습니다. 다음은 중요한 이해관계자의 검토를 잘 받기 위한 팁입니다.
– 작게 자주 검토받을수록 요구사항 변경의 리스크가 줄어듭니다.
고위 경영층일수록 프로젝트 추진현황에 대한 충분한 보고시간을 확보하기 힘듭니다. 긴 시간 동안 보고를 준비하여 1시간을 확보했지만 보고 시작부터 예상하지 못했던 질문에 대한 답변을 하느라 30분이 지나면 준비한 내용을 남은 30분 동안 보고하기 힘들어집니다. 첫 번째 보고는 세부내용보다는 보고하고자 하는 주제와 개략적인 방향을 설명하고 그에 대한 경영층의 주 관심사항을 청취하는 수준이면 충분합니다. 간혹 10,000피트 상공에서 지상으로 빨리 내려와서 보고주제를 정확하게 파악하는 경영층도 있지만, 대부분은 최초 1~2번 보고에는 가벼운 대화를 나누는 것도 좋습니다. 경영층이 보고주제에 흥미를 느끼고, 검토의견을 제시하는데 부담이 없도록 하는 것이 가장 좋습니다. 상세방안까지 모두 수립하여 보고하면 경영층이 내용파악도 힘들고, 검토의견을 제시하기에 부담을 느낄 수 있습니다. 경영층은 여러분들이 보고하는 프로젝트 내용보다 더 심각한 현안들을 고민 중이기 때문입니다.
따라서 길고 드문 업데이트 보다 짧고 잦은 업데이트가 효과적입니다. 이전 보고에서 조금씩 실행한 내용을 중간에 보고하면 보고받는 사람은 이해하기 쉽고, 보고하는 사람의 입장에서는 변경의 가능성도 줄어듭니다. 이런 보고는 30분이면 충분하기 때문에 보고하는 사람, 보고받는 사람 모두 부담이 없습니다. 최악은 긴 시간 준비하여 보고했는데 결과가 좋지 않아, 더 긴 시간 동안 준비했는데 경영층의 생각과 다른 경우입니다. 잽(jab)을 맞아야지 카운트 펀치를 맞으면 안 됩니다. 다만 잽을 맞고 이를 만회하는 리액션을 보여주어야 합니다. 경영층과 소통 없이 주변만 돌면 카운트 펀치를 맞을 가능성이 높아집니다. 카운트 펀치 두 방이면 극복하기 힘들어집니다.
– 경영층의 검토의견은 빼먹지 말고 피드백합니다.
경영층의 검토의견에 대해선 피드백을 해야 합니다. 프로젝트 팀이 반영할 수 있는 검토의견뿐만 아니라 반영하기 힘든 검토의견도 빼먹지 말아야 합니다. 지시를 받은 사람은 잊어버려도 지시를 한 사람은 지시한 내용을 잊지 않습니다. 반영하기 힘든 사유를 명확하게 보고한다면 경영층이 납득하거나 중요한 사항이면 대안에 대한 의견을 제시하는 경우가 많습니다. 물론 경영층의 검토의견을 프로젝트 팀이 반영했더라도 그 결과에 대한 추가 의견을 받을 수도 있습니다. 이러한 활동들은 힘들지만 프로젝트 종료시점에서 만기가 도래하는 적금으로 생각하고 정기적으로 예금하듯이 경영층과 소통해야 합니다.
– 한 사람씩 검토의견을 받습니다.
이해관계자와의 검토시간을 줄이고자 여러 이해관계자들에게 한 번에 보고할 수도 있지만 이는 초보자의 생각입니다. 여러 이해관계자들이 모이면 가장 직급이 높은 사람의 눈치를 보느라 본인의 생각을 표현하지 않는 경우가 많습니다. 그렇다고 그러한 이해관계자들이 끝까지 아무 말도 하지 않는 것은 아닙니다. 프로젝트 종료를 판단하는 의사결정에 관련되어 있는 이해관계자라면 언젠가는 본인의 생각을 강하게 주장합니다. 개별 이해관계자의 요구사항을 듣기 위해서는 개별로 심층적인 소통을 해야 합니다. 본인의 이야기를 별도로 들어주기만 해도 이해관계자의 긍정적인 프로젝트 참여를 유도할 수 있습니다. 이해관계자별로 소통하는 것은 단기적으로 비효율적인 것처럼 보일 수 있어도 장기적으로는 프로젝트 팀의 시간을 줄여줍니다.
3) 모든 팀원들이 한 장소에서 함께 작업합니다.
근무장소와 프로젝트 조직구조는 소통에 큰 영향을 미칩니다. 근무장소가 떨어져 있고 기능조직의 형태로 프로젝트를 진행할수록 소통은 어려워집니다. 소통의 관점에서 이상적인 것은 모든 팀원들이 한 장소에서 프로젝트 착수부터 종료까지 함께 작업하는 것입니다. 이러한 조직형태를 애자일에서는 홀팀(whole team)이라고 합니다. 물론 홀팀을 운영하기는 쉽지 않습니다. 한 사람이 한 프로젝트에 전담하는 것보다 여러 개의 프로젝트를 동시에 수행하는 것이 효율적이라고 생각할 수도 있고, 프로젝트 사무실을 확보하기도 힘듭니다. 특히 재택근무가 확산되는 것도 홀팀의 운영을 힘들게 만듭니다. 그러나 조직에 큰 영향을 미치는 중요한 프로젝트를 수행하는데 성공의 확신이 없을 때 프로젝트 관리자는 홀팀 운영운영을 적극적으로 주장해야 합니다.
4) 요구사항을 정의하는 템플릿과 기법을 적용합니다.
요구사항 정의서(또는 사용자 스토리)는 요구사항을 협의한 결과입니다. 결과를 구체적으로 정리해야 사람에 따라 다르게 기억하는 문제, 선택적으로 기억하는 문제를 줄일 수 있습니다. 요구사항 템플릿은 요구사항 정의서가 갖추어야 할 최소한의 수준을 제공합니다. 요구사항의 템플릿이 최소한이자 최대한이 되는 문제점을 줄이기 위해서는 요구사항을 정의하는 기법도 이해해야 합니다. 대표적인 내용은 다음과 같습니다.
– 다양한 유형의 요구사항을 누락 없이 파악해야 합니다.
보통 요구사항이라 하면 기능 요구사항만 생각하기 쉽지만 요구사항을 파악하기 위해서는 아래와 같이 다양한 관점을 고려해야 합니다.
• 프로젝트 수행을 통해 얻고자 하는 비즈니스 가치
• 비즈니스 프로세스, 기술적 요구사항
• 서비스 수준, 안전성, 보안, 기술 지원과 같은 비기능적 요구사항
• 품질요구사항과 품질 검수기준
• 요구사항의 가정, 제약조건
• 운영을 위한 인수인계 요구사항
• 교육 요구사항, 지원 요구사항
– 좋은 요구사항의 특징은 다음과 같습니다.
상품개발 프로젝트를 예로 요구사항 문서가 갖추어야 할 조건은 다음과 같습니다.
• 가치가 명확한 요구사항
해당 요구사항이 고객의 어떤 불편을 해결하는지 또는 어떤 혜택을 제공하는지 명확해야 합니다. SI 프로젝트의 요구사항은 고객사 이해관계자가 가치를 확인하지만, 상품개발 요구사항은 상품관리자가 VOC 분석을 통해 고객가치를 확인해야 합니다.
• (기한 내) 구현이 가능한 요구사항
요구사항의 구현 가능성은 주어진 시간과 비용에 따라 달라집니다. 무한대의 시간과 비용이 주어진다면 구현 못할 요구사항은 없습니다. 따라서 요구사항은 프로젝트에 주어진 예산, 자원, 개발기간 내에 구현 가능해야 합니다.
• 우선순위를 평가할 수 있는 요구사항
제한된 자원을 효율적으로 활용하기 위해서는 상품 요구사항 우선순위를 고려하여 자원을 투입해야 합니다. 그러기 위해서는 상품 요구사항의 우선순위 평가가 가능해야 한다. 우선순위 평가가 어렵다고 해서 모든 요구사항을 ‘must’로 결정해서는 안 됩니다.
• 추정 가능한 요구사항
상품 요구사항의 규모, 개발기간, 투입공수를 추정할 수 있어야 합니다.
• 적정한 크기의 요구사항
요구사항이 너무 크면 추정이 힘들고 요구사항을 너무 작게 분할하면 관리비용이 증가합니다. 적정한 크기는 개발팀의 역량, 사용기술에 따라 달라집니다.
• 상호독립적인 요구사항
요구사항 간에 의존성이 있으면 공통기능이 있을 수 있고 그 결과 중복 개발의 위험이 존재합니다. 공통기능은 하나의 요구사항 규모 추정에만 반영해야 합니다. 또한 의존성이 있는 요구사항은 관련 요구사항을 고려하여 우선순위를 부여해야 합니다.
• 명확한 요구사항
모든 사람들이 요구사항 내용을 동일하게 이해하기 위해서는 사람에 따라 해석이 달라질 수 있는 모호한 형용사가 아닌 명확한 단어를 사용해야 합니다. 상품의 우수함을 설명하기 위해 콘셉트 수준에서 형용사를 사용할 수는 있지만 요구사항 문서에서 형용사 사용은 부작용만 발생합니다. ‘사용자는 조회한 상품을 쉽게 주문할 수 있어야 한다’는 요구사항 대신 ‘사용자는 조회한 상품을 3초 내에 주문 완료할 수 있어야 한다’는 식으로 정의해야 합니다. 요구사항을 정의할 때 유의해야 할 모호한 표현 및 대응방안은 다음과 같습니다.
요구사항 정의 시 유의해야 할 모호한 표현과 대응방안(출처: 칼 위거스, 소프트웨어 요구사항, 2003)• CX 및 UX를 포함한 요구사항
상세 화면 디자인은 개발을 진행하면서 결정하지만 상위 수준의 고객 경험, 고객 인터페이스는 상품을 기획할 때 정의해야 합니다. 상품 요구사항과 CX를 별개로 구분해서는 안 됩니다.
• 추적 가능한 요구사항
요구사항이 최종 상품에 정확하게 반영되었는지 확인할 수 있어야 합니다
– 사용자 스토리 작성 시 유의할 사항
사용자 스토리는 상품 요구사항이 고객에게 제공하는 가치를 고객관점에서 간결하게 정의한 것입니다. 사용자 스토리는 작은 카드 한 장에 정리하여 토론할 때 사용하기도 합니다. ‘익스트림 프로그래밍’의 저자는 ‘요구사항’이라는 단어는 필수적이고 강제적인 어감이 있어 변경을 포용하지 않는다며 스토리’라는 단어를 사용한다고 설명하였습니다.
사용자 스토리는 상품관리자와 개발 팀 간의 의사소통을 촉진하는 도구이기 때문에 애자일 방법론에서 자주 사용됩니다. 사용자 스토리는 스프린트 계획을 수립할 때 구체화되어 확정됩니다.
사용자 스토리는 ‘As(who), I want(what), So that(why)’의 형태로 작성하는 것이 일반적입니다. 예를 들어 에어비앤비 임대 사업자가 방문객에게 집 출입을 위한 임시 비밀번호를 제공하고 싶다면 사용자 스토리를 다음과 같이 정리할 수 있습니다.
• As(who) 에어비앤비 임대 사업자
• I want(what) 예약 승인된 방문자에게 도어록 임시 비밀번호를 제공하고 싶다. 또한 방문객의 숙박 기간 종료 후에는 해당 비밀번호가 작동하지 않아야 한다.
• So that(why) 직접 방문객을 만나지 않고 방문객이 도어록을 열 수 있도록
필자의 대학 시절에는 도서관에서 책을 찾을 때 PC를 활용하는 것이 아니라 책 내용을 카드 형태로 정리한 도서목록카드를 활용했습니다. 카드 한 장에 도서에 대한 정보를 요약하듯이 사용자스토리도 한 장의 카드에 고객의 스토리를 요약합니다. 도서카드에 책의 내용을 모두 담아낼 수 없듯이 스토리 카드에 상세한 요구사항을 모두 포함할 수 없습니다. 종이 카드에 사용자 스토리를 정의하면 책상 위에 펼쳐 놓고 순서를 조정하거나, 내용을 강조할 때 손에 쥐고 이야기할 수 있습니다. 카드 형태로 정리한 사용자 스토리의 템플릿은 아래 그림과 같습니다.
사용자 스토리의 항목 예시사용자 스토리를 정의할 때 유의할 사항은 다음과 같습니다.
• 사용자 스토리는 개발자 관점에서 분할하지 않습니다.
개발자는 고객접점(front), 서버(back end)와 같이 기술적 관점에서 사용자 스토리를 구분하기 쉽습니다. 사용자 스토리는 컵케이크처럼 사용자 요구사항 구현을 위해 필요한 기술을 모두 포함해야 합니다. 즉, 고객접점과 서버를 통합하여 정의해야 합니다. 컵케이크 크기를 작게 하는 것은 문제가 없지만 케이크 재료를 모두 포함하도록 잘라야 케이크의 맛을 평가할 수 있습니다.
예를 들어 ‘에어비앤비 임대 사업자는 도어록의 임시 비밀번호를 발급할 수 있다’는 스토리를 다음과 같이 나누어서는 안 됩니다.
임대 사업자는 방문자 전화번호와 임시 비밀번호, 사용 기간을 등록한다. (I)
임시 비밀번호와 사용 기간을 데이터베이스에 기록한다. (II)
위와 같은 스토리 분할은 사용자 관점에서 어느 하나도 완전하지 않습니다. (I)은 등록한 값이 저장되지 않고, (II)는 (I)을 전제로 한다. 스토리를 컵케이크처럼 나눈 예는 다음과 같습니다. 컵케이크처럼 분할하는 것의 장점은 애플리케이션 아키텍처의 모든 계층을 포함하여 문제점을 사전에 검증할 수 있고, 일부 기능만 구현해도 고객에게 릴리스할 수 있다는 것입니다.
에어비앤비 임대 사업자는 방문자에게 임시 비밀번호를 제공할 수 있다.
에어비앤비 임대 사업자는 비밀번호 사용 기간을 연장할 수 있다.
• 인수 조건은 사전 조건(given), 사전 동작(when), 수행 결과(then)의 내용을 포함합니다.
사전 조건은 주어진 환경이나 값, 사전 동작은 구현하는 기능의 동작, 수행결과는 구현된 기능의 결과를 의미합니다. 예를 들어 사용자 ID를 받을 때(사전 조건), 특수 기호가 포함하지 않은 비밀번호를 받으면(사전 동작), 특수 기호를 포함하여 다시 등록하라는 메시지가 제공되는 경우입니다(수행 결과)
• 요구사항 구현 방법은 포함하지 않습니다.
요구사항을 정의할 때 요구사항 문서에 구현의 세부사항을 포함하는 오류를 범하기 쉽습니다. 개발자 관점의 요구사항 구현 방법은 요구사항 문서에 포함하면 안 됩니다.
• 고객가치와 상관없는 사용자 스토리도 있을 수 있습니다.
예를 들어 소프트웨어 구조 개선을 위한 리팩토링 프로젝트는 앞에서 설명한 내용과 다른 사용자 스토리 템플릿을 적용할 수 있다.
• 이해만 한다면 사용자 스토리를 간략하게 작성해도 됩니다.
상품관리자와 상품개발 팀의 협업이 원활하고 내용에 대한 이해도가 높으면 키워드 중심으로 사용자 스토리를 작성해도 됩니다. 사용자 스토리는 소통의 수단입니다
5) 요구사항 정의 후 릴리즈까지의 리드타임을 짧게 합니다.
요구사항을 정의하고 릴리즈까지의 리드타임이 길수록 요구사항 변경의 가능성이 높아집니다. 새로운 정보를 파악하고, 주변의 상황이 바뀌면 사람의 생각도 바뀔 가능성도 그만큼 높아지기 때문입니다. 일단 릴리즈 후에는 변경을 하더라도 현장에서 검증된 변경만 하기 때문에 검증되지 않은 개인의 생각을 반영하는 일은 없습니다. 무엇보다 릴리즈 후에는 프로젝트 팀이 변경에 대한 책임에서 많이 자유로워집니다.
작게 분할하여 자주 릴리즈 하는 것은 애자일 방법론의 핵심원칙이지만 현실에서 이를 적용하기 힘든 상황이 많습니다. 쉽지 않더라도 프로젝트 업무를 최대한 분할하여 요구사항을 정의하고 릴리즈 하는 것이 요구사항의 정의부터 릴리즈까지의 리드타임을 줄일 수 있습니다. 애자일 방법론을 적용한다고 해서 정보가 부족한 상황에서 요구사항을 조기에 확정하는 것은 잘못된 것입니다. 오히려 반대입니다. 허용가능한 수준에서 요구사항을 최대한 늦게 확정하는 것이 가장 최신의 정보와 환경을 반영하기 때문에 변경의 가능성을 낮춥니다.
김병호 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
