Resource Management, 효과적인 관리법
당당하게 "나 리소스 관리 잘해"라고 말할 수 있는 5가지 방법
리소스 관리 (Resource management): 프로젝트 또는 프로그램에 인력, 비용 및 기술 등 모든 자원을 계획, 스케줄링 등에 할당하는 작업이다. 본질적으로 가장 큰 조직적 가치를 달성하기 위해 자원을 할당하는 과정이며, 적절한 자원 관리를 통해 적절한 시간에, 적절한 자원을, 적절한 작업에 사용할 수 있도록 프로세스를 최적화하는 스킬을 일컫는다.
PMI (국제 프로젝트 관리연구소) 비영리단체는 PM이 '적어도 이 정도는 해야 한다'는 영역을 10가지(통합, 범위, 일정, 품질, 리소스, 의사소통 등)로 나눠놓았다.
PMBOK Guide Knowledge Areas & Process Groups (Detailed Review) (project-management-prepcast.com)회사마다 "리소스(자원)"의 정의가 다르기 때문에 "여기 리소스 매니저가 누구예요?" "PM팀은 리소스 관리 어떻게 해요?" 등 질문을 받으면 답변이 다 다를 것이다.
오늘 프로덕트 오너이자 팀장 직급의 동료분께 내가 하고 있는 리소스 매니징을 리스트업 하여 피드백을 요청했었다. 그동안 하고 있는 방법에 놓친 건 없는지 논의하고, 동시에 더 효율적인 방법은 없을까 고민하는 자리였다.
Photo by Headway on Unsplash리소스 매니징을 하는 이유는 팀원들의 업무량을 조절하기 위함이 크다. 적절히 업무를 할당해줘야 지속 가능한 속도로 일하도록 도울 수 있다. 조절하는 과정에서 팀이 어떻게 목표를 달성할지도 전반적으로 파악할 수 있다.
Asana는 리소스 관리의 범위를 아래와 같은 질문으로 정의한다.
각 리소스는 어디에 위치해 있는가?
각 프로젝트 활동의 일정(시작일, 배포일, 마감일 등)은 잘 짜여 있는가?
각 활동을 완료하기 위해 얼마나 많은 리소스가 필요한가?
해당 활동을 효과적으로 수행하는 데 가장 적합한 사람은 누구인가?
기본이지만 효과적인 리소스 관리법
팀원들이 필요한 정보가 있을 때 내게 물어봐서 눈을 불살라 여기저기 찾아주는 게 습관이 되다 보니 팀 내에 리소스(문서, 레퍼런스 사이트 등)가 어디에 흩어져 있는지 거의 알고 있다. 팀원들이 적절히 필요한 타이밍에 필요한 문서를 볼 수 있도록 도와주는 것도 PM으로서 내 역할이라 생각한다.
1) 정보 데이터 중앙 집합화
개발자, 디자이너들에게 해야 할 업무 내용을 적은 "이슈"를 발행했다고 치자. 한 프로젝트 안에는 세 부화된 수많은 이슈들이 존재한다. 예를 들어 구조가 아래와 같다.
>> 프로젝트 이름: 대시보드에 "다운로드" 버튼 넣기
이슈 1: 디자인 - "다운로드" 버튼 사이즈 규격화 > 제플린 업로드
이슈 2: 디자인 - "다운로드" 버튼 컬러 지정 > 제플린 업로드
이슈 3: 백엔드 - "다운로드" 버튼 클릭 시 PDF가 다운로드되도록 작업
이슈 4: 프런트 - "다운로드 버튼 클릭 시 확인 모달이 나오도록 작업
우리 회사는 깃랩(Gitlab)을 이용해 이슈를 발행하고 저장한다. 개발자가 기능을 배포하면 관련 이슈를 닫고 말이다. 하지만 업무용 메신저는 슬랙(Slack)을 사용하기 때문에, 깃랩에 올린 이슈에 관련한 대화를 슬랙에서 자주 한다.
이런 경우 슬랙에서 대화를 목격하면 대화 내용 링크를 따서 복사해 깃랩 이슈 내 코멘트로 붙여 넣는다. 관련 이슈에서 Bug가 발견되었거나, 고쳐졌다는 대화 또한 슬랙에서 이뤄져도 마찬가지다. 이는 이슈의 진행 상태가 트래킹(추적)되고 있다는 증거를 남기는 동시에, 이슈를 모니터링하는 모든 이해관계자가 화면을 스크롤하며 히스토리를 읽어낼 수 있도록 돕기 위함이다.
이슈를 닫을 때도 왜 닫는지를 반드시 코멘트로 간단히 작성해 남긴다. "해결되었다", "이슈가 더 이상 유효하지 않다" 등 여러 이유가 있을 수 있겠다.
즉 정보로 취급되는 모든 것을 데이터로 인식하고 관련 이슈에 집중화시키는 것이다.
2) 개발 문서, 기본 디자인 리소스 등 위치 파악
제품 가이드, 우리 회사 사람들이 쓰는 용어를 모아놓은 폴더, 템플릿 모음집, 디자인 리소스 등 회사 내 사람들이 자주 찾는 문서들을 잘 정리해뒀다가, 필요할 때 꺼내 준다. 다 모른다면 위치를 아는 관계자라도 파악해놓는다.
처음 회사에 입사한 사람들에게 필요한 정보가 DM으로 가게끔 슬랙 내에 "입사 안내 가이드"를 채널 목적에 따라 저장시키는 작업도 했었다. 그래서 굳이 PM팀이 말해주지 않아도 신입 입사자들이 DM으로 어떤 문서를 온보딩 용으로 읽어야 하고, 어떤 교육을 누구에게 부탁해야 하는지 알아야 하게끔 말이다.
https://slack.com/intl/ko-kr/help/articles/4412443174547-신입-팀원-환영하기리소스를 적절한 타이밍에 주고 또 어디에 위치해 있는지 아는 게 중요하다. 그래야 다수가 헤매는 상황에서는 모두에게 하나의 참고 문서를 줌으로써 지나친 혼란을 통제할 수 있다.
3) 이해관계자 (Stakeholders) 파악
우리 대시보드 제품의, 필터링 부분에서 캘린더 기능, 어떤 개발자가 개발한 걸까?
우리 대시보드 제품의, "다운로드" 버튼 기능 오작동, 누구에게 보고하지?
우리 대시보드 제품의, 그래프 세팅 기능, 공부하고 싶은데 관련 문서가 있나?
우리 대시보드 제품의, 필터링 기능을 백엔드 쪽에서 리팩터링 했는데, 날 도와줄 프런트 개발자가 누굴까?
... 등의 질문을 받을 때가 있다. 슬랙 대화들을 잘 읽어, 정리하고, 표로 만들어 기억하는데 시간을 좀 더 투자하면 쉽게 이해관계자를 찾을 수 있다. 아니면 슬랙 검색창에 키워드로 검색해 대화를 주로 나눴던 이들을 찾아보거나 (예. 필터링+캘린더, 그래프+유저 가이드), 깃랩(Gitlab)에 올라가 있는 과거 관련 이슈들을 찾아내 히스토리를 트래킹 하는 방법도 있다.
프로젝트 일정을 챙기다 보면 어떤 개발자가 곧 일을 끝내고 무슨 리소스를 찾을지 보인다. 업무 다음에 필요한 문서나, 도와줄 프론트 혹은 백엔드 팀원을 할당해달라고 요청하기도 한다. 몇 분 안에 빠르게 결정해드리려면 미리 예측하고, 특히 마감일이 정해진 프로젝트라면 더 챙겨야 한다.
예시. 아주 큰 프로젝트의 예시이다또 프로젝트 진행상황을 알아야 하는 사람들을 파악해 적절한 타이밍에 업데이트해주는 것도 중요하다. 예를 들어 특정 기능 배포를 기다리고 있는 마케터들이 있다면, 그들이 기다리는 이유는 아마 사용자들에게 이야기를 해놔서였을 것이다. 유저들에게 잘 업데이트하라고, 프로젝트 변동 사항이 있을 때마다 혹은 배포 후 버그가 발견되었다면, 마케터들에게 공유해준다.
프로젝트의 이해관계자들의 중요도를 파악하는 표4) 툴 위에서의 시각화
개발팀 내에서 쓰는 툴(Gitlab, Jira 등 당신의 회사에서 쓰는 것)에서 프로덕트 로드맵을 만드는 것이 가능할 것이다. 나 또한 프로덕트 로드맵에 진행되는 프로젝트들을 다 모아놓고 마감일을 수시 업데이트한다. 각 프로젝트를 클릭하면 누가 담당자고, 진행상태가 뭐고, 어떤 목적인지 등 필요한 정보가 한눈에 보이도록 해놨다. 로드맵은 외부/내부 공유용으로 아무나 들어와 우리 팀이 하는 일을 보도록 하기 위함이다.
또 팀원들이 하는 일을 수시로 "이슈"로 깃랩에 올려 놈으로서 그들의 업무량을 체크하기도 한다. 다른 이슈를 드려도 될지 고민될 때 바로 가서 볼 수 있는 유용한 작업이다.
여기서 Naoma는 네 개의 이슈를 하고 있다. 프로젝트를 측정하는 다양한 기능이 어느 툴에나 있다. 툴을 공부하면 팀의 효율성을 수학적으로 계산할 수 있는 등 더 많은 정보 데이터를 뽑아낼 수 있다. 규모가 크다면 Jira, 처음 툴에 입성하는 주니어 PM이라면 Asana를 추천한다. 깃랩도 훌륭하지만, 마크다운 형식도 배워야 하고, 코드를 알아야 구현할 수 있는 기능이 많아 어려울 수 있다 (지극히 주관적인 견해니 참고만 부탁한다). 개발자 팀원들과 상의하여 툴의 기능을 파악하는 것도 좋은 방법이다.
5) 우선순위 조정
프로젝트나 이슈의 우선순위 조정은 PM 팀 전체에서, 나와 팀장이 같이 확인해야 한다. CTO도 개입할 수 있다. 우리 쪽에서 뭐가 급한지 선택하고, 개발적으로 뭐가 가능할지 조정하고, 비즈니스 목표와 프로젝트가 부합하는지 확인해야 한다. 이후 팀원들에게 일을 할당해 줄 때 어떻게 큰 그림을 그려 프로젝트의 중요도를 전달할까 고민하기도 해야 하고 말이다.
우선순위는 수시로 바뀌지만 전체적인 흐름은 깨지 말아야 하니 중요한 프로젝트들은 그룹핑하여 변동이 없도록 한다. 개발이 쉬운 이슈는 덜 급한 프로젝트들은 따로 뺀다. 개발자 분들이 병행할 수 있는 수준으로 판단되니 그 레벨에서의 우선순위 조정은 개발자 분들이 정하시도록 한다.
우선순위가 조정돼야 어떤 리소스가 더 중요해질지, 혹은 새로 만들어져야 할지 파악 가능하다. 이 5번이 되지 않으면 위의 1, 2, 3, 4번은 부수적으로 작용할 수밖에 없다. 팀의 전체적인 우선순위 (큰 그림)은 반드시 상사, 혹은 높은 직급의 팀원들에게 확인받아야 한다.
프로젝트 관리자. 애자일을 전문으로 합니다. 아프리카 지역학 전공하고 우연히 IT 회사로 들어가 주니어 PM으로 활동하고 있어요. 홍대 살고 종로에서 일해요.
- 만화 연재: pm_life_24(인스타그램)
- 블로그: babylion.eun(인스타그램)
