태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'애자일'에 해당되는 글 3건

  1. 2017.03.24 [pxd talks 69] User Story와 애자일 방식의 활용방법 by IO Lee
  2. 2012.06.22 [2012 pxd talks 07] Extreme Prototyping : Being Resourceful in Prototyping (1) by 진현정
  3. 2011.04.22 Agile과 UCD (User Centered Design) (2) by 이 재용
2017.03.24 07:50

[pxd talks 69] User Story와 애자일 방식의 활용방법

작년 11월 17일, 69회 pxd talk가 User Story라는 주제를 가지고 워크숍 형태로 진행이 되었습니다.

장장 4시간 동안, Agile Consulting(애자일컨설팅)의 대표이신 김창준 님을 모시고 User Story는 무엇이며, 어떻게 실제 업무 상황에 접목하여 활용할 수 있을지에 관해서 토론과 간단한 실습 통해 pxd talk를 진행하였습니다.


강의 시작은 4명이 한 개의 조가 되어 실제 업무 상황에서 고객사의 요구사항을 정의하는 과정에 발생했던 불편했던, 어려웠던 혹은 짜증 났었던 실질적인 상황들을 5개 이상 적어보고, 그중 지금 당장 꼭 해결하고 싶은 문제 한 가지를 선택하여 김창준 님께서 그 문제를 어떻게 해결하는 것이 좋을지 방향성을 제시해주는 방식으로 강의가 진행되었습니다.

아래는 각 조에서 제시한 고객사와 종종 발생되는 문제 사항들에 대한 내용입니다.



고객사와 발생되는 문제점은 무엇이 있는가?

[1조]

“고객사에서 이미 솔루션을 만들어 놓은 상태에서, 사용자가 어떤 문제가 발생했을 때 해당 솔루션을 필요로 할지 찾아달라고 하는 경우가 있다. 다시 말해, 현재 사용자에게 문제가 없는데 문제를 찾아달라는 것이다.”


[2조]

“고객사의 요구사항을 실질적으로 우리에게 전달해주는 고객 본인이 요구사항에 대한 이해 없이 전달되어, 결국 프로젝트 중간에 문제가 발생되는 경우가 있다. 고객 본인이 무엇을 원하는지 모르는 상황에서 요구사항을 요청하는 경우이다.”


[3조]

“고객과 프로젝트 업무 범위 및 방향성에 대해서 논의한 담당자와 그 업무를 진행하는 실무자가 달라 고객이 요청한 요구사항이 명확하게 전달되지 않는 경우가 있다. 결국, 프로젝트에 대한 Goal이 고객과 실무자 간 싱크가 맞지 않는 경우이다.”

[고객 --> 영업담당자 --> (실무자 <--> 고객)]


[4조]

“고객에게 전달받을 요구사항을 가지고 몇 가지 컨셉 혹은 방향성에 대해서 제안을 했을 경우 결정을 회피한다거나, 결정했던 내용을 중간에 다시 변경하거나 번복하는 상황들이 발생한다. 그리고 고객사 측에서 결정해줘야 하는 서비스 정책 같은 부분들도 결정하지 못하고 결정을 우리에게 요청하는 경우도 있다.”


이렇게 각 조에서 고객사와 프로젝트를 진행하면서 발생했던 문제들 중 다수결 의견을 통해 2조에서 이야기한 문제 상황에 대해서 김창준 님의 의견을 통해 좀 더 심도있게 논의해 보기로 하였습니다.



어떻게 하면 이 문제를 해결할 수 있을까?

‘고객이 정확하게 무엇을 원하는지 모르면서 요구사항을 요청하는 문제’를 문제라고 생각하는 이유는 결국, ‘고객은 무엇이 문제인지, 무엇을 원하는 것인지 알고 있어야 한다는 것’을 우리가 전제로 생각하고 있기 때문이다.

여기서 우리는 이러한 전제가 옳은 것일지를 다시 한번 생각해보는 것이 중요하다.

애자일 방법론에서는 이러한 관점을 옳다고 보지 않는다. 고객 본인들이 정확하게 무엇을 원하는지 모르는 상태에서 우리에게 요구하는 것이 정상에 가깝다고 보기 때문이다. 따라서, 우리는 고객들이 무엇을 원하는지도 모르는 것을 가지고 불평을 하기보다는, 고객 본인이 원하는 것이 무엇인지 잘 모르는 경우, 우리는 어떻게 해야 할지를 고민하는 것이 더 좋은 전략이라고 생각한다.


고객이 무엇을 원하는지 정확하게 알려면 아래와 같은 단계가 필요할 것이다.

원하는 것에 대해서 정확하게 생각하기 -> 정확하게 원하는 것을 전달하기 -> 그것을 정확하게 이해하기 -> 결과물을 제시


이때 정확하게 요구사항을 이해하고 결과물을 제시했음에도 불구하고, 고객이 필요로 했던 것과 원하는 것이 일치하지 않아 문제가 발생할 수도 있다. 하지만 이렇게 일치하지 않는 것도 일반적이라고 볼 수 있다.

이와 같이, 고객이 무엇을 원하는지 정확하게 알기 위해서는 많은 단계가 거쳐야 하기 때문에 결국 정확하게 알 수 없는 문제가 발생할 수 있는 가능성이 높은 것이다.


이런 경우, 우리는 어떻게 해야 할 것인가를 고민해 볼 필요가 있다.

예를 들어 행동심리학에서 수술 만족도에 대한 연구한 결과 수술 전반에 대한 만족도는 수술 말미의 경험이 좌우한다는 것을 알 수 있었다.

+ 시작과 진행 과정이 좋아도 마무리가 나쁜 경우 -> 나쁘다

+ 시작과 진행 과정이 별로였지만 결과가 좋은 경우 -> 좋다


따라서 우리는 고객에게 결과물을 제공했을 때 그 당시 만족을 하였는지, 또는 그 후에 결과물을 적용하여 비즈니스 결과에 대해서 만족을 하였는지 알 수 있어야 한다. 다시 말해, 현재 고객은 A라는 결과물을 원하지만, 3개월 후 A라는 결과물을 제시했을 때 고객이 만족해하지 않을 것이 예상될 경우에는 의도적으로 고객의 현재 요구사항을 만족시키기 보다는 3개월 후의 상황에 투자하는 것이 고객과의 비즈니스 관계를 오래 유지시킬 수 있는 방법이라고 생각한다.


만약 고객이 원하는 A라는 결과물을 제공하였지만, 몇 개월 후 그 결과물로 긍정적인 비즈니스 결과를 얻지 못한다면 고객과 비즈니스 관계를 오래 지속하는 것이 어려워질 것이다. 단, 고객을 어떻게 설득시켜 나갈 것인가는 고민이 되어야 한다.

이런 상황에서는 고객이 원하는 것을 제공해주면서, 그 고객이 미처 깨닫지 못하고 있지 부분에 대해서 깨우칠 수 있도록 유도하는 것이 필요하다. 쉽게 말해서 설득의 과정을 거쳐야 한다. 고객이 현재 결과물에 대해서 판단하는 초점을 몇 개월 후 혹은 몇 년 후 이 제품이 사회에서 인정받을 수 있을 것인가를 고민하는 쪽으로 초점을 변화시켜주어야 한다는 것이다.


이러한 것을 User Story와 애자일 방식을 통해 어느 정도 해결하는 데 도움이 될 수 있다.

먼저 User Story를 사용하면 고객이 요구한 것에 대해서 고객이 빠른 시일 내에 확인하고 학습할 수 있는 방향으로 요구사항들을 정리할 수 있다. 그리고 프로젝트 기간을 여러 개의 마디로 쪼갠 후 각 마디마다 고객이 가지고 있었던 가설 혹은 가정을 검증해서 가지고 있던 가설이 틀렸다는 것을 깨우치게 해주거나, 또는 확인시켜 주는 것이다.


이러한 것을 반복하다 보면 고객들은 단계별로 제시되는 결과를 확인하고 신뢰가 쌓이면서 자신들이 가지고 있던 생각의 틀을 깨고, 점점 더 원하는 것이 무엇인지 정확하게 알 수 있는 상태가 되어갈 수 있을 것이다.



User Story란 무엇인가?

먼저 User Story가 무엇인지 이해하려면 사용자(User)와 이야기(Story)에 대한 의미를 알아야 한다.


“User Story란, 사용자의 요구사항을 정의하고 그것을 관리해 나아가는 방법이다.”


여기서 사용자(User)는 End User 또는 Stakeholder와 같이 우리가 만들려고 하는 시스템을 원활하게 잘 돌아갈 수 있도록 참여하는 사람들을 의미한다. 이야기(Story)는 어떤 종류의 메시지를 왜곡되지 않고 잊어먹지 않게 잘 전달해야 한다는 것을 의미한다. 그리고 Story의 특징은 정해진 틀이 없고 허술하기 때문에 무언가에 관해서 이야기하는 것이 쉬우며, ‘더 이야기를 나누어라’라는 뜻을 내포하고 있기도 하다.

결국, User Story는 고객과의 커뮤니케이션 증가를 위한 것이라고 할 수 있다.


User Story는 보통 3”x5” 크기의 인덱스카드에 작성하여, 고객과 이야기를 하기 위한 일종의 토큰으로 활용된다. 그리고 작은 카드에 모든 요구사항을 다 적을 수 없기 때문에 더욱더 고객과의 커뮤니케이션이 증가할 수밖에 없는 것이다.


User Story를 작성하는 형식은 아래와 같다.

“As a <role>,” “I want <function/goal/desire>,” and “so that <benefit>


<출처: https://www.mountaingoatsoftware.com>


User Story를 작성하는 경우 모든 요구조건을 작성하지 않는다. 우리가 만들려고 하는 시스템의 에센스만 추출하여 User Story를 만들어야 한다. 그리고 그것을 기반으로 만들어낸 산출물을 통해 피드백을 받고 추가하면서 점점 더 User Story를 늘려나가야 한다.


예를 들어 홈 오토메이션 시스템을 만든다고 가정하였을 경우 아래 이미지와 같이 홈 오토메이션이라면 꼭 가능해야 되는 에센스를 Activity 순으로 User Journey 또는 Path를 작성한다. 그리고 각 Activity 단계별로 여러 가지 Validation을 작성한 후 End to End가 가능하도록 Full path를 선택하여 이 Story에 대한 산출물을 구현하고, 피드백을 받을 수 있어야 한다. 만든다. 이러한 과정의 Iteration(반복)을 통해 고객은 어떠한 가치를 얻을 수 있을 것이며, 우리 자신도 빠르게 학습할 수 있게 될 것이다.



이는 그림을 그리는 것 혹은 엄마 뱃속에서 아이가 만들어져 가는 과정과 유사하다고 볼 수 있다.

부분을 완성해가며 전체를 완성하는 것이 아니라, Transformation(변형)과 Differentiation(갈래치기)을 통해 전체를 다듬어 나아가면서 점점 완성해 나가는 것과 유사하다. 그리고 이것은 복잡하고 모호한 것을 만들어 내야 할 때 매우 효과적이다. 만약 복잡한 것을 만들어야 할 때 부분부터 완성해 나간다면, 완성되었을 때 심각한 오류가 발생할 수 있다.


그리고 첫 번째 Iteration은 우리가 만들려고 하는 시스템을 사용하는 어떤 사용자든 사용할 것이라고 생각하는 가장 간단한 또는 논의할 필요도 없을 정도로 Common한 하나의 Full Path를 먼저 선정하여 모델링을 시작해야 한다.

하지만 이러한 과정을 모든 고객사와 함께 진행하는 것은 대부분 불가능할 것이다. 따라서 고객사와 함께 이러한 단계를 진행할 수 없더라도 내부적/자체적으로는 진행하여 우리 스스로가 학습을 통해 점점 더 똑똑해져야 한다.



실습을 통해 User Story 익히기

실습은 [뽀모도로 타이머 앱 UI설계]를 주제로 하여 아래와 같이 각 조별로 뽀모도로 타이머 앱을 사용하는 Activity 단계 및 단계별 Validation을 작성한 후 End to End가 가능하도록 Full Path를 선정하여 앱 UI를 설계해보는 과정을 진행하였다.


이 과정을 진행할 때 하나의 Iteration이 끝날 때마다 우리 스스로가 우리가 만든 것을 보고 이 제품의 핵심이 무엇인지 자문을 해봐야 한다.

뽀모도로 타이머는 알람 울리는 것이 중요한 것이 아니다. 뽀모도로 타이머는 이것을 사용하는 사람들이 집중해서 일하기 위해 사용하는 것이다. 따라서 시간을 설정하는 것보다 중요한 것은 얼마나 집중했었는지를 아는 것이 더 중요한 것일 수 있으며, 이러한 자문을 통해 서비스의 기본적인 기능들이 달라질 수도 있는 것이다. 그리고 이러한 과정을 거치면서 재미있는 부분은, 이야기를 통해 서로가 다르게 생각했었던 부분들이 표면적으로 드러나고, 점점 더 서로가 공통적인 기반을 마련해 나아갈 수 있다는 것이다.



강의에 대한 마무리 소감 및 질의응답

[pxd_1]

“과거 경험상 일반적으로는 어떤 서비스를 만들 때 클라이언트로부터 이미 만들어진 Feature list를 전달받아 프로젝트를 진행하다 보니, 위 과정을 모두 뛰어넘은 느낌이었는데, User Story는 무언가를 꺼내놓고 클라이언트와 보면서 이야기할 수 있는 장치가 될 수 있는 것 같아 의미 있는 것 같았어요.”


[pxd_2]

“실습과정에서 첫 번째 Iteration을 통해 산출물을 만들고 그다음 Iteration은 어떤 기준을 가지고 Validation을 선택하여 다음 Iteration을 진행해야 할지 쉽게 판단이 서질 않아 어려웠다.”

[김창준]

“첫 번째 Iteration을 거친 후 나온 산출물에 대한 피드백이 그다음 Iteration을 위한 Seed가 될 것이다. 그리고 이러한 Iteration 과정을 3번 정도 진행한 후 우리는 우리의 생각이 틀렸었다는 충격을 받아야 한다. 또는 어떻게 하면 지금 우리가 일하고 있는 방식(상황에 제약은 있겠지만)에 약간의 변화를 주어, 산출물이 나왔을 때 우리가 그것을 보고 서프라이즈를 경험할 수 있을까? 에 대한 고민도 해볼 필요가 있다. 왜냐하면, 서프라이즈를 경험하지 않고서는 현재보다 더 나아질 수 없을 것이기 때문이다.”


[pxd_3]

“우리의 업무 프로세스 중 전략 단계에서 도출된 소스들을 가지고 User Story를 만들 수 있을 것 같지만, 그것들을 어떻게 Iteration 해볼 수 있는가에 대해서는 한계점이 있는 것 같았다. 그것을 검증해 나가기 위해서는 우리에게 새로운 시도나 변화가 필요할 것으로 생각이 들었다.”


[pxd_4]

“Activity를 잘 도출하려면 어떻게 해야 하는가?”

[김창준]

“기본적으로 애자일은 처음부터 정답을 맞추기 위해 노력하기보다는 어떻게 하면 점점 더 정확성을 높일 수 있을 것인가로 생각을 변화시켜야 한다. 따라서 엉성하게 시작해서 중간중간 진행 과정을 통해 빠진 부분들을 찾아내면서 추가해 나아가면 된다. 처음부터 완벽한 Activity를 도출하려고 노력하지 말아라.”


[pxd_5]

“Iteration 단계를 언제까지 진행해야 되는 것인가?”

[김창준]

“원칙적으로 Iteration 단계는 프로젝트가 시작했을 때부터 끝날 때 까지 진행해야 된다. 하지만 현실적으로 불가능하다면, 최소한 프로젝트 시작 후 몇 주 혹은 몇 개월 동안만이라도 상황에 맞춰 변형해서 진행하는 것을 권장한다.”



마지막으로

User Story라는 방법은 꼭 클라이언트와의 프로젝트를 진행하며 산출물을 만드는 경우에만 활용이 가능한 것이 아니라, 개인적인 레벨에서도 얼마든지 활용 가능하다는 것을 알 수 있었습니다.

예를 들자면 공지 메일 쓰기, 프로젝트 일정 작성, 발표자료 작성 등 다양한 상황에 적용할 수 있다는 것입니다. 발표자료를 만드는 경우 각 장표마다 내가 전달하고자 하는 핵심 단어를 작성하고, 그것을 문장이나 Phrase로 성장시키며, 몇 번의 Iteration을 거쳐 완성을 해나간다면 전체적으로 일관성을 가진 잘 구성된 발표자료를 만들 수 있게 될 것입니다.


결론은 복잡한 무언가를 만들기 전에 전체를 단순화시킨 어설픈 상태부터 시작하여 거기에 조금씩 살을 붙이고 분화시켜 만들어 나아가면서 완성시키는 일련의 행위를 몸에 배는 것이 중요하다는 것입니다. User Story는 몸에 배게 되면 생각보다 다양한 상황에서 활용이 가능해질 것입니다.


[참고##pxd talks##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2012.06.22 09:16

[2012 pxd talks 07] Extreme Prototyping : Being Resourceful in Prototyping

지난 6월 12일, 2012년 세 번째 pxd workshop이 "Extreme Prototyping: Being Resourceful in Prototyping"이란 제목으로 애자일 컨설팅 대표 김창준님에 의해 진행되었습니다.

1시간 30분 정도의 강의와 30분 정도의 조별 실습으로 이루어진 이날 워크샵은 프로토타이핑을 제품 개발 뿐만 아니라 인생에까지 적용할 수 있는 의미있는 강의였습니다.

우선 김창준님은, '프로토타이핑'이란 말을 매우 광범위하게 해석한다고 합니다. 개발 과정에서 무엇을 먼저 만들어 보는 것 뿐만아니라, 살면서 머리속으로 시뮬레이션 해 보는 것 등 문제를 풀기 위해 해 보는 모든 작은 시도들을 프로토타이핑으로 본다는 것이죠.


문제를 해결할 때는 너무 추상적인 개괄에서 구체적인 해법으로 빨리 들어간 후, 계속 그 구체적인 수준에서만 유지하는 것도 안 좋고(잘 생각 안 하고 무조건 해보면서 그 방식을 고수하는 방식), 반대로 너무 오랫동안 추상적인 생각만 하다가 마지막으로 해결해 보는 것도 안 좋고(오랫동안 계획을 꼼꼼히 세워서 한 번에 성공하자는 방식), 추상과 구체를 계속 오가는 방식이 가장 좋다고 합니다. 즉, 조금 생각해 본 후(local planning), 간단히 실행에 옮겨보고(feedback), 문제를 다시 생각하고, 다시 간단히 실행에 옮기는 식이죠. 이것이 애자일한 방법이며, 실제 전문가들일수록 이런 방법을 따른다고 합니다.

또한 전문가들은 여러 가지 방법을 시도해 보고, 문제를 잘 나누고, 동료와 협력을 잘 하는 것이 특징이라고 합니다. 

예를 들어 한 도자기 수업의 학생들에게, 두 가지 평가 방법 가운데 하나를 고르라고 합니다. 한 방법은 무조건 양으로 점수를 주는 방식이고, 다른 하나는 몇 개를 내건 간에 무조건 가장 잘한 것의 품질로 점수를 주는 방식입니다. 학생들이 성향에 따라 선택 후, 한 학기가 지났을 때, 당연히 한 쪽은 많은 양을 만들었을테고, 한 쪽은 정성들여 하나 또는 두 개를 만들었겠죠. 가장 높은 품질은 '양'그룹에서 나왔을까요? '질'그룹에서 나왔을까요? 놀랍게 '양'그룹에서 나왔다고 합니다. 많은 시행착오를 통해 오히려 더 잘 만드는 방법을 깨달은 것이죠. 반대로 '질' 그룹은 직접 만들어보기보다 자리에 앉아서 어떻게 해야 잘할까 하는 탁상공론만 하다가 시간을 다 보냈다고 합니다.

마지막으로 중요한 것은, 잘못하는 것을 장려하고, 잘못했을 때 외부로부터 건전한 피드백을 받을 수 있는 방법을 확보하는 것입니다.

실습시간에는 우선 선물 주기 연습을 통해 즉흥 연기를 익혔습니다. 즉흥 연기에서 중요한 것은 CROW (Character, Relationship, Objective, Where) 라고 합니다.(추가적인 설명은 서비스디자인 프로토타이핑 참고) 이렇게 한 후에, 조를 나누어 '선물주기' 연습을 하였습니다.


연습이 끝난 후, 본격적으로 4명씩 조를 나누어 "UX 관련 컨퍼런스에서 사람들이 네트워킹을 더 활발하게 할 수 있는 이름표(네임택)를 디자인하라"라는 주제를 가지고 프로토타이핑을 시작하였습니다. 



이후에 즉석 채점에서는
1. Iterative
2. Parallel (devide & feedback)
3. Error Management
4. Mental Simulation
5. Improv (즉흥연기)
로 나누어 채점을 하고, 1조가 우승을 하였습니다. 

실습을 마치고 마지막 마무리로,
미래를 예측하려고 할 때, 사람들은 미래 시제를 사용할 수록 추상적이 되는 경우가 많으므로, 미래를 과거형으로 표현하면 더욱 구체적인 예측(Prospective Hindsight)이 될 수 있다고 강조하였는데, 이는 디자인에서 많이 사용하는 디자인 픽션(혹은 비즈니스 픽션)과 직접적으로 닿아 있었습니다.

참석한 많은 사람들이 프로토타이핑에 적용하는 것도 좋지만, 당장 내가 진행하고 있는 프로젝트, 그리고 내 인생에도 적용해 볼 수 있는 교훈을 얻었다며 좋아했습니다. 매우 뜻깊은 워크샵이었습니다.



(블로그 작성에 도움을 주신 김창준님, 이재용님 감사합니다.)


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 1
Ad Test...
2011.04.22 22:10

Agile과 UCD (User Centered Design)

일반적으로 사용자 중심 디자인(UCD, User Centered Design)은 개발에 들어가기 전, 사용자 연구 등을 통해 필요한 사항(Requirement)과 전략을 명확히 하면 할 수록, 개발 비용도 줄고 과업의 성공 확률도 높다고 주장하고 있다. 이에 따르면 하나의 단계가 끝나고 또 다른 단계를 진행하는 전통적인 폭포수 진행법(Waterfall Process)이 적합해 보인다.
그런데 개발에 있어서 폭포수 진행법이 공격을 받으면서, 빠르게 개발하는 다양한 방법(Agile Process)이 개발자들에게 인기를 점차 얻게 됨에 따라 사용자 중심 디자인에 익숙해져 있던 전통적인 UI 디자이너들도 이에 대응할 필요가 생기게 되었다.
과연 1주에서 2주 내에 빠르게 제품을 만들어 (어떤 부분이든 돌아가게) 빌드하고, 릴리스하면서 제품의 문제점을 빠르게 보완해 가는 반면 전통적인 요구사항(Requirement)이란 실패의 지름길이라고 여기는 이 애자일(Agile) 방법론에서 UI 디자이너들은 어떤 태도를 취해야 할까? 우리 나라에도 제법 사례가 있을텐데 구글신께서 알려주질 않으니 알 도리가 없고, 해외 사례들을 가지고 찾아보았다.


우선, Agile 용어가 낯선 분들 위해 간략하게 무엇인지 알아보면,
http://j.mp/gSrMYc (위키피디아)
http://xper.org/wiki/xp/AgileMethodology

그런데 왜 이것이 UCD와 문제가 되는가?에 대해 기초적인 포스팅은,
http://www.boxesandarrows.com/view/bringing-user인데,
대체로 이 포스팅에서 Agile 환경에서 문제점을 지적하길, 1. 디자인의 역할이 불명확하거나 아예 없다. 2. 요구사항 단계도 없고, 자유로운 컨셉 탐색 단계도 없다. 3. 미완성에서 안정화보단 기능추가 욕구가 더 생긴다.4. 결과적으로 품질 문제가 생긴다. 그래서 개선에는 도움이 되지만 맨 처음 만들 때는 도움이 안된다(Agile is good for refining, not defining.)고 말한다. 따라서 Agile 하게 진행하고 싶으면, 프로젝트 초반에 '컨셉' 혹은 '전략' 잡는 단계를 두고, 그 뒤에 Agile하게 진행하는 것이 좋다는 결론이다.

또 다른 글에서도 역시 비슷한 지적을 하고 있다.
http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
Agile 에서 성공하려면, 프로젝트 초반에 '최소한의' 사용자 조사와 모델링을 하라는 것이다.(Research, model, and design up front - but only just enough) 이 글에서는 이를 포함하여 총 12가지의 Agile 환경에서 성공하기 위한 방법을 설명하는데, 예를 들면 디자이너들이 개발팀의 일부가 되어야 한다, 계속 사용자 테스트를 하기 위한 사용자 풀이 있어야 한다, 개발과 병행하여 사용자 연구를 계속해야 한다, 프로토타입(low fi)을 계속 만들고 이를 요구사항으로 여겨야 한다는 등의 조언을 하고 있다.

대부분의 사람들처럼 갑자기 들이닥친 Agile 환경에 대응하여 실패에서 성공으로 이끈 사례를 발표한 슬라이드
http://www.slideshare.net/jgothelf/beyond-staggered-sprints-integrating-user-experience-and-agile
에서는 첫번째 단계에서 실패하고 두 번째, 세 번째, 네 번째 점점 더 나아져 결국 성공하게 되었는데, 우선 쉽게 가져다가 쓸 수 있는 풍부한 라이브러리(스타일 가이드, 혹은 패턴 라이브러리)가 갖추어지고, 프로토타입을 계속 만들어가면서 개발팀 전체가 같이 디자인하는 식으로 일하면서 계속 User Test를 해 나가면 성공할 수 있다는 것이다.

프로젝트가 시작되면, 일주일 혹은 이주일 단위로 테스트하고 수정해야하는데,
http://agile2010.agilealliance.org/files/agile_2010_Cindy_McCracken.pdf
에서 보는 것처럼 기존의 긴 기간 하던 몇 가지 방법들을, 기간이 짧아지고 계속 반복해야하는 만큼 수정해야할 필요가 있다. 예를 들면 테스트 리포트 같은 경우에도 과정을 하나씩 나열하고 결론을 쓰는 것이 아니라, 신문 기사처럼 가장 중요한 것을 두괄식으로 쓰는 것이다.

자, 이제 요약하면,
1. 디자인팀이 전체 개발팀과 완전히 한 팀이 되어야 한다.
2. 프로젝트 초반에 최소한의 사용자 조사와 모델링을 한다.
3. 부지런히 베껴서 빨리 프로토타입을 만들고 반복하여 테스트한다.

정도로 요약해 볼 수 있다. 자! 이제 우리도 시작해보자.

1. Agile Persona
시간이 없다는 개발팀을 설득하고 설득하여 약 3주간의 리드 타임을 확보하였다.
이를 위하여 pxd에서는 여러 차례 적용하였던 빠른 user research 기법을 사용하였는데, 이 기법의 핵심은 모든 것을 거꾸로 하는 것이다. 즉 전통적으로 user interview ->modeling(critical characteristics)->persona->strategy 순서로 진행했다면, 이번에는

1. peer interview (2~4) -> 2. persona assumption -> 3. questionnaire(critical characteristics) -> 4. user interview

즉 아주 짧은 peer interview를 한다. peer interview란 프로젝트를 함께 진행하는 구성원들간에 '너는 어때?'하고 물어보는 것이다. 물론 정말 시간이 없으면 1번도 하지 않겠지만, 그럴만큼 급한 경우는 없다. 1-2시간에 끝나기 때문이다.

그리고 그것을 통해 대략 퍼소나에 대한 감을 잡은 후,퍼소나를 구분할 수 있는 설문지를 만든다. 이것도 1-2시간안에 끝난다. 설문지는 key critical characteristics를 구별할 수 있는 4-7개의 문항으로 2-3분 내에 끝나게 만든다. 전통적인 설문지가 상호 배타적인 보기(라디오)로 이루어져 있어서 무엇과 무엇 중에 선택을 해야한다면, pxd에서 사용하는 설문지는 모든 문항이 체크로 이루어져 있어 응답자들이 머리를 텅 비우고 답할 수 있게 만들어져 있다. 또한 이 설문지의 모든 보기는 critical char.의 구성 요소가 되도록 만들어져 있기 때문에, 응답자의 대답을 보는 즉시 퍼소나 패턴을 판별할 수 있도록 되어 있다.

이렇게 설문지를 계속 돌리면서 궁금한 패턴이 나타나는 사람들을 불러서 질문한다. 이 작업은 주어진 시간이 될 때까지 한다. 그렇게 하기 위해선 아는 사람들에게 설문지를 돌리고, 궁금한 사람들을 즉시 부르거나 전화로 물어볼 수 있어야 한다. 당연히 필요하면 설문지도 계속 수정한다. 필요하면 persona assumption도 바꾼다. Agile하게! 대략 하루-이틀 정도 걸린다.

첫 번째 주- 일주일만에 user research와 persona & strategy building을 마치고

2. Framework Sketch Workshop
5명의 프로젝트 외부 구성원을 초청하여 1시간동안 프로젝트 개요를 설명한 뒤, 본 프로젝트팀원 포함하여 8명이 각자 프레임웍 두 개씩 그려오기를 두 시간 동안 진행한 뒤, 각자 발표 시간을 가졌다. 거기서 가장 뚜렷한 방향을 가진 프레임웍 3개를 골라서

-퍼소나의 잡을 가장 잘 해결한 프레임웍
-안정적이고 익숙한 구조를 가진 프레임웍
-서비스의 고유한 컨셉을 가장 잘 시각적으로 보여주는 프레임웍

본 프로젝트 구성원 3명이 각각 발전시키기로 하고, 하루동안 작업한 후, 이를 다시 두 개로 통합하여 정리하고, 고객에게 제시하기 위한 준비를 마쳤다.

두 번째 주-일주일만에 프레임웍 15개 그려보고, 3개 골라 발전시키고, 결국 2개로 통합하여 정리

3. Rapid Design Styling
GUI 팀은 프레임웍 워크샵에서부터 참여하기 시작한 사람과 주 중반에 프레임웍이 3개 혹은 2개로 골라지는 시점에 참여하는 사람 등을 포함하여 초기부터 스타일링 작업을 시작하고 2주차 후반에 시안 작업을 시작하였다.

세 번째 주-고객과 최종 프레임웍 결정하고 디자인 시안 완성하여 3주 마지막에 디자인 결정하는 것이 목표 (진행중)

---------

이렇게 만들어진 최소한의 사용자 조사, 모델링, 전략을 가지고 개발에 들어가며, 개발이 Agile 하게 진행되는 경우 2주에 한 번씩 프로토타입을 만들고 테스트할 계획이다. (이렇게 준비했는데 개발이 agile하게 안 할 가능성 발생 ㅠㅠ)

여전히 Agile 프로세스에 앞서 약간의 waterfall을 하는 것이라 완전한 agile 주장자들에겐 변칙으로 보일 가능성도 있고, 또 매우 성급한 결론을 역으로 적용시키는 방식이라 전통적인 UCD 지지자들에게는 날림으로 보일 가능성이 있다. 그러나 Agile 개발 환경이 점점 더 필요하고 늘어나는 것이 대세가 된다면, 분노하고 거부하는 것만이 답은 아니라고 많은 사람들이 문헌에서 밝히고 있다.

그런데 이러한 방법을 진행하기 위하여 매우 중요한 부분이 하나 있다. 이렇게 진행하려면 프로젝트를 진행하는 사람이 매우 경험이 많아야 오류나 우왕좌왕을 피할 수 있다는 것이다. 사용자 조사 경험이나 사용자 인터페이스 설계 경험도 풍부해야겠지만, 도메인 지식도 풍부해야한다. 이 부분이 많은 문헌에서 간과하고 있지만, 필자가 생각하기에 가장 중요한 부분이다.

--------
참고 문헌 포인트로 Keywon Chung & Amy Chung 두 분이 도와 주셨다.
http://ux.stackexchange.com/questions/1919/resources-for-building-a-ui-ux-team-and-process/1940#1940

[참고##Lean UX##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...