회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
AWS 이용 중이라면 월 최대 15% 할인받으세요
기획자 판에는 이런 말이 있습니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
회원가입을 하면
성장에 도움이 되는 콘텐츠를
스크랩할 수 있어요!
확인
기획자 판에는 이런 말이 있습니다.
“기획자는 외로운 직무야. 원래 혼자 크는 것이지. 바닥에서 직접 굴러가며 말이야.”
하지만 저는 이 말을 좋아하지 않습니다. 모든 직무가 신입과 경력을 막론하고 스스로 짊어져야 할 배움의 무게가 있습니다. 기획 직무는 그 무게가 큰 것도 사실입니다. 하지만 비즈니스 도메인의 특수성은 물론 제품의 레거시까지 파악해야 하는 기획자에게 이를 그저 혼자 배워야 할 것이라 치부할 수 있을까요? 그 무게가 지나치게 커 보입니다.
신입, 그리고 경력직 신입들의 성장을 그저 개인의 몫으로 치부할 경우 발생하는 문제는 오롯이 또 다른 기획자들에게 배가됩니다. 신입 기획자는 빠르게 업무에 적응한다면 문제를 풀어나가기 위한 새로운 아이디어의 출처가 되기도 합니다. 또, 프로젝트를 진행하는 원동력이자 한 명의 전문가로 자라기도 하죠. 그런 점에서 이는 관리자 본인의 역량 또한 동반 상승하는 효과를 가져다줍니다.
그래서 오늘은 좋은 기획자 사수가 되기 위해서는 어떤 조건들이 필요할지 이야기해 보고자 합니다. 새로운 기업과 팀에 배치될 때마다 신입으로 힘들었던 점을 상기하는 동시에 좋은 사수가 되기 위해 노력해 온 제 고민을 눅진히 적어보겠습니다.
여기 2명의 관리자 A, B가 있습니다. 둘은 모두 같은 회사에서 일하고 있고, 서비스 기획에서 특정 영역을 총괄하는 보직입니다. 이 관리자들이 팀/파트와 프로젝트를 관리하는 방식은 다음과 같습니다.
관리자 A
- 신규 업무 배정 시, 팀원 자율에 따라 하고 싶은 업무 모듈을 배정 (PO 등 파트장 논의는 선호도 투표 이후 진행)
- 기획자들의 업무 권한을 최대한 존중하며 의사결정의 주도권 역시 모듈 담당 기획자들에게 부여
- C레벨 커뮤니케이션 역시, 본인이 모든 내용을 총괄해 보고하는 것이 아닌 모듈 담당자와 동석. 담당 기획자가 직접 보고하도록 함
- 유관부서 간의 문제가 생길 경우, 위험 정도가 높은 건이라면 직접 나서서 문제를 해결하지만, 그 수위가 얕음. 이 또한 담당 기획자의 판단을 기반으로 결정
- 3개월 단위 회고 미팅을 진행. 그 외 일감에 대한 진척 현황은 모두 프로젝트 관리 툴 내에서 확인. 개별 현황에 대해 건건이 질문하는 방식으로 모든 백로그를 관리
관리자 B
- 매년 모듈을 바꾸며 업무를 배치하거나 다양한 모듈을 경험하도록 기획자들을 배정
- ‘특정 모듈 = 특정 담당자’라는 공식을 사내에서 만들어 내도록 함
1) 사내 인트라넷/협업 툴 게시판을 활용해 전사 직원 대상 질의응답 게시판을 생성
2) 연초마다 담당 모듈에 관한 스터디를 진행하고 해당 스터디에 참관할 직원을 모집 - 특정 문제가 발생한 경우, 담당 기획자가 어디까지 해결했는지 질의한 다음, 부족한 부분에 즉시 피드백을 제공. 동시에 해당 문제를 해결하기 위해 팀장이 직접 유관부서 협의 등 이슈에 적극적으로 개입
- 월 단위 회고 미팅을 진행하며 일감의 진척 현황을 점검. 그와 함께 기획자로서 겪는 어려움, 특정 프로젝트에서 발생한 특이점, 프로젝트 소통 과정의 어려움 등을 면밀히 체크
여러분은 어떤 관리자를 더 선호하시나요? 개인의 업무 자율권을 인정해 주는 관리자 A, 적극적인 문제 해결과 함께 방향성을 제시해 주는 관리자 B.
저 역시 2011년부터 인턴을 포함해 크고 작은 기업에서 일하며 서로 각기 다른 성향을 가진 9명의 리더와 15명이 넘는 관리자를 만났습니다. 그렇게 내린 결론은 이렇습니다. 적어도 신입 기획자에게는 관리자 B와 같은 분이 필요하다는 것이죠. 문제는 실제 그런 관리자가 몇 없다는 것입니다. 그렇다면 어떻게 해야 좋은 사수/관리자가 될 수 있을까요?
현업에 배치된 신입/경력직 신입을 대상으로 소위 ‘업무 인수인계’를 한다고 하면 대개 아래와 같이 이뤄집니다.
우선 레거시 파악을 목적으로 사내 정책/기획 및 개발 히스토리를 담은 협업 툴(컨플루언스, 노션 등) 링크가 몇 개 나갑니다. 곧이어 동료 선배가 슬랙 또는 팀즈의 몇 가지 채팅/채널에 초대해 핵심 내용을 모두 확인하라는 조언을 하죠. 여기에 더해 주요 프로젝트별 기획 산출물 파일과 피그마 링크 몇 가지가 전달됩니다.
문제는 “도대체 이 기획안과 정책 히스토리가 우리 제품 내에서 어떤 영역을 차지하는 부분이고, 다른 모듈과의 관계는 어떻게 되는 것인지” 모른다는 것입니다. 그에 대한 안내는 일체 빠져 있죠.
수험생 시절, 1등급 학생들의 비법을 묻는 콘텐츠를 보면 ‘단권화’라는 단어를 쉽게 접할 수 있었습니다. 여러 출처에 흩어져 있는 지식을 한 권의 책이나 노트에 요약하는 공부 방법이죠. 이 전략은 신규 업무를 배울 때에도 필요합니다.
그래서 아래와 같은 항목을 정리한 ‘단권화 노트', 즉 비법 노트를 만들어 전달할 수 있습니다.
레거시 | 모듈별 관계 | 기획 산출물 | 지표 | 커뮤니케이션 |
우선 제품의 레거시를 파악할 수 있는 내부 정책 문서로 시작합니다. 다음으로는 새로 맡을 업무의 특성과 프로세스는 어떻게 이뤄지는지를 정리해 줘야 합니다.
이 단계가 끝나면 다른 모듈과 관계를 포함하여 주로 협업하는 부서와는 무엇을 주제로 소통하는지, 주로 작성하는 기획 산출물의 예시로는 어떤 것들이 있는지, 결국 우리 팀이 집중해야 하는 지표는 무엇이며 이 중 내가 기여할 수 있는 부분은 무엇인지 알려줄 수 있습니다.
마지막으로 업무 유형별 보고 체계와 소통 방식 가운데 어떤 방법이 최적인지 먼저 제안하면 신입 기획자가 빠르게 산출물에 접근할 수 있을 것입니다.
일 잘하는 직장인이 되려면 업무 용어 숙지는 기본 중의 기본입니다. 문제는 사수/관리자 입장에서는 어떤 용어를 신규 입사자가 모를지 그 개념조차 없다는 것입니다. 신규 입사자는 사수/관리자가 쏟아내는 수많은 단어에 휩쓸려 단어의 개념조차 모른 채 업무나 미팅에 떠밀리는 경우가 더러 있습니다.
이런 사태를 피하려면 사수/관리자들이 자신이 사용하는 개념을 점검해야 합니다. 즉, 담당하는 모듈에 대한 설명을 ‘유치원생’이 들어도 (적어도 용어에 대해서는) 알 수 있을지 스스로 점검해 보는 과정이 필요합니다.
예를 들어, 최근 티몬, 위메프 사태에 따라 유통사 PG업 등록 관련 이슈를 공유한다고 가정해 보겠습니다.
아쉬운 예시 (A) | “00님, 티메프 사태로 오는 9월부터 일반 유통사들도 PG로 등록해야 할 수 있다는 기사가 나왔더라구요. 페이 시스템을 이용하는 상당수 유통 업체에 이런 내용이 적용될 텐데 법적으로 어떤 문제가 있는지 확인해 보고 기획 단위에서 논의할 것들 생각해 봐주세요” |
더 나은 예시 (B) | 1. 신입 업무 담당자에게 업무 전달 전 - 온라인/오프라인의 결제 구조를 이미 이해하고 있을까?
|
누군가는 B와 같은 방식이면, 소통 시간이 길어진다고 할지도 모릅니다. 회사가 유치원도 아니고 어디까지 챙겨줘야 하는지 비판할 수도 있죠.
하지만 위 사례에서 생소할 수 있는 개념은 단 2가지입니다. A와 B의 차이점이라고는 전달하려는 내용과 연관된 개념을 신입이 사전에 숙지하고 있을까, 라는 질문을 스스로 던진 것뿐이죠. 모든 업무에 레퍼런스를 달아줄 수는 없습니다. 그래도 사수/관리자 차원에서 최대한 신규 업무 담당자가 큰 틀에서 해당 내용을 파악하고 개념을 숙지할 기회는 제공해야 합니다.
방식은 저마다 다르겠지만, 회고는 기업 내부에서 고객의 평가와 요구를 수용하기 위해 더 나은 방법이 무엇인지 팀원들과 함께 찾아가는 과정입니다. 따라서 애자일과 워터폴을 막론하고 가장 중요한 과정이지 않을까 싶습니다.
회고 전후로 사수/관리자는 지라 등 프로젝트 관리 툴에 작성된 일감(백로그)들의 진척도를 체크합니다. 이어 개발 기간 내에 수행하지 못한 일감을 따로 분류하며 우선순위를 재조정하고 팀원의 역량을 기반으로 일감을 재분배하죠.
이때 신규 담당자를 고려하면, 회고 과정에서 그들이 겪었을 업무에 대한 ‘감정’에 조금 더 비중을 둘 수 있습니다. 아래와 같은 방법으로 말이죠.
신입 기획자를 고려한 회고 방법
- 단순한 업무 질문만 던지기보다 팀원 모두 프로젝트를 포함하여 서로에게 궁금한 사항을 질문하도록 유도하기: 팀원들에 대한 이해도를 높이고, 나아가 팀워크를 견고히 하는 것
- 회차별 회고 내용을 요약하고 이를 게시하기: 회고로 ‘우리’ 프로젝트가 어떻게 진행되고 있는지 신규 업무 담당자를 포함한 팀원 모두가 스스로 돌아볼 기회를 제공. 동시에 예상한 만큼 진척되지 않는 이유와 그 과정에서 힘들었던 문제를 논의한 것도 게시하며 기획자로서 소프트 스킬도 함께 성장하고 있다는 모습을 느끼도록 유도
- 할당받은 업무의 양과 성과 체크하기: 팀원들과 함께 현재 할당 받은 일감이 너무 버겁거나 적지는 않은지, 양은 적당하지만 유의미한 성과가 없다고 느끼지는 않는지 함께 체크. 업무적 효능감을 서로가 높일 수 있는 방안에 대해서 함께 고민해 보기
지극히 개인적인 입장으로 썼지만, “필연적으로 외로울 수밖에 없는 서비스 기획 직군의 사람들이 조금은 덜 외로워질 방법은 없을까?”라는 질문으로 글을 시작했습니다. 스스로 학습해야 할 일과 짊어져야 할 책임이 많은 만큼, 서로에게 따뜻한 서비스 기획자 업계가 되기를 바라며 글을 마칩니다.
요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.