배경
올해 초부터 회사에서 팀 노션 사용을 장려하게 되면서 각 팀마다 프로젝트와 그에 해당하는 task를 관리하기 시작했다.
사실 내가 노션을 적극적으로 사용하기 시작한 건 6월인데, 타냐 라일리의 <개발자를 넘어 기술 리더로 가는 길>을 읽으면서이다.
스테프 엔지니어에 대한 얘기가 나오는데, 목차는 아래와 같다.
PART 1 빅 픽처 관점의 사고력
CHAPTER 1 스태프 엔지니어의 업무
CHAPTER 2 스태프 엔지니어의 세 가지 지도
CHAPTER 3 빅 픽처 관점 수립
PART 2 성공적인 프로젝트 실행력
CHAPTER 4 업무 시간 한계
CHAPTER 5 대규모 프로젝트 진행
CHAPTER 6 프로젝트 중단
PART 3 조직 차원의 레벨업
CHAPTER 7 롤모델 역할
CHAPTER 8 선한 영향력 전파
CHAPTER 9 경력 사다리 설계
챕터5 까지, 자원별 영향력(에너지, 사회 자본, 신뢰성, 스킬, 삶의 질)을 기준으로 프로젝트를 정리해서 비교해보는 예시, 그리고 RFC(Requests For Comments)에 대한 부분에 대한 얘기가 중간에 나온다.
어떤 작업이 나의 컨디션에 얼마나 영향을 미치는 지, 컨디션에 따라 내가 할 수 있는 일과 걸리는 시간이 얼마나 되는지, 그리고 각 작업이 나에게 얼마나 도움이 되는 지를 적어보는 게 회고 관점이나, 나의 앞으로의 발전에 큰 도움이 될 것 같아서 개인 노션 페이지에 회사 프로젝트 관리와 내 개인 작업을 관리해보고 싶어졌었다.
초안
프로젝트 별 문서에 넣고싶었던 항목은 아래와 같았다.
| 속성 | 설명 |
| 태그 | 팀 업무, 백엔드 업무, 데브옵스 업무, 할일 등 |
| 중요도 | ++, +, =, -, -- |
| 타겟 데이 | |
| 상태 | Not started, In progress, Done, Pause |
| 에너지 | ++, +, =, -, -- |
| 스킬 | ++, +, =, -, -- |
| 삶의 질 | ++, +, =, -, -- |
| 예상 기간 | 프로젝트를 수행하는데 걸릴 것이라고 예상한 기간 |
| 실제 기간 | 프로젝트를 수행하는데 실제로 걸린 기간 |
| RFC | 맥락, 목표, 설계, 보안, 대안적으로 고려할 만한 사항/선행 기술, 배경, 절충점, 위험 요소, 의존성, 운영 (책에서 따왔다) |
프로젝트 문서를 데이터베이스로 관리하고, rfc를 제외한 속성값을 데이터베이스 속성에 추가했다.
그리고 Project 데이터 베이스를 확인할 수 있는 곳에서 캘린더 보기를 추가해 예상기간과 실제기간을 볼 수 있도록 했다.
그리고 Project 문서 내부에 데이터베이스를 하나 더 생성해서 프로젝트에 필요한 Task를 관리하도록 했다.
Task에는 target day, 중요도, 상태, 예상기간, 실제 기간을 속성값으로 갖도록 했다.
Task 안에는 템플릿을 정하지 않고, 자유롭게 해결 과정이나 생각했던 것들을 적을 수 있도록 비워뒀다.
각 Task의 기간을 보기 위해서 아래에 캘린더로 보기(예상 기간, 실제 기간 각각)를 추가했다.
초안 - 문제점
일주일 동안 진행해보니 문제점이 생겼다.
내가 현재 해야하는 task를 한 눈에 보기가 어렵다는 것이다. 여러 개의 프로젝트의 각 테스크가 각각의 타겟 데이를 갖고있기 때문에, 우선순위가 달라지고, 가독성 좋게 빠르게 확인할 수 있어야하는데 그게 불가능 했다.
v2
노션을 거의 처음 써본 것이나 마찬가지기 때문에, 초안의 문제점을 발견하기 전에 속성값을 여기저기 눌러보고 탐색하다가 관계형이라는 속성값을 발견했다.
관계형을 잘 사용하면 초안의 문제점을 해결할 수 있을 것이라는 생각이 들었다.
관계형으로 Project와 Task를 묶도록 해서 Task를 따로 볼 수 있었다.
프로젝트 문서 안에서는 task의 project로 필터해서 보면 된다.
매번 필터를 해야하는 귀찮음은 템플릿으로 해결했다.
템플릿 편집에서 프로젝트 템플릿으로 필터를 걸면 새로운 프로젝트 노션을 만들었을 때 자동으로 해당 프로젝트로 필터해준다.
빠르게 자주 접근해야하는 Task는 아이콘을 달아서 개인 페이지에 왔을 때 한 번에 찾을 수 있도록 했다.
v2 - 문제점
며칠 간 사용해보니 또 다시 문제점이 발견됐다.
팀 노션 프로젝트로 관리하고 있는 프로젝트 템플릿이 내가 사용하고 있는 템플릿과 형태가 비슷해서 팀 프로젝트를 개인 프로젝트에 옮겨와서 나의 task를 정리하고 관리하고 있기 때문에, 팀 프로젝트 문서와 개인 프로젝트 문서에 두 번 적어야 하는 귀찮음이 있었다.
사실 팀 프로젝트를 진행한 과정이나 결정, 생각 등의 레슨런은 팀 문서에 공유돼야하는 게 맞다.
v3 & 팀 프로젝트 노션 개편
회사의 프로젝트와 관련된 것들은 회사 노션에서 관리되고 기록될 수 있도록 개인 Project는 개인적인 일들만 넣고, 회사의 프로젝트를 v2와 같이 볼 수 있도록 했다.
사실 이러려면 초안과 같이 각 프로젝트 페이지마다 테스크 데이터베이스를 생성하는 프로젝트 템플릿을 전격적으로 개편해야했다. 새로운 전체 task 데이터베이스를 만들고 기존의 task를 모두 새 데이터베이스로 옮기면서 관계형으로 프로젝트를 매핑했다.
팀원들이 사용에 불편함이 없도록 기존 템플릿이나 속성은 고수하되, 조금씩 추가하거나 변경하고 OJT를 진행했다.
v3.1 - 시간 계산
사실 여기까지의 과정에서 개인 페이지에서 프로젝트 관리와 테스크 및 일정 관리(with Google Calendar)가 테크팀 내에서 전파되었다. 내 템플릿이 공유되었는데, 이 때 진행도나 총 예상 시간을 계산할 수 있다면 좋겠다는 의견이 있어 추가할 수 있는 방법을 알아보았다.
목표
- Task 각각 예상시간 입력
- Task의 총 예상시간을 Project 속성에서 볼 수 있게 하기
- 완료된 Task의 시간과 총 예상 시간으로 진행도 계산하기
v3.1 - Task에 완료 시간 추가
Task의 예상 시간은 숫자 속성을 사용하면 됐다.
총 예상시간도 롤업 속성을 사용하니 쉬웠다.
진행도 계산이 막막했다.
그래서 꼼수를 썼다.
Task에 수식(완료 시간) 속성을 추가해서 상태가 Done으로 넘어갔을 때 예상 시간과 같은 값을 가질 수 있도록 했다.
따라서 완료 전에는 완료 시간이 0이지만
완료 상태로 넘어가면 완료 시간이 계산된다.
v3.1 - 총 완료 시간 추가 및 진행도 계산
Project에는 총 완료 시간을 롤업 속성으로 추가했다.
이제 총 예상시간과 총 완료 시간을 구했으니, 진행도를 계산할 수 있게 되었다.
수식 필드를 추가했다.
퍼센트로 볼 수 있도록 했다.
그럼 project의 진행도를 확인할 수 있다.
진행도(시간) 또한 개인 및 팀 프로젝트 노션에 추가했다.
v4 - 회사 meeting log 관리하기
회사의 프로젝트 노션에는 meeting log가 있다. 여태까지 meeting log는 초안과 다름없이 각 프로젝트의 새로운 데이터베이스로 생성되어 관리되고 있었다.
따라서 meeting log 전체를 한 눈에 볼 수 없었다. 사실 meeting log의 제목에는 날짜만 쓰고 있어서 어떤 안건인지 누가 회의에 참여했는지 전체적으로 파악도 어려웠다.
역시나 하나의 meeting log라는 데이터 베이스를 생성해서 Project를 관계형으로 추가하여 관리했다.
미팅로그를 작성하는 것까지는 좋았으나, 회사에서 회의를 진행할 때 아젠다가 없다거나, 진행자가 없어서 회의가 다른 길로 샌다거나 해서 정작 빠르게 결정하거나 깊게 논의해야할 부분은 하지 못하는 비효율이 발생해왔었다.
이번에 팀 온보딩 프로세스를 만드는 프로젝트를 담당하고, 국지적으로 노션 개편을 비공식적으로 이끌게 되면서, 동시에 회의를 열게되는 경우가 많이 있었는데 이 때를 이용해서 미리 진행자를 나로 선정하고 레퍼런스(+참고해야하는 노션 페이지), 회의 목표와 안건과 논의해야할 지점을 정리하고 회의를 진행했다.
Meeting log의 속성값에 진행자를 추가하게 됨으로써 회의 진행에 프로세스가 생기도록 했다.
또한 나눴던 논의를 편하게 검색할 수 있도록 제목에는 꼭 안건을 적도록 하는 것으로 공유하고 합의했다.
팀 노션을 개편하면서 우리 팀의 노션만 개편하는 것이 아니라, 주로 같이 프로젝트를 진행하는 기획팀의 기획서(프로젝트) 노션도 내가 책임지고 구조를 바꿀 수 있었다. 최근에 기획팀에서 진행해준 업무 가이드에서 기획서 템플릿을 위와 같이 변경하는 작업이었다.
개인 페이지에는 필터 조건을 걸어 예정되어있는 회의를 볼 수 있도록 했다.
기타
팀 노션 페이지를 아예 개편하면서 위키와 스터디를 관리할 수 있도록 데이터베이스를 만들었다.
위키
플랫폼, 태그, 상태, 작성일시, 최종편집자, 최종편집일시를 속성으로 추가했다. 태그를 통해 각 백엔드, 프론트, 데이터 위키에서 필터해서 볼 수 있도록 했다.
우리팀와 협업하는 다른 팀을 위한 위키는 팀 노션 상단에 필터해서 보기로 추가해, 쉽게 확인할 수 있도록 했다.
프로젝트를 진행하면서 그 당시의 결정사항을 남겨놔야하는 경우 위키 페이지 안에서 데이터베이스를 생성해 버저닝을 할 수 있도록 했다.
현재 사용 중인 위키는 아이콘으로 구분했다.
OJT를 통해 공유하긴 했지만, 다시 찾아볼 수 있도록 속성값에 대한 가이드를 작성했다.
스터디
팀 내에서 진행하는 스터디에 대한 아카이빙도 노션으로 할 수 있게 했다.
상태 속성으로 현재 진행 중, 예정, 완료된 스터디를 알 수 있다.
발표 자료도 데이터베이스로 관리하도록 했다. 파일을 올리거나, 녹화본 url을 올릴 수 있도록 속성을 설정했다.
Output
프로젝트의 일정과 진행 과정을 뚜렷하게 데이터로 남겨놓는 것이 얼마나 일을 진행하는 데에 개인과 팀에 효율을 불러오는 지 알 수 있었다.
백오피스 업무를 하면서 내 팀이나 다른팀과의 협업 과정에서 적어도 어떤 템플릿을 갖고 일 할 때 효율적인지 고민할 수 있게 되었고, 그만큼 문서화의 중요성을 알 수 있었다. 또한 사람들이 어떤 프로세스에서 일하고 싶어하는 지, 어떻게 소통하는 것을 선호하는지 고민해볼 수 있었다.
사람은 곧잘 망각하며 무언가로 남겨두지 않으면 결국 그 기억을 찾아가는 동안 엄청난 시간과 노력을 쏟아야 한다. 잘 정리된 문서는 불필요한 커뮤니케이션 비용을 줄일 수 있고, 잘 설계된 회의는 가장 중요하고 필요한 논의를 할 수 있도록 도와준다.