TIL5. 여전히 보고가 어려운 4년차
보고의 경계를 잘 살리는 것이일 잘러의필수 조건
※ TIL 이란?
Today I Learned의 줄임말로 오늘 배운 사소한 그 어떤 것이든 기록해보는 시간을 의미합니다.
잘한 점 - 내부 솔루션 개발 시 주의 점
나는 2년째 고객센터 콜 통합 통계 시스템을 기획하는 PM 업무를 맡고 있다.
고도화를 진행하기 위해 시작된 올해의 프로젝트는 요청 건만 60개에 육박한다.
외부 개발사가 다행스럽게도 여러 고객센터의 프로젝트를 맡았던 터라 현업에 대한 이해도가 크지만
3-6개월짜리 프로젝트가 진행될 때마다 늘 교체되는 인력으로 인해 A to Z까지 다시 설명해야 하는 번거로움이 있다.
솔루션을 개발할 때 가장 주의해야 할 점은 개발 요청 사항에 대한 히스토리를 관리하는 것이다.
협업 툴을 쓰지 않는 우리 회사의 분위기 상 이걸 JIRA나 노션, 슬랙에 공유할 수 없기 때문에 오로지 개발 내역은 사내 메신저와 날짜별로 기재된 메모장의 내용이 전부다.
솔루션 초기 도입 당시엔 멋도 모르고 엑셀에 적힌 요구사항이 이행 됐는지에 대한 O, X만 기재했었다. 하지만 고도화가 진행되는 올해에는 더 이상의 추가 개발 일정이 잡혀 있지 않기 때문에 나의 확언은 곧 시스템 개발의 완료와 동의어가 되어버리는 상황이다.
아이러니했던 건 사내에 다양한 솔루션이 도입되고 기획자와 CX관리자의 운명이 늘 그렇듯 상담 어드민 개발이 연속되지만 어느 누구 하나 간트차트 하나, 프로젝트 파일 하나 만드는 사람이 없었다는 점이다.
그럼에도 일을 잘하고 있는 선배들이 그저 놀라울 따름이었다.
어쨌든 선배들도 관리하지 않는 프로젝트 파일이길래 그냥 간단한 개발 건들은 이전처럼 그냥 확인만 하고 넘어갈까도 싶었다. 하지만 뭔가 뒤숭숭했다.
고객센터에 있는 현업자들은 요구사항은 많지만 이러한 모든 개발 요청사항과 히스토리를 챙길 만큼 환경적으로 꼼꼼할 수 없다. 누군가 챙겨야 한다면 그건 CX 기획자의 몫일 것임을 알기에, 이틀간의 작업을 거쳐 프로젝트 관리 파일을 만들었다. 자잘한 개발 업데이트 사항까지 적어보니 초기에 요청한 23개의 개발 요청 건은 어느새 50가지로 늘어나 있었다. 그리고 요청사항에 없던 것들이 어느새 개발자가 잘못 이해해 개발이 진행되고 있던 것도 파악할 수 있었다.
나의 귀차니즘이 내일의 사용자 경험 실패로 이어질 수 있음을 체감한 날이다.
못한 점 - 보고의 경계를 잘 세우자
보고의 범위를 잘 설계하자.
입사이래 이렇게 팀장님께 혼난 건 처음이다. 상황은 그랬다.
콜센터 품질지수 인증제도인 KSQI 팀에서 연락이 왔다. 네이버 공식 블로그를 개설하였으니 홍보용 사진 몇 장을 골라 보내달라는 내용이었다. 이미 업로드가 된 다른 회사의 레퍼런스를 보니 사내 언론 홍보 동정만 캡처해서 덕지덕지 붙여놓았다. 나 또한 이것에 큰 리소스를 투입하고 싶지 않아 신입 사원에게 요청하여 사내에서 찍었던 홍보 사진 2개를 추려 팀장님께 보고만 받아달라고 했다. 근데 그게 화근이었다.
팀장님 입장에선 중간관리자 협의 없이 사진만 골라 달라는 신입사원의 요청을 받고 '중간 관리자들이 일하기 싫어 팀장에게 일을 전가시키나?'라는 생각을 하게 된 것이었다. 거기에 기름을 부은 것은, 타사의 성의 없는 사진을 기준 삼아 우리 회사도 그런 식의 사진을 업로드하는 것이 맞는 것이냐며 성의 없는 나의 생각을 철저하게 비판하셨다.
이때 아차 싶었다. 아무리 아무도 검색하지 않고 보지도 않을 블로그지만, 1명의 고객이라도 어떤 유입 경로를 통해 우리 회사의 이름이 걸린 콘텐츠를 봤을 때 무성의한 콘텐츠를 본다면 한 번이라도 기업을 알릴 기회를 스스로 잃어버릴 수 있는 것이었다. 팀장님은 그 단계까지 생각하고 계셨던 것이다.
비대면 보고로 보고하며 설명이 부족했던 것도 문제였지만 회사 타이틀을 달고 나가는 콘텐츠에 사소한 주제라도 신경 쓰시는 평소 팀장님의 성향을 알고 있었음에도.. 디테일이 부족했다.
누가 보겠냐는 안일한 생각이 방심하게 만들었고, 팀장님께 보고를 드릴 땐 늘 최종 확정안에 대한 결정 여부만 논의하자는 걸 체감했다.
