지난번 글에서는 서문을 읽으며 나의 업무 프로세스를 돌아봤다. 막연하게 책을 읽기 전까지 우리 조직은 린 UX와 상관없는 업무 프로세스로 일한다고 생각했었는데 알고보니 아니었다. 린 UX에서 말하는 방식들 중 일부는 이미 회사에서 적용되어 업무에 활용되고 있었다.
그래서 이번에는 린 UX 원칙들을 하나씩 소개하면서 린 UX 원칙을 체크리스트로 만들어보려고 한다. 체크리스트로 만든 린 UX 원칙을 현재 상황과 비교해보면서 어떤 원칙을 준수하고 있는지, 어떤 원칙은 준수하지 않는지 한 번 파악해보려고 한다.
본 게시글은 《린 UX》 3판의 제 1부 소개 및 원칙를 기반으로 작성되었습니다.
우선 린 UX의 원칙은 무엇일까?
린 UX의 중심에는 디자인 프로세스, 팀 문화, 조직 구성을 좌우하는 일련의 핵심 원칙이 있다. 이러한 원칙을 프레임워크로 대하라. 여러분의 팀이 올바른 방향으로 나아가려면 원칙에서 출발해야 한다. 린 UX가 잘 작동하기 위해서는 책에서 설명하는 프로세스를 각자의 상황에 맞게 변형해야 한다. 각자의 상황에 맞게 프로세스를 조정하는 법을 배워보자. 근본적으로 원칙을 적용할 수 있다면 팀 문화도 바꿀 수 있다. - 2장 원칙 9p
책에 나와있는 린 UX의 원칙을 위와 같이 체크리스트로 만들었다. 각각의 원칙만 나열하기에는 책에서 말하고자 하는 의미를 전달할 수 없을거라고 생각하여 원칙 아래에는 어떤 의미인지 설명을 적어두었다. 원칙은 본문을 그대로 인용하였지만 의미는 체크리스트로 만들기 위해 약간 수정을 했다. 원문이 궁금하신 분들은 직접 책을 읽어보시는 편을 추천합니다. 그렇다면 이제부터 체크리스트로 만든 원칙을 하나씩 우리 팀의 상황과 비교하여 점검해보겠다.
먼저 점검해 본 것은 팀 구성에 관한 원칙인데, 총 4개의 원칙 중에서 2개의 원칙만 우리 팀에 해당된다. 그 이유를 하나씩 꼽아보고자 한다.
첫번째, "다양한 분야의 전문가로 구성하기"는 해당하지 않는다.
책에서는 다양한 분야의 전문가로 팀이 구성되어야 한다고 하는데 소규모 조직인 우리는 정말 제품 개발의 최소한의 인력으로 운영되고 있다. 우리 팀을 살펴보자면 개발자 그룹, 서버 구축 담당자, 디자이너 이렇게만 구성되어 있다. 1인 디자이너로 근무하는 나는 프로덕트 디자인은 물론이고 마케팅 업무와 가끔은 QA도 진행하고, 제품의 매뉴얼도 작성한다. 개발자 그룹은 각각 맡은 분야만 개발하는데 반해 나는 이렇게 많은 분야의 업무를 내가 전담하는 것이 맞나? 하는 의문이 들 때가 종종 있다. 마케터나 QA라는 직무가 따로 있는 만큼 해당 분야의 전문가 인력이 더 투입되어야 된다고 생각하지만 실제로는 여러 조건이 녹록치가 않아서 그럴 수 없다는 사실이 너무 아쉽다.
두번째, "작은 규모로 구성하기, 같은 목표에 전념하기, 같은 공간에서 일하기"는 해당한다.
사업부를 제외하고 제품 개발에 힘쓰는 팀원들은 총 여덟 명이고, 모두 같은 사무실에서 근무를 한다. 여덟 명 중에서 일곱 명은 개발 및 서버 구축 인력이고, 디자이너는 한 명이다. 회사 규모가 작기 때문에 모든 사람이 같은 사무실에 있기 때문에 이 조건에는 부합한다. 그리고 모두가 클릭업이라는 툴을 통해 태스크를 확인하고 우선순위에 따라서 업무를 진행한다. 거기다가 모두의 공동 목표는 끊임없이 연구하고 제품 개발에 매진한다는 목표를 가지고 있다.
세번째, "팀 내에서 해결하고, 자율성을 갖기"는 해당한다.
대표님이 항상 강조하시길 우리는 제품 개발 조직이라고 말한다. 제일 최우선으로 두는 것이 더 나은 제품, 최선의 제품, 뛰어난 제품이라고 믿으며 되도록이면 모든 문제 해결과 기능 구현을 조직 내에서 수행하고 자체적으로 개발한다. 책에서 내부에서 소프트웨어를 직접 만들고 출시할 수 있으면 효율적이라고 하는데 우리가 그렇다. 직접 제품을 만들고 배포하여 출시 할 수 있기 때문에 제품의 새롭게 업데이트 된 내용을 고객사를 대상으로 격주로 온라인 웨비나를 진행하고 있다. 그렇게 고객과 직접 소통할 수 있는 창구를 만들었으며 들어오는 피드백과 VoC는 모두 전사에게 내용이 공유된다. 사실 여기에서 아쉬운 점이 하나도 없지는 않다. 고객사와 소통할 수 있는 창구가 있지만 피드백과 VoC는 정리되지 않고 산발되어 있기 때문이다. 이 부분을 읽으면서 별도의 공간에 VoC를 깔끔하게 정리해두어야 겠다는 생각을 했다.
네번째, "문제에 집중하기"는 해당하지 않는다.
책에서는 문제에 집중하기라는 의미가 비즈니스나 사용자의 문제를 해결하려고 모인 조직이며, 결과를 중심으로 조직된 팀이라고 의미를 설명했다. 하지만 아쉽게도 우리는 결과를 중심으로 조직된 팀이 아니라고 생각한다. 나는 가끔 우리가 하는 제품 개발이 단순히 기능만 개발하고 있는 것이 아닌가? 하는 생각이 종종 들기 때문이다. 문제를 해결할 역량이 있는 팀에서는 단순히 기능을 구현하는 대신에 문제가 해결될 때까지 이터레이션*을 하게 된다는데 우리는 아니다. 기능을 구현하면 태스크는 완료되고 그 이후에는 다시 보지 않는다. 하지만 시일이 지난 후에 분명히 구현 완료된 기능이고 태스크가 끝났다고 생각했는데 버그가 생기거나 문제가 생긴 적이 여러번 반복되었다.
이터레이션이란? 작은 시도와 피드백의 반복이다. 제품을 만들기 전에 가설을 세우고, 해당 가설을 검증할 수 있는 만큼만 제품을 만들어 시장에서 테스트한다. 결과를 분석하고 문제를 보완한 다음 제품에 살을 붙여 다시 시장에 던진다. 이런 매 단계가 이터레이션이다.
팀 구성에 관한 원칙을 살펴보았는데 사실 회사에 소속된 디자이너인 내가 팀 구성을 어떻게 바꿀 수는 없다. 이 원칙은 나보다는 좀 더 상부 조직에 있는 사람이 지킬 수 있는 원칙이라는 생각이 들었다. 다음은 조직 문화에 관한 원칙을 체크리스트로 점검해보았다.
조직 문화에 관한 원칙은 총 6개가 있는데 점검해보니 여기에서 2개의 원칙만 해당되었다. 아무래도 린 UX이 정착된 조직 문화가 아니다 보니까 어쩔 수 없다고 생각한다.
첫번째, "불확실에서 확신으로 가기"는 해당하지 않는다.
모든 프로젝트는 일련의 가설로부터 시작한다고 책에서는 말한다. 하지만 가설을 세우고 검증하는 방식으로 진행되는 업무 프로세스가 아니기 때문에 이 부분은 확실히 아니라고 생각했다. 잘못된 가설에서 출발한 작업에 많은 시간과 노력을 투자하는 위험을 피하려면 가설을 검증하는데서 시작해야 한다고 하는데 우리는 가설을 검증하기도 전에 일단 기획을 해보고 일단 디자인을해서 UI를 그려본다. 일단 해보는 이 방식이 어떤 때는 빠르게 시장에 먹히지만 어떤 때는 그동안 들인 리소스가 날라가 버리는 허무한 경험을 하기도 했다. 제대로 된 가설을 세워보고 가설을 검증하며 진행하는 업무 프로세스를 꼭 도입하고 싶다는 생각이 들었다.
두번째, "생산물보다 결과를 중시하기"는 해당하지 않는다.
이 부분을 읽으며 그동안 우리가 중요하게 여긴 것은 결과(outcome)가 아니라 생산물(output)이라는 것을 깨달았다. 그저 고객사가 요청하는 기능이면 개발해서 넣어주고 문제가 해결되었다고 여겼으며 기능 구현이 전부라고 생각했다. 하지만 해당 기능이 얼마나 효과적이었으며 기능이 충분한 성과를 내었는지 검토해본적이 없었다. 읽으면서 그동안 일했던 방식들을 스스로 되돌아보게 만드는 문장이었다.
세번째, "낭비를 없애기"는 해당하지 않는다.
린 UX에서 최종 목표는 결과 개선이기때문에 최종 목표에 기여하지 않는 것은 낭비라고 생각하여 업무 프로세스에서 제거한다고 한다. 이 원칙이 해당되지 않는 다고 이야기 한 것은 바로 나 때문이다. 다른 팀원들은 주요 업무인 개발 외 다른 업무는 하지 않는다. 다만 나는 지금 프로덕트 디자인 외에 새롭게 맡은 업무들 때문에 불만을 가지고 있다. 현재 어떤 업무를 새로 맡았는지 자세히는 말할 수 없지만 나 스스로도 내가 추가로 맡은 업무가 인적 자원 및 시간 자원을 낭비하는 것이라고 생각한다. 며칠 전에 이 업무가 고민이라서 함께 점심식사를 하는 동료에게 고민을 이야기 했더니 그도 아이러니하게 생각을 했다. 지금 내게 산적된 태스크가 나를 기다리고 있는데 이 업무를 하는 것이 정말 맞는건지 회의감이 든다.
네번째, "공유된 이해"는 해당하지 않는다.
이전 글에서 우리 조직은 클릭업을 통해 모든 태스크를 확인 할 수 있다고 말했는데 왜 공유된 이해는 해당하지 않는다고 말했을까? 그 이유는 태스크를 확인 할 수 있는 거지만 현재 진행 상황에 대한 공유가 없기 때문이다. 분명 태스크는 진행중이라고 나와있는데 한 꺼번에 여러가지 일을 진행중이라서 어떤 때는 나중에 시작한 일이 더 간단한 문제라서 금방 끝나고 먼저 시작한 일임에도 불구하고 우선순위에 밀려서 늦게 끝나기도 한다. 메신저 봇을 통해 데일리 스크럼을 하지만 가끔 사무실에서 나오는 이야기들을 들으면 서로가 어떤 일을 진행중인지 파악하지 못해서 생기는 이슈가 더러 있었다.
다섯번째, "스타나 고수, 능력자는 없다"는 해당한다.
스타는 서로 의견을 나누지 않고 아이디어도 공유하지 않으며 혼자 관심 받기를 원하는 자를 일컫는 말이라고 책에서 말한다. 우리는 그런 사람은 없다. 물론 CTO가 있긴 하지만 그는 다른 사람들과 자주 의견을 나누며 아이디어도 모두가 볼 수 있도록 모아서 공유하기 때문에 책에서 말하는 스타랑은 거리가 먼 사람이다. 협업을 위해 노력하는 CTO가 있기 때문에 우리 조직이 여기까지 올 수 있었다고 생각한다.
여섯번째, "실패할 권리 주기"는 해당한다.
체크리스트에는 의미를 간단하게 적어두었지만 책에는 좀 더 자세하게 쓰여있다. 실패를 용인한다는 의미는 기술적인 환경으로 아이디어를 시도해 볼 수도 있으며, 아이디어가 실패로 끝나고 불이익을 받지 않는 환경을 일컫는 말이라고 한다. 아이디어는 항상 누구나 자유롭게 내고 일단 만들어 본다. 가끔 사업부의 무리한 요구로 시작된 아이디어가 실제로 개발 구현까지 이루어지지 않는 경우도 있지만 이에 대해서 누구하나 뭐라고 하는 사람이 없다. 그래서 제품이 출시된 이후 나는 아이디어를 메모하는 곳에 정말 많은 아이디어를 작성했다. 아마 순위를 매기자면 내가 기재한 아이디어가 가장 많다. 이러한 자유로운 환경이 있었기 때문에 수 많은 아이디어가 나올 수 있었다고 생각한다.
이렇게 조직 문화에 관한 원칙을 살펴보았는데 읽으면서 많은 생각과 다짐을 하게 해줬다. 내가 어떤 행동을 해야 조직 문화의 관한 린 UX 원칙을 지킬 수 있을지에 대해서 생각해볼 수 있는 계기가 되었다.다음에는 프로세스를 이끌어 줄 원칙을 점검해보도록 하겠다.
마지막은 프로세스를 이끌어 줄 원칙을 체크해보았는데 총 9개의 원칙 중에서 3개의 원칙이 해당되는 것을 알 수 있었다. 앞서 살펴본 다른 원칙에 비해서 가장 많이 해당된다.
첫번째, "같은 일을 더 빨리 하지 않는다"는 해당한다.
이 문장이 의미하는 바는 팀이 애자일 방식을 채택할 때 단순히 더 빨리 수행하는 경우가 있는데 예를 들어 8주가 걸리는 리서치를 2주만에 끝날 수 없다는 것을 말하고 있다. 애자일의 목표는 일을 빨리 하는 것이 아니라 2주 주기 스프린트* 안에 일을 끝내는 것이 아니라고 한다. 우리 팀도 스프린트 방식을 도입해서 업무를 진행하고 있는데 2주 안에 모든 일을 끝내려고 하지 않는다. 때로는 2주 주기 스프린트 안에 업무가 끝나지 않고 계속 스프린트가 진행되어도 남아있는 업무가 있다. 그런 경우는 보통 각 담당자들이 맡고 있는 업무가 있어서 일정때문에 어쩔 수 없는 경우가 대다수다. 물론 스프린트 안에 일사천리로 업무가 끝나면 좋겠지만, 그럴 수 없다는 것을 모두가 알고 있으며 억지로 스프린트에 맞춰서 업무를 끝내려고 하지는 않는다.
스프린트란? 작은 기능 하나에 대한 계획, 개발, 테스트, 기능 완료 주기를 일컫는다. 보통 1주에서 4주 정도 기간 동안 스프린트를 진행한다. 스프린트 기간 동안 팀 구성원들은 단거리 전력질주를 하듯 집중하여 자신의 업무를 수행한다.
두번째, "단계에 주의한다"는 해당하지 않는다.
매 스프린트 안에서 디자인도 개발도 테스트도 동시다발적으로 진행되고 있지만 리서치가 진행되지 않고 있기 때문에 이 원칙에 해당하지 않는다고 생각한다. 리서치를 안 하는데 특별한 이유는 없다. 나는 리서치가 필요하다고 생각하지만 시간과 리소스가 충분치 않기 때문에 할 수 없다. 다른 팀원들은 담당하고 있는 개발 업무가 있기 때문에 할 수 없다. 필요성은 알지만 할 수 없기 때문에 이 원칙은 해당하지 않는다.
세번째, "이터레이션은 애자일의 핵심이다"는 해당하지 않는다.
왜냐면 우리는 수차례 디자인하고 테스트하지 않는다. 책에서는 하나의 기능이 제대로 될 때까지 작업함으로써 사용자를 만족시킬 수 있는 기능을 만들고 기업이 해결하고자 하는 문제를 풀어 낼 수 있다고 말한다. 하지만 시안을 여러개 만들고 제작하는 일은 언제나 시간을 많이 소요하기 때문에 여유가 없는 소규모 조직인 우리에게는 어려운 일이다. 물론 시안을 더 많이 만들고 다양한 UT를 내부에서 진행한다면 고객사로부터 듣는 VoC가 줄어들고 긍정적인 피드백이 늘어날 수도 있다. 하지만 여건이 그렇지 못하다.
네번째, "리스크를 줄이기 위해 배치 사이즈를 줄이다."는 해당하지 않는다.
많은 리소스를 투여해서 제작한 디자인이 있었는데 잘못된 아이디어 였으며 가설 검증을 충분히 하지 않았기 때문에 폐기된 적이 있다. 디자인을 만들기 전에 가설 검증을 충분히 했었다면 리소스를 낭비하지 않을 수 있었을 텐데 하는 아쉬움이 남는 작업이었다. 만약 작업하던 당시에 배치* 사이즈를 작게 만들어 디자인을 하고 결정 사항을 검증할 수 있었으면 리스크를 줄일 수 있었을 것이 분명하기 때문에 더욱 아쉽다.
배치란? 데이터를 실시간으로 처리하는 게 아니라, 일괄적으로 모아서 한 번에 처리하는 작업을 의미한다. 배치 사이즈가 클 수록 한 번에 처리해야 하는 작업이 무거워져 시스템에 부담이 될 수 있다.
다섯번째, "지속적 발견을 포용한다"는 해당된다.
우리 팀은 사업부에서 가져오는 고객의 의견을 적극적으로 반영하여 기능으로 구현하기 위해 힘쓴다. 리서치는 진행하지 못하지만 사업부에서 진행하는 수 많은 외부 미팅과 격주로 진행하는 온라인 웨비나에서 고객과 정기적으로 대화하기 때문이다. 이러한 고객의 니즈가 전사에 메일로 내용이 공유되면 팀원들이 함께 사용자의 입장에서 생각해보며 기능을 구현하기 때문에 이 원칙은 해당된다고 말할 수 있다.
여섯번째, "사무실 밖으로 나가라"는 해당되지 않는다.
왜냐면 우리 팀은 나가지 않기 때문이다. 사업부만 외부 미팅때문에 나간다. 사업부의 입장에서 생각한다면 이 원칙은 해당되는 것이지만 제품 개발팀의 입장에서는 주로 내부에서 회의를 진행하고 제품을 개발하기 때문에 해당되지 않는다고 생각한다.
일곱번째, "업무를 외부로 드러낸다"는 해당되지 않는다.
책에서 말하는 업무를 외부로 드러낸다는 의미는 작업물을 머릿속과 컴퓨터 속에서 꺼내서 공개적으로 보여주는 걸 말한다. 우리는 일단 화이트보드도, 폼보드도, 아티팩트 벽도, 인쇄물도, 포스트잇도 사용하지 않기 때문에 업무를 외부로 드러내지 않는다. 다만 자사에서 사용하는 협업툴에 태스크를 등록하고 관련 문서들을 링크걸고 확인할 뿐이다. 아마 이 업무 방식은 수년째 고착되어 있으며 회의실이 따로 없는 우리는 모여서 회의하는 것이 어렵기 때문에 해당 원칙을 지키긴 힘들다고 생각한다.
여덟번째,"분석하는 것보다 만드는 게 중요하다"는 해당된다.
왜냐면 일단 만드는 것이 내가 하는 일이기 때문이다. 책에서는 사람들이 반응할 수 있는 무언가를 만들어야 한다고 한다. 정지된 디자인 시안은 보는 사람들로 하여금 반응을 이끌어내기 힘들다는 것을 안다. 나는 그래서 제품 디자인을 시안만 만드는 것이 아니라 화면 녹화를 통해 무엇을 누르면 어떻게 변하는지 어떻게 연결되는지 보여준다. 화면 녹화는 동영상 포맷으로 제작하지 않고 되도록 gif 파일로 만드는 편이다. 이 편이 협업툴 문서에 업로드 했을 때에도 바로 보이고, 메일에서도 바로 보이고, PPT에서도 슬라이드 쇼를 하면 바로 보여지기 때문에 편하다. 재생을 하려면 플레이어가 필요한 동영상 파일과 달리 gif는 이런 점에서 강점을 가지고 있다.
아홉번째, "산출물에 대한 미련을 버려라"는 해당하지 않는다.
책에서 말하길 팀원끼리 소통하기 위해 사용하는 아티팩트는 중요하지 않고 보다 어떤 결과를 얻을 수 있는지에 대한 대화를 많이 하는 것이 더 중요하다고 한다. 하지만 결과에 대해서 커뮤니케이션이 저조한 우리 조직은 아직 아티팩트를 더 중시한다고 생각하기 때문에 이 원칙은 해당하지 않는다고 생각한다. 어떻게 해야 팀원들이 결과에 대해서 모두 적극적으로 대화를 할 수 있도록 유도할 수 있을까?
린 UX 원칙을 체크리스트로 만들어보고 하나씩 점검해보니 아직은 많이 부족하다는 점을 깨달았다. 하지만 원영적사고의 관점에서 생각해보면 현재는 부족한 점이 많으니까 앞으로 더 좋아질 일만 남았다고 긍정적으로 바라보려고 한다. 모든 린 UX원칙을 조직에 적용할 수는 없을 것이다. 하지만 체크리스트로 만들어 점검하면서 어떤 건 우리에게 적용할 수 있을 것 같다고 생각되는 부분들이 있었다. 그 원칙을 팀에 사용하여 어떤 목표를 잡을지 노력해나가야 겠다.
참고 서적 : 《린 UX》 3판 - 린 UX 캔버스를 활용한 프로덕트 개발 실무, (주)도서출판인사이트
*사족 : 이 글을 읽으시고 린 UX 원칙 체크리스트가 필요하신 분들은 댓글을 달아주세요. 피그마 파일로 제작된 체크리스트를 공유드립니다.
'읽은 도서 > 린 UX 3판' 카테고리의 다른 글
| 《린 UX》 3판을 읽으며 업무 프로세스 돌아보기 (0) | 2024.07.07 |
|---|
