업무의 우선순위
안녕하세요. 연두씨입니다.
업종이나 연차에 상관없이 대다수 회사에서 이런 경험들이 있으실 것 같은데요.
업무는 쏟아지고 내 몸은 하나고, 하고 있던 일이 다 끝나지도 않았는데 또 다른 이슈가 또또 밀려오는 혼돈의 카오스!!
특히나 기획자들은 본인의 업무뿐 아니라 다른 파트의 업무 진행 상황이나 전체 프로젝트 이슈들도 같이 체크할 일이 많아서 더더욱 멀티 플레이에 대한 부담감이 있을 거라 짐작됩니다.
그래서 오늘은 업무의 우선순위에 대해 이야기해보려고 합니다.
우선!! 한 사람이 한 번에 한 가지 일만 하는 그런 눈부시고 아름다운 환경은 없음을 미리 알려드립니다.
구축을 하면서 운영을 하기도 하고, 운영에 운영에 운영을 동시에 하기도 하고,
구축만 한다고 해도 문서작성과 이슈 체크와 일정 체크와 또 뭐와 또 뭐와 뭐와 같이 할 수밖에 없는 상황이 될 거예요.
만약, 나는 한 번에 한 가지 일만 하겠다는 마음을 가지고 있다면 그 마음 빨리 버리시길 바라고요...
그래도 그런 마음을 계속 가지겠다 하시면, IT는 협업의 집약체 분야인데 나로 인해 다른 사람들이 많이 힘들어진다는 것을 아셔야 합니다.
그러니, 우리는 내 몸 하나로 최대한 많은 업무를 빨리 처리하여 많은 이들에게 도움을 주고, 그런 실력을 인정받아 빨리 승진하고 더 많은 연봉을 노리는 길을 찾는 게 좋겠습니다.
많은 업무를 빨리 처리하는 기준이 바로 업무의 우선순위가 되겠는데요.
업무의 우선순위 기준은 처해진 상황이나 사람마다 다를 수 있겠으나.. 저는 보통 아래와 같은 기준을 많이 설명하는 편입니다.
일순위. 데드라인이 있고 여러 작업자가 있는 경우
이순위. 데드라인이 있고, 나 혼자만 하는 경우
삼순위. 데드라인이 없고, 여러 작업자가 있는 경우
사순위. 데드라인이 없고, 나 혼자만 하는 경우
데드라인이란 즉시 처리에서부터 오늘 내 처리, 정해진 기간 내 처리 등의 시간차가 있을 텐데요,
당연히 데드라인이 짧은 순부터, 그러니까 즉시 처리해야 하는 경우부터 해야겠지요.
즉시 처리하는 경우는 보통 운영 중인 서비스의 장애입니다. 이 때는 하던 일도 멈추고 급한 불 먼저 끄는 게 맞고요
오늘 또는 몇 월 며칠까지 해야 하는 기간 내 처리 업무들은 기간 내를 넘기지 않되, 작업자가 많을수록 먼저 하고
혼자 할 때는 작업량이 짧을수록 먼저 합니다.
예를 들면 이번 주까지
1) 주간업무보고 작성 2) 웹사이트 텍스트 수정 3) 작년 수행 업무내역 작성 4) 웹사이트 기능 추가
을 해야 한다고 하면,
오늘은
1) 웹사이트 텍스트 수정 : 수정할 내용 정리해서 퍼블 넘기고
2) 주간업무보고 : 지난주 기억을 살려서 후딱 써버립니다.
3) 웹사이트 기능 추가 : 1차로 기능 정의할 부분을 검토만 한 후
4) 작년 수행 업무내역 : 업무내역을 어디서 찾아볼지 생각만 합니다.
그럼, 내일부터 이번 주까지...
주간업무는 처리 완료된 상태이니, 이제 업무가 3개로 줄어든 상태고
텍스트 수정 적용되는 거 마무리 치고, 웹사이트 기능 추가를 좀 더 작성해서 디자인-퍼블-개발과 회의하고
작년 수행 업무 내역은 어디서 찾아서 어떻게 할지만 생각하다가 목-금에 휘몰아쳐서 쭉 작성합니다.
그럼 그다음 주에는 웹사이트 기능 추가 건만 남게 됩니다.
물론 그 사이에 다른 업무가 또 들어오겠죠. 그럼 그 업무들도 기준에 따라 지금의 리스트의 위아래로 껴 넣으면 되어요.
같은 기간 안에 같은 인원이 처리해야 하는 모든 조건이 동일한 업무라면,
이 업무를 하지 않았을 때의 영향도를 체크합니다. 더 많은 사람들이 불편하거나 더 민감한 영향도를 먼저 합니다.
예를 들면 오늘 안에 어떤 게시판의 필터 기능을 프런트와 어드민 둘 다 넣어야 한다면 내부 임직원이 사용하는 어드민 보다 대 고객 접점인 프런트에 적용하는 것을 우선 합니다.
또, 매출 합계가 안 맞는 경우와 매출 리스트에 필터를 넣는 기능을 같이 해야 할 경우 합계를 맞추는 작업부터 합니다.
위에처럼 여러 업무가 동시에 들어오게 될 경우도 있지만 한 업무를 처리하는데 추가 이슈가 발생되는 상황도 생기게 됩니다.
A라는 기능을 개발하는데, 개발 요건이 계속 수정되고 추가될 수 있고, 개발 중 미정의 된 부분을 발견할 수 있고, 개발 중 예전부터 있었으나 몰랐던 버그를 찾아낼 수도 있습니다.
여러 가지 이슈들이 발생이 될 때 이슈가 발생된 시점마다 처리하려고 하면 앞으로의 진전이 어렵습니다.
무슨 말이냐면, 개발 중에 요건이 추가돼서 하던 개발을 멈추고 추가 기능을 분석하거나 몰랐던 버그를 잡다 보면 원래 계획한 기능 개발이 계속 늘어지게 되는 상황이 됩니다.
이 때는, 현재의 상황과 이슈의 성격을 빨리 파악하여 정리정돈을 해야 합니다.
예를 들면 A라는 기능 개발이 약 90% 되어 있는데
1) 버튼명 한 개 수정이라면... 이 이슈를 처리해서 오픈하는 쪽으로 정리하고
2) 전체 버튼명 재검토라면... 이 이슈를 처리하는데 대략의 일정만 산정해서 오픈일을 미룰지, 오픈하고 보완할지를 유관자들과 빨리 상의해서 결정하는 회의를 먼저 합니다.
그러나 A라는 기능 개발이 약 10% 되어 있다면,
버튼 외의 다른 기능을 먼저 개발하고 그 사이에 버튼명을 재정의하여 버튼 개발 시에 최종 버튼명으로 개발될 수 있도록 조정합니다.
설명드린 기준과 예시는 그야말로 예로 작성한 거고요, 반드시 저 기준으로만 해야 하는 것은 아닙니다.
중요한 것은 기준 없이 나에게 업무나 이슈가 생기는 시점마다 바로 착수하는 것이 아니라
나름의 기준을 잡고 우선순위를 정리 한 뒤 계획을 세워서 업무와 이슈를 처리해야 보다 효율적이라는 것입니다.
여러 명이 협업할 때도 좋고.
업무를 계속 오래 하다 보면 기준을 찾고, 별도로 정리를 하는 절차가 없어도 자연스럽게 업무의 순위나 이슈 파악이 빨리 될 거예요. 정리가 빨리 되니 업무 처리의 속도도 빨라지게 될 것이고요.
만약, 아직 익숙지 않다면 위의 기준 와 예시들이 참고가 되었으면 합니다.
