1) 우리는 왜 애자일 하지 못할까
빠르게 가치 있는 프로덕트를 만들기 위해 우리가 가져야 할 가치
글목록
1) 우리는 왜 애자일 하지 못할까 (현재 글)
소프트웨어를 만드는 회사, 그리고 스타트업들은 산업의 특성상,
“빠르게 프로덕트를 만들고, 시장에서 프로덕트를 시험하고 지속적으로 발전, 또는 피봇 한다.”
라는 관점에서 린 스타트업, 익스트림 프로그래밍, 애자일 등의 방법론과 업무 프로세스에 대해 많은 사람들이 관심을 가지고, 이하 프로덕트 개발 방법론들을 도입하고 적용하기 위해 노력하고 있습니다. 그래서 많은 방법론 책, 애자일에 대해 신성시하는 글, 또는 애자일에 대한 부정적인 글들도 많이 나오고 있는데요,
이런 많은 방법론들이 나오고 좋은 프로세스가 있음에도 불구하고 우리가
우리가 진짜 애자일(Agile)하게, 또는 린(lean)하게 일하고 있을까?
라는 관점에서 봤을 때, 우리는 어떻게 일을 했었고, 우리가 일을 하는 방식이 정말 그런 방법론들이 이야기하는 방법으로 일을 하고 있는 건가에 대한 부분은 확인이 필요합니다.
제가 지금까지 다니며 많이 배운 회사들 그리고, 개발자, 디자이너 그리고 피엠분들과 이야기했을 때, “제가 다니고 있는 회사는 이런 부분에서 문제가 있었어요.”라는 이야기를 들을 때마다 공통적으로 느낀 점들은
프로덕트를 사용할 “유저” 보다 생각하는 “기능”에 집중하고
“무엇이 가장 중요한지”에 보다 “뭐든지 빨리” 만드려 하고
우리가 들이는 시간과 노력을 “왜” 이 기능에 들여야 하는지에 대한 공감이 없고
"기능"을 정확한 기간 안에 맞추기 위해 사람들이 시달리고, 팀 서로 간의 배려가 없어지고
일을 하면서 소통을 위한 회고는 줄고, 업무의 피로도는 쌓이는
등의 비슷한 상황들을 경험하시는 것을 확인했고, 이러한 불안정한 상황이 굉장히 애자일 하게(!) 돌아가는 상황들을 확인할 수 있었습니다.
그리고 이 부분을 개선할 수 있는 가장 기본적인 시작은 "프로덕트를 만드는 과정에서 우리는 어디에서부터 고민을 시작해야 할까"라는 생각을 했고, 이를 통해
빠르게 가치를 확인하는 프로덕트를 위해 무엇을 가장 먼저 고민해야 하는가
라는 주제로 이야기를 좀 해보려 합니다.
1. 처음 프로덕트를 만드는 건 우리지만, 결국 프로덕트를 사용하는 건 유저다.
애자일 프로세스에서 가장 기본적인 목표는 “Agility” 즉 빠르게 가치를 만들어 나가는 과정입니다. 그리고 빠르게 가치를 만들어 나간다는 것은 ”빠르게 프로덕트를 만든다.” 보단 “유저가 가치를 느낄 수 있는지 빠르게 확인하고 가치를 늘려나간다.”라는 부분이 더 중요하다고 생각해요.
그리고 빠르게 유저에게 가치를 줄 수 있는지는 실제 유저들과의 다양한 interation을 바탕으로, 빠르게 배포하고 빠르게 수정하는 과정이 애자일 프로세스의 가치입니다. 그래서 “어떤 기능을 어떻게 만들겠다.”라는 생각에 대해
어떤 유저가 사용할 것인지
유저는 어떤 가치를 얻기 위해 사용할지
가치를 얻기 위해 가장 먼저 해야 할 것은 무엇인지
에 대한 고민이 우선되고, 가장 우선돼야 하는 일들부터 시작하는 것이 우선인데, 우리가 프로덕트를 만드는 과정에서는 “애자일, 스프린트”라는 이름에 갇혀 개발의 과정이 너무나도 가려져 온 것 같습니다.
"어떤 기능을 만들어야 한다."라는 가치에 대한 제안(Value Proposition)이 나왔을 때, 가장 우선시 돼야 하는 것은 "이게 유저에게 얼마나 큰 가치가 있고, 이게 비즈니스 적으로 가장 중요한 일인가."라는 검증이 우선돼야 합니다.
정말 유저에게 좋은 프로덕트더라도 아무도 쓰지 않으면 의미가 없고, 가치를 통해 회사가 이윤을 얻을 수 없다면 좋은 기능이라고 판단할 수 없죠. 그렇다고 100% 검증된 기능을 만들 수 있다는 이야기는 더더욱 아닙니다.
그래서 우리는 더 작게, 유저가 가치를 얻을 수 있는 프로덕트를 만들고, 개선시켜 나감으로써 지속적인 배포를 가지고, 지속적으로 유저가 필요한 것들을 확인할 수 있습니다(파란색 줄).
그리고 이런 과정을 지속적으로 진행하면서 우리는 짧은 기간의 론칭 또는 배포 주기에 따라 유저의 성향에 맞춘 프로덕트를 만들고, 상대적으로 위험성을 낮춘 프로덕트를 만들 수 있습니다.
한 가지 기능을 위해서 내가 생각하는 모든 것들을 한 번에 100% 만들 필요는 없어요. 유저가 가치를 느낄 수 있는 가장 작은 범위부터 서비스를 만들고, "우리가 타케팅 한 유저는 어떤 걸 정말로 좋아하는지"에 대해 확인해 가면서 성장할 수 있으니까요.
2. 프로덕트를 개발하는 과정은 “스프린트”가 아니라 "마라톤"이다.
애자일한 프로세스 진행 시 "정형화된 스프린트, " "목적이 명확한 이터레이션"에 막혀 릴리즈에 대한 압박들 때문에 스트레스를 느끼게 되는 경우가 많은데, 과연 이런 "정책"들이 "일하는 사람들"보다 중요할까요?
스프린트처럼 빠르게 진행되는 개발과 검증의 과정에서 일정한 움직임(Cadence)으로 빠른 속도(Velocity)는 굉장히 중요한 요소입니다. 비즈니스와 프로덕트의 목적에서 역시 계산 가능한 범위 산정 및 릴리즈 계획은 꼭 필요한 요소지만, 일정과 기능에 대한 기한 때문에 우리가 일하는 과정에서 정책, 개발론이 사람이 일하는 환경과 심리적 요소를 해친다면 결코 좋은 애자일 방법론이 아니라고 생각합니다.
위 이미지와 같이 애자일 프로세스를 진행함에 따라, 일정한 개발 주기와 개발 속도를 따라감으로써 기술 부채와 러닝 커브를 줄이기 위해 노력하지만, 우리가 지금까지 일하는 방식에서는
- 정확한 이터레이션의 종점을 찍기 위해
- 정확한 개발 범위와 마커를 세우기 위해
즉, "기계 같은 개발 속도와 빠른 론칭"을 얻기 위해
- 왜 무엇을 빌드해야 하는지에 대한 이해와 공감 없이 작업이 진행되고
- 팀원들의 심리적, 물리적 한계를 느끼게 되는
상황들을 우리는 자주 볼 수 있었어요. 그리고 이런 공장 같은 프로세스에서는 지속 가능한 프로덕트보다는 만드는 과정에서 지치게 돼 사람들이 떠나는 아주 비 생산적인 프로덕트를 만들 수 있는 가능성이 커지게 되죠.
즉 프로덕트를 만드는 사람들이 숨도 돌릴 틈 없이 스프린트를(Sprint)하다가, 프로덕트가 결국 가야 하는 높은 레벨(High-level)을 가기 위한 기나긴 42.195km라는 길을 도착하기도 전에 지칠 수 있게 되는 거죠.
물론 비즈니스의 방향과 마일스톤, 그리고 프로덕트를 만드는 요소중 중요한 요소중 하나인 "일정"이란 부분은 절대적인 부분이기 때문에 거스를 수 없습니다. 그래서 프로세스와 정책이 있는 것이지만, 모든 프로세스와 정책은 결국 일하는 사람들이 어떤 가치를 위해 일할 때 이를 잘 이룰 수 있게 길을 제시하기 위해서 존재하는 것이라고 생각합니다.
오늘 말씀드린 이야기 두 가지를 한 번에 정리하자면, 프로세스는 유저와 팀원을 가두는 게 아니라, 그들을 기반으로 프로세스를 정립해야 한다는, "사람을 위한" 프로세스를 가져야 한다고 아주 간단하게 정리될 수도 있을 것 같아요. 이야기들이 조금 모호하고, 직접적인 내용들이 좀 부족해 다음엔 스토리엔 오늘 말씀드린 내용들을 중심으로
기존에 제가 느꼈던 제가 했던 또는 들었던 프로덕트를 만들며 힘들었던 과정에 대한 자세한 설명
유저 가치를 기반으로 작업함에 따라 힘들었던 과정을 지속적으로 수정하고 있는 업무 프로세스
에 대해 설명하고 비교를 통해, 어떤 가치를 얻고 있는지 설명드리도록 하겠습니다!
