Work Breakdown Structure
WBS 2편으로 돌아왔습니다! 이번 편에서는 지난번에 쪼개어 살피며 얻은 WBS의 개념으로 조직의 WBS를 지어보는 과정을 소개하겠습니다.
지난 이야기
새로운 기능을 통해 앞선 원초적인 일정 캘린더는 한층 진화하게 되는데…!
노션에 업데이트된 기능들
노션은 강력한 툴입니다. 그중에서도 ‘데이터베이스’ 기능은 백미라고 할 수 있겠네요.
데이터베이스 기능은 그 활용도가 무궁무진합니다. 이 모든게 단순한 데이터가 나열된 표를 다양한 ‘속성’과 ‘보기’의 조화를 통해서 데이터를 사용자가 원하는 대로 보여주고자 하는것을 나타냄이 가능한 것입니다.
그리고 데이터간의 관계를 표현함으로써 화룡점정이 되는것이지요.
어떠한 데이터의 하위 항목으로 배치해 정리하거나 선∙후행관계를 종속성으로 표현하는 기능을 통해서 WBS의 작업과 프로젝트간의 종속성도 노션의 데이터베이스로 나타낼 수 있게 되었습니다. 기능 추가가 다소 늦은감이 있지만 아무렴 어떤가요?
우리가 여지껏 해온 작업을 모아 프로젝트들을 정리하기 시작했습니다.
마침내 완성된…
그동안 남겨온 발자취를 모두 모아 정리하고 현재 진행중인 프로젝트도 새로운 양식에 맞게 수정이 얼추 완료되었습니다.
직접 만들어 본 WBS의 계층 구조는 다음과 같습니다.
이제 우리만의 WBS를 효율적으로 잘 활용해 뛰어난 효율의 업무를 해볼…
진도가 너무 빠릅니다 선생님!
1편의 원고를 작성한 지난 5월 이후, 6월 1일(한국 시간 기준)을 맞이하면서 중요한 업데이트가 한번 더 있었습니다.
Notion 2.30: 프로젝트 관리
링크를 클릭하면 노션 업데이트 문서로 이동합니다.
역시 원조집이 맛집인가 봅니다.
노션이 2.30 버전으로 업데이트 되면서 공식으로 제공하는 템플릿에 WBS가 공식적으로 추가되었습니다. 프로젝트 관리에 필요한 A to Z가 모두 담긴 템플릿이 탄생하고야 만 것입니다.
덕분에 본래 계획했던 2부의 방향을 급하게 선회하게 되었죠. 다른 여러 기능도 추가되었지만 주 기능에 집중하여 이 템플릿을 살펴보고 이용해보는 시간을 준비했습니다.
작동 원리
이 템플릿에서 ‘프로젝트’와 ‘작업’은 각기 다른 데이터베이스로 분리되어 있습니다.
그리고 관계형 데이터베이스 속성을 통해 서로가 연결이 되어있는 구조입니다. (관계형 데이터베이스에 대한 심도있는 이야기는 나중에 기회가 되면 다루고자 합니다.)
이런 연결으로 사용성이 더 좋아지는 효과를 낳았습니다. 프로젝트는 프로젝트대로, 작업은 작업대로 모아 관리하면서 양쪽 데이터베이스의 연계가 자동적으로 원활하게 이루어져 프로젝트 관리가 쉬워졌습니다.
데이터베이스간에 관계가 맺어지니 작업자는 자신이 분배받은 작업만, 프로젝트 오너는 자신이 담당한 프로젝트를 한눈에 볼 수 있게 되어 처음 만들었던 WBS에 대해 많은 멤버들이 제기한 문제인 ‘열람하기 번거롭다!’가 개선되었습니다.
핵심 골칫덩이를 해결해 준다면 안쓸 이유가 없죠! 바로 쓸 수 있게 준비해봅시다.
우리 조직에 맞게 고치기
우리만의 특징을 반영할 수 있게 템플릿을 고치는 작업에 들어가야 합니다.
잠깐! 고치기 이전에 해야 할 일이 있네요. 그건 바로 …
프로젝트 운영 구조 정립하기
사실 WBS 템플릿은 프로젝트의 운영 상태를 시각적으로 보여줄 뿐입니다.
본질적으로는 프로젝트를 어떤 방식으로 운영 하는지에 대한 개념과 구조를 정립하는 것이 중요한 부분이죠.
팀마다 작업 방식이 달라서 프로젝트를 운영하는 방법도 다 달랐습니다.
무엇보다 우리는 멤버들이 여러 팀에 걸쳐 있기 때문에 리드들이 각 멤버의 일정을 파악할 필요가 있으며 멤버들은 여러 WBS를 이용해야 하기 때문에 운영구조를 최대한 제네릭하게, 어떤 팀이든 사용 가능하게 다시 정립했습니다.
요구사항 캐치
팀 마다 프로젝트를 운영하는 방법이 다르더라도 프로젝트라는 큰 틀에서 벗어나지 않습니다.
그래서 반드시 기록해야 할 필수 항목들을 정리했습니다. 모든 기록물은 가급적 육하원칙을 따르는게 좋습니다.
・ 프로젝트의 이름 (및 정보) – 무엇을
・ 프로젝트의 관리 주체 (인원) – 누가
・ 프로젝트의 일정 – 언제
・ 프로젝트의 상세 내용 – 어디서, 어떻게, 왜
이걸 바탕으로 이 항목들을 자세히 나타낼 속성을 만듭니다.
프로젝트 이름
프로젝트를 지칭하는 명칭입니다. 반드시 있어야 합니다. 실제 프로젝트에서 ‘무제-1’ 같은 이름은 곤란하니까요.
프로젝트 이름은 가급적 중복되지 않아야 합니다. 어떤 프로젝트인지 한눈에 알아볼 수 있는게 좋은 프로젝트 이름이기 때문이죠.
명확하게 식별할 수 있으면 먼 나중에 프로젝트가 끝나고 나서, 이 프로젝트 때 있었던 경험과 그것으로 얻은 교훈과 기록를 다시금 찾고자 할 때 소문의 ‘그때 그 프로젝트’가 뭔지 뒤져보는 수고스러움을 방지할 수 있게 됩니다.
이를 위해 작명 지침도 만들었습니다.
프로젝트의 관리 주체
이 원대한 계획의 주인공이 누구냐도 중요할 것입니다.
우리는 내부적으로 정의하고 그에 따라서 이 항목을 여러개로 나눴습니다.
- 팀 : 어떤 팀이 소유한 프로젝트인지 알아야 할 필요가 있었습니다.
- 프로덕트 : 다양한 일을 하는 회사인 만큼 팀들은 프로덕트를 가지고 있고 그 프로덕트는 저마다 특정한 작업 절차가 있습니다. 어떤 팀의 어떤 절차를 따르는 프로젝트인지 표시하는 속성입니다.
- P.O : 프로젝트의 주된 소유자입니다. 실무 차원에서 작업의 진행을 관리하여 프로젝트 수행을 제어하는 역할이라고 정의 내렸습니다.
- 참여 작업자 : 프로젝트의 하위 작업에 참여하는 작업자들 입니다.
- 디렉터 : 프로젝트의 총책임자입니다. 프로젝트를 기획하고 업무를 배당하며 전체적으로 관리하는 존재입니다. 프로젝트의 생성자가 디렉터가 되는데, 책임이 큰 만큼 일의 시작하기 위해 본인이 직접 첫 삽을 뜨라는 의미를 담았습니다. (물론 실용성이 없다 판단된다면 일반적으로 등록할 수 있게 변경할 수 있습니다.)
프로젝트의 일정
자고로 계획이란 일정이 큰 비중을 차지하기 마련입니다. 목표의 달성이라는 관점으로 보면 주로 무언가를 기한 내에 완수하기 위해서, 더 나아가면 어떤 일의 진행 속도를 촉진하기 위해서든, 단계별로 비중을 조절하기 위하는 등의 수단으로 일정이 사용됩니다.
그리고 경제적인 관점으로 보면 인력의 투입량을 가시화 할 수 있게 수치로 환산하는 수단이죠. 이는 비즈니스에서 아주 중요한 부분이 아닐 수 없습니다.
일정과 관련된 속성들을 다음과 같이 준비했습니다.
- 예정 기간 : 이 프로젝트의 계약 상의 진행 기간, 별도의 계약 내용이 없으면 목표로 정한 기간을 시작일과 종료일로 표시하게 됩니다.
- 최종 완료일 : 결국 목표를 달성했을 때 그 기간을 지켰는지 기록을 남길 수 있습니다.
- 중단일 : 그런데 피치 못할 사정으로 프로젝트가 멈출 수도 있겠죠. 흔한 경우는 아니지만 별도로 기록할 필요가 있는 부분입니다.
- 재개일 : 그러다가 다시 시작하게 된 날짜입니다.
- 총 업무기간 : 예정 기간의 시작 일로부터 최종 완료까지 실질적으로 업무를 진행한 일자를 계산하게 됩니다. 물론 잠깐 멈추었던 기간은 제외하고요!
그 밖의 속성과 내용들
- 상태 : 프로젝트가 어떤 상태인지 알립니다. 할 것인지, 하는 중인지, 했는지, 하지 않는지 말이죠.
- 진척도 : 템플릿에서 가장 흥미로웠던 기능입니다. 프로젝트에 소속된 하위 작업 중에서 완료된 작업의 비율을 진행도 게이지로 나타내주어 직관적으로 얼마나 진행했는지 알 수 있습니다.
( * 주의사항 – 불러오는 속도가 느리기 때문에 ‘작업’ 데이터베이스의 양이 방대해지면 고장납니다!) - 작업 : 프로젝트에 속해있는 하위 작업들을 리스트로 보여줍니다. 목표를 달성하기 위해 해야 할 일들의 일람입니다. 기본적으로 다른 속성과 달리 페이지 섹션에서 보이게 되어있습니다.
- 선행 / 후속 프로젝트 : 이 프로젝트와 연계된 다른 프로젝트를 표시합니다. 마찬가지로 페이지 섹션으로 이동 시켰습니다.
속성은 이 정도입니다. 이보다 자세한 내용은 프로젝트 문서의 내부에 작성하도록 하였습니다. 한번 살펴볼까요?
프로젝트의 내부는 팀 별로 다르게 입력할 수 있습니다만, 그래도 표준 양식이 필요했기 때문에 이또한 SG팀에서 이용하던 템플릿을 개량했습니다.
- 프로젝트 작업 리스트 보기 : 이 부분은 노션 템플릿에서 제공하는 부분입니다. ‘작업’ 데이터베이스에서 오직 이 프로젝트에 속하는 작업들만 보여줍니다. 이곳에서 작업을 추가하면 자동적으로 이 프로젝트의 하위 작업임을 가리키게 됩니다. 이미 페이지 섹션에 작업 패이지로 연결되는 리스트가 있지만 이 보기에선 더 많은 기능으로 디렉터 및 P.O가 작업을 바로 관리할 수 있는 장점이 있습니다.
- 최종 산출물 : 프로젝트를 마치면 최종적으로 나와야 하는 결과물을 일컫습니다. 클라이언트에게 전달될 물리적인 결과물 뿐만 아니라 목표를 작성해도 좋습니다.
- 프로젝트 자료실 : 프로젝트와 관련해서 모은 자료들을 수집 할 수 있는 데이터베이스를 만들었습니다. 파일을 직접 올리거나, 웹페이지의 링크를 걸거나, 피그마 파일의 링크를 걸 수 있지만 모두 마음에 들지 않는다면 페이지 안에 직접 작성할 수도 있는 일종의 게시판이라고 할까요? 그리고 외부에 공개할 수 있도록 설정된 페이지가 기본적으로 있습니다. 주로 클라이언트와의 소통시 참고자료를 전달할 때 사용될 수 있겠네요.
- 회의록 : 프로젝트를 위해 진행했던 회의를 기록하는 곳입니다. 기본적으로 제공하는 회의록 양식이 있습니다. 그리고 프로젝트를 마치고 난 뒤에 프로젝트 회고도 기록할 수 있도록 회고는 별도의 양식이 있습니다.
소개는 여기까지
입맛에 맞게 고친 WBS 시스템에 대한 소개는 이쯤에서 마칩니다.
슬슬 이번 시리즈의 제목 ‘소규모 조직에서도 WBS를 도입해야 하는 이유’에 대해 본격적으로 논해볼 차례네요.
저희의 사례는 사실 소규모 조직에는 적합하지 않을 수 있습니다. 그렇다고 저희가 소규모 조직이 아닌 것도 아닙니다. 그럼에도 불구하고 이토록 형식에 집중하는 까닭은 무엇일까요?
될 성 부른 나무는 떡잎부터 튼튼하다.
스타트업이 agile하고 lean한 방식을 지향하는 것은 당연한 일을 넘어서 정석으로 받아 들여집니다.
목적 지향적인 태도만큼 효율적인 것이 더 있을까요? 모로 가도 서울만 가면 된다는 말도 있고요.
다만, 이런 풍조가 자리 잡으면서 체계를 구성하는 것이 어딘가 죄악시 되기도 합니다.
유연한 것과 무른 것은 잘 구분해야 합니다. 목적지만 보고 달리다가 어느 시점을 지나면 필연적으로 뒤를 돌아보고 한번 정비해야 하는 때가 옵니다. 그 때 이것이 유연한 것인지 아니면 그저 물러터진 것인지 평가를 거쳐야 합니다. 이것은 우리가 조정을 가하는 과정이었습니다.
겉보기엔 불필요한 절차가 없이 신속하게 결과를 내는 것으로 보였지만 전사를 아우르는 표준 업무 관리 방법이 없었기 때문에 팀 마다 혹은 개인 마다 규칙을 만들어야만 했습니다. 중복된 업무가 반복되면서 비효율을 만들어내고 있음을 알지 못했던 겁니다.
만약에 이 상태를 인지하지 못한 채로 규모를 키워나간다면 장래에는 규모에 비례하여 나타나는 갖가지 문제에 시달리고 그 문제를 해결하기 위해 많은 역량을 소모하게 될 것입니다. 그렇게 되기 전에 미리 약간의 시간 투자를 통해 정리를 해두면 더 작은 비용으로 방지할 수 있으니 결과적으론 효율적으로 업무를 하는 셈이 되는거죠. 이런 개념을 기술 부채라고 합니다.
기술 부채(Technical debt)란?
현 상황에서 더 오래 걸리지만 좋은 방법 대신에, 문제가 있어도 당장 쉬운 방법을 선택해서 생기는 문제들을 나중에 해결하기 위해 재작업을 하면서 드는 비용을 말합니다.
소규모 조직에서 WBS를 도입해야 하는 이유가 바로 이런 데 있습니다. 끝까지 소규모로 유지를 할 수도 있지만 언젠가 규모의 성장을 계획한다면 업무, 나아가선 다른 부분에서도 미리 어느 정도의 체계화를 이루어야 합니다.
그러나 거기에 지나치게 몰두한다면 지금 쓸데없는 절차와 규칙이 생기고 모든 일에서 발목을 잡아 원활한 처리가 힘들어집니다. 또, 귀찮음을 못 이겨 기껏 만들어 놓은 체계를 자연스레 무시하면서 허튼 시간을 투자한 게 될 수도 있고요.
네, 결론은 뻔한 말이네요. 균형이 중요합니다.
맺으며
무언가 다른 이야기도 많이 풀어 놓은 듯 하네요. 핵심만 말씀드리자면 WBS는 단순히 일정표가 아니라 어느 정도 표준 업무 절차 성격을 띄는 개념이라는 것입니다.
WBS를 만들어보면서 우리 조직의 현황을 진단해보는 시간을 가져보도록 하면 좋겠습니다.
이상으로 시리즈를 마치고 다음에는 더욱 알찬 정보를 전해드릴 수 있게 노력하겠습니다!
감사합니다.
