개인적인 불만일까 해결해야할 문제일까?
팀원들과 업무 회고, 티타임을 진행하다보면 공통적인 '불만 사항'을 발견할 때가 있다. 불만 사항이 지속된다면 팀원들의 만족도는 떨어질 것이고, 만족도가 떨어진다면 적극성이 떨어지며 퇴사, 목표 달성 실패가 발생하고 이는 팀 전체에 급속도로 퍼지게 되어 긍정적인 미래를 기대하기 힘들다. 따라서 '공통적으로 발생하는 불만 사항, 반복적으로 발생하는 불만 사항'은 문제로 정의하고 해결하는 것이 좋다고 생각한다.
'나는 팀에서 어떤 역할을 할 수 있을까, 내가 팀원들에게 어떤 도움이 될 수 있을까?'
라는 질문을 스스로에게 던지곤 하는데, 소통에서 발견한 공통적이고 반복되는 문제를 해결하는 것이 내가 할 수 있는 역할이고 도움 중 하나라고 생각했다. 따라서 문제를 정의하고 솔루션을 만들고 의사결정자를 설득하여 변화를 만들어보자는 목표를 세우게 되었다.
문제안에 문제를 찾아서
'~ 때문에 너무 힘들다' 라는 말을 들어면 먼저 '왜 힘들까', '왜 그런 문제가 발생하게 될까?'를 질문하게 된다. 이를 통해서 표면적으로 들어나는 단어와 안에 숨어있는 진짜 문제를 파악하고자 노력한다
예를 들어 다음과 같다
'업무 저글링이 심해서 힘들어요'
- 업무 저글링이 있으면 왜 힘들까요?
1. 금방 처리할 수 있는 자잘한 업무 요청이 빈번하게 들어와 스위칭이 자주 발생해서 하나의 문제에 집중하기가 어려워요
2. 어떤 업무를 더 우선적으로 처리해줘야할지 혼란스러워요
3. 급하게 들어온 업무를 처리하자니 나의 일에 병목이 생기고 급하게 들어온 요청을 뒤로 미루자니 해당 팀에 병목이 생겨요
- 업무 저글링은 왜 발생할까요?
1. 업무가 큰 단위로 묶여서 들어오지 않고, 작은 단위로 자주 들어와요
2. 중간에서 업무를 관리해줄 수 있는 사람이 없어요(타부서에서 업무가 다이렉트로 요청이 와요)
3. 단순 데이터 추출 업무인데 비개발자가 접근할 수 있는 방법이 없어요 '프로젝트가 너무 산발적으로 진행되어서 어떤 목표를 가지고 있는지 모르겠어요'
- 왜 힘들까요?
1. 제가 팀에서 어떤 역할인지 모르겠어요(그냥 기계처럼 업무를 처리하는 것 같아요)
2. 왜 해야하는지 모르겠어서 동기부여가 점점 떨어져요
- 왜 그런일이 발생할까요?
1. 프로젝트가 문제를 지표로 정의하지 않고 '~기능이 있으면 효과가 있을 것이다'로 시작해서
2. 전사가 목표로 하는 지표가 불명확해서 지표로 문제 정의가 이뤄지지 않아서 이렇게 인터뷰를 진행하고 정리하고 나면 다시 문제를 정의하거나 문제의 범위를 넓히거나 좁히는 작업을 진행하게 되었다. 이를 '본질적인 문제 파악' 과정이라고 생각한다
위 내용에서 정리한 문제는 다음과 같다
1. 데이터 추출로 인한 병목과 자동화가 되어있지 않아 비효율이 발생한다.
2. 지표 기반의 의사결정이 없다.
3. 업무 관리 책임이 불분명하다. 정의한 문제에서 why 시작하기
- 데이터 추출로 인한 병목과 자동화가 되어있지 않아 비효율이 발생한다
왜 병목이 발생하는가?
- 데이터 추출 업무를 특정 인원만 진행할 수 있어서
왜 데이터 추출 업무를 특정 인원만 진행할 수 있는가?
- 비개발 인원이 데이터에 접근할 수 있는 방법이 없어서
- 원하는 데이터와 실제 DB에 있는 데이터를 연결짓기 어렵기 때문에
왜 비효율이 발생하는가?
- 일자, 특정 상수 정도만 변경하는 단순 반복적인 요청들의 빈도가 높아서
- 자동화가 되어있지 않아 수기로 작업을 진행하는 경우가 생겨서 - 지표 기반의 의사결정이 없다.
왜 지표를 확인할 수 없는가?
- 지표의 변화를 지속적으로 볼 수 있는 환경이 구축되지 않았다
- 어떤 지표를 지속적으로 봐야하는지 논의가 되지 않았다 - 업무 관리 책임이 불분명하다.
왜 불분명한가?
- 업무 관리를 누가 할 것인지 논의되지 않았다
- 이슈 레이징이 되지 않았다 솔루션 (What to do) 만들기
솔루션은 문제 정의 과정에서 why를 타고 들어간 세부적인 이유를 보면서 생각해볼 수 있다.
또한 문제는 따로 정의했지만, 문제를 해결할 수 있는 방법은 하나일 수도 있다. 예를 들어 1번과 2번은 모두 데이터 추출 및 열람 환경을 구축하여 해결할 수 있다. 이를 위해 별도의 admin 페이지를 만들거나 클라우드 환경을 이용해서 파이프 라인을 구축한 뒤 데이터 마트와 대시보드 시각화를 통해 해결하는 방법이 있다.
대시보드와 함께 아래와 같이 현재 팀이 목표로 하고 있는 주요 지표들과 하위 어떤 세부 지표들이 있고 각 프로젝트가 현재 어떤 지표를 올리기 위한 것인지 파악하기 쉽도록 tree를 만들어 공유할 수도 있다
솔루션 리스트를 작성하고 각 솔루션에 대해서 장점과 단점을 작성한 뒤 의사결정자와 논의를 진행한다.
결과물에 대한 피드백 수집과 단계적 고도화
문제를 해결하면서 배우게 된 것은 '한번에 모든 것을 해결할 수는 없다'이다. 처음부터 완벽하게 모든 것을 만들기보다 핵심적인 것을 먼저 만들어보고 사용성이 좋은지 어떤 것이 부족하고 추가되면 좋을지 피드백 수집 과정도 중요하다. 이를 기반으로 빠르게 적용해서 고쳐야할 부분인지 혹은 장기적으로 고쳐지면 좋은 부분인지를 식별하여 단계적 고도화를 진행했다.
