3) 나는 애자일 하게 일하고 있을까?
"내"가 아닌 "유저"가 생각하는 가치를 "우리"가 만들어 과는 과정
글목록
3) 나는 애자일 하게 일하고 있을까? (현재 글)
지속적인 속도로 업로드를 못했네요 죄송합니다! 앞으론 지속 가능한 글쓰기를 실천할 수 있도록 할게요!
이전 글에서는
1. 어떤 가치를 기반으로 저는 일하고 있고,
2. 이런 방식으로 일하면서도 제가 겪고 있는 수많은 난제들
에 대해 설명드리려 했으나, 이번 글에서는 오늘도 분량 조절의 실패로 제가 일하고 있는 팀은 어떤 가치를 기반으로 일하는지 설명드리도록 하겠습니다.
우리는 어떤 가치를 기반으로 일하고 있는가
1. "나" 보단 "우리"가 맞고, "우리"보단 "유저"가 맞다
프로덕트의 가치를 확인할 때 나(또는 개인)의 기준보다는 프로덕트를 만들고 있는 모두의 의견이 더 중요하고, 그리고 이보다 더 중요한 건 이 프로덕트를 사용하는 유저가 프로덕트에 가지는 의미가 더 중요합니다.
이를 실천하기 위해 User Persona(유저 페르소나)를 구축하고, 해당 User Persona를 더 정확하게 구성하기 위해 많은 유저들과의 인터뷰를 진행하고,
1. 유저가 가지고 있는 기본적인 사실들을 확인 (Facts)
2. 유저가 어떻게 행동하고 있는지에 대한 행태를 조사하고 (Behaviors)
3. 그리고 그 유저가 어떤 니즈와 목표를 가지고 있는지(Needs & Goals)
를 확인하고, "유저들이 니즈와 목표를 수행할 수 있도록 프로덕트는 어떤 것들이 가장 필요할 것인가"에 집중하고 있습니다.
유저들과의 인터뷰를 통해, 공통된 니즈와 목표, 행태, 그리고 팩트를 기반으로 Persona를 만듭니다 이렇게 작업을 하는 이유는 프로덕트를 만들며 나올 수 있는 다양한 "기능" 또는 "전략" 등 다양한 이해관계가 같이 일하는 많은 동료들(우리 식구들!) 간 "어떤 것을, 왜, 그리고 언제"에 대한 것을 결정하며 많은 갈등 상황을 초래할 수 있고, 이해되지 않는 부분들에 대해서도 명확하게 설명할 수 없는 상황들이 생길 수 있으나, "누군가의 의견"또는 "아직은 검증되지 않은 이야기"들을 기반으로 하는 게 아닌, "진짜 유저들이 원하는 무언가"를 전달할 수 있는 가치에 대해 모두가 하나의 시선으로 바라볼 수 있게 함으로써 모두가 프로덕트에 집중할 수 있기 때문입니다.
2. 무엇이 유저 or 비즈니스 상 필요한가 / 빠르게 빌드하고 테스트할 수 있는가를 기반으로 순서를 만들고 개발한다.
아무리 Persona를 기반으로 작업한다고 하더라도, 많은 Task들이 눈앞에 닥칠 경우, 개발팀은 당연히 많은 작업량 때문에 시작도 하기 전 겁을 먹을 수 있고, 무엇을 어떻게 시작해야 할 지에 당황하고 걱정하기 마련입니다. 그리고 이런 상황에서 리소스(Resource)는 지극히 한정되어 있기 때문에 항상 우선순위를 두고 작업을 진행하는 것은 상당히 중요합니다. 그리고 제가 일하는 팀은 이를 해결하기 위해 몇 가지 기준을 가지고,
1. 무엇이 유저에게 또는 비즈니스 상에서 가장 큰 가치를 주는가
2. 무엇이 가장 빠르게 개발할 수 있는가 또는 테스트할 수 있는가
를 기준으로 우선순위를 지속적으로 산정하고 일하고 있습니다.
우선순위는 지속적으로 변경되고 발전합니다. 그리고 우선순위에 대한 기준은 언제나 유저 입니다!이런 우선순위의 설정과 지속적인 확인은 우리가 개발을 해야 하는 이유에 대해 명확한 이유를 만들고, 수행과정에서 일을 하고 있는 모두가 같은 같은 곳을 바라볼 수 있어 굉장히 중요합니다. 그리고 지속적인 우선순위에 대한 산정을 통해 더 빠르게 개발하고, 검증하고, 성장하고, 실패를 통해 배울 수 있습니다. 우선순위에 대한 산정에 있어 많은 의견도 나오고 조율에 시간이 필요하지만, 유저를 기반으로, 그리고 우리가 가진 산업에 대한 지식을 기반으로 일하기 때문에 생각보다 빠르게 의사결정을 할 수 있기 때문에 효율적으로 일하고 있습니다.
3. 프로덕트 팀에서도 "유저에게 가치가 있다"라는 부분이 이해될 때 작업한다.
아무리 좋은 "기능", "방향"이래도
1. 개발이 비즈니스 사이드 또는 디자인 사이드에서 의도한 대로 개발되지 않고
2. 유저 또는 비즈니가 원하는 목표와 니즈를 만족시키지 못하는 기능이 만들어진다면
결국, "사용할 수 없는 프로덕트"를 양산할 수밖에 없습니다. 그리고 이런 리스크를 최소화하기 위해,
- 개발자 / PM과 함께 유저 시나리오를 기반으로 한 디자인 스튜디오 진행
- 개발 이터레이션 이전 Pre-IPM/ IPM 진행
을 통해 개발/ PM/ 디자인 간의 투명성을 높이고, 모두가 "유저에게 필요한 건 무엇이고, 어떤 이유 때문에 지금 해당 개발을 진행할 예정이다."라는 것을 알고 일할 수 있도록 최선을 다하고 있습니다.
이해가 되지 않는 프로덕트에 대해 PM이 방향성을 설명할 수 없고, 근거에 대해 정확하게 포인트 아웃(Pointing out)할 수 없으면 개발을 요청하기보단, 검증이 부족한 부분을 더 채우고 진행하려고 노력합니다.
(* 디자인 스튜디오: 목표와 유저 시나리오를 기반으로 개발/ PM/ 디자인 사이드에서 생각하는 과정 예외에 대한 부분들을 자유롭게 그려보고 아이디어를 공유하는 워크샵)
(* Pre-IPM, IPM: Iteration Planning Meeting의 줄임말로, 개발 전 1. 무엇을 개발할지, 2. 유저에게 가치가 있는지, 3. 작업량의 분기는 적당한지, 3. 기술적 결함이나 선행되어야 할 부분들이 있는지 확인하는 미팅)
"어떤 기능이 필요하다"라는 단순한 판단으로 기능 개발을 요구, 혹은 강요하는 건 기능 개발에 대한 이해를 해치고, 실제 작업하는 작업자들의 판단 기준을 흐리게 하고, 능률을 저하시키는 등 많은 최악의 경우들을 지속적으로 만듭니다. 함께 하는 모든 분들이
- 해당 기능이 왜 필요한지
- 유저는 어떤 가치를 얻을 수 있는지
- 해당 기능을 위해서 내가 할 일은 무엇인지
에 대해 정확하게 알고 있다면, 서로가 놓치는 부분들에 대해서 공유할 수 있고 이해할 수 있는 부분들이 생기고 이렇게 지속적으로 신뢰가 생기기면 우리는 이제 진짜로 "100미터 달리기"로 프로덕트를 만드는 것이 아닌 "진짜 마라톤"을 모두가 같이 달릴 수 있다고 생각합니다.
오늘도 분량 조절에 실패했습니다... 글쓰기는 굉장히 어려운 것이군요(또르르...)
다음장에서는
- 이렇게 좋은 말만 가득함에도 불구하고, 겪고 있는 문제점과 이를 해결하기 위해 노력하는 부분
을 이야기하도록 하겠습니다. 이후에도 애자일한 개발과 검증 그리고 피봇을 하기 위해 하고 있는 다양한 방법들과 애자일 하게 나갈 수 있는 방법에 대해(XP 그리고 Lean Roadmap, Interview 등등등) 소개하는 글도 차례차례 올릴 예정이니 기대해 주세요! 감사합니다!
