brunch

You can make anything
by writing

C.S.Lewis

by 백희 Jul 17. 2023

자, 디자인 스프린트 합시다

Agile 하세요

여러 직군이 포함된 제품팀에서 애자일 스프린트를 하다 보면 발견하는 문제가 있습니다. 개발 조직 중심의 스프린트에서 다른 직군의 소속감과 효율성을 어떻게 가져갈 수 있을까에 대한 문제입니다. 머릿수가 많은 어느 한 직군의 의견이나 일정에 휘둘리지 않고 소수 직군의 전문성을 발휘할 수 있는 방법에는 무엇이 있을까. 늘 어려운 문제입니다.

Product owner로 재직한 어떤 조직에서든 비슷한 문제를 경험해 왔습니다. 스크럼-스프린트 체제가 애초부터 개발 효율화와 점진적 개선을 목표로 수립된 것이기 때문에 개발 주기에 맞춰 업무 프로세스가 형성되어 있습니다. 그래서 개발자를 제외한 다른 직군에서는 줄곧 '개발자만 편한 프로세스', '우리에게 맞는 프로세스는 무엇인가요?' '개발 일정에 대한 Dependency가 너무 심해요' 등에 대한 피드백과 목소리가 주를 이루는 것이죠. 대체로 스프린트가 어느 정도 자리를 잡고 안정화되기 시작하면 회고에서 등장하는 내용입니다.

글로벌 조직도 마찬가지 입니다

현 조직에서도 똑같은 논의가 이뤄지기 시작했습니다. 지금 함께 일하고 있는 제품팀은 다양한 직무와 국적의 개발자 4명과 디자이너 1명, 스크럼 마스터 1명으로 이뤄져 있어요. 개발문화의 성숙도가 높고 개발 속도를 정량적으로 측정하고 회고한 덕분에 개발 스프린트는 큰 개선이 필요하지 않게 되었지만, 개발팀이 날아다닐수록 디자이너는 힘에 부치는 그림이 줄곧 형성되었습니다.

그 외에도 디자인 스펙이 개발팀에 전달되기 직전에 구현 불가능성에 대한 피드백이 날아온다거나 PO가 생각한 범위와 PD가 도출한 솔루션 범위의 갭이 크다거나, 개발자들에게 다소 부담되는 스펙이 포함되어 있어 수정하는 경우가 생기면서 디자이너의 피로도가 높아졌습니다.

그래서 우리 팀에 'Dual Track Agile - Design Sprint'를 만들어보기로 했어요. Dual Track인 이유는, 개발 스프린트를 'Delivery Track'으로 명명하고, 디자인 스프린트를 'Discovery Track'으로 명명하여 스프린트를 하는 체제이기 때문입니다.

디자인 스프린트 프로세스를 만드는 목적은?

1. 디자이너가 다양한 의견을 ideation 하며 영감을 얻도록 유도한다

2. PO의 문제 정의와 해결안을 디자이너가 정확히 이해하고 솔루션의 목표를 세울 수 있도록 돕는다.

3. 비즈니스 그룹, PO, 디자이너가 각자 떠올리는 디자인 솔루션의 불일치를 최소화하고 의견을 수렴할 수 있도록 한다.

등입니다.

제가 혼자 고민한 초안이기에 실효성에 대해 고민이 많았지만, 올해 3월 시작하여 7월인 현재까지 잘 정착하여 유지되고 있는 저희 팀의 프로세스이자 문화가 되었습니다.

이런 형태의 디자인 스프린트가 유지되기 위해서는 팀이 협력적인 자세여야 하며 CEO의 견해 또한 팀원과 동등한 위치의 '의견'으로 받아들일 수 있는 문화가 전제되어야 합니다. 또한 PD, PO의 전문성이 존중되어야 합니다. 다른 팀에서는 보통 이것이 잘 되지 않아 디자인 스프린트가 효과적이지 않았습니다. 저희 팀의 경우 CEO의 견해에도 'NO'를 외치길 두려워하지 않는 구성원들 덕분에 생산적인 토론이 가능했고, 이 밑바탕에는 높은 제품 지식과 유저에 대한 이해도가 있었습니다.

만일 CEO의 견해가 무게감 있는 팀이라면, CEO를 디자인 스프린트의 과정 중에 포함시키기보다 각 미팅에서 도출된 내용을 PO가 CEO에게 Share & Sync 하는 방법을 선택하세요. 다음 미팅에서 CEO의 견해를 대신 메이커들에게 전달하는 방식으로 전환하면 됩니다. 비즈니스 그룹에 의해 Maker가 위축되기 시작하면 솔루션의 품질이 저해될 수 있습니다. 팀 건강이 제품 건강과 직결된다는 사실을 잊지 맙시다.

Discovery Track - Design sprint 프로세스를 소개합니다.

1. Pre-Kick off : 문제 정의와 목표 설정

참여 인원 : PO

첫 번째 단계는 해결하려는 문제를 정의하는 것입니다. 이는 비즈니스 문제, 고객 문제 또는 제품 문제일 수 있습니다. 문제를 명확하게 정의하고 목표를 공유하면, Product Designer가 솔루션을 도출하기 위해 방향성을 찾는 시간을 줄일 수 있습니다.

해결이 필요한 문제와 Task 주제는 Design Sprint Kick Off meeting 하루 전까지 PO가 간단히 정리하여 디자이너에게 전달합니다.

PO는 Kick off meeting 날 문제에 대한 정의, 목표와 이를 해결해야 하는 이유, 솔루션의 최소 조건, 이 Task를 수행함으로써 기대되는 효과와 성공 지표 등을 공유해야 하므로 Draft 문서를 작성합니다.

2. Kick off

1) 재료 준비

미팅 시작 전에 포스트잇, 화이트보드, 마커 같은 필요한 모든 재료가 있는지 확인하세요. 킥오프 중에 재료를 찾느라 시간을 낭비하고 싶지 않을 것입니다.

2) 발산적 사고로 시작하기

참여 인원 : PO, PD, CEO

스프린트의 처음 몇 날은 가능한 한 많은 아이디어를 발생시키는 발산적 사고에 중점을 둬야 합니다. 이것은 Rough 하며 wild 한 사고를 장려하고 다양한 가능성을 탐색하는 시간입니다.

PO가 준비한 draft를 리뷰합니다. PO와 PD, CEO가 해당 Draft 내용을 기반해 Discussion을 진행합니다.

Discussion에서 도출된 아이디어를 화이트보드에 그리며 논의합니다. 여기서 그린 내용이 꼭 솔루션으로 나와야 하는 것은 아닙니다. PO와 PD, CEO가 솔루션 방향을 align 하기 위한 시간입니다.

화이트보드, 포스트잇 등으로 각자 생각한 솔루션을 그려봅니다. / 사진 예시: Unsplash의Kaleidico

3. Design Sprint Planning : 일정 만들기

참여 인원 : PD

디자인 스프린트는 시간제한이 있으므로 주어진 시간 내에 모든 활동을 완료할 수 있는 일정을 만들어야 합니다. 각 활동에 충분한 시간을 할당하고 그 사이에 휴식 시간을 확보해야 합니다.

일정에는 다음 활동의 일정이 포함되어야 하며, Planning이 이뤄진 당일 팀에 공유되어야 합니다.

1차 솔루션 공유 with PO-PD-DEV

2차 솔루션 공유 및 최종안 결정 with PO-PD

UI 스펙 전달 to Dev

4. 플래닝 이후

1) 1차 Solution 공유 - 개발 가능성 확인하기

참여 인원 : PO, PD, DEV

Product Designer가 개발자나 엔지니어와 아이디어를 공유하는 이유는, kick off에서 도출된 아이디어를 실제로 구현할 때 생길 수 있는 기술적인 한계나 문제점을 사전에 파악하기 위해서입니다. 디자인 스프린트의 목표는 솔루션을 빠르게 검증하는 것이므로, 구현 가능성을 높이기 위해 개발자나 엔지니어의 의견을 들어보는 것이 좋습니다.

ideation 한 kick off 결과물의 1차 Lo-fi wireframe이 여러 Variation으로 도출되어 있어야 합니다

해당 내용을 DEV에 공유하고 개발 난이도, 고려해야 할 스펙을 들어보세요

PO와 협의하여 개발 난이도와 구현 기간, 문제 해결 가능성 등을 판단해 더 Develop 할 솔루션을 선택하세요

2) 2차 Solution 공유 - 최고의 아이디어로 수렴하기

참여 인원 : PD PO Others

Product Designer는 제안된 솔루션이 회사의 전반적인 목표와 비전에 부합하는지 확인하고 이번 스프린트의 문제에 부합하는 이상적인 솔루션인지를 최종 align 하기 위해 PO와 공유해야 합니다. 제품에 관심이 있는 다른 메이커 및 비즈니스 그룹도 optional로 참여해 다양한 시각에서의 피드백과 의견을 수렴하고 최종 솔루션을 결정합니다.

PO가 2차 솔루션 공유 미팅에서 도출되는 의견을 중재, 수렴하여 PD에게 피드백 사항을 전달합니다.

PD는 PO가 제안한 피드백 사항의 반영 여부를 Discussion한 뒤 최종안을 도출합니다.