"스테이시, 집요할만큼 요구사항에 대해 질문해야 해요"
사내 애자일 교육 들은 썰 푼다.txt
이 글은 사내 애자일 교육에서의 에피소드를 담은 글입니다.
이 글의 BGM으로는 걸그룹 위키미키의 Tiki-Taka(99%)를 권합니다.
뭔가 부족한데 알 수가 없네
그 1퍼센트의 어떤 것
Just tell me what you want
재고 따지지 말고 알려줘, 너의 진짜 맘을
- Tiki-Taka(99%) 가사 中
프롤로그.
최근 사내에서 매 달 진행되는 애자일 교육에 참석했다. 오전 10시부터 오후 5시까지 하루의 스케줄을 온전히 빼야 해서, 나는 바쁜 일들이 끝난 이제야 참석할 수 있었다. 다양한 프로그램들이 준비되어 있었고, 이번 글에서는 그중 가장 인상 깊었던 'Role-Play'에 대한 나의 개인적인 경험과 생각들을 담았다.
Role-Play
역할극은 세 명이서 한 조를 구성하며 각자 고객, PO, 개발자 역할을 맡아 두 번의 플레이를 진행한다.
이때 진행자는 고객에게 미리 직선 요소 3가지, 곡선 요소 3가지로 이루어진 두 그림을 전달한다.
PO와 개발자는 고객의 그림을 전혀 알지 못하는 상태이며, 고객은 오로지 말로만 이 그림에 대해 설명할 수 있다.
첫 번째 워터폴 플레이에서는
고객과 개발자는 각자 다른 방에 떨어져 있다. PO는 고객의 요구사항을 최대한 빠르게 수집 후, 개발자에게 전달해 15분 내로 고객이 원했던 그림을 그려내야 한다.
두 번째 애자일 플레이에서는
고객, PO, 개발자가 같은 방에 참석하여 15분 동안 요구사항을 들으며 그림을 그려낸다. 특이점은 그 자리에서 고객의 피드백을 받고 수정을 반복한다.
30분 후, 진행자가 처음에 전달했던 원본과 어느쪽이 더 유사한지 비교해보는 일종의 실험이었다. 나는 프론트엔드, 풀스택 개발자분들과 한 조가 되었고, 가위바위보를 져서 PO 역할을 맡았다. 주륵.
역할 분담
1. 고객 - 풀스택 개발자 (엘*)
2. PO - 프로덕트 오너 (스테이시)
3. 개발자 - 프론트엔드 개발자 (이*)
1st Play.
고객 -> PO -> 개발자
첫 번째 플레이에서는 고객과 개발자가 다른 방에 떨어져 있고, PO가 고객의 요구사항을 수집해 개발에게 전달하는. 즉 워터폴 방식으로 그림을 그렸다. 고객은 말로만 설명할 수 있다 보니 처음엔 "큰 대각선 옆에 영어 스펠링 M이 있어요"라는 러프한 요구사항을 주었다.
머릿속으로 나는 선, 문자로 요소를 나누고 각 요소에 대한 위치, 크기 등 정보 구조도를 그렸다.
"큰 대각선 기준으로 왼쪽에 있을까요, 오른쪽에 있을까요?", "큰 대각선은 얼마나 클까요?"라고 요구사항에 대해 다시 질문했다. 그러자 고객은 "오른쪽 위에 있어요!", "A4용지 가로 기준으로 왼쪽 위에서 오른쪽 아래를 가로지를 만큼 커요!"라고 답했다.
이때 고객이 말한 큰 대각선의 기준으로 '오른쪽 위에 있다'라는 말을 통해 M의 사이즈를 유추할 수 있었고, 대각선의 '크다'라는 개념이, 넓이가 아닌 길이임을 알게 되었다. 나름 요구사항을 잘 수집했다 생각하고 개발자분이 계신 방으로 향했다.
하지만 개발자분은 "큰 대각선의 시작점 위치는 어디예요?", "M은 소문자예요, 대문자예요?"라고 되물었다. 아놔. 대각선은 둘째치고, M은 스스로 당연히 대문자라고 판단하고 고객에게 확인조차 하질 않았던 것이다.
“스테이시, 집요할 만큼 요구사항에 대해 질문해야 해요. M과 m은 달라요.”
뼈를 맞은 기분이었다.
고객에게 요구사항을 받기 전부터 곡선 요소 3개, 직선 요소 3개라는 룰이 있었다. 이 룰은 프로덕트의 정책이라 볼 수 있는데, 내가 이를 무시한 채 기존 정책과 다를 수도 있는 요구사항을 바로 받아와 버린 것이다. 대문자 M이면 직선 요소에 해당하고, 소문자 m이면 곡선 요소에 해당하기 때문에 이건 PO가 꼭 파악을 했어야 하는 부분이었다.
나는 이 사태를 해결하기 위해 개발자분이 다른 요소를 그릴 동안 다시 고객에게 돌아가 대소문자 구분을 확인해야 했다. 하지만 15분이라는 시간은 우릴 기다려주지 않았고, 그렇게 그림은 덜 그린채로 끝이 났다.
2nd Play.
고객 & PO & 개발자
두 번째 플레이에서는 고객, PO, 개발자가 같은 방에 모여 함께 요구사항을 수집하는 동시에 그림을 그렸다. 초안 완성 후 바로 피드백을 받아 수정을 반복하며 애자일 하게 그림을 완성하려 노력했다.
첫 번째 플레이에서는 혼자 고객을 마주해야 한다는 부담감이 컸었는데, 개발자 분과 함께 고객을 만날 땐 심적으로 든든했다. 먼저 요구사항을 받아본 경험이 있으니 이번에는 내가 먼저 A4용지를 사등분했을 때 어느 정도의 위치에 존재하는지, 어느 정도의 면적을 차지하는지 등 애초에 구체적으로 물어보려 노력했다.
그런데 시간이 지날수록 내가 질문하는 일이 거의 없어졌다.
내가 요구사항을 들을 때, 머릿속으로 동시에 정보의 위계를 나눴다면 개발자분은 동시에 그려내는 느낌이랄까? 작은 원의 반지름은 어느 정도 길이인지, 대각선의 시작점은 꼭짓점으로부터 어느 정도의 각도에 위치해 있는지 등 질문이 훨씬 더 구체적이었다. 15분 동안 수정을 통해 완성되어 갈 때마다 만족해하는 고객의 표정을 보며 생각했다.
워터폴이든 애자일이든...
PO로 살아남으려면
일을 정말 잘해야겠는데...?
에필로그.
이번 역할극을 통해 조금 큰 충격을 받았다.
워터폴이든 애자일이든 커뮤니케이션 역량은 디폴트였다. 그리고 내가 Product ghOst가 되지 않으려면 요구사항을 디테일하게 수집하는 것뿐만 아니라 고객과 사업에 대한 이해도가 높아야 한다는 점을 깨달았다.
애초에 고객과 사업.
즉, 배경에 대한 이해도 자체가 높으면 요구사항을 들었을 때, 단순히 원하는 것을 정확히 그리기 위함을 넘어선 진짜 문제와 목적을 파악할 수 있을 것이다. 머리로는 고객과 비즈니스에 대한 이해가 높아야 한다는 걸 잘 알고 있다 생각했지만, 이번 역할극을 통해 온 몸으로 느꼈던 것 같다. '정말 일을 잘해야겠어...'
Product ghOst가 되기 싫은
오늘의 배움 마침.
p.s. 분량조절 실패로 다음 글에서는 '사내 애자일 교육 들은 썰 푼다.txt' 2탄이 연재됩니다.
그리고 작가로서 제 브런치의 피드백 요정을 구합니다! 제 글을 재밌게 보셨다면, 설문에도 꼭 참여해 주세요 :')
