회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반 번역문입니다. 이 글의 작가인 이타마르 길라드(Itamar Gilad)의 블로그를 통해 발행된 글입니다. 그는 Google, Microsoft, IBM 및 기타 여러 스타트업에서 20년 이상의 경력을 쌓은 베테랑 프로덕트 매니저입니다. 본문은 비즈니스 팀과 애자일 조직 사이의 소통 방법에 대한 내용으로 조직 생활에 있어, 서로 간의 경계를 허물고 원만하게 일할 수 있는 방법은 무엇일지 함께 고민해볼 수 있겠습니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반 번역문입니다. 이 글의 작가인 이타마르 길라드(Itamar Gilad)의 블로그를 통해 발행된 글입니다. 그는 Google, Microsoft, IBM 및 기타 여러 스타트업에서 20년 이상의 경력을 쌓은 베테랑 프로덕트 매니저입니다. 본문은 비즈니스 팀과 애자일 조직 사이의 소통 방법에 대한 내용으로 조직 생활에 있어, 서로 간의 경계를 허물고 원만하게 일할 수 있는 방법은 무엇일지 함께 고민해볼 수 있겠습니다.
기업의 경영진과 프로덕트 매니저들은 개발자들이 기업의 비즈니스 차원에서 필요한 부분에 대해서 관심이 부족하다는 사실을 깨달을 때마다 좌절하는 경우가 많습니다. 개발자들은 제품을 디자인하고 기능을 구현하느라 끝없이 바쁘게 일하지만(그들의 업무는 눈으로 쉽게 파악할 수 없는 경우도 많습니다), 비즈니스 측면에서 바라보자면 중요한 프로젝트가 진행되는 속도는 언제나 굼벵이처럼 느리기만 할 뿐입니다. 오랫동안 기다려왔던 제품이나 기능이 마침내 출시된다고 하더라도, 정작 기업이 원하는 수준에는 못 미치는 경우도 허다합니다.
우리는 흔히 엔지니어나 디자이너, 데이터 엔지니어 등의 개발자들에게 비즈니스 감각이나 “바람직한 조직문화”가 결여되어 있다고 생각하기 쉽지만, 실제로 그런 경우는 많지 않습니다. 오히려 개발자들은 계획 단계에서 배제되어 있거나, 비즈니스적인 부분과 단절되어 있는 경우가 더 많습니다. 그들의 업무는 언제나 제품이나 기능을 만들어내는 것(산출)에만 머물러 있으며, 비즈니스나 고객의 측면에서 사고하는 방식에는 익숙하지 않습니다. 부서별로 인센티브가 주어지고 목표가 할당되는 분위기 때문에, 개발자들은 강력하고 확장 가능하며, 기능이 훌륭한 소프트웨어를 만드는 일에 더욱 내몰리게 됩니다. 그래서 비즈니스의 성공보다는 자신들의 성과를 수치적으로 개선하는 것에만 집착하게끔 만듭니다.
애자일 기법을 활용한다고 해서 반드시 상황이 나아지는 것은 아닙니다. 오히려 더욱 악화되는 경우도 많습니다. 애자일 기법에서는 사양 → 설계 → 개발 → 테스트로 이어지는 기존의 순차적인 개발 방식을 폐기했지만, 대부분의 기업들에서 여전히 사용하고 있는 방식인 전략 → 로드맵 → 프로젝트 → 실행으로 이어지는 비즈니스 프로세스를 바꾼 것은 아니기 때문입니다. 그래서 관리 및 경영 부서의 사람들은 여전히 “폭포수 모델(waterfall model)[2]이 지배하는 세계”에서 대부분의 시간을 보내고 있습니다. 즉, 매우 잘 정의되고, 웬만해서는 변하지 않는 전략, 로드맵, 계획에 의해서 거대한 프로젝트를 진행하고 있습니다.
반면에 수많은 기업의 개발자들은 현재 “애자일 세계”에 완전히 몰두해서 대부분의 시간을 보내고 있는데, 그들은 엄격한 리추얼(ritual)[3]에 의해 코딩 작업을 조금씩 늘려가면서 결과물을 향해 나아갑니다. 이런 팀에서는 우선순위가 정해진 프로덕트 백로그(product backlog)[4]와 상세한 요구사항들을 전달받을 것이라고 기대하는데, 흔히 에픽(epic)[5]이나 유저 스토리(user story)[6]의 형태인 경우가 많습니다. 사용자나 시장, 비즈니스 등의 좀 더 커다란 맥락은 그 뒤로 사라집니다. 역사적으로 모든 애자일 기법은 사용자와 비즈니스 모두에게 있어서 코드가 아니라 지속적인 가치의 전달을 강조하고 있습니다. 이들 모두 사용자/고객 및 이해당사자들과의 짧은 피드백 루프(feedback loop)[7]가 필요합니다. 그러나 애자일 기법에서는 이런 부분을 반드시 지켜야 하는 것은 아닙니다.
이에 대해서 많은 기업들이 채택하고 있는 해결책은 바로 프로덕트 매니지먼트(product management)[8]입니다. 요즘에는 프로덕트 오너(product owner, PO)라고 부르기도 하는 프로덕트 매니저(product manager, PM)들은 이러한 두 세계 사이를 연결해주고 “모든 것이 원활하게 동작하게” 만드는 사람들입니다. 이러한 경계선 사이의 한쪽 측면에서 보자면 그들은 로드맵에 따라서 제품이나 기능을 완성해야 하는 책임이 있는데, 이것은 일반적인 프로젝트 매니저(project manager)의 업무와 크게 다르지 않습니다. 그리고 다른 쪽의 측면에서 보자면, 그들은 기술 인력들을 최대한의 역량으로 바쁘게 작업하도록 만들면서 애자일이라는 만만치 않은 조직을 가동시켜야 하는 책임이 있습니다.
이러한 PM과 PO의 역할 모두 대체적으로 힘들고 웬만해서는 겉으로 성과가 드러나지도 않습니다. 프로덕트 매니저는 플래닝 세션(planning session, 기획 회의), 리뷰(review), 스탠드업(standup, 애자일 조직에서 매일 간단하게 진행하는 회의), 레트로스펙티브(retrospective, 성과 리뷰 회의)와 같은 이해당사자들과의 다양한 미팅을 관리해야 하는 것은 물론이고, 목표 및 핵심 결과(OKR)[9], 로드맵, 에픽, 유저 스토리도 만들어야 하기 때문에 엄청나게 많은 시간과 노력을 들여야 합니다. 이런 업무들은 아주 어렵고도 시간이 소요되는 업무이기 때문에, 정작 실질적인 영향력을 발휘할 수 있는 제품을 만드는 데 있어서 필수적이라고 할 수 있는 시장조사나 데이터 분석, 아이디어 검증과 같은 업무를 할 수 있는 시간이 부족한 경우가 많습니다. 제가 이야기를 나누어 본 많은 프로덕트 매니저들은 이런 시스템이 제대로 작동하지 않으며 시간낭비라는 사실을 충분히 잘 알고 있었지만, 개인이 그것을 바꾸기에는 무기력하다고 느끼고 있었습니다.
이번 글에서 저는 톱다운(top-down)의 방식의 폭포수 모델을 벗어나서 근거에 기반한 제품 개발 방식으로 전환하는 것이 조직의 관리, 기술, 프로덕트 매니지먼트, 디자인, 당사자들 사이의 밀접한 관계 유지 등에 어떻게 도움을 주는지를 설명하고자 합니다. 여기에서는 제가 고안한 기스트(GIST) 프레임워크를 참고해서 설명하도록 하겠습니다.
GIST는 제품 계획 및 개발의 네 가지 레벨인 목표(Goal), 아이디어(Idea), 단계(Step), 작업(Task)을 관리하는 기법입니다.각각의 레벨에 대해서 간단히 말하자면, 목표(Goal)는 우리가 성취하고자 하는 바를 정의하는 것입니다. 아이디어(Idea)는 그 목표를 달성하기 위해서 고안해 낸 방법입니다. 단계(Step)는 그러한 아이디어가 유효한지를 검증하면서 점점 더 발전시켜 나가는 소규모 프로젝트나 간단한 활동을 말합니다. 작업(Task)이란 어떤 단계를 구현하기 위한 일상적인 활동들로, 우리가 스프린트 백로그(sprint backlog)[10]나 간반(Kanban)[11]회의를 통해서 하는 것들입니다. 저는 이러한 GIST의 초기 버전을 구글에서 처음 사용하기 시작했는데, 그 이후로도 수많은 기업들이 이를 구현하는 과정에서 도움을 주고 있습니다.
그런데 작업(task)에 대해서는 GIST에서 뭔가 전혀 새로운 시스템을 도입하려는 것이 아닙니다. 스크럼(scrum)[12]이든, 간반(kanban)이든, XP(eXtreme Programing)[13]이든, 심지어는 우선순위가 지정된 작업 리스트이든, 조직에서 선호하는 용어라면 무엇이든 가능합니다. GIST가 주로 관심을 갖는 것은, 조직이 결과와 영향력을 만들어내기 위해서 언제나 노력하는 것입니다. 즉, 시장에서의 가치를 창출하고 기업에게는 수익을 가져다 주기 위한 활동에 대해서 많은 관심을 가지고 있습니다. GIST는 바로 이러한 과정을 네 개의 레벨로 나누어서 살펴보는 기법이라고 할 수 있습니다.
목표(Goal) 레벨은 기업의 모든 부문들이 서로 공통의 언어로 소통하는 영역이며, 보다 더 큰 맥락인 “우리가 이 일을 왜 하는가”라는 질문에 대한 답이 결정되는 곳입니다. 일반적으로 저희는 비즈니스에 있어서 (새로운 온보딩 절차를 만들어 내는 것과 같은) 산출(output)이 아닌 (온보딩 완료 비율을 75%로 끌어올리는 것과 같은) 성과(outcome)에 해당하는 스마트한 목표를 부여하기 위해서 노력합니다. 실제로 조직 내의 모든 팀들이 이러한 목표를 정하기 위해서 함께 참여해야 합니다. 그 방법은 다음과 같습니다.
첫 번째의 중요한 단계는 조직의 영향력 평가지표를 정하는 것입니다.대표적으로는 회사가 시장에 창출하는 가치의 양을 측정하는 ‘북극성 지표(North Star Metric, NSM)’와 회사가 (이러한 과정을 통해서) 다시 포착할 수 있는 가치의 양을 측정하는 ‘톱 비즈니스 KPI(Top-Business KPI)’가 있습니다. 이러한 지표들은 기업이 성공으로 간주하는 것이 무엇이며, 모든 구성원들이 마음속에서 가장 우선시해야 하는 것이 무엇인지를 보여주는 것입니다. 기업에서 이루어지는 모든 일들은 조직은 물론이고 각 구성원 개인들의 성장과도 연결되어야 합니다. 이런 과정을 돕기 위해서, 저희는 NSM과 톱 비즈니스 KPI에 영향을 주는 하위 지표들을 만들어 내곤 합니다. 이런 지표들은 성과 지표(outcome metrics)라고 불리며, 여러 가지의 평가지표들로 구성된 트리(tree) 형태의 구조 안에서 배치되는 경우가 많습니다.
그런 다음 각 부서별로 이러한 하위 지표들을 할당할 수 있습니다. 예를 들자면, ‘온보딩 완료 비율’이라는 지표는 비즈니스의 성장을 담당하는 부서에게 주어질 수 있습니다. 이렇게 함으로써, 모든 팀들이 비즈니스의 명시적인 목표를 향해서 (또는 다른 팀들이 비즈니스의 목표를 달성하는 것을 돕기 위해서) 노력할 수 있습니다.
다음으로 우리는 위와 같은 트리 구조에서 가장 중요한 지표들에 대해서 분기별 목표와 연간 목표를 설정할 수 있습니다.여기에서는 일반적으로 ‘목표 및 핵심 결과(OKR)’가 아주 유용하게 쓰입니다. 각 팀들은 각자의 목표를 설정해야 하며, 또한 누락된 목표가 있는지를 찾아내기 위해서 적극적으로 참여해야 합니다. 기술적 부채(technical debt)[14]를 줄이는 것이나 사용자의 프라이버시를 강화하는 것과 같은 트리에서는 구체적인 목표들이 누락되는 경우가 많습니다. 따라서 이러한 누락된 목표를 찾아내는 것은 수많은 기업들을 곤경에 빠트리는 근시안적인 조치를 막기 위해서 중요한 대응방안이라고 할 수 있습니다. 이러한 지표들이 모두 커다란 트리 구조 안에서 서로 관계를 맺고 있기 때문에, 조직 전체가 공동의 목표를 설정하고 동일한 맥락을 공유하는데 도움을 줄 수 있습니다.
수많은 조직에서는 어떤 제품이나 비즈니스의 아이디어(Idea) 레벨에 대한 결정권이 회사의 경영진이나 핵심적인 이해당사자들의 특권인 경우가 많습니다. 프로덕트 매니저들은 (그러한 결정권을 가진) 위원회의 의사결정 프로세스를 진행시키는 “실무 담당자”로 전락하기도 합니다. 넷플릭스(Netflix)나 에어비앤비(Airbnb), 부킹닷컴(Booking.com)처럼 근거를 중시하는 기업들은 이와는 다른 급진적인 접근방식을 채택하고 있습니다. 이들은 대부분의 아이디어들이 실질적인 가치를 보여주지 못하기 때문에 수많은 아이디어를 테스트해야 한다는 것을 알고 있습니다. 그들은 아이디어를 짜내고 평가하는 과정에서 제품을 만들어내는 팀들이 적극적으로 참여할 것을 원하며 요구하고 있습니다. 경영진이나 이해당사자들도 여기에서 제외되는 것은 아닙니다. 이들도 아이디어 작업에 참여할 수 있고 발언권을 가지지만, 그들의 의견이 자연스럽게 최고의 아이디어로 받아들여지는 것은 아닙니다.
이러한 과정에서 고려해야 하는 사항들은 다음과 같습니다.
단계(Step) 레벨은 위와 같은 아이디어를 만들어내고 동시에 테스트도 수행하는 단기적인 프로젝트입니다. 예를 들어서 설문조사처럼 혼자서 며칠 동안 일하는 것도 이러한 단계(Step)의 일부라고 할 수 있습니다. 또는 사용 적합성 조사, 스모크 테스트(smoke test)[19], A/B 테스트[20]처럼 교차 기능 팀들이 좀 더 오랜 기간 동안 수행하는 일들도 여기에 속한다고 볼 수 있습니다. 스크럼(scrum)의 측면에서는 이러한 단계가 여러 개의 스프린트에 걸쳐 있을 수도 있지만, 하나의 완전한 스프린트보다는 기간이 더 짧을 수도 있습니다.
단계별 TF(step force)란 단계별 태스크 포스(step task force)를 줄인 용어입니다. 단계별 TF는 여러 부서의 사람들을 불러 모아서 소집하는 임시 조직으로, 어떤 단계를 계획해서 실행하고, 그를 통해서 생성되는 결과를 수집하고 분석하는 일을 하게 됩니다.이러한 단계별 TF에는 일반적으로 개발자, 디자이너, 데이터 엔지니어/분석가, 프로덕트 매니저 등이 포함되며, 경우에 따라서는 비즈니스 오너가 직접 참여할 수도 있습니다.
단계별 TF에 속한 사람들은 요구사항을 정리하거나, 디자인을 하거나, 코드를 작성하거나, 새로운 소프트웨어를 구현하는 일처럼 기존에 자신이 맡고 있던 역할에만 몰두하지 않습니다. 단계별 TF 조직이 맡고 있는 더욱 커다란 임무는 위에서 도출한 아이디어를 어떠한 추정이나 리스크, 가설 등을 대상으로 검증할 수 있는 수준까지 발전시키는 것입니다. 이러한 조직에서는 “완료”라는 의미가 달라집니다. 예를 들어서 어떤 엔지니어가 A/B 테스트를 구현해야 하는 책임을 맡았다면, 그것은 단지 코드를 작성해서 내놓는 것이 아니라, 그 테스트가 올바로 진행될 수 있게 하는 것은 물론이고, 적절한 분석이 이루어질 수 있을 만큼 충분한 양의 데이터를 확보하는 것까지 포함됩니다.
그런데 실제로 일을 진행하다 보면, 우리는 특정한 작업에만 사로잡힌 나머지 목표나 아이디어, 단계에 대해서는 잊어버리는 경우가 많습니다. 이를 방지하기 위해서 제가 추천하는 방법은 GIST의 각 항목들을 추적할 수 있는 GIST 보드를 만들어서 활용하는 것입니다.
실물이든 디지털이든 이러한 보드를 만들면, 단계별 TF 팀이 현재 진행하고 있는 부분이 전체적인 GIST에서 어디에 해당하는 지를 보여줍니다. GIST 보드는 다음과 같이 만들 수 있습니다.
이번 분기에 착수하기로 했던 기술적인 목표나 디자인의 목표들도 이 보드 위에 추가하는 것이 좋습니다. 이런 것들을 숨겨두기보다는, 눈에 잘 띄게 해 놓고 추적하는 것이 중요합니다.
그리고 주간 또는 격주 단위로 회의 일정을 세워서, 진행 상황을 점검하고 보드의 내용을 업데이트합니다. 이러한 회의는 주간 또는 격주 단위의 정기적인 애자일 기획 회의를 시작하기 전에 30분 정도 진행되는 간단한 미팅이라도 괜찮습니다. 여기에서 해야 할 일은 해당하는 목표, 아이디어, 단계의 현황을 점검하고, 보드의 내용을 업데이트하는 것입니다. 이렇게 하면 이어지는 작업 일정 논의에 있어서도 아주 훌륭한 도움이 될 수 있습니다.
이처럼 정기적인 회의 일정이 하나 더 추가되는 것에 대해서 눈살을 찌푸리는 팀원들도 있을 것입니다. 그러나 일단 이런 미팅을 몇 번 시작하고 나면, 그러한 거부감이 자연스럽게 사라질 것입니다. 엔지니어와 디자이너들은 기존의 일상적인 업무를 벗어나서, 좀 더 커다란 관점에서 이야기를 나눌 수 있다는 것을 높이 평가할 것입니다. 이런 모임을 지속하다 보면, 주어진 목표와는 직접적인 연관성이 없는 스토리 포인트(story point)[21]나 순전히 기술적/디자인적인 문제에 불필요하게 집착하지 않고 원활하게 논의를 진행할 수 있습니다.
조직 내의 각 부서에서는 이런 과정을 거쳐서 만들어진 프로덕트 백로그를, 스프린트 백로그나 간반 백로그 목록에 넣기 위한 작업(task) 단위로 변환할 수 있을 것입니다. 각각의 단계에 우선순위를 설정하면, 각 팀에서 필요한 정확한 백로그를 만들어낼 수 있습니다.
이러한 작업까지 완료되고 나면, 프로덕트 매니저들은 이제 “프로덕트 오너(PO)”로서의 역할에 투자하는 시간을 적극적으로 줄여야 할 필요가 있습니다. 이제 모든 팀들이 동일한 맥락과 명확한 목표를 공유하고 있기 때문에, 그 전보다는 프로덕트 오너로서의 역할에 대한 부담이 상대적으로 줄어들게 됩니다. 이제는 더 이상 구체적인 작업들까지 모두 개입할 필요가 없이, 좀 더 높은 차원의 목표, 아이디어, 단계 레벨에서 상황을 리드하는 것이 좋습니다.
정보라는 것은 기업의 위에서 아래로 흐르는 일방적인 형태가 되어서는 안 됩니다. 조직 내의 누구라도 언제든 문제점을 지적하고 발언할 수 있게 해야 합니다. 신뢰를 구축하는 것이 중요합니다. 커뮤니케이션은 많을수록 좋습니다. 그리고 프로덕트 매니저들이 해야 하는 일도 바로 이런 것입니다.
조직의 목표나 아이디어 뱅크, 그리고 GIST 보드를 포함해서 이런 방식으로 만들어지는 모든 자료들은 조직 내의 누구라도 쉽게 이용할 수 있어야 합니다. 그러나 경영진이나 비즈니스의 이해당사자들이 그런 자료를 언제든지 들여다볼 수 있다는 생각이 들게 해서는 안 됩니다. 그러지 않으려면 이메일이든 대면 회의를 통해서든, 조직의 목표가 무엇이고, 그것이 어떻게 이루어지고 있으며, 현재 연구가 진행되고 있는 아이디어는 무엇인지, 지금까지 얻어낸 결과는 무엇인지, 그다음 단계는 어떻게 될 것인가 등의 내용을 주기적으로 구성원들에게 공유해야 합니다. 이러한 활동은 새로운 아이디어나 피드백을 요청하기에도 좋은 기회가 될 수 있습니다. 하향식 의사결정 문화에서는 쉽지 않은 시스템인 것입니다. 우리는 몇몇 사람의 의견보다는 근거에 기반해서 결정을 내려야 합니다.
마지막으로, 이러한 조직 문화는 모든 구성원들간에 더욱 건강한 관계를 키워나갈 수 있습니다. 프로덕트 매니저, 다양한 이해당사자, 경영진과 여러 부서들이 공동의 이해와 신뢰를 바탕으로 하나의 견고한 조직을 만들어낼 수 있습니다. 프로덕트 매니저들은 더 이상 단순히 로드맵이나 백로그만 담당하는 실무자가 아닙니다. 이제 그들은 고객 전문가, 제품 탐색 과정의 리더, 실행 단계의 조력자로서 제대로 역할을 수행할 수 있어야 합니다.
원문: https://itamargilad.com/breaking-the-walls-between-business-and-agile-teams/
[1] 끊임 없이 변화하는 환경에서 살아남기 위해서 조직을 기민하게 만들어서 운용하는 기법
[2] 마치 폭포수처럼 지속적으로 아래로 향하는 방식의 순차적인 개발 프로세스
[3] 애자일 조직에서 수행하는 의식적인 절차
[4] 사용자가 요구하는 제품의 기능 목록으로, 모든 요구사항에 대해서 우선순위가 정해져 있음
[5] 애자일 조직에서 활용하는 프로젝트 단위의 목표
[6] 어떤 제품이나 소프트웨어를 실제 사용자가 사용하는 것처럼 이야기의 형태로 쉽게 풀어서 설명하는 것
[7] 어떤 결과물에 대한 테스트를 개발 과정에 지속적으로 반영해서 끊임없이 개선하는 프로세스
[8] 제품 수명주기(life cycle)의 전 단계에 걸쳐서 제품의 개발과 관련된 모든 사항들을 체계적으로 관리하는 것
[9] 목표 및 결과를 추적하기 위한 프레임워크
[10] 스프린트(sprint)를 통해서 백로그(backlog)를 만들어내는 활동
[11] 개발자에게 과도한 부담을 주지 않으면서 적시(just-in-time)에 제품을 출시할 수 있게 하는 개발 기법
[12] 럭비에서 선수들이 스크럼을 짜는 것처럼, 구성원들이 각자의 역할에서 최선을 다하면서 모두가 하나로 결집하여 문제를 해결하기 위한 기법
[13] 고객이 개발 과정에 직접 참여해서 단기간에 생산성을 극대화 하는 프로그래밍 기법
[14] 시간에 쫓겨서 급하게 완성품을 출시하려고 하다 보니, 개발 과정에서 발생한 기술적 결함을 부채(빚)처럼 쌓아두고 가는 것
[15] 한 사람이 여러 부문의 일을 수행하거나, 또는 여러 다양한 부서의 사람들이 하나로 모인 것
[16] 새로운 제품을 디자인 할 때 혁신적인 아이디어를 만들어내기 위한 기획 단계의 프로세스
[17] 여러 명이 팀을 이뤄서 마라톤을 하듯이 긴 시간 동안 어떤 제품에 대한 아이디어나 솔루션을 만드는 이벤트
[18] 어떠한 아이디어가 가치의 창출로 이어지는 과정을 지도처럼 시각적으로 표현하는 것
[19] 어떤 시스템을 본격적으로 테스트하기 전에 동작 여부를 점검하기 위한 일종의 시험 가동
[20] 서로 비교되는 두 가지의 항목을 사용자에게 제시하고 그에 대한 선호도를 평가하는 것
[21] 주어진 유저 스토리를 구현하는 것이 얼마나 어려운지를 측정하는 난이도
좋아요
댓글
공유
공유
2.7K
