일정 정리하며 드는 생각 (2) 업무의 실행
이전 글에서 업무의 임팩트에 관한 생각을 적어봤다. 임팩트를 생각한 이후에는 실제로 그 임팩트를 낼 수 있는지, 낸다면 어떤 방법으로 효과적으로 또는 효율적으로 낼 수 있는지에 대해 생각한다. 즉, 업무의 실행 방법에 대해 생각한다.
업무의 실행에 대해서는 이미 시중에 정말 많은 방법론과 콘텐츠 및 아티클이 나와 있지만, 스스로의 회고와 조금이나마 이 글을 통해 도움을 받을 수 있는 누군가를 위해서 다시 한번 간략하게 적어본다. 임팩트보다는 짧을 것으로 예상되나, 막상 쓰기 시작하면 또 길어질지도 모르겠다.
간단한 업무로 큰 임팩트를 가져올 수도 있지만, 대게 큰 임팩트를 가져오는 업무는 보통 어려운 경우가 많다. 그렇기 때문에 일단 무작정 시작해보자는 생각으로 하다 보면 놓치는 부분이 많이 생기기 일수다. 따라서 업무에 들어가기 앞서 최소한의 가이드라인, 프로세스를 생각하는 게 좋다(나중에 가이드라인을 만들면서 일해야 하는 이유에 관한 글도 따로 작성해 봐야겠다).
어려운 업무는 보통 기존의 지식만 가지고는 해결하기 어렵거나, 효율적이지 않은 방법으로 해야 하는 경우가 많다. 따라서 책, 강의 등을 통해 새로운 개념을 익혀 업무에 적용하고, 또 새로운 스킬을 통해서 더 효율적으로 업무 하는 방법을 배워야 한다.
특정 업무를 하기로 한 후에는, 해당 업무가 얼마나 어려운지, 또 그 업무를 하는 데 필요한 개념이나 스킬이 무엇인지 파악해야 한다. 그 후, 내가 가진 개념과 스킬로만 해결이 가능한지 그렇지 않다면 어떤 것을 배워야 하는지 파악하는 게 꼭 필요하다. 내가 뭘 아는지, 내가 뭘 모르는지를 파악하는 가벼운 메타 인지라고 할 수 있을 것 같다.
지금 당장은 새로운 개념과 스킬을 배우는 게 힘들 수도 있지만, 이렇게 하나씩 배운 개념과 스킬이 쌓이면 나중에는 비슷한 업무를 훨씬 더 수월하게 할 수 있다. 즉, 생산성이 높아지는 것이다. 그리고 이렇게 생산성이 높아지는 경험을 하면, 더 어렵고 더 큰 임팩트를 낼 수 있는 업무에 계속해서 도전해 나갈 수 있다. 업무 바운더리가 넓어지는 것이다.
개인적으로 지금 있는 회사는 자유로운 분위기라서, 업무 시간에 강의를 듣거나 플레이북을 읽고 요약하는 데 큰 제약이 없다. 따라서 필요할 경우에는 하루 이틀 동안 강의를 몰아 듣고, 해당 개념이나 스킬을 실무에 어떻게 적용할 수 있을지 고민하고, 테스트해보고, 할 수 있는 만큼만 적용하는 경우도 많다.
위의 질문과 비슷한 질문이다. 하지만 위의 질문은 좀 더 개념적인 부분에 초점을 맞췄다면, 지금 질문은 구체적인 스킬에 좀 더 초점이 맞춰져 있다. 쉽게 말해서 어떤 방법과 스킬, 툴을 사용해서 업무를 할 것이냐에 관한 것이다. 조직 내부에 어려운 업무를 하기 위한 툴이나 환경이 갖춰졌다면 베스트이겠지만, 그렇지 않은 경우가 아마 훨씬 많을 것이다. 이러한 경우 최선이 아닌 차선의 방법 혹은 대안을 어떻게 찾을 것이냐는 것도 이 질문에 해당하고, 중요한 일이다.
나의 경우, 모바일 앱 서비스를 담당하고 있어서 고객의 제품 사용 주기에 맞게 전환 유도를 위한 앱 푸시를 기획하고 싶었다. 보통 앱 푸시는 Braze라는 툴로 쓰는데, 사용료가 상당히 세서 도입하지 못한 상태다. 백엔드를 통해 바로 푸시 알람을 기획하고 발송하는 방법도 있지만, 기획도 훨씬 더 어렵고 개발자의 도움도 필요한 상태라 대안을 찾아야 했다. * 참고로 위에 언급한 제품 사용 주기도 AB 180의 리텐션 플레이북을 보고 배운 개념이다.
따라서 처음부터 완벽하게 자동화된 앱 푸시를 기획하기보다는, 지금 조직에서 갖춘 툴과 내가 사용할 수 있는 스킬들로 업무를 할 수 있는 방법을 찾아봤다. 그래서 앱 푸시 대신 문자 발송 툴을 사용하기로 결정했다.
그리고 고객 세그멘테이션은 또 간단하게 SQL을 사용할 수 있었기 때문에, 직접 제품 사용 주기를 계산해서 발송 대상에 해당하는 고객들을 뽑아 문자를 보내기로 결정했다. 그래서 이 방법으로 자동화된 앱 푸시 대신, 1회성의 전환 유도 문자를 발송했다. 이런 식으로 처음 그린 완벽한 업무를 할 수 없더라도 조직 내의 자원을 최대한 활용해 비슷하게, 혹은 낮은 수준의 업무로 대체할 수 있다.
처음 예상한 업무가 아니더라도, 조직 내 자원을 가장 효과적으로 또 효율적으로 활용할 수 있는 업무를 배운다는 점에서 이렇게 대체 업무를 찾는 것도 업무 능력을 기를 수 있는 좋은 방법이다. 또 추후에 비슷한 업무를 하게 될 경우에는, 쿼리문을 고도화하고, 문자 템플릿을 만들어 놓고 발송도 특정 조건에 맞춰 스케줄을 걸어서 더 효율적으로 업무를 할 수도 있다.
이런 식으로 주어진 자원 내에서 업무를 할 수 있는 가장 최적의 방법을 찾는 생각을 계속해서 연습하는 경험을 해봐야 한다. 이런 경험이 계속 쌓이면, 주어진 상황에서 가장 최적의 업무 방법을 가장 빠르게 찾을 수 있는 능력이 생기고, 이 능력은 어떤 상황에서도 문제를 해결하고 임팩트를 내는 데 좋은 무기가 되어줄 수 있다.
보통 큰 임팩트를 내는 일은 혼자서만 할 수 있는 게 아니라, 다른 직군과의 협업이 필요한 경우가 많다. 특히 개발자, 디자이너와의 협업은 거의 필수라고 할 수 있다. 따라서 이들이 하고 있는 업무와 스케줄, 선호하는 커뮤니케이션 방식을 파악해 원활히 커뮤니케이션할 수 있어야 한다.
특히 사람마다 선호하는 커뮤니케이션 방법이 다른데, 각자 선호하는 방법에 맞춰 커뮤니케이션해야 한다. 커뮤니케이션은 메시지는 어떻게 말하는가가 아니라, 듣는 사람이 어떻게 받아들이는지에 따라서 성패가 갈린다. 즉, 옳고 합리적인 메시지라도 전달 방식에 따라 전달되지 않을 수도 있다. 쉽게 말하면 맞는 말이라도 듣는 사람이 기분 나쁘게 말하면, 메시지는 제대로 전달되지 않을 가능성이 높다.
그리고 특히 비 개발자, 비 디자인 직군이 개발자, 디자이너와 협업하기 위해서는 그들의 사고방식과 그들이 주로 사용하는 단어, 개념 등을 어느 정도는 알아 놓을 필요가 있다. 전문가만큼 알 수는 없지만, 최소한 그들의 입장을 이해하고, 그들의 업무를 충분히 고려하고 있다는 인상을 줄 정도로는 알아야 한다. 그래서 자신이 개발자, 디자이너가 아니더라도 해당 지식들을 조금씩이나마 꾸준히 공부해야 한다.
이 질문의 핵심은 일의 완료 시점이 언제인지 예측하는 것이다. 개인적으로도 가장 어려운 부분이다. 일의 완료 시점을 예측할 수 있어야, 특정 기간 해야 하는 업무들을 정리해서 계획할 수 있다. 그래야 해당 업무 말고 이외의 업무들도 일정에 맞춰 넣을 수 있어서, 불필요한 야근이나 크런치 모드를 줄일 수 있다.
개인적으로 팀원에게 말해주거나, 공식적으로 밝히는 업무 완료 예상 시점은 스스로 예상한 완료 시점에다가 2, 3일 정도 여유를 두는 걸 추천한다. 업무를 하면서 예상치 못하게 새로운 일을 해야 할 수도 있고, 생각보다 진행이 더딜 수도 있기 때문에 약간의 여유 기간을 두는 게 좋다. 또한 예상 완료 시점보다 늦게 업무를 완료하는 건 문제가 되지만, 일찍 완료를 하는 건 문제가 되지 않는다. 따라서 구성원들의 신뢰도를 얻는 측면에서도 기간을 조금 여유롭게 두는 걸 추천한다.
그리고 업무가 특정 시점에 끝나는 프로젝트성 업무인지, 아니면 특정 주기마다 반복적으로 해야 하는 업무인지 파악하는 것도 중요하다. 프로젝트성 업무라면, 하루에 얼마나 해당 업무에 시간을 투입할지 결정해야 하고, 반복적이고 루틴한 업무라면 얼마 주기로, 얼마나 시간을 써서 업무를 할지를 결정해야 한다. 물론 처음에는 완벽하게 예상 시간을 측정할 수 없다. 대신 예상한 시간과 실제 업무를 하는 데 걸린 시간 차이를 체크하고, 그 원인을 파악해서 완료 예측을 더욱 정확하게 할 수 있어야 한다.
지금까지 두 편의 글에 걸쳐서 특정 업무를 할 때, 특히 일정 정리를 할 때 스스로 던지는 질문들을 정리해 봤다. 누군가에게는 너무나 뻔하고 당연한 질문이지만, 생각보다 이런 뻔하고 당연한 내용을 자세히 알려주는 콘텐츠는 많지 않은 것 같아서 이 글을 썼다. 누군가에게는 업무를 선정하고 리딩 하는 데 있어서 도움이 되었길 바란다.