📕

애자일 프로덕트 매니저의 역할과 기술 (실전 - 어려움)

토글 ( )을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다. (전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )

목차 확인하기

애자일 조직에서 프로덕트 매니저의 역할과 기술에 대해 간략히 알아봅시다.

프로덕트 미션, 비전과 목표를 명확하게 제시하기

애자일 조직에서는 프로덕트 매니저가 프로덕트로 사업을 이끌어 나갈 수 있도록 충분한 권한을 부여합니다. 이 때, 기업이 가지고 있는 비전과 목표를 상위 조직과 하위 조직들이 서로 일치하도록 정렬하는 것이 필요합니다. 기업이 목표하는 방향으로 동일하게 각 프로덕트가 목표를 설정하고 성장하기 위해서 입니다. 하위 조직의 민첩함, 속도, 성장, 학습을 자발적으로 할 수 있도록 장려하고 동시에 방향과 기대치를 함께 맞추기 위해 사용하는 목표와 기대 성과 전략이 OKR 입니다.

OKR 은 일정기간 (3개월 또는 6개월) 조직 상위에서 목표로 하는 방향과 핵심 지표를 설정하면, 이에 맞춰 단계적으로 하부 조직, 그리고 개인까지 각각의 목표를 설정합니다. 조직의 전체 목표를 실질적으로 달성하기 위해 개별 단위로 기여할 수 있는 목표를 명시하는 것입니다. 프로덕트 매니저는 프로덕트 단위로 업무를 하는 팀 (스크럼 팀, 스쿼드)이 어떤 목표를 가지고 프로덕트를 성장시켜 나갈 것인지 목표를 설정합니다.

OKR 의 사용 여부와 관계없이도 프로덕트 매니저는 담당하는 프로덕트의 미션과 비전을 명시적으로 설정합니다. 미션과 비전은 프로덕트의 가장 높은 수준에서 이해할 수 있는 프로덕트의 성격과 발전 방향성을 이해할 수 있는 문장입니다.

‘인스타그램’의 미션과 비전을 예시로 이해해 보겠습니다. 그리고 구글 번역으로 한글화한 문장을 추가합니다. (출처: https://mission-statement.com/instagram/#Vision_Statement)

미션

“to capture and share the world’s moments.”

⇒ 세상의 순간을 포착하고 공유하는 것

비전

“to solve three simple problems: Mobile photos always come out looking mediocre. Our awesome looking filters transform your photos into professional-looking snapshots. Sharing on multiple platforms is a pain – we help you take a picture once, then share it (instantly) on multiple services. Most uploading experiences are clumsy and take forever – we’ve optimized the experience to be fast and efficient.”

⇒ 세 가지 간단한 문제를 해결하는 것입니다. 모바일 사진은 항상 평범하게 보입니다. 우리의 멋진 필터는 사진을 전문가 수준의 스냅샷으로 변환합니다. 여러 플랫폼에서 공유하는 것은 쉽지 않습니다. 한 번 사진을 찍은 다음 여러 서비스에서 (즉시) 공유할 수 있도록 도와드립니다. 대부분의 업로드 경험은 서투르고 오래 걸립니다. 우리는 경험을 빠르고 효율적으로 최적화 했습니다.

이것을 조금 더 하위 수준에서 목표를 설정할 수 있는 핵심 가치도 설정하고 있습니다.

Community first
Inspire creativity
Simplicity matters

⇒ 1. 커뮤니티 우선 2. 창의력 고취 3. 간단함 지향

미션, 비전, 핵심 가치만 확인한 것으로도 인스타그램이 어떤 성격, 발전 방향, 미래 모습을 갖는지를 이해할 수 있습니다. 프로덕트를 개발하는 팀은 어떨까요? 프로덕트를 만드는 사람들은 문제를 해결하기 위해 다양한 아이디어와 해결책을 제시하고 그것을 실현합니다. 이 때, 프로덕트 매니저가 이들을 도울 수 있는 가장 중요한 것은 미션, 비전, 핵심 가치를 명확히 해서 길을 잃지 않고, 우리가 목표로 하는 방향으로 성장할 수 있게 이해를 공유하는 것입니다. 프로덕트를 만들고 싶은 마음에 개발을 하는 세부적인 일을 시작하기 전에 방향성을 먼저 고민하고 계속 최적화해 나가보세요.

애자일 사고방식으로 일 하기 기본

애자일이 되기 Being Agile 위해서는 ‘우리는 정답을 모른다.’ 를 전제로 하면 쉽습니다. 또한 ‘프로덕트를 만드는 것은 혼자 할 수 없다.’ 를 받아들이는 것입니다.

우리는 정답을 모르기 때문에 아는 만큼 구체화하고 계획하고 실행합니다. 이 작은 단위의 개발을 반복하면서, 실험 결과, 경험, 시간의 흐름으로 인해 새로 알게되는 것을 계속해서 흡수하고 새로 적용하며 사람과 프로덕트가 함께 성장하는 것입니다.

요즘의 프로덕트를 하나 떠올려 보세요. 이것을 혼자서 개발할 수 있을까요? 또는 한 사람의 아이디어로 만들었다고 생각하시나요? 역할과 상관없이 많은 사람들이 자신이 아는 것과 유저 이해, 창의력, 전문 역량을 발휘하여 함께 만든 것입니다. 디지털 프로덕트가 시작되고 발전해 온 시간이 길어지면서, 유저의 만족도를 충족시키는 것과 고도화된 기술을 프로덕트에 활용하는 것은 쉬운 일이 아닙니다. 역할을 정하고 개인의 일을 하는 프로덕트 팀 보다 같은 목표를 설정하고, 과정을 함께 고민하고 협업하는 원팀을 지향해 보세요.

프로덕트 미션, 비전, 목표는 멀리 있는 산 정상처럼 보여서 멀기만 하고 길도 잘 보이지 않습니다. 이 목표 지점까지 도달하기 위해서 가는 여정을 보이는만큼 짧은 단위로 나누어서 가보세요. 작은 목표 하나씩을 달성하면서 나아가면, 보이지 않던 다음 체크 포인트가 보이고, 전체 여정이 보다 덜 힘들면서 확신이 드는 효과를 얻을 수 있습니다. 실제 프로덕트 개발 여정에서는 전체 개발 기간을 짧게 나누고 전체 개발 할 일을 작게 분할하는 것을 의미합니다.

프로덕트 매니저가 프로덕트의 모든 세부사항을 혼자서 구체화 해야한다고 생각하면, 이런 경우 실제 프로덕트 개발 과정에 병목 현상을 가져오는 경우가 발생합니다. 프로덕트 매니저가 프로덕트의 모든 구체적인 해결책을 혼자 구상하여 정리하고 기획서 라는 문서를 작성하여 개발팀에게 전달하면 개발팀이 이것을 이해하고 동일하게 개발해서 결과물을 만들 것이다. 이제 이 생각은 오래된 믿음 입니다. 또한 개발자들을 더 수동적으로 일 하게 만드는 악순환 입니다.

애자일 팀의 프로덕트 매니저는 목표와 가설, 이를 해결하기 위한 대략적인 계획을 가지고 팀에 공유하고, 디자이너, 개발자들, QA 등 모든 역할자가 함께 구체화하여 작은 단위 할 일들을 프로덕트로 완성해 나가는 것을 반복합니다.

프로덕트 목표를 달성하기 위한 개발 계획 수립

프로덕트 매니저가 개발자들에게 일정 기간의 전체 할 일을 보여주는 방법 중 유저 스토리 매핑 User Story Mapping 이라는 기술을 사용할 수 있습니다. 이 작업을 할 때, 실제 유저, 주요 이해관계자, 개발자들이 함께 참여합니다. 목표는 참여한 사람들이 프로덕트 전체 개발 과정을 동일하게 이해하고 정보를 공유하는 것입니다.

유저의 입장에서 공감한 것, 정보, 문제점 Pain Point 를 바탕으로 우리가 개발하려고 하는 프로덕트의 할 일들을 큰 단위로 나누어 작성합니다. (포스트 잇을 이용합니다. 디지털 도구를 활용할 수도 있습니다.) 큰 단위 할 일들을 다시 작은 단위의 할 일들로 분할하여 큰 단위 할 일의 열에 붙여봅니다. 작은 단위의 할 일들이 충분히 작성되면, 이 일들을 우선순위를 구분하여 우선순위 레벨에 따라 위에서 아래로 구분하여 이동시킵니다. (우선순위 부여는 아주 여러가지 방법이 있습니다. 간단한 한 가지 방법은 MoSCoW: 반드시 필요한 일 Must / 해야 하는 일 Should Have / 하면 좋은 일 Could Have / (현재는) 하지 않을 일 Won’t Have 로 구분하는 것입니다.)

이제 작은 단위 할 일들을 살펴보면서 대략적으로 팀이 가지고 있는 개발주기 (스프린트, 이터레이션) 만큼 어느 정도의 할 일들을 완료할 수 있을지 수평선을 그어봅니다. 전체 할 일들이 우선순위가 높은 일들부터 낮은 일들로 완성되어 가는 전체 기간에 대한 일정이 생깁니다. 이 일정은 현재 기준의 목표로 할 수 있는 것이고, 개발주기를 진행해 나가면서 다음 주기의 할 일 또는 일정은 필요하면 우선순위 조정을 통해 변경이 발생할 수도 있습니다. 이 결과가 팀이 함께 공유한 릴리스 플래닝 Release Planning 이 됩니다. 프로덕트를 어떻게 개발해 나갈 것인지 일정과 함께 완료하는 일의 일정을 갖는 것입니다.

이제 전체 할 일을 이슈 관리 프로덕트 (예, 지라 등)에 등록하고, 로드맵으로 표현을 해 보면, 프로덕트 매니저가 앞으로 다른 팀원들과 함께 목표와 진척을 확인할 수 있는 시각화 된 뷰 View 가 생깁니다. 로드맵은 실시간으로 할 일의 우선순위와 할 일 간의 관계 표시, 일정 표시를 업데이트 하면서 모두가 볼 수 있는 곳에 두고 활용하시기 바랍니다.

스토리 Story - 인수기준 Acceptance Criteria

할 일을 어떻게 표현하고, 무엇이라 부를 것인가? 그것이 바로 스토리 입니다. 유저가 우리에게 이야기 해 준 내용, 우리가 그 이야기를 바탕으로 어떻게 일을 완료할 것인지 필요한 내용과 기준을 적는 카드 형태의 메모가 원형 입니다.

스토리에는 해당 할 일에 대한 유저의 입장을 이해할 수 있는 유저 스토리가 있습니다. 유저 스토리는 일반적으로 다음과 같은 문법으로 작성합니다.

As …

I want to …

So that …

이것을 한글로 작성하면, 유저 ‘누구’ 가 / 무엇을 하고 싶다 / 그럼으로써 얻게 되는 실질적인 영향, 효과 를 3 줄로 구분하여 적는 것입니다. 누구에는 기존에 세분화 한 유저 페르소나의 특정 대상을 적습니다. 이 할 일 완료를 통해 유저가 사용할 수 있는 기능 또는 추상적으로 유저가 무엇을 하고 싶다고 한 것인지를 적습니다. 유저가 이 기능을 사용하게 되면 어떤 것이 가능해 지는 것인지, 어떤 목표를 달성하게 되는 것인지를 마지막으로 적습니다.

유저 스토리 예시) 20대 후반 지방 중소도시 거주 남성 A 시에 있는 B 쇼핑몰 상품을 온라인으로 선택하고 주문하고 싶다. 유저는 B 쇼핑몰에 방문하지 않고도 상품을 구매할 수 있다. B 쇼핑몰은 가능 고객층 이었던 고객 집단에 매출을 발생시킬 수 있다.

스토리 본문에는 유저 스토리 작성 이후에 진행되는 구체화된 내용, 디자인 파일, 팀 또는 유저와의 대화 내용 등을 작성합니다. 해당 스토리 제목에 한정된 범위의 모든 내용을 한 곳에 모으는 것입니다.

스토리의 중요한 또 한가지 부분은 인수기준 입니다. 스토리의 개발을 완료 했을 때, 요청한 측이 어떤 기준으로 이것을 인수할 것인지를 체크 리스트 또는 테스트 시나리오 방식으로 작성합니다. 예를 들어 위의 예시에 있는 유저 스토리에 해당하는 인수기준을 예시로 작성해 보겠습니다.

인수기준 예시) C 메뉴에서 B 쇼핑몰 상품이 전시된다. 전시된 상품을 선택하고 주문할 수 있다.

스토리의 개발된 사항을 완료할 때, 프로덕트 매니저는 개발 전에 개발자들, QA 와 함께 작성한 인수기준에 해당하는 기능 행동이 실행 가능한 것을 확인하고 인수 확정을 하여 개발이 완료되었음을 명확히 할 수 있습니다. 인수기준이 왜 필요한지 이해하기 위해, 인수기준이 없다고 가정해 보겠습니다. 인수기준이 없으면, 개발자들은 스토리가 의도하는 목표 수준에 도달하지 않거나 그 이상으로 초과하는 개발을 할 수도 있고, 전혀 다른 방향으로 해결하여 개발을 완료하여, 처음에 팀이 함께 이해했던 스토리와는 다른 결과물로 개발이 완료될 수 있습니다. 우리는 목표를 가지고 있으며, 가설과 검증을 통해 프로덕트를 만들어 나가는 과정을 하고 있기 때문에, 함께 이해한 기준에 따른 프로덕트 개발이 완료되지 않으면 프로덕트 매니저는 프로덕트를 관리하면서 성장시킬 수가 없게 됩니다.

할 일을 작은 단위로 나누기 Story Splitting

스토리라고 하는 작은 단위 할 일을 어떻게 나누는 것 일까요? 스토리를 구성할 때 중요한 점은 해당 스토리의 목표 / 기능이 실제로 동작할 수 있도록 완료하는데에 필요한 모든 작업을 포함한다는 것입니다. 실제 업무 현장에서 스토리를 잘못 작성하는 많은 경우는 XX 기획 / XX 화면 개발 / XX API 개발 / XX 연동 테스트 같은 방식으로 일을 나누는 것입니다. 스토리를 구성하는 방식은 XX 에 해당하는 위 모든 할 일이 하나의 스토리 안에서 이루어 지도록 묶는 것입니다. XX 스토리를 개발하는 과정에서 이 단위의 할 일 내에 기획, 프론트엔드 개발, 백엔드 개발, 테스트 와 같은 모든 활동을 하는 것입니다. 이것을 스토리를 수직으로 자른다고 표현합니다.

수직으로 잘라야 하는 스토리를 어떻게 하면 최소한 작은 크기로 분할할 수 있을까요? 1) 스토리가 하나로 독립적으로 존재하고 개발할 수 있어야 합니다. 2) 스토리를 확정적으로 구체화된 내용으로 작성하지 않음으로써, 팀 내부 또는 외부 이해관계자들과 함께 해당 문제 해결을 위한 방안을 논의할 수 있는 여지가 있어야 합니다. 3) 스토리는 완료 시에 얻게 되는 혜택이나 영향력이 있는 실질적인 가치를 담고 있어야 합니다. 4) 스토리에 정의된 할 일을 이해하고, 할 일의 규모를 측정할 수 있어야 합니다. 5) 스토리를 개발하는 일이 팀이 가지고 있는 규모 범위에서 충분히 완료할 수 있는 작은 크기여야 합니다. 6) 스토리에 적힌 내용을 통해 테스트를 어떻게 할 수 있을지 정할 수 있는 충분한 내용을 담고 있어야 합니다.

여전히 이 부분은 이해하기 어려울 수 있습니다. 스토리를 적절하게 나누는 것은 실제 할 일을 가지고 실행해 보면서, 개발과 스토리 완료를 확정하는 과정까지 진행하는 경험을 반복하면서 익혀야 합니다. 팀과 함께 스토리를 이해하고, 구체화하고, 추정하는 패턴을 발견해 보세요.

다음 자료에 있는 스토리의 INVEST 기준을 참고해 보세요. 참고 자료: https://en.wikipedia.org/wiki/INVEST_(mnemonic)

업무 시각화 Work Visualization

할 일을 말로 설명하고, 논의하고, 이해하는 것은 어려운 일입니다. 애자일 팀은 일이라는 무형의 개념을 시각화 하는 것을 적극 활용합니다. 할 일을 시각화 하면, 우리가 전체 할 일을 어떤 단위로 나누고, 어떤 상태에 두고, 어떤 순서로 하고 있는지 전체적인 흐름을 할 때 쉽고 빠르게 할 수 있습니다. 문서나 표 같은 형태로 하기도 하지만 포스트 잇을 활용하여 나누고 표시하면, 변화하는 상황을 계속해서 업데이트 하는 것이 용이합니다. 최근에는 원격근무 등으로 가상환경에서 협업을 하는 상황이 늘면서 이런 포스트 잇으로 업무를 시각화 하는 활동을 온라인에서 할 수 있는 여러 업무 도구들이 있습니다. (미로 Miro, 피그잼 FigJam 등)

유저 스토리 매핑, 릴리스 플래닝, 디자인 스프린트, 유저 페르소나 등의 여러가지 협업 이벤트는 업무를 시각화가 더해져 큰 효과를 얻을 수 있는 활동입니다. 애자일 팀의 경우에는 정보 방열판, 칸반 보드 와 같은 이름으로 팀이 업무를 진행하는데 필요한 다양한 현황 (목표, 일정, 팀원 상태, 일의 진척 상황 등)을 업무 공간에 시각화 합니다. 이로써 팀원들이 지속적으로 쉽게 동일한 정보를 얻고, 목표에도 일치하는 방향으로 업무에 집중할 수 있습니다.

할 일 우선순위 조정 Work Prioritization

할 일을 단위로 나누었다면 우선순위를 파악하여 조정하는 것이 프로덕트 목표 달성과 가치 극대화에 결정적인 효과를 가져옵니다. 우선순위를 파악하는 것은 시장 상황, 이해 관계자의 의견, 유저의 요청사항, 개발 기술 환경, 가설과 목표 지표 등의 다양한 정보를 종합하여 내리는 판단입니다. 프로덕트 매니저 (프로덕트 오너)가 최종적으로 의사결정을 해야하는 중요한 일 입니다.

할 일의 우선순위를 판단하는데에 활용할 수 있는 다양한 방법을 확인해 보세요. 참고 자료: https://roadmunk.com/guides/product-prioritization-techniques-product-managers/

프로덕트 백로그에서 우선순위를 조정한다는 것의 행동적인 의미는 할 일 단위로 생성한 프로덕트 백로그 아이템의 정렬 순서를 변경하는 것입니다. 예를 들어 이슈에 숫자 아이디가 부여되어 있다고 가정하고 프로덕트 백로그에 할 일이 수직으로 위에서 부터 아래로, ( 1 → 2 → 3 → … ) 과 같이 정렬되어 있습니다. 1주일 뒤에 유저와의 인터뷰를 통해서 3 번 할 일이 완료되는 것이 시장에 아주 중요한 영향력을 미친다는 것을 발견하였습니다. 그러면 프로덕트 백로그의 할 일을 ( 3 → 1 → 2 → … ) 과 같은 순서로 정렬을 변경하는 것입니다.

반복 / 점진적인 개발 수행 Iterative / Incremental Development

애자일을 개발 방법론 측면으로 보면 ‘반복적이고 점진적으로 개발을 한다’ 라고 합니다. 프로덕트 매니저는 할 일을 구상할 때, 반복 / 점진적인 개발을 이해하고 프로덕트 성장 전략을 구상할 수 있습니다.

반복적인 개발은 A 라는 기능을 개발하는데, 최대한 이른 시기에 개발을 완료하여 내부에서 유저 또는 이해관계자의 피드백을 받는 것이 필요합니다. 이 때, A 라는 기능이 동작할 수 있는 가장 간단한 방식과 수준으로 코드 작성 또는 품질을 낮추어 개발을 완료합니다. 애자일 팀은 높은 수준과 기술과 품질을 지향하는데, A 기능을 이 수준에 맞추어 개발을 하기까지 시간이 많이 소요될 것으로 예상되면, 이런 방식으로 이른 시기에 이 기능이 실질적으로 효과가 있는지를 판단할 수 있습니다. 피드백 결과 A 기능이 필요하지 않으면, A 기능과 관련된 개발 사항을 제거할 수도 있고, A 기능을 사용하기로 결정하면, 추가적인 할 일을 생성하여 A 기능을 구현한 수준과 품질을 높여서 A 와 관련된 모든 개발 사항을 완료합니다. 이 때 외부적인 기능은 변경하지 않고 내부적인 개발 내용만 변경하는 것입니다.

점진적인 개발은 B 라는 경험을 유저에게 프로덕트를 통해 제공하기 위해 필요한 할 일이 여러가지가 있고, 이 기능들 간에 경험 수준이 다른 경우가 있습니다. 예를 들어 결제 라는 경험을 유저에게 전달하는 경우를 살펴보겠습니다. 처음에는 신용카드 결제만 가능하게 완료하여 한 가지 기능을 통해 경험을 전달합니다. 다음에는 소셜 플랫폼 연동 간편 결제 기능을 개발 완료하여 같은 결제를 다른 기능으로 할 수 있게 제공할 수 있습니다. 이제부터 추가적으로 결제와 관련하여, 자체 페이먼트 개발, 자사 포인트 결제 등과 같은 여러가지 경험 루트를 제공할 수 있습니다. 이런 방식으로 어떤 경험에 해당하는 기능 수준을 점차 높이고 확장하는 방식을 점진적인 개발이라고 합니다.

과제: 위에 소개된 핵심 용어들을 검색해 보고 어떤 모습 / 형태인지 이미지를 확인해 보세요.

← 이전 주제