4)우리를 애자일 하지 못하게 만드는 건 무엇일까?
애자일하게 프로덕트를 만들며 느낀 문제점들과 해결의 과정
글목록
4) 우리를 애자일 하지 못하게 만드는건 무엇일까? (현재 글)
아무리 좋은 개발 문화를 기반으로 빠르게 프로덕트를 만드려 해도 수많은 위험요소들이 생깁니다. 그리고 이런 위험요소들은 우리의 성장을 막곤 하지요.
제가 일하고 있는 팀은
1. 유저에게 필요한 프로덕트를 만들자(User Centric Design, Lean UX).
2. 가장 가치 있는 기능을 빠르게 만들고 확인하자(Agile, Lean Startup, XP).
3. 우리가 “왜 만들었는지”를 스스로 설명할 수 있는 프로덕트를 만들자.
라는 목표를 가지고 프로덕트를 만들고 있고 엄청나게 다양한 허들(장애요소)을 만나며 성장하고 있습니다. 그래서 오늘은 우리를 애자일 하게 만들지 못하는 건 어떤 것들이 있는지, 어떻게 해결해 나가고 있는지를 간단히 설명드리려 합니다.
프로덕트의 기능과 일정, 그리고 품질
장애요소
서비스를 만들어 가는 과정은 마라톤이라고 했지만, 프로덕트를 만드는 모든 팀원들이(개발자, 디자이너 피엠도 있지만, 비즈니스와 마케팅을 관리하는 팀원들 역시) 생각하는 프로덕트에 대한 일정과 품질, 그리고 성능에 대해 같은 생각을 할 수 없습니다.
그래서 애자일 방법론에서는
“MVP를 만들고, 유저가 필요한 기능부터 하나씩 추가하면 돼요!”
“처음부터 스포츠카를 만드려 하지 마세요! 스케이트 보드를 만들고, 자전거를 만들고 그다음 필요한 것들을 개선하다 보면 멋진 스포츠카가 완성될 겁니다.”
라는 이야기를 하지만,
“MVP의 기준이 뭔데? 우리 프로덕트의 스케이트보드 버전은 뭔데? 개발팀에게 시간은 많이 준거 같은데 내 스포츠카는 어딨지?”
등으로 프로덕트에 대한 이해가 없다면 프로덕트에 대한 시각은 달라지고, 만드는 팀과 팔아야 하는 팀의 제품에 대한 기준을 맞추기 위해 결국 단거리 선수처럼 몰아치는 일정이 생기는 건 막을 수가 없게 됩니다.
해결방안
왜 이런 일이 생기는 걸까? 를 생각하면, "우리가 만드는 프로덕트는 어떻게 커가고 있는지"를 모르는 게 가장 첫 문제(Risk)라고 생각합니다. 물론, 모든 것들을 생각하는 시간에 딱딱 맞춰 생산해 나가는 건 많은 위험요소들과 개발 중 찾아내는 미지의 영역들(Unknowns) 때문에 거의 불가능합니다. 그래서 저희는 프로덕트 릴리즈의 기준과 목표를 데모데이와 문서화를 통해 공유하고 중/단기적인 로드맵 공유로 최대한 많은 정보를 효율적으로 전달하려 노력합니다.(나중에 시간이 될 때 하나하나 자세히 설명할게요.)
수행하는 일들
1. 데모데이
한 개발 주기 동안 프로덕트가 얼마나 성장했는지, 다음 개발 주기 동안 프로덕트는 얼마나 성장할 것인지 공유하고, 사업 쪽에서도 지속적인 사업방향에 대한 공유를 통해 프로덕트 팀에게 요청할 업무들이 어떤 이유에서 나왔는지 이해할 수 있게 해 주는 행사 진행
2. 프로덕트 로드맵
기간에 나와야 할 "산출물 리스트"가 아닌 기간 안에 이루고자 하는 목표와 목표를 이루기 위해 진행해야 하는 업무를 바탕으로 하는 로드맵 산정과 공유
3. Task management tool의 적절한 사용
프로덕트팀이 어떤 일을 하는지에 대해 비개발자들도 스토리를 통해 파악할 수 있도록 Jira 등의 툴을 사용하고, User story 기반으로 업무 리스트를 만들고, gerkin과 최대한 자세한 설명으로 업무를 공유
방법론과 라이브 프로덕트의 간극에서 생기는 문제
장애요소
우리만의 개발 문화를 만들기 위해선 기초적인 방법론을 적용하기 위해 Pivotal Labs에서 연수받은 Agile, Lean UX, UCD, 그리고 XP를 기반으로 우리만의 개발 문화를 만들어 가는 도중, 개발론에서는 정말로 맞는 방법이지만, 라이브 프로덕트를 개발해 나가면서 생기는 어쩔 수 없는 이슈들을 만났습니다. 가장 많이 당면한 문제들은
“빠르게 진행하자”라고 했던 많은 것들이 결국은 기술 부채로 다가왔고
나중에 꼭 해야 하지만 방법론 때문에 작업하기 애매한 업무가 생기고
효율적으로 일하고 싶으나 절대적인 리소스와 시간은 지속적으로 부족하고
서로 간의 개발 이해도와 적용방법에 차이가 생겨 소통에서 오류가 생기는
등의 에러사항들이 있고, 지금도 계속해서 생겨나는 중입니다.
해결방안
가장 먼저 저희가 깨달은 건 “우리가 방법론에 노예가 되지 말고, 우리가 일을 더 잘할 수 있는 법을 개척하자.” 였어요. 그래서 기초적인 방법론을 기반으로 우리만의 개발 방식을 만들어 가고 있습니다.
수행한 일들
1. Technical Parking lot 사용
프로덕트 개발 중 기술적인 부분에서 “이건 어떻게 처리해야 하지?” 등의 물음표가 생기는 부분이나 “반드시 해야 해”라고 생각하나, 진행 중인 User Story에선 포함되지 않는 내용. 들을 모아 Technical Parking Lot을 만들어, 매주 어떤 이슈가 나왔고,
1. 언제 작업하는 게 가장 적합할지
2. 어떻게 처리해야 할지
에 대해 논의하는 시간을 가집니다.
2. IPM을 통해 페어를 할 업무와 혼자서 할 업무를 선정하고 진행
저희 팀은 기본적으로 모든 개발 리소스가 Pair로 업무 하는 것을 지향합니다. 그러나 인원 운용이나 시간적 여유 때문에 항상 페어로 업무를 하진 않고,
1. 서비스의 기능 상 코어적인 기능들의 초반은 반드시 페어로 진행한다.
2. 기본적인 리서치를 통해 공유하는 Chore들이나 일반적인 서비스에서 이미 다들 해본 개발은 솔로로 진행한다.
라는 기조를 가지고 Iteration을 시작하는 기점인 IPM(Iteration Preparing Meeting)에서 Task를 “페어”또는 “솔로”로 결정합니다. (디자인과 PM은 때때로 페어를 합니다.)
3. 지속적으로 성장하는 개발 문화 정착
일을 하다 보면 모르는 부분은 당연히 생깁니다. 그래서 모르는걸 빠르게 질문할 수 있는 문화를 만들기 위해 Stand up meeting과 위에 말씀드린 Technical Parking lot을 진행하고, 도메인 놀리지나 기술적 또는 비즈니스 적으로 도움이 필요할 땐 서로서로가 빠르게 확인할 수 있도록 White Boarding 등을 통해 개선하고 있습니다.
새로운 방법론을 만들고 적용하는 것에 대한 문제.
장애요소
업무 시작 시
“애자일이 좋은 건 알겠는데 한국사회에선 어울리지 않아요.”
“이미 적응해서 하고 있는데 이제 와서 뭘 또 어떻게 바꾼다는 건지 이해가 안돼요.”
“그냥 시킬 일 정확하게 잘라서 주세요 그냥 하면 되니까.”
(아마 소름 돋은 분들 많을 걸로 예상....) 등의 새로운 방법에 대한 일방적인 거부감이나 오랫동안 가져온 관습의 변화에 대한 반대 의식이 가장 큰 장애요소 중 하나였습니다.
물론, 애자일 방법론, 빠른 의사결정과 수렴 그리고 빠른 개발과 빠른 확인이 진리는 아닙니다. 기존의 워터폴 방식으로 프로덕트를 잘 성장시킨 회사들도 너무나 많고 아직도 워터폴 방식으로 좋은 프로덕트를 만드는 회사도 많이 있습니다. 명확한 사업 기획서와 화면 기획서, 명확한 디자인 가이드라인, 정리된 개발 문서가 있다면 물론 워터폴은 매력적인 방법이에요. 하지만 제가 있는 팀은
1. 변동성 높은 시장에 따라 빠르게 개발하고 빠르게 확인해야 하는 것들이 많은 점
2. 현재 가지고 있는 리소스(물적, 인적 리소스)를 문서화나 가이드에 쓸 수 없다는 점
3. 팀에 조인한 모두가 하나의 프로덕트를 다 같이 만들어 가고 싶다는 의지가 있다는 점
을 기반으로 빠르게 가치를 만들어 낼 수 있는 팀으로 프로덕트 팀의 문화를 세우기를 결정했습니다. 그리고 이하와 같은 상황을 당면했죠.
작은 팀으로 서로가 많은 공유를 했더라도 놓치는 부분이나 의견이 맞지 않는 상황들은 피할 수 없다
기조는 있지만 디테일한 부분에서 개발 문화에 대해 결정하고 나아가야 하는 이슈들이 지속적으로 생긴다
너무 방법론에 치우치거나 너무 의미 없이 일하거나 중간이 없는 상황들이 생기는
등에 대한 문제사항 황들이 발생했습니다.
해결방안
방법론은 의사결정권자나 스크럼 마스터가 결정하고 통보하는 게 아닙니다. 프로덕트를 만드는 인원들이 방법에 대해 공유를 통해 이해하고 인정함으로써 가치가 생기고 많은 시행착오를 거치며 진정한 의미가 생깁니다.
그리고 결국 중요한 건 애자일이 중요한 게 아니라 우리가 일을 잘하는 게 중요합니다. 일을 잘하기 위해 월급과 복지 말고도 팀과 자신의 성장에 대한 동기부여가 필요하다면 그렇게 일할 수 있게 우리가 만들면 되는 거죠.
그리고 이런 팀 안에서의 의지로 만들어진 우리가 개발하는 방법은 우리가 일을 잘하기 위해 만든 방법 이기 때문에 서로서로가 지키려는 의지를 가지게 돼서 더 잘 적용할 수 있는 거 같아요 그래서 저희는 일을 하면서
1. 개발단 또는 사업단에서도 지속적으로 확인하고 체크하는 습관을 가지고
2. 문제를 느낄 때마다 그리고 변화가 필요하다고 느낄 때마다 회고나 포스트모템을 통해 개선 리스트들을 바로바로 만들어 내고 개선하며
3. 사소한 정책이더라도 모두가 지킬 때 진짜로 의미가 있다는 것을 주기적으로 상기해 습관을 만들 수 있도록
팀을 가꿔가고 있습니다.
우리가 하고 있는 일도 결국 많은 사람들과 협업을 통해 서비스를 만들어 내 가는 과정이므로 업무에 대한 지속적인 공유와 소통이라는 이 마르고 닳도록 나오는 이 마법의 문장이 정말 중요합니다. 그리고 소통에서 무엇보다 가장 중요한 건 화자가 아니라 청자라는 것을 잊지 말고 청자를 위한 소통을 해야 합니다.
함께 일하는 동료들에게 항상 Actionable (바로 행동을 취할 수 있고), Specific (명확하며), Kind (친절하게)를 기준으로 일해주세요 그게 우리가 일을 잘할 수 있는 시작이지 않을까 싶습니다.
오늘도 긴 글 읽어주셔서 감사합니다.
앞으로도 종종 저희 팀이 일하는 모습들을 실제 사례를 들어 하나하나 설명드리고 알려드릴게요!
감사합니다.
