일을 하면서 ‘혼자 일하고 싶다’ 라는 생각을 한번도 해보지 않은 분들은 아마 없을 것이라 생각합니다. 이런 마음은 협업에서 오는 시너지를 체감하지 못할 때 불쑥 튀어나오는데요.

저희가 속해있는 세일즈서비스팀에서는 이왕 함께 일하는 거, ‘혼자 일하고 싶다’ 보다는 ‘함께 일해서 다행이다’는 마음이 들 수 있도록 최고의 팀웍을 기반으로 협업하기 위한 다양한 시도를 전개하고 있습니다.


세일즈서비스팀은 사장님의 배달의민족 입점계약을 승인하는 시스템을 다루는 팀입니다. 그렇기 때문에 복잡한 입점 구조나 승인 프로세스에 대한 이해 그리고 히스토리 파악이 매우 중요한 도메인인데요.

그에 비해 최근 2년 이내에 입사한 신규입사자의 비율이 절대적으로 높고, 각자 참여한 프로젝트도 달라 서로가 알고있는 지식의 규모와 축적된 히스토리가 제각각인 상황이었습니다.

그 과정에서 크고 작은 애로사항들을 발견하였고, 이를 해결하기 위해 시도한 사례들을 여러분들께 공유해볼까 합니다.

🐥 신규 입사자의 온보딩을 위한 노력들

새로운 팀에 합류한 신규입사자는 기대와 걱정이 공존하는 시기를 보내게 되는데요. 낯선 환경에 적응하는 것이 쉽지 않은 신규입사자의 성장에 큰 도움이 되었던 저희 팀의 시도는 페어로 일하기, 대화의 시간 그리고 당근 흔들기 였습니다.

1. 페어로 일하기

저희 팀 PM 파트는 신규입사자가 들어오면 효과적인 온보딩을 위해 페어로 일하는 방식을 채택하고 있습니다. 시니어 PM이 큰 방향성과 태스크들을 정리하여 가이드를 하고, 그 안에서 일정 관리, 유관부서 리뷰, 운영가이드 작성, 오픈 시나리오 작성과 같은 세부적인 경험치를 쌓을 수 있는 업무를 주니어 PM이 실행해 보는 방식이에요.
저 또한 처음 팀에 왔을 때 사장님의 계좌 정보 변경을 승인하는 프로젝트를 맡았는데, 중요한 기능을 개발하는 프로젝트였음에도 불구하고 페어로 일하면서 안정적으로 프로젝트 전체 사이클을 경험하고, 좋은 온보딩 경험을 쌓았던 기억이 있어요.

2. 대화의 시간

낯선 환경에 적응하는 과정에서 개인적인 고민들도 생기기 마련이죠. 그 부분에 대해 도움이 되었던 건 저희 팀 PM들끼리 진행하는 ‘대화의 시간’이었습니다.

이 시간에는 주니어 PM이 고민거리를 편하게 얘기하고, 그 고민에 대해 다른 PM들이 어떻게 해결할 수 있을지 같이 고민해 줍니다. 또한 각자 경험한 것을 토대로 어떻게 해결하면 좋을지 이야기 나누며 직접 실행해 볼 수 있는 액션아이템을 선정하고 있습니다.

이 과정에서 공감과 위로도 얻고, 액션아이템을 실행함으로써 고민을 해소하며 팀에 한결 더 편하게 적응해 나갈 수 있었어요.

3. 당근 흔들기

당근 흔들기는 슬랙 워크플로를 활용해 ‘현재 주어진 업무를 다루는데 어려움이 있는 상태이니 저를 도와주세요’라는 메세지를 전달하는 방법입니다.

신규입사자는 아직 적정 업무 소화량이 가늠이 어려워 여러 업무를 동시에 진행하다 우선순위가 높은 업무를 놓치는 경우가 발생할 수 있는데요. 이렇게 어려움에 빠진 신규입사자가 좀 더 편하게 도와달라고 알릴 수 있도록 당근 흔들기 워크플로가 탄생하게 되었습니다.

당근 흔들기 워크플로가 생긴 이후, 보다 캐주얼하게 도움을 요청할 수 있게 되어 신규입사자도 우선순위 높은 업무에 집중할 수 있게 되었어요.

📝 서로에게 튜터(tutor)가 되어주는 법

세일즈서비스팀에서 노력했던 또 한 가지는 ‘서로의 이해도 맞추기’ 입니다.

어느 조직이나 겪는 문제지만 저희 또한 모두 입사 시기도 다르고 각자의 프로젝트를 맡아 일하는 과정에서 시스템에 대한 지식이나 히스토리 이해의 차이가 생기면서 어려움을 겪곤 했어요.

물론 100번의 질문에도 100번 다 친절하게 대답해주는 팀원들이 있는 곳이지만요.

이러한 어려움에 공감하고, 모두가 비슷한 수준의 도메인 이해도를 바탕으로 일할 수 있도록 시도한 것이 바로 이벤트 스토밍과 품앗이 설명회였습니다.

1. 이벤트 스토밍

이벤트 스토밍이란 Event와 BrainStorming의 합성어로, 시스템에서 발생하는 이벤트에 대한 각자의 지식을 공유하며 주요 프로세스에 대해 팀원 모두가 힘을 합쳐 도식화 해보는 워크샵이에요.
예를 들면 저희 팀은 IMR(Information Management Request) 이라는 계약 승인 시스템을 운영하고 있는데요. 이 승인 프로세스의 모든 과정을 각자 포스트잇에 적어 붙이는 것입니다.

이 단계에서는 어떤 인풋이 필요하고, 어떤 Api를 호출하고, 어떤 정보를 업데이트 하고, 타팀의 어떤 시스템과 연동되며, 최종적으로 어떤 결과물이 나오는지 서로가 아는 지식을 총동원해서 완성해보는 것이죠.

몸을 움직이며 함께 완성하는 과정에서 재미도 느끼고, 시스템의 전체 구조를 실체적으로 가시화할 수 있어 업무적으로도 유용했기에 팀원들의 만족도가 높았던 워크샵이었습니다.

2. 품앗이 설명회

이름 그대로 팀 안에서 지식을 품앗이 하는 행사로, 각자가 자신있는 부분에 대해 팀원들에게 캐주얼하게 프레젠테이션을 하는 자리에요.(벌써 8회차!)

방대한 히스토리나 인과관계로 인해 문서만으로는 이해가 어렵거나, 특수성이 있어 담당자의 설명이 필요한 기능들이 품앗이 설명회의 소재가 됩니다.

저희 팀은 PM과 개발이 한 팀에서 일하고 있기 때문에 PM은 정책적인 부분을, 개발자는 기술적인 부분을 설명하는 자리를 만들어 서로의 부족한 부분을 보완하는 기회로 삼고 있습니다.

사전에 어떤 내용에 대한 설명을 듣고 싶은지 투표를 하고, 그 내용에 대해 가장 자신있는 팀원이 프레젠테이션을 준비하는 방식으로 진행되는 설명회는 특히 신규입사자나 프로젝트 참여기회가 적었던 팀원들에게 좋은 피드백을 받았어요.

누구나 새 조직에 들어가게 되면 ‘나만 모르는거 아닐까?’ ‘어디서부터 질문해야하지?’ 같은 속앓이를 한 번쯤은 해보았을텐데요.

이런 어려움은 시간이 해결해준다는 것이 만고불변의 진리이긴 하지만 저희는 그 시간을 좀 더 단축하고, 기왕이면 덜 힘들 수 있는 방법을 찾고 싶었어요.

그리고 그 방법이 바로 ‘서로에게 튜터가 되어주는 것‘이었습니다. 지식을 나누는 과정에서 느끼는 뿌듯함이나, 나의 능력치 상승도 보상으로 따라오고요.

👩🏻‍🚒 우리 모두가 멋진 소방관이 되기 위해

프로덕트를 운영하는데 있어 빼 놓을 수 없는 큰 역할 중 하나가 ‘사고를 잘 수습하는 것’이지요.
프로덕트가 늘 이슈없이 완벽하게 잘 돌아간다면 너무나도 행복하겠지만, 프로덕트 또한 사람이 만드는 것이기에 예상치 못한 크고 작은 이슈는 늘 존재할 수 있습니다.
저희가 속해있는 세일즈서비스팀도 이슈를 해결하는 과정에서 크고 작은 어려움을 겪으면서 업무진행방식에 개선이 필요하다고 느꼈어요.

🤔 우리팀의 기존 이슈 해결 방식

처음 팀에 입사했을 때 놀랐던 점이, 이슈가 발생하면 처리속도가 어마무시하게 빠르다는 점이었어요.
관련된 도메인을 가장 잘 아는 PM과 개발자가 열일 제치고 바로 이슈를 확인하고 이를 해결할 수 있는 방안을 찾아서 적용을 하기까지의 속도가 짧게는 수분, 길어도 대부분 당일 내에 해소가 되었습니다.
하지만 이런 방식으로 오랜시간 이슈를 해결하다보니 아쉬운 점이 발견되었어요.

문제1. 사실은 급하지 않은 이슈임에도 기존 업무가 ALL-STOP 되었어요.

이슈는 예고하고 오는 법이 없기 때문에, 기존에 계획하던 업무를 하던 와중에 불청객처럼 불쑥 들이닥치는데요. 그렇다고 모든 이슈가 열일 제치고 봐야하는 시급한 건은 아니지요.
하지만 저희는 ‘인입된 이슈는 바로 처리해 줘야 해’ 라는 강박을 갖고 모든 이슈를 빠르게 처리하려고 애썼어요. 이 때문에, 사실은 계획했던 기존 업무가 더 시급하고 중요도가 높음에도 불구하고 이슈해결을 하느라 우선순위가 밀리는 경우가 빈번하게 발생했습니다.
전날 데일리 미팅때 ‘이런이런 일을 할거에요’ 라고 공유하고, 다음날 데일리 미팅에 ‘어제 이슈때문에.. 들여다보지도 못했습니다’ 라고 공유하게 되는 경우가 허다했어요.

문제2. 불 잘끄는 노련한 소방관만 점점 더 바빠졌어요.

빠르게 이슈 해결을 하려다보니 매번 도메인을 가장 잘 아는 담당자가 이슈를 해결하게 되더라고요. 신규입사자나 도메인에 대한 이해도가 부족한 담당자가 해결할 시간을 기다려 줄 수 있는 구조가 마련되어있지 않았던 것 같아요.
그러다보니 리소스 분배가 적절히 이루어지지 못해 가장 노련한 담당자만 바빠지게 되고, 그 외의 팀원들은 뒤늦게 이슈를 파악하지만 정확하게 이슈의 원인이나 해결방식을 공유받지 못하니 노하우나 지식의 격차가 점점 벌어지는 것이 느껴졌어요.

😎 변경된 이슈 해결 방식

방법1. 이슈의 성격과 긴급도, 담당자를 체계적으로 관리하기로 했어요.

먼저 슬랙의 팀 서포트채널의 워크플로를 만들어 이슈를 일원화해서 접수받고, 이슈 접수자가 1차적으로 해당 이슈의 긴급도를 선택할 수 있게 했어요. 놀랐던 것은, 생각보다 긴급하게 확인해야하는 이슈가 많지 않다는 점이었어요.

이렇게 이슈의 성격을 접수 시점부터 분류해서 받기 시작했어요.

일반적인 문의인지 오류접수인지, 오류라고 판단된다면 접수자가 생각하는 긴급도는 어느정도인지를 기재하게 하였습니다. 이후 PM이 접수된 이슈를 확인해서, 개발자가 이슈 내용을 바로 파악할 수 있도록 1차적으로 정리를 했고요!


이슈가 접수되는 즉시 지라 티켓이 자동생성되고, 담당자도 배정됩니다.

슬랙 써포트채널을 통해 이슈가 등록되면 지라 티켓이 자동생성되었기 때문에, 그 티켓에 이슈내용을 정리해두고 즉시 확인이 필요한 건 외에는 익일 데일리 시간에 이슈 리스트와 내용을 공유했어요.

티켓으로 모든 이슈를 관리할 수 있게 되니 칸반보드를 활용해 인입된 이슈 중 담당자가 배정되지 않은 건을 한눈에 확인할 수 있었고, 우선순위도 함께 기재되어있어 우선순위 순으로 이슈를 처리할 수 있게 되었어요.

방법2. 이슈 공유를 정례화하고, 이를 아카이빙하기로 했어요.

매일 데일리 미팅 전, 전일 해결했던 이슈를 간단하게 기록해두고 데일리 미팅 말미에 이슈를 해결한 담당자가 접수된 현상과 파악한 원인, 그리고 이를 해결한 방법에 대해 간략하게 공유했어요.
이로 인해 모든 팀원들이 해당 이슈를 인지할 수 있게 되었고, 지식격차를 줄일 수 있게 되었어요. 설사 당시에는 공유받은 기억이 가물하더라도 기록을 해두니 나중에 꺼내쓸 수 있는 비밀노트가 되었어요.

뿐만 아니라 반복되는 이슈들은 별도의 정리된 족보문서를 만들어 두어, 추후 유사한 이슈가 인입되었을 때 다른 담당자가 이슈를 처리하더라도 멘땅에 헤딩하지 않고 빠르게 문제를 파악하고 해결할 수 있는 순기능도 하였습니다.

신규입사자가 오면 가장 먼저 자랑하는 저희 팀의 보물같은 족보⭐️



위와 같은 이슈 처리 프로세스 개선 이후, 팀원들의 업무 만족도가 꽤 높아졌어요.

‘이슈’라는 불청객이 갑자기 난입하는 경우가 현저히 줄어들게 되어 업무 피로도가 줄어들게 되었고, 덕분에 계획한 업무에 집중할 수 있게 되었습니다.

또한 이슈를 해결하는 담당자가 적절하게 분배되고, 이슈 종료 이후 팀 구성원들에게 내용이 공유되면서 지식과 노하우의 격차가 점차 줄어들고 있습니다.

이로 인해 한명의 슈퍼맨에 의존하는 것이 아니라 세일즈서비스팀 구성원 모두가 불 잘끄는 멋진 소방관이 되어가고 있답니다

마무리하며

이렇게 여러 노력들을 해왔지만 사실 저희는 아직도 어떻게 하면 모두가 더 잘, 즐겁게 일할 수 있을지 고민하고 있습니다.

특히 2023년은 우리 팀의 일하는 방식에 대해 정말 많은 시도를 했던 한 해였는데요.

회고 때마다 팀 운영방식에 대해 점검하고, 다른 조직의 방식을 벤치마킹하기도 하고, 최근에는 업무 효율성을 높이는 방법론에 대한 책을 함께 읽는 북스터디까지 하고 있는데도 여전히 많은 고민들이 남아있어요.

‘우주의 유일한 정답은 정답이 없다는 것뿐’이라는 글귀처럼, 일하는 방식 또한 정답이 없는 것 같습니다.

빨리 명쾌하고 완벽한 결론을 찾고 싶다는 마음으로 시작했지만, 돌아보니 서로의 어려움을 공감하고 함께 성장해가는 그 과정이 중요한 것이더라고요.

그래도 이런 시도들이 모이면 언젠가 서론에 언급한 바람대로 ‘이 팀에서 함께 일해서 다행이라고 느끼는’ 목표 정도는 이룰 수 있지 않을까요?

내년에도 아마 저희는 이렇게 열심히 고민하고 시도할 것 같아요.

일을 하면서 항상 좋기만 할 수는 없겠지만 기왕이면 덜 힘들기를, 그리고 또 기왕이면 함께하는 지금이 즐겁기를 바라니까요.