프로젝트 설계 및 관리에 관한 개념의 맥락 이해하기
WBS만이 프로젝트의 전부는 아니니까
프로젝트 매니징을 처음 담당한 때에 접한 아티클 대부분은 프로젝트 매니징을 "WBS를 만든다"거나, "칸반 보드를 만든다"는 식으로 To-do List와 Due date 중심의 설명에 그쳤다. 그러나 실제 매 분기, 또는 매 월 프로젝트를 설계하고 관리하는 업무를 하다 보면 이 외에도 어떤 문제를 풀 것인지, 프로젝트의 목표는 무엇인지, 누가 할 것인지, 어떻게 현황을 확인하고 이슈를 조율할 것인지에 관한 개념과 방법론, 프레임워크가 등장한다.
그래서 이번 글에서는 프로덕트 팀의 프로젝트의 설계와 관리에 관한 몇 가지 용어, 개념 중 일부를 서로 맥락을 연결 지어 설명하고자 한다.
1. 문제 발굴 : 어떠 문제를 풀 것인가?
조직 또는 팀의 비전과 현재의 상황을 바탕으로 다음 월/분기/연도에는 어떤 방향으로 조직과 팀이 향해야 할지, 어떤 문제를 풀어야 할지 검토한다. 이미 알고 있는 문제점과 이슈를 나열하여 이를 개선해나가는 귀납적인 방법도 있지만, 도달하고자 하는 장기적인 목표로 나아가기 위해 필요한 것들을 나열하는 연역적인 방법을 주로 이용한다. 왜냐하면 전자의 경우에도 무언가 분명 개선되고 해결되겠지만, 그래서 총체적으로 어디를 향해 나아가는지 알기 어렵기 때문이다.
귀납적으로 과제를 달성해나가는 방안(좌)과 연역적으로 목표를 향해 나아가는 방안(우). 귀납적인 접근은 장기적인 방향을 알기 어렵다. 2. 문제 정의 및 목표 수립 : 목표는 무엇이고 이 목표가 달성되면 어떤 모습 end-image인가?
발굴한 문제 중 다음 월/분기/연도에 풀기로 한 문제가 선택된다면, 이를 정의하여 구체적인 목표를 수립한다. OKR을 따르자면, Objective는 완수하고자 하는 목표이고, Key Results는 목표가 완수되었을 때 결과적으로 나타나는 모습, 특히 정량적인 수치이다.
특히 목표가 달성되었을 때에 어떤 모습인지를 상상하고 정의하는 것은, 기획자로서 '무엇을 위해 이 일을 하는지', 그리고 '이 일이 끝나면 어떤 결과가 나와야 하는지'를 명확하게 그려주는 나침반이자, 참여하는 이들이 동일한 이해도를 갖고 움직이게 하는 장치가 된다.
3. 목표는 높고 명확하게
또한 이때에 목표는 되도록 명확한 문장으로 명시하여 조직과 팀이 동일하게 이해할 수 있게 하되, 우리의 평소 능력, 역량보다는 다소 높아야 한다. 그 이유는 첫째로 실제 업무 중 생겨나는 다양한 변수와 사건사고를 감안했을 때, 실제 목표보다는 다소 부족하게 달성하게 될 가능성이 있기 때문이며, 둘째로 높은 목표치를 달성하고자 할 때에 비로소 평소보다 조금이라도 더 높은 집중력, 더 높은 생산성을 보일 수 있기 때문이다.
출처 : https://www.pinterest.co.kr/pin/819655200933689922/가령 전년도에는 100을 달성했다면, 새해에는 110~120을 달성하고자 계획을 세워야 한다. 이전에 하던 만큼을 목표로 삼는다면, 무엇이 더 나아지겠는가? 또한 그건 어차피 하던 대로만 하면 달성할 수 있는 목표 아닌가? 이는 목표가 아닌 '현황'이다.
4. 백로그 : 목표를 달성하기 위해 구체적으로 수행해야 할 과제는 무엇인가?
그러나 목표는 어디까지나 목표일 뿐, 실제로 이를 달성하는 과정은 구체적인 업무 task에 달려있다. 우리의 목표를 달성하기 위해 해야 할 일은 무엇인가? 사실 모든 것은 현재 시점에서 내리는 추측, 가정일 뿐이므로 '해야 할 일'의 목록 역시도 변경될 수 있고, 이 일들을 모두 완수한다고 해서 목표가 반드시 달성된다는 보장 또한 없다. 다만 그럼에도 우리는 '목표를 달성할 수 있을 것으로 추측되는' 구체적인 업무를 설계하여 진행함으로써 목표를 향해 나아간다.
다만 이를 설계하는 건 직무나 조직/팀의 업무의 방식에 따라 다르겠지만, '실험'을 기반으로 움직이는 프로덕트 또는 그로스 팀이라면 '목표를 달성하는데 기여할 것으로 추측되는' 아이디어의 목록을 만들고 이 목록들을 차례대로 수행해나간다. 이것이 바로 (목표를 달성하기 위해) 해야 할 일의 목록인 백로그 backlog다.
이러한 백로그에 목록을 쌓아가는 건 평소의 아이디어나 누군가의 요청, 건의 사항을 기록해두거나, 또는 팀의 아이데이션/브레인스토밍 등을 통한 방법이 있다.
5. I.C.E : 해야 할 일의 목록 중 무엇을 먼저 할 것인가?
그러나 우리의 리소스는 한정되어있고, 아이디어 역시 각기 값어치가 다르다. 어떤 아이디어는 누가 봐도 그 효과가 클 것으로 추측되는 반면, 어떤 아이디어는 효과가 미미해 보인다. 또는 어떤 아이디어는 성공만 한다면 효과가 클 것으로 보이지만 성공 확률이 낮아 보이기도 하고, 또 어떤 아이디어는 실현 과정이 제법 녹록지 않을 것처럼 보이는 경우도 있다. 이러한 점을 두루 고려하여 아이디어의 우선순위를 정하는 프레임워크가 ICE(Impact, Confidence, Ease)다.
ICE 프레임워크 내에서 구체적인 숫자를 부여하는 기준은 참여자들의 감 gut feeling에 의한 방법부터 구체적인 추론에 의한 방법이 있다. 사실 이 숫자는 어디까지나 '우선순위를 정하기 위한' 용도일 뿐이므로, 어떠한 통계적 근거나 물증을 필요로 하진 않는다. 다만 서비스가 크고 복잡할수록, 조직 구성원의 업무가 과중할수록 우선순위에 대한 판단이 더욱 예리해질 필요가 있기에 몇 가지 추론의 방안을 사용한다.
예컨대 Impact의 경우 해당 실험이 영향을 미칠 사용자의 범위나 숫자, 영향을 미칠 기간, 이에 따라 영향을 받을 예상 매출액/사용빈도 등을 계산해볼 수 있다. 반면 Confidence의 경우, 이전에 유사한 실험을 진행했던 내역이 있는지 살펴본 뒤 이를 토대로 추측해볼 수도 있다.
또한 Ease의 경우 User Story 기반의 개발을 하는 프로덕트 팀에서 Story Point를 검토하는 것과 마찬가지로, 1시간 또는 반나절 등 특정 단위를 기준으로 해당 시간을 소요하는 업무를 10점짜리라 했을 때, 이와 비교하여 어느 정도가 소요될지 비교하는 방법부터, 참여자 중 경험자의 추측에 의한 방안도 있을 수 있다.
다만 다시 말하지만 이러한 추론은 결국 '우선순위를 판단하기 위한' 용도이므로, 단순히 추론을 위한 추론이 되거나, 추론에도 리소스가 필요 이상으로 투입되어 전체적으로는 낭비가 되는 경우는 피해야겠다.
6. DRI : 누가 할 것인가?
목표를 달성하기 위해 해야 할 일의 목록과 그중에서도 먼저 수행할 일들이 정해지면, 그다음은 이를 누가 담당하여 진행할 것인가? 에 대한 질문이 남는다. 모든 실험에 기획과 설계가 필요하다고 해서 이를 모두 기획자/PM에게만 전가한다면, 팀의 효율은 전체적으로 저하된다. 왜냐하면 기획자/PM의 기획과 설계가 끝날 때까지 누구도 움직일 수 없기 때문이다.
또한 어떤 업무의 경우 굳이 기획자/PM이 아니어도 기획과 설계가 가능하거나, 또는 팀의 다른 누군가가 더욱 친숙하거나 능숙한 업무인 경우도 있다. 이런 경우 이를 굳이 기획자/PM에게 담당을 맡기기보단, 할 수 있는 사람이 담당자로써 업무를 끌고 가고, 필요에 따라 다른 이들의 도움을 요청하는 편이 훨씬 효율적이다.
또한 이는 직무, 기능에 얽매이지 않고 제품에 관한 관점-가설, KPI, 실험 방안-을 갖게 하는 장치가 되기도 하고, 구성원들이 더욱 주도적으로 업무에 참여하게 하는 장치가 되기도 한다.
세부 과제마다 DRI는 각기 다를 수 있고, 나머지 구성원이 필요에 따라 참여하여 돕는다.7. Due : 언제까지 할 수 있을까?
당연하게도 모든 업무에는 종료 시점이 있다. 이상적으로는 DRI가 전체 업무의 흐름과 월/분기/연 목표를 고려하여 자신이 이 업무를 완수할 수 있을 것으로 예상하거나 목표로 하는 일정을 제안하는 것이 좋지만, 때에 따라서는 다른 이해관계자의 요청이나 필요에 따라 탑다운으로 정해지기도 한다.
8. 스크럼 : 하기로 한 일을 목표로 하는 일정까지 진행하는 데에 장애가 되는 요소가 있는가?
애자일 하게 일하는 팀이 매일 아침 간단하게 진행하는 스크럼 scrum 미팅은, 사실은 하고 있는 일의 상황을 나열하거나 이슈를 논의하는 자리가 아니다. 정확히는 각 DRI가 자신이 담당한 일을 목표로 한 일정 Due까지 진행하는 과정에 있어서 이슈가 되는 사항을 공유하고, 이를 빠르게 공유하여 도움을 구하거나 의사결정을 요청하는 목적이다.
워터폴 조직에서는 주간 회의, 월간 회의 등의 방식을 통해 이슈를 정기적으로 보고한다. 이는 다시 말해 이슈가 있더라도 해당 회의가 있기까지는 공유할 수도 없고, 이에 따라 필요한 도움이나 의사결정을 받을 수 없다는 뜻이기도 하다.
반면 애자일 조직에서는 각 담당자 사이의 병목 현상을 없애고, 나중에 할 일을 미리 수행함으로써 효율을 증진시키고자 하기에, 매일 아침 이슈를 공유하여 필요한 도움과 의사결정을 받는다.
그러나 이는 다시 말해, 이슈가 없는 업무들에 대해 일일이 '현재 어디까지 왔다'라고 일일이 공유한다거나, 업무의 진행을 위해 논의되어야 할 사항을 일일이 펼쳐놓는 자리가 아니라는 뜻이기도 하다. 전자는 프로젝트 칸반 보드 등을 통해 모두가 평소에 확인할 수 있게 세팅해두면 되고, 후자의 경우 논의가 필요한 이들이 별도 미팅을 조율하여 논의를 하면 되기 때문이다.
9. 스프린트 : 월 단위 업무를 조금 더 잘게 나누어 밀도 있게 진행할 수는 없을까?
개인이든 조직이든 큰 방향성과 목표는 '일정 기간'을 단위로 설계한다. 가령 사람을 키우는 교육은 100년에 걸친 장기적인 계획이 필요하다(百年之大計)는 이야기는 '100년 단위'의 계획을 의미하듯이, 큰 기업은 10년 앞을 내다보고 10년, 3~5년, 1년, 분기, 월간 계획을 세운다. 개인의 경우에도 새해 계획을 세우고, 월 가계부 등을 작성하고 관리하는 것은 '1년' 단위의 계획과, '월' 단위의 계획을 의미한다.
그러나 작은 조직, 또는 빠른 움직임을 추구하는 조직에선, 월 month 단위의 업무도 상대적으로 호흡이 길게 느껴지기 마련이다. 그래서 '아이디어 제안부터 기획, 구현, 출시에 이르는 과정을 단 1주일 내에 진행한다'는 스프린트 sprint는 '가설을 검증하는 데에 이렇게 빠르게 진행해볼 수도 있어요'라는 의미로도 쓰이지만, '월 단위의 업무를 더 작은 주 week 단위로도 쪼개어서 설계하고 관리할 수 있어요'라는 의미가 되기도 한다.
그래서 보통 분기 또는 월 업무와 별개로, 구체적인 업무의 진행 단위를 2주 단위의 스프린트로 구성하는 경우도 있고, 이 호흡이 더욱 빠른 조직의 경우 1주 단위, 또는 더 나아가 '1일' 단위로 실험을 설계하고, 구현하여 배포하기도 한다.
구체적인 단위가 어찌 되었든, 이는 분기 또는 월 단위로 바라보던 업무 과정, 호흡을 더 작은 단위로 쪼개어 밀도 있고 속도감 있게 진행하기 위한 시도이다.
큰 단위를 더 작은 단위로 쪼갬으로써 관리와 파악이 용이해지고, 업무는 더욱 밀도 있고 속도감 있게 진행된다.10. 마일스톤/진척률 : 우리는 잘하고 있는가? 현재 어디쯤 와있는가?
팀이 목표를 세우고 이를 달성하기 위한 업무 목록을 만들어 담당자들이 목표 일정을 수립하여 진행했다면, 그래서 현재 팀은 어느 위치에 와있는가? 목표로 한 것과 비교하여 얼마나 잘하고 있는가?를 보기 위한 척도가 마일스톤이다.
이는 1년, 분기, 월 등의 큰 단위를 더 작은 단위로 쪼개어 목표를 수립하고 업무를 추진해나가는 개념과 유사한데, 가령 "이번 달의 목표는 000인데, 그래서 현재 1주 차인 지금 어디까지 와있는가? 그래서 다음 2주 차에는 어디까지 갈 수 있는가?"라는 식으로 더 작은 단위로 현황과 목표를 비교하고 점검해나가는 방법이다.
반대로 만약 마일스톤/진척률에 대한 확인과 설계가 없다면, 월 단위 목표의 경우 우리는 목표 달성 여부를 해당 월이 끝나고 나서야 뒤늦게 알 수 있지만, 이를 더 작은 단위인 주 week 단위로 쪼개어 마일스톤을 설계하고 진척률을 확인한다면 매주마다 현황을 확인하고 이슈를 조율해나감으로써 이슈는 미리 방지하고, 달성 여부는 더욱 일찍 확인할 수 있게 된다.
큰 단위의 업무를 작은 단위로 쪼개어 마일스톤을 설계하고 진척률을 확인하면, 이슈와 도달 가능 여부 등을 더욱 미리 파악하고 조율할 수 있게 된다.
