애자일 agile은 무엇인가?
언제고 해야 할 것을 더 먼저, 빠르게, 적은 리스크로 하기
애자일 agile 하다는 건 나중에 할 것을
더 먼저 할 수 있게 만드는 거라고 생각해요
새로운 회사에 합류한 첫 달, 그로스 팀의 리더가 해준 피드백이다.
부동산 개발, 운영 회사에서의 서비스 기획, 운영을 담당하던 관습이 남아서였을까? 첫 달에는 이 말이 그저 문장으로만 이해되었다. 옆에서 지켜본 부동산 개발 프로젝트는 중도에 무언가 바뀌는 것이 큰 위험 혹은 불편으로 다가왔고, 차곡차곡 순서대로 진행되는 것이 미덕으로만 보였다. MVP 같은 개념은 존재하지 않았고, 마감이 끝나지 않은 건물을 고객에게 오픈할 수도 없는 노릇이었다. 모든 것은 순서가 정해져있었다.
그러나 최근, 담당하는 프로덕트의 일부 개편 프로젝트를 과정에서 몇 가지 시행착오를 거치고 나서, 이 말이 크게 와닿았다. 나중에 할 것을 더 먼저 할 수 있게 하기. 어차피 해야 할 것을 미리 할 수 있게 하기. 리드lead 타임을 줄이기. 리스크를 줄이기.
그러자 그간 당연하다고 생각한 업무 혹은 피상적으로만 이해하던 과제와 역할들이 실은 모두 애자일 agile의 맥락에 닿아있다는 생각이 들어 정리해본다.
1. UX : 고객이 우리 프로덕트를 통해 해결해야 할 문제를 더 쉽고 빠르게 해결하도록 돕기
제품과 서비스는 고객의 문제를 해결하고 가치를 제공하는 수단이다. 그렇다면 애자일 관점에서, 제품은 고객이 언제고 얻어가야 할 가치를 더욱 쉽고 빠르게 얻어갈 수 있는 UX를 설계, 제공해야 한다.
- UX/UI는 그래서 단순히 시각적 통일성, 심미적인 요소가 아니라 해결해야 할 문제를 해결하기 위해 필요한 기능을 더욱 빠르고 쉽게 발견-인지-학습-수행하게 하는 데에 목적이 있다.
- 신규 유저의 튜토리얼 tutorial, 온보딩 onboarding 이 대표적인 사례다. 고객이 자신의 문제를 해결하는 방법에 대해 더욱 빠르게, 그리고 명확하게 알 수 있게 도와주니까.
- 어쩌면 특정 퍼널의 UX/UI 개선 또는 퇴보가 특정 지표의 개선 또는 하락에 직접적으로 귀결되지 않을 수도 있다. 그러나 여전히 고객이 더욱 빠르게 핵심 가치를 체감할 수 있도록 만드는 데에 좋은 UX 설계는 필요하다.
2. 기획 단계에 개발팀 참여 : 구성원이 기획에 대해 더 빨리 이해하고 검토하기
모든 제품은 결국 개발을 통해 구체화된다. 따라서 개발팀의 기획안 검토는 언제고 해야만 하는 일이다.
그러나 워터폴 조직에선 기획이 끝난 뒤에 이를 디자인 및 개발팀에 전달한다. "이렇게 하기로 했어요." 물론 사전에 협의를 거치는 경우도 있지만, SI 프로젝트 등의 경우엔 기획이 완료된 스토리보드 등을 가지고 이를 구현할 수 있는 개발팀이 합류하기도 한다.
반면 애자일 조직에서는, 기획의 구상 단계에서 이미 개발팀이 참여한다. 예상되는 이슈와, 기존의 레거시 등을 확인하고 이를 프로젝트의 설계에 반영한다.
3. 프로젝트의 전사 공유 : 조직이 우리의 프로젝트에 더 빨리 이해하고 이슈사항 확인하기
모든 제품의 변경은 외부 고객 또는 최종 사용자 end-user만이 아니라, 내부 운영자 및 이해관계자에게도 영향을 미친다. 또한 내부 이해관계자의 충분한 이해는 제품의 안정적인 운영과 고객 응대에도 필수적이다. 결국 이는 언제고 해야 할 필수적인 과정이다.
이런 맥락에서, 프로젝트에 대해 사전-프로젝트의 착수, 기획, 기획의 완료 또는 과업범위의 확정 단계-에 내부 이해관계자에게 충분히 안내하고 고려 사항 또는 피드백을 논의하는 것은, 애자일한 조직문화 또는 정신에 부합한다.
반면 워터폴 waterfall 조직에서라면 일방적인 협조 요청 혹은 지시 방식으로 일이 진행된다.
4. 고객 만남 : 고객에 대해 더 빨리, 더 적은 리스크로 배우기
제품과 서비스는 고객의 문제를 해결하고 가치를 제공하는 수단이자, 동시에 고객에 대해 학습하는 수단이기도 하다. 고객이 실제로 어떻게 사용하는지, 해결하기로 한 문제를 해결할 수 있는지, 만족도는 어떠한지 등을 배우게 된다. 그렇다면 고객에 대한 학습은 언제고 해야 할 일이고, 이를 더 먼저 하는 것이 애자일이다.
워터폴 waterfall 또는 기존의 조직은 제품을 출시한 후에 고객의 반응을 통해서 배운다. 그러나 애자일 조직은 린 lean 프로세스를 통해, 제품의 기획과 디자인 단계에서 고객을 만나 미리 학습한다.
- 고객 개발 Customer Development 로서의 주기적인 고객 만남
- 기획 초기 단계의 고객 인터뷰
- 프로토타입을 활용한 UT (Usability Test)
5. 스크럼 : 팀이 이슈 사항에 대해 더 빨리 파악하고 논의하기
실제 프로젝트 진행 과정에선 어떤 식으로든 이슈가 발생한다. 이를 논의하는 일은 그래서 언제고 발생하는 일이고, 그렇다면 이를 더 먼저, 기민하게, 유연하게 하는 것 역시 애자일이다.
워터폴 waterfall 조직에선 이슈 사항에 대해 '보고' 형식을 취한다. 문제가 생기면 이를 상급자에게 공유하고, 상급자는 다시 자신의 상급자에게 찾아간다. 이렇게 전달된 문제는 논의 및 결정을 거쳐 다시 하급자와 하급자를 거쳐 돌아온다.
반면 애자일 조직에선 이슈 사항에 대해 스크럼 scrum 형식을 통해 공유한다. 문제 상황에 대해 인지하고, 의사 결정하고, 해결/수행해야 하는 이들이 모두 모여 논의하거나 팔로업 논의를 조율한다. 이를 통해 파악 및 논의, 결정해야 할 이슈에 대해 더욱 빠르고 기민하게 대처한다.
6. QA: 제품의 안정성에 대해 더 빨리, 더 적은 리스크로 확인하기
어떤 제품이든 예상치 못한 문제는 발생한다. 다만 이를 제품의 배포/출시 이후에 깨닫는 대신, 배포/출시 이전에 알 수 있다면 제품의 안정성을 보장하고, 고객의 경험을 저해하는 일을 방지할 수 있다.
QA(Quality Assurance)는 비단 애자일 조직만의 일이 아니지만 (어쩌면 워터폴 한 조직 또는 계약을 통해 타사에 제품을 납품하는 SI 업체가 더욱 엄밀하게 진행하는 일이지만) 원론적으로는 확인해야 할 것을 먼저 확인하는 과정이므로, 애자일의 정신에 맞닿아 있다고도 생각한다.
7. PM의 서포트 : 팀이 해야 할 일, 달성해야 할 결과를 더 빠르게 완료하게 돕기
PM에 대해 이런저런 일을 다 하는 제너럴리스트, 혹은 스스로도 정확히 무슨 일을 하는 사람인지 모르는 역할, 이라는 식의 고충을 종종 읽었다. 이를 두고 서번트 리더십이라는 이야기도 있고
제품의 담당자이나 결정적으로 제품을 직접 구현을 할 수는 없는 PM으로썬, 결국 동료/팀원의 성과와 산출물이 본인과 제품의 성과며 산출물이다. 그리고 이는 제품의 구현, 개선을 위해 언제고 완료해야 할 부분이다.
그렇다면 PM의 서포트는, '디자인과 개발 빼고 다' 하는 여집합으로써의 부차적인 업무가 아니라, 팀과 제품이 달성해야 할 것을 더 먼저, 빠르게, 효율적으로 달성하도록 돕기 위한 애자일의 정수는 아닐까?
