2021.05.11

스크럼에 ‘디자인 사고’ 접목하기 A to Z

Isaac Sacolick | InfoWorld
애자일 개발 팀에는 여러 개발자, QA 자동화 엔지니어, 사이트 신뢰성 엔지니어가 참여하기 마련이다. 이들에게 업무를 전달하는 출발점은 사용자 스토리를 정의하고, 사용자 스토리가 스프린트 내에서 완수되도록 하는 것이다. 

때때로 사용자 스토리는 데이터 통합 구성, 마이크로서비스 API 코딩, 기술 부채 해결, 애플리케이션 성능 개선 같은 ‘백엔드’ 측면의 구현을 요구한다. 그러나 이는 여전히 사용자 스토리이다. 구현이 비즈니스 가치를 제공하기 때문이다. 단 제품 소유자는 기술적인 기준으로 타깃 사용자의 경험을 규정할 수 있다.

기능이나 사용자 스토리가 디자인이 필요한 ‘프론트엔드’ 구현을 요구하는 경우가 있다. 이 때 애자일 팀은 디자인 사고, 와이어프레이밍, 사용자 경험, 디자인 스펙을 요건에 반영할 시기와 방법을 결정해야 한다.

애자일 팀이 사용자 경험과 디자인 스펙을 규정하는 방법, 시기에 대한 ‘답’은 하나가 아니다. 이를 감안하는 것이 애플리케이션과 워크플로우, 모바일 앱의 성공에 아주 중요하다. 궁극적으로 고객 만족과 이용 편의성을 보장하는 것이 비즈니스 결과에 큰 영향을 주기 때문이다.
 
Image Credit : Getty Images Bank

문제 진술(problem statement)을 정의하는 애자일 사용자 스토리
디자인 사고와 애자일 방법론이 어떻게 교차하는지 알아보기 위해, 먼저 제품 소유자가 애자일 팀의 백로그에서 요구사항을 포착하는 방법을 살펴보면 다음과 같다.

대체적으로 제품 소유자는 목표를 서사(epic)와 기능, 사용자 스토리로 구성된 계층으로 세분화한다. 사용자 스토리는 다음과 같은 질문에 답하는 데 도움을 준다.

• 고객, 또는 최종 사용자는?
• 다뤄야 할 문제나 기회는?
• 구현을 통해 달성하려 하는 혜택이나 이점은?
• 고객에게 중요한 이유는?
• 이 사용자 스토리에 대해 ‘완료’를 규정하는 허용 기준은?

여기에서 사용자 스토리가 고객 관점의 문제에 대한 진술과 기회를 정의하는 것을 알 수 있다. 개발 팀에게 사용자 스토리에서 정의된 수용 기준과 목표를 다루는 솔루션을 추천해 구현하도록 돕는 모범 사례이다. 

이런 모범 사례가 항상 적용되는 것은 아니다. 애자일 제품 소유자와 비즈니스 애널리스트 다수가 사용자 스토리 요구사항에 솔루션 구현을 위한 요소를 규정한다. 때론 제품 소유자가 특정한 구현을 염두에 두고 있을 수 있다. 그리고 문제 진술을 솔루션 스펙에서 분리하지 못할 수도 있다. 사용자 스토리 구현을 규정하는 것은 제품 소유자에게 ‘나쁜 사례’이며, 팀과 신뢰 및 협업이 미흡함을 나타낸다.

고려해야 할 실질적인 질문이 있다. 사용자 경험이 문제 정의의 일부인가? 아니면 구현의 요소 중 하나인가? 사용자 경험과 디자인은 문제와 솔루션 모두가 될 수 있다. 경험의 성격, 사용자 경험과 디자이너가 애자일 팀의 구성원인지 여부, 개발 팀이 구현에 플랫폼을 사용하는 방법에 따라서다. 

디자인 사고 프로세스
디자인 사고로 고객 경험을 정의하고 반복적으로 개선하는 방식에 대한 논의에 두 번째 요소를 추가해보자. 소매와 전자상거래, 미디어, 게임, 퍼스널 뱅킹 등 B2C 산업은 고객 경험과 일관된 디자인, 유용성을 전략적으로 아주 중요하게 생각한다. 고객들의 쇼핑, 구매, 구독, 서비스 소비에 있어 아주 중요한 차별화 요소가 될 수 있는 요소들이기 때문이다.

또 현재 대부분의 B2B 기업들도 디지털 트랜스포메이션에서 고객 및 직원 경험을 전략적으로 중요하게 고려한다. 사람들은 거추장스러운 워크플로우를 거치거나, 일관되지 못한 디자인의 도구들을 사용하거나, 이해하기 어려운 설명서나 오류 메시지와 씨름하거나, 완료에 너무 많은 시간이 걸리는 것을 좋아하지 않는다.

디자인 사고는 고객이나 최종 사용자를 염두에 두고 시작하는 하향식 프로세스이다. 애자일 방법론과 마찬가지로 몇 가지 디자인 사고 사례가 존재한다. 상당수는 다음 디자인 단계를 활용한다.

• 고객 니즈에 공감하고, 고객 입장이 되려 노력한다.
• 최종 사용자 니즈와 관련된 문제, 기회, 가치, 경쟁 요인들을 규정한다.
• 여러 시나리오, 개념, 혁신적 아이디어를 구상한다.
• 흐름의 원형을 만들고, 개념 증명을 발전시키고, 소규모 사용자 집단을 대상으로 시범 운영을 한다.
• 솔루션을 테스트하고, 피드백을 수집하고, 인사이트를 발굴하고, 개선할 부분을 중시한다.

디자인 사고는 고객 세그먼트 개발, 사용자 페르소나 파악, 가치 제안 확립 등 다른 영역과 도구들 또한 다룬다. 여정 매핑, 공감 지도 같은 도구들을 이용해 행동에 대해 연구한다. 이는 전자상거래 사이트에서의 구매나 구독 서비스 등록 같은 특정 태스크를 달성시키는 애플리케이션 디자인에 특히 유용하다.

제품과 서사, 기능 디자인 및 개발
애자일 개발팀의 업무 시작 전에 디자인이 완성되는가? 또는 사용자 경험과 디자인 고려 사항이 사용자 스토리와 구현에 반영되는가? 

디지털과 기술 조직이 피해야 할 시나리오가 있다. 사용자 경험 전문가와 디자이너는 디자인 사고 사례를 적용하고, 개발자는 독립적인 스크럼 프로세스를 적용하는 것이다. 이로써 단절되거나 상충되는 프로세스가 야기되게 된다.

대부분 조직이 새 제품과 복잡한 워크플로우, 또는 모바일 애플리케이션을 개발할 때 완전한 혁신, 브레인스토밍, 디자인 사고 프로세스를 적용할 것이다. 이런 상황에서 프로토타이핑(원형 구현)은 최종 사용자 피드백을 얻기 위한 목업, 와이어프레임, 기타 시각적 도구에 국한될 수 있다. 팀은 다음을 논의해야 한다.

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2021.05.11

스크럼에 ‘디자인 사고’ 접목하기 A to Z

Isaac Sacolick | InfoWorld
애자일 개발 팀에는 여러 개발자, QA 자동화 엔지니어, 사이트 신뢰성 엔지니어가 참여하기 마련이다. 이들에게 업무를 전달하는 출발점은 사용자 스토리를 정의하고, 사용자 스토리가 스프린트 내에서 완수되도록 하는 것이다. 

때때로 사용자 스토리는 데이터 통합 구성, 마이크로서비스 API 코딩, 기술 부채 해결, 애플리케이션 성능 개선 같은 ‘백엔드’ 측면의 구현을 요구한다. 그러나 이는 여전히 사용자 스토리이다. 구현이 비즈니스 가치를 제공하기 때문이다. 단 제품 소유자는 기술적인 기준으로 타깃 사용자의 경험을 규정할 수 있다.

기능이나 사용자 스토리가 디자인이 필요한 ‘프론트엔드’ 구현을 요구하는 경우가 있다. 이 때 애자일 팀은 디자인 사고, 와이어프레이밍, 사용자 경험, 디자인 스펙을 요건에 반영할 시기와 방법을 결정해야 한다.

애자일 팀이 사용자 경험과 디자인 스펙을 규정하는 방법, 시기에 대한 ‘답’은 하나가 아니다. 이를 감안하는 것이 애플리케이션과 워크플로우, 모바일 앱의 성공에 아주 중요하다. 궁극적으로 고객 만족과 이용 편의성을 보장하는 것이 비즈니스 결과에 큰 영향을 주기 때문이다.
 
Image Credit : Getty Images Bank

문제 진술(problem statement)을 정의하는 애자일 사용자 스토리
디자인 사고와 애자일 방법론이 어떻게 교차하는지 알아보기 위해, 먼저 제품 소유자가 애자일 팀의 백로그에서 요구사항을 포착하는 방법을 살펴보면 다음과 같다.

대체적으로 제품 소유자는 목표를 서사(epic)와 기능, 사용자 스토리로 구성된 계층으로 세분화한다. 사용자 스토리는 다음과 같은 질문에 답하는 데 도움을 준다.

• 고객, 또는 최종 사용자는?
• 다뤄야 할 문제나 기회는?
• 구현을 통해 달성하려 하는 혜택이나 이점은?
• 고객에게 중요한 이유는?
• 이 사용자 스토리에 대해 ‘완료’를 규정하는 허용 기준은?

여기에서 사용자 스토리가 고객 관점의 문제에 대한 진술과 기회를 정의하는 것을 알 수 있다. 개발 팀에게 사용자 스토리에서 정의된 수용 기준과 목표를 다루는 솔루션을 추천해 구현하도록 돕는 모범 사례이다. 

이런 모범 사례가 항상 적용되는 것은 아니다. 애자일 제품 소유자와 비즈니스 애널리스트 다수가 사용자 스토리 요구사항에 솔루션 구현을 위한 요소를 규정한다. 때론 제품 소유자가 특정한 구현을 염두에 두고 있을 수 있다. 그리고 문제 진술을 솔루션 스펙에서 분리하지 못할 수도 있다. 사용자 스토리 구현을 규정하는 것은 제품 소유자에게 ‘나쁜 사례’이며, 팀과 신뢰 및 협업이 미흡함을 나타낸다.

고려해야 할 실질적인 질문이 있다. 사용자 경험이 문제 정의의 일부인가? 아니면 구현의 요소 중 하나인가? 사용자 경험과 디자인은 문제와 솔루션 모두가 될 수 있다. 경험의 성격, 사용자 경험과 디자이너가 애자일 팀의 구성원인지 여부, 개발 팀이 구현에 플랫폼을 사용하는 방법에 따라서다. 

디자인 사고 프로세스
디자인 사고로 고객 경험을 정의하고 반복적으로 개선하는 방식에 대한 논의에 두 번째 요소를 추가해보자. 소매와 전자상거래, 미디어, 게임, 퍼스널 뱅킹 등 B2C 산업은 고객 경험과 일관된 디자인, 유용성을 전략적으로 아주 중요하게 생각한다. 고객들의 쇼핑, 구매, 구독, 서비스 소비에 있어 아주 중요한 차별화 요소가 될 수 있는 요소들이기 때문이다.

또 현재 대부분의 B2B 기업들도 디지털 트랜스포메이션에서 고객 및 직원 경험을 전략적으로 중요하게 고려한다. 사람들은 거추장스러운 워크플로우를 거치거나, 일관되지 못한 디자인의 도구들을 사용하거나, 이해하기 어려운 설명서나 오류 메시지와 씨름하거나, 완료에 너무 많은 시간이 걸리는 것을 좋아하지 않는다.

디자인 사고는 고객이나 최종 사용자를 염두에 두고 시작하는 하향식 프로세스이다. 애자일 방법론과 마찬가지로 몇 가지 디자인 사고 사례가 존재한다. 상당수는 다음 디자인 단계를 활용한다.

• 고객 니즈에 공감하고, 고객 입장이 되려 노력한다.
• 최종 사용자 니즈와 관련된 문제, 기회, 가치, 경쟁 요인들을 규정한다.
• 여러 시나리오, 개념, 혁신적 아이디어를 구상한다.
• 흐름의 원형을 만들고, 개념 증명을 발전시키고, 소규모 사용자 집단을 대상으로 시범 운영을 한다.
• 솔루션을 테스트하고, 피드백을 수집하고, 인사이트를 발굴하고, 개선할 부분을 중시한다.

디자인 사고는 고객 세그먼트 개발, 사용자 페르소나 파악, 가치 제안 확립 등 다른 영역과 도구들 또한 다룬다. 여정 매핑, 공감 지도 같은 도구들을 이용해 행동에 대해 연구한다. 이는 전자상거래 사이트에서의 구매나 구독 서비스 등록 같은 특정 태스크를 달성시키는 애플리케이션 디자인에 특히 유용하다.

제품과 서사, 기능 디자인 및 개발
애자일 개발팀의 업무 시작 전에 디자인이 완성되는가? 또는 사용자 경험과 디자인 고려 사항이 사용자 스토리와 구현에 반영되는가? 

디지털과 기술 조직이 피해야 할 시나리오가 있다. 사용자 경험 전문가와 디자이너는 디자인 사고 사례를 적용하고, 개발자는 독립적인 스크럼 프로세스를 적용하는 것이다. 이로써 단절되거나 상충되는 프로세스가 야기되게 된다.

대부분 조직이 새 제품과 복잡한 워크플로우, 또는 모바일 애플리케이션을 개발할 때 완전한 혁신, 브레인스토밍, 디자인 사고 프로세스를 적용할 것이다. 이런 상황에서 프로토타이핑(원형 구현)은 최종 사용자 피드백을 얻기 위한 목업, 와이어프레임, 기타 시각적 도구에 국한될 수 있다. 팀은 다음을 논의해야 한다.

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X