[번역/NNg] 애자일에서 유저 리서치를 위한 계산법

Rachel Krause, 2021년 11월 26일

오역, 의역 있습니다. 오역은 제보해주시면 감사하겠습니다.

Accounting for User Research in Agile

---

<요약 및 감상>

애자일에서 스프린트 단위로 리서치 추적이 어렵지만 다음의 방법으로 해소가 가능함을 안내. 현재 팀상황이 연상되서 유익했음.

1.백로그 아이템으로 개별분리해 가시화&추적 노하우 공유

2.지속적 여러번 투명한 공개로 공감구축

3.백로그에다시 넣어 실제니즈반영하는지 체크

---

요약: 디자인, 개발과 마찬자지로, 프로젝트 내내 팀이 지속적으로 사용자를 배우는 것에 집중할 수 있도록 리서치의 노력도 애자일 백로그에 표현되어야 합니다.

유저 리서치와 애자일은 늘 단짝이었던 것은 아닙니다. 애자일 개발은 보통 기능 구현과 일감을 먹기 좋은 크기로 잘라내는 것에 집중합니다. 유저 리서치는 단일 기능에 꼭 항상 묶이지는 않으며, 때문에 (보통의 스프린트 기간인) 2주 혹은 3주 단위에 완벽하게 들어맞기 어렵습니다. 어떻게 하면 유저 리서치를 애자일 방법론에 맞출 수 있을까요?

이 기사에는 다음이 있습니다:

애자일에서 유저리서치는 도전

기능이 아닌 결과에 집중하기

앞으로의 일감(백로그)에 리서치 나타내기

연구 결과물에 기반해 일감(백로그) 업데이트하기

애자일 환경에서, 리서치를 통해 배운 점 소통하기

레퍼런스

애자일 환경에서 유저리서치는 도전

일반적으로 애자일 환경에서 유저 리서치는 팀이 새 기능을 만드는 것과 같은 방식으로 접근하게 됩니다. 일감이 실질적으로 눈에 보이는, 먹기 좋은 사이즈로 나뉘어서 말입니다.

이런 종류의 생각은 많은 도전들을 낳습니다:

리서치는 여러 회차의 스프린트에 걸쳐 이루어집니다. 한 번의 스프린트에 리서치를 완료할 수 없으며, 일감(백로그)은 여러 스프린트에 걸쳐 열린채로 남아있습니다.

리서치 완료 후, 리서치 결과는 고려되지 않습니다. 팀은 사용자로부터 피드백을 받지만 그 피드백들이 이후의 일감(백로그)로 연결되지 않습니다.

리서치 결과는 실질적으로 눈에 보이는 가공품이 아닙니다. 협업 관계자와 팀은 리서치로부터 배운 것들로 뭘 해야할 지 알 수 없습니다. 생산 준비를 마친 완성된 디자인이나 코드를 건네받는 것에 익숙하기 때문입니다.

이런 어려움들 때문에 종종 UX 리서치는 애자일 환경에서 무시되거나 완전히 버려지는 결과를 만나곤 합니다.

기능이 아닌 결과에 집중하기

상품 개발에 있어 가장 큰 함정 중에 하나는 결과가 아닌 결과물에 집중하는 것입니다. — 즉, 목적을 명확히 정의하기 전에 무슨 기능이 만들어져야 할지 논의하는 것입니다. 이렇게 생각하는 것은 사용자와 비즈니스에게 어떤 가치를 전달해야 할지 이해하는 것을 지나쳐 빛나는 기능을 만드는 것에 우선순위를 둬버리게 됩니다.

예를 들어 Venmo와 같은 앱은 아마도 사용자가 현금 없이 쉽게 이체할 수 있도록, 타인에게 송금하는 기능을 만들 것을 결정할 것입니다. 결과물은 송금 기능처럼 개발될 기능입니다. 결과는 타인에게 지불할 또다른 방법과 같이 사용자가 무엇을 얻는가에 대한 것입니다. 우리가 풀고 있는 문제를 이해하고 결과는 무엇인지 알아내기 위해서는 유저 리서치가 필요합니다.

애자일의 주요 가치 중 하나는 계획에 따라 변화에 반응할 수 있는 것입니다. 팀은 프로젝트 내내 지속적인 발견, 즉 지속적으로 배워가는 것에 집중해야 합니다. 리서치는 지속적인 발견을 지탱하는 원동력이 되어야 하고, 프로젝트 전반 계속해서 진행되어야 합니다. 많은 팀이 리서치를 6주짜리 프로젝트 혹은 개발 직전 발견 단계 정도로 생각하고 이후 지속 단계에서는 다시는 진행하지 않습니다. 그러나 매 스프린트마다 어떤 리서치를 수행하는 것을 목표로 한다면, 사용자 중심적 프로덕트를 더 성공적으로 만들 수 있습니다. 이 방법은 항상 배우고 프로젝트 목표를 정제하도록 합니다.

앞으로의 일감(백로그)에 리서치 나타내기

디자인과 개발 일감처럼 리서치도 애자일 일감으로 나타낼 필요가 있습니다. 리서치가 일감 내에 반영되지 않는다면, 리서치는 알아차리기 어렵고 후순위로 밀려날 수밖에 없습니다. — 보이지 않으면, 마음도 멀어집니다.

일감에 리서치를 문서화하려면 다음의 단계를 따라해 보세요:

일감 내에 리서치를 하나의 백로그나 사용자 스토리로 넣으세요.

연구를 먹기 좋은 사이즈로 작게 나눠 리서치 백로그 안에 각각 테스크로 만들어 넣으세요.

테스크를 마쳤다면 완료했다고 표시합니다. 그 동안 리서치 백로그는 모든 테스크를 완료할 때까지 열린 채로 남겨두세요.

이제 예제를 살펴봅시다.

예제: 6명의 참가자들과 함께한 사용성 테스트

예제를 위해서 당신의 앱 내 키보드 단축키를 사용자들이 쓸지 여부에 대해 알기 위해 6명의 사용자들과 함께 사용성 테스트를 하길 원한다고 상상해 보세요.

이 연구를 마치기 위해 다음의 테스크를 끝내야 할 것입니다.

참가자를 모집하고 각각 스케쥴 잡기

세션 진행

데이터 분석

협업 관계자들에게 찾아낸 것을 발표

각 사용자들 마다 모집, 스케쥴 잡기, 세션 진행에 해당하는 테스크를 각각 분리해 백로그에 추가해야 합니다. 그런 다음 데이터 분석과 발표를 위해 하나 혹은 그 이상의 테스크를 추가할 수 있습니다. 어떤 팀은 데이터 수집의 중간쯤 되는 지점에서 패턴을 찾기 시작해, 리서치 기간 내 데이터 분석과 초반에 처음 찾아낸 것들의 발표를 2번씩 할 것입니다.

스프린트 초반의 사용자 6명 리서치 연구: 사용자 테스팅: 키보드 단축키는 백로그 아이템의 이름입니다.; To-Do 구역에 각각을 표현하는 여러 테스크가 포함되어 있습니다. 6명의 참가자들을 테스트할 것이기 때문에 각각의 참여자들에 관련된 기여가 여섯개의 테스크로 표현되어 있습니다. 이 예제에서 팀은 데이터 분석과 발표를 2번씩 하기를 원합니다.

스프린트 마지막 즈음의 동일한 사용성 테스트: 이 시점에 팀은 3명을 모집해 스케쥴을 잡았습니다. 4번째 사용자 모집과 스케쥴링을 진행중이며, 한개의 사용성 테스트 세션을 마쳤습니다.

리서치에 대한 기여가 다회차 스프린트에 열린 채 남아 있을 것이란 사실을 소통하고 수용하는 것은 중요합니다. 어떤 협업 관계자들에게 이 사실을 납득시키는 것은 어려울 수 있으므로, 리서치가 결과물이 아닌 결과를 가져다준다는 것을 상기시키세요. — 즉 기능이 아닌 목표와 필요를 전달한다는 것 말입니다. 세웠던 목표에 가까워졌는지 자문해보세요. 만약 예라고 대답할 수 있다면, 배우고 있다는 뜻입니다. — 좋습니다! 스프린트 리뷰 도중 리서치가 어떻게 진행중이고, (세션 도중) 들었던 인상적인 말들과 무엇이 앞으로 올 것인지에 대해 이야기할 수 있습니다. 이러한 접근은 리서치가 지속적으로 일어날 것이며 팀 내 지지를 계속해서 쌓도록 도와줍니다.

다음 스프린트의 마지막 즈음 6명 사용자 연구: 모든 참가자들은 모집 및 스케쥴링이 완료됬고, 절반의 인터뷰는 끝났으며 연구원들은 절반의 데이터 분석을 마쳤습니다. 스프린트 리뷰 도중 발표된 연구 결과들은 아마 초기의 패턴이나 다른 종류의 진행 보고서를 포함하고 있을 겁니다.

이 중간 점검은 협업 관계자들을 과정에 포함시킬 수 있는 훌륭한 기회입니다! 이제 사람들은 이른 단계의 피드백을 봤기 때문에 나머지 절반의 연구에 자신들도 포함되길 바랄 수도 있습니다. — 리서치를 팀 스포츠로 만들 첫번째 도약입니다. 만약 연구가 빠르게 진행되고 있다면 이러한 중간 지점은 필요하지 않지만, 프로세스를 더욱 투명하게 공개할수록 리서치가 프로세스에 가져오는 가치를 팀원들과 협업 관계자들이 더 잘 이해할 수 있습니다.

백로그 아이템에 있는 모든 테스크를 마치면, 이 리서치는 완료된 것으로 간주하고 닫을 수 있습니다.

연구 결과물에 기반해 일감(백로그) 업데이트하기

리서치가 끝난 후에는 결국 버그 고치기, UX 부채, 가능성 있는 새로운 기능, 미래 리서치에 대한 기회들을 갖게 될 것입니다. 반드시 모두 백로그로 다시 이동해야 합니다. — 현존하는 백로그와 버그픽스와 새 백로그 둘 다 말입니다.

스프린트 리뷰에서의 연구 결과 발표 후에 우선순위를 높이고 즉시 백로그에 추가될 수 있도록 이 목록들을 회상시키세요. 협업 관계자들이 스프린트 리뷰에 이미 있을 것이기 때문에 이후 다른 미팅에 참석하도록 요청할 필요가 없기 때문입니다.

백로그에 연구 결과를 어떻게 포함할 건지에 상관없이 그에 따른 조치를 취하는지 확인하세요. 받은 피드백을 해결하지 않는 팀은 새로운 정보를발견 할 뿐 실제로 바꾸려고 하지 않을 겁니다.

애자일 환경에서, 리서치를 통해 배운 점 소통하기

애자일 팀은 결과물을 전달하는 것에 대해서는 많이 알고 있지만, 연구와 지속적인 배움은 그만큼 중요합니다. 에자일 환경에서 사용자 리서치 수행의 어려움을 극복하기 위해서는, 이것들을 기억하세요:

리서치 활동은 다회차 스프린트 동안 진행될 수 있습니다. 한 개 이상의 기능에 영향을 줄 수 있는 사용자 목표에 집중하고 있으므로, 스프린트 리뷰 동안 어떻게 리서치가 팀을 앞으로 나아가게 할 수 있는지 투명하게 보여주세요. 리서치 진행 중에 자주 소통하는 것은 동의와 공감대를 만들 겁니다.

연구 결과를 백로그에 다시 이어가세요. 애자일 환경에서 지속적으로 전달하고 변화에 반응하는 것은 실행 가능한 소프트웨어를 만드는 것에 중요합니다. 팀이 사용자로부터 들을 뿐만 아니라 그들의 필요에 반응하는지 확인하세요.

리서치는 팀에게 유형의 것 대신 배움의 형태로 가치를 제공합니다. 리서치로부터 배운 것은 앞으로의 기능에 대해 알려주고, 요구사항과 허용 기준을 구축하며, 사용자를 이해하도록 도와줄 겁니다. 이 모든 것은 팀을 앞으로 나아가게 하며 가치를 제공합니다.

레퍼런스

Josh Seiden. 2019. 결과물 너머 결과: 왜 고객의 행동은 비즈니스 성공을 위한 주요 데이터인가. Sense & Respond Press, 미국