Product Management Research #11 (User Story / Agile)

누구나 일상생활에서 불편한 점을 한 두 가지씩 느끼곤 한다.

나는 옷박스를 볼 때마다 매 번 불편함을 느꼈는데,

인원에 비해 좁은 집에서 살고 있다면 이런 옷 박스를 본 적 있을 것이다.

가성비 끝판왕이다.

 

나 홀로 서울살이를 10년 넘게 하면서 커다란 집이라고는

현장일 다니며 4명에서 살았던 30평짜리 아파트가 다였고,

조그만 집에서 어떻게든 정리를 하려면 정리 박스가 필수였다.

 

우체국 박스, 바나나 박스 등 별의별 아이템을 다 써봤지만

다이소에서 사면 무려 3,000 원에도 구매할 수 있는

가성비 끝판왕인 이 녀석을 따라오진 못했다.

 

하지만 이 녀석도 치명적인 단점이 존재했는데

바로 옷을 하나라도 꺼내고나면 정리했던 옷이

와르르 무너지며 엉망진창이 된다는것이었다.

 

결국 다시 정리를 하지 않으면

다음번에 원하는 옷을 찾기 위해

난장판을 뒤지느라 더 엉망이 되고

시간을 더 쓸 수밖에 없었다.

 

이런 불편한 점을 기업에서는 사용자 스토리로 표현하는데,

Atlassian - Jira에서 얘기하는 사용자 스토리 작성 방법을 보도록 하자.

 

사용자 스토리 작성 방법
사용자 스토리를 작성할 때 다음을 고려합니다.
"완료"의 정의 - 스토리는 일반적으로 사용자가 요약된 작업을 완료할 수 있을 때 "완료"이지만 그 내용을 정의해야 합니다.
하위 작업 또는 작업 개요 - 완료해야 할 특정 단계와 각 단계의 담당자를 정합니다.
사용자 페르소나 - 대상이 누구입니까? 최종 사용자가 여러 명인 경우 스토리도 여러 개 만드는 것을 고려합니다.
순서가 지정된 단계 - 더 큰 프로세스에서 각 단계의 스토리를 작성합니다.
피드백 듣기 - 사용자와 소통하고 그들이 말하는 대로 문제 또는 요구 사항을 포착합니다. 스토리를 고객으로부터 얻을 수 있는 경우에는 스토리를 추측할 필요가 없습니다.
시간 - 시간은 민감한 주제입니다. 많은 개발 팀이 추정 프레임워크에 의존하는 대신 시간 관련 논의 자체를 아예 피합니다. 스토리는 한 스프린트에서 완료할 수 있어야 하므로, 완료하는 데 몇 주 또는 몇 달이 걸릴 수 있는 스토리는 더 작은 스토리로 나누거나 자체 에픽으로 간주해야 합니다.

"저는 [페르소나]로서, [하고 싶은 일]을 하여 [목적]을 이루고 싶습니다.”

"[페르소나]로서": 누구를 위해 이것을 만듭니까? 단지 직책을 의미하는 것이 아니라 한 사람의 페르소나 예를 들어 Max를 추구합니다. 팀은 Max가 누구인지 공동으로 이해해야 합니다. 팀은 여러 Max와 인터뷰한 상태여야 합니다. 팀은 해당 사용자가 어떻게 일하고 생각하며, 무엇을 느끼는지 이해합니다. Max에 대한 공감대가 있습니다.

"하고 싶은 일": 여기서는 사용자가 사용하는 기능이 아니라 의도를 설명합니다. 사용자가 실제로 달성하려는 목표는 무엇입니까? 이 문장은 구현과 관련이 없어야 합니다. 사용자 목표가 아닌 UI의 일부를 설명하고 있다면 논점을 놓쳤다는 의미입니다.

“목적”: 특정 작업을 하려는 사용자의 즉각적인 바람이 그들의 더 큰 그림에 어떻게 잘 맞습니까? 사용자가 달성하고자 하는 전반적인 이점은 무엇입니까? 해결해야 할 가장 큰 문제는 무엇입니까?

 

위의 방식대로 유저 스토리를 작성해 보자.

"저는 집 정리자로서 옷을 쉽게 정리하여 원하는 옷을 찾는 시간을 단축하고 싶습니다."

 

이렇게 작성된 스토리를 기반으로 

Sprint / Kanban을 활용하여 개선을 하는 것이

Jira에서 말하는 Agile User Story이다.

 

사용자가 원하는 것은 결국 옷을 찾는 시간을 단축하는 것인데,

옷을 쉽게 정리하는 것에 초첨을 맞출 수도 있고,

시간을 단축시켜 주는 아이디어를 낼 수도 있다.

 

간단한 해결책 중 하나는

보통 이런 옷박스는 사각형 모양을 유지하기 위해서

양쪽에 쇠로 된 프레임을 넣어두는데,

박스 안에 칸을 나눌 수 있는 프레임을 추가하여

공간을 분리하는 방법이다.

 

쇠로 된 프레임이 있다

 

하지만 이미 4방향으로 프레임이 달려있는 데다

추가로 프레임을 더 붙이면 원가도 비싸지고

저가 정책과 맞지 않는 상품이 되어버릴 가능성이 있다.

 

그렇다면 천과 벨크로를 사용해 사용자가 원하면

중단에 천을 부착하여 공간 분리를 할 수 있도록 한다면?

벨크로로 인해 옷이 상할 수도 있고,

얼마까지 옷의 무게를 버틸 수 있는지 테스트도 해야 한다.

 

이젠 방향을 조금 틀어보도록 하자.

사용자가 옷을 찾는 시간을 단축할 수 있도록 하려면

어떤 방법들이 있을까?

 

시중에 나와있는 옷박스에는 이미

상단에는 지퍼나 벨크로로 위쪽을 열어

쉽게 옷을 찾을 수 있도록 되어있다.

 

하지만 일반적으로 옷박스는 3~4개 이상 겹쳐 사용하므로

최상단에 위치한 박스를 제외하면 큰 의미가 없다.

보통 3~4개 이상 쌓아서 사용한다.

 

그렇다면 지퍼를 옆에도 달아 준다면?

옷을 꺼내기는 쉬워질 수 있으나 

박스의 양면이 물체에 붙어있다면

큰 의미가 없고 박스의 내구성도 떨어질 것이다.

 

조금 더 시야를 넓혀서 옷을 보자.

대부분의 옷에는 태그가 달려있다.

태그를 활용할 수는 없을까?

 

마트의 계산대에서는 물품에 달려있는

바코드를 찍으면 포스에 물품이 뜨며,

중국에서는 현장 결제를 할 때 포장마차에서조차

스마트폰으로 QR을 찍고 현금을 내지 않는다.

 

옷태그에 QR이나 바코드가 들어가 있다면 어떨까?

정리를 하며 스마트폰으로 QR을 찍어뒀다면

앱에 연동되어 옷의 위치가 보이고

앱만 켜서 원하는 옷을 찾을 수 있다.

 

물론 여기에도 치명적인 단점이 존재한다.

옷에 태그가 없다면?

옷을 추가하거나 뺄 때마다

사용자가 앱을 정리해야 하나?

앱을 만드는 데 걸리는 시간과 자원은?

 

또한 아이디어를 현실화시키는 것도

기획자 / 디자이너 / 엔지니어 등

최소 4명 이상이 붙어야 하고

한 주의 Sprint로는 해결할 수 없는 부분이다.

 

무엇보다 예산이 투자자로부터 나온다면

앱을 통해 얼마만큼의 이익을 가져다줄 수 있는지

투자자를 설득하지 못하면 의미가 없다.

 

투자자는 천사가 아니다.

 

오히려 단순한 Sprint가 아닌 

일정 규모 이상의 옷을 판매하는 기업에서

(ex.Uniqlo, Topten, H&M 등)

브랜딩을 위한 방법으로 앱을 개발한다면,

생산공장에서 태그에 QR이나 바코드를 추가하기도 쉽고

시도해 볼 가능성도 훨씬 높아 보이는 게 사실이다.

물론 여러 기업에 투자를 받는 것부터가

엄청난 난관이 되겠지만.

 

결국 유저 스토리, 애자일 방법론 같은 것들은

기업이 원하는 것을 찾는 한 가지 방법일 뿐

만사를 해결해 주는 만능 도구가 아니며,

내놓은 아이디어를 마구잡이로 시도하기 전에

기업의 규모, 투자자, 시장 상황 등

여러 가지를 고려해야 한다.

 

무엇보다 쓰여버린 시간은 돈으로도

살 수 없으니 기획이 중요한 이유다.

 

마지막으로 재미있는 글을 하나 첨부하며 글을 마친다.

대표님, 린스타트업 반대합니다!