정말 해야 하는 1일까?
해야 하는 일 vs 하고 싶은 일 _01
모든 회사원에게는 (아마도) 각자 해야 하는 일이 있다. 그리고 (아마도) 해야 하는 일이 하고 싶은 일과 일치하는 경우는 드물다. 그러나 (아마도) 해야 하는 일을 하고 싶은 일처럼 다루거나, 조금 더 욕심을 내자면 하고 싶은 일과 연결할 수 있(을 지도 모른)다.
만들어야 하는 것 vs 만들고 싶은 것
팀의 특성상 나는 회사에 필요한 온갖 종류의 크리에이티브에 관여했다. 제작물의 종류와 형태 역시 다양했는데 (지금 하고 싶은 말을 하기 위해) 내 멋대로 분류하자면 '만들어야 하는 것'(해야 하는 일)과 '만들고 싶은 것'(하고 싶은 일)으로 나눌 수 있겠다.
만들어야 하는 것
다른 부서의 작업 요청은 대체로 모든 것이 부족한 상태로 전달된다. 작업 내용 혹은 배경에 대한 설명부터 결정 권한, 무엇보다도 시간이 부족하다. 마음 같아선 누구 하나를 콕 집어 독수리 먹이로 주고 싶지만, 개인의 잘못이나 책임이 아닌 경우도 많기 때문에 나쁜 마음은 비우도록 한다.
우선 요청사항이 정말 '해야 하는 일'인지, 배경과 목표는 무엇인지, 그래서 무엇을 어떻게 만들어야 하는지 정확히 파악해야 한다. 요청사항이 적힌 쪽지가 다이너마이트와 함께 도착하더라도 무작정 작업을 시작하면 안 된다. (정말 폭탄이라면 어차피 터질 확률이 높다. 굳이 받아들고 외롭게 죽을 필요는 없다.)
그냥 시작하면 그냥 하다가 그냥 끝난다.
요청사항이 정말 '해야 하는 일'이라면 안타깝게도 일이 계획대로 굴러가지 않아도 '만들어야 하는 것'은 만들어야 한다. 따라서 기일에 맞게 최선의 결과를 만들기 위해서는 첫 단추를 잘 끼어야 한다. (대충대충 넘어갔다가는 단추를 모조리 다시 만들어야 할 수도 있다.)
우선 담당자가 '그냥 과일'이라고 말했다면 어떤 과일인지 (집요하게) 캐물어 최소한 '귤 같은 것' 정도의 답을 얻어낸다. 이 과정을 통해 작업의 배경과 목표를 확인한다. 대답이 영 시원찮다 싶으면 '왜 과일인가' (조금 덜 집요하게) 되물어, 작업 요청의 시발점(발음주의)이라도 파악해본다.
이렇게 수집 혹은 추리한 정보를 바탕으로 작업 목표와 결과물의 예시를 준비한다. 예시는 예시일 뿐이니 너무 많은 노력과 시간을 써서는 안 되지만, 그것을 통해 결과물을 머리에 그릴 수 있는 정도는 되어야 한다.(레퍼런스를 활용하면 매우 쉽고 효율적이지만, 레퍼런스와 정말 똑같은 것 혹은 그 이상을 기대할지 모르니 매우 주의해야 한다.)
귤이라고 해도 오렌지를 함께 준비한다.
이제 예시를 놓고 해당 작업에 기대하는 최소한의 것을 확인한다. 이는 작업의 1차 목표이자 작업을 완료할 때까지 내리는 모든 결정의 큰 기준이 된다. 이때 주의할 점은 작업 요청자뿐 아니라 최종 결정권을 가진 사람의 생각이나 기대치를 반드시 확인해야 한다는 것이다. (진짜 엄청 중요함. 땅을 치고 후회할 일이 매우 높은 확률로 발생함.)
*부득이하게 결정권자와 이야기를 할 수 없는 경우는 차순위(?) 결정권자, 그도 안되면 결정권자의 생각(혹은 성향)을 가장 잘 이해하는 사람이라도 만난다.
예시를 준비했다면 결정권자를 만난다.
0. '과일' 건으로 얘기하고 싶다. (모른다고 답하면 작업 홀드)
1. 여차여차하여 '과일'이 필요하다고 들었다. (배경과 목적 확인)
2. 그중에 '귤 같은 것'을 원한다고 들었다. (작업 방향성 확인)
3. '귤이면 되는'지, '귤이어야 하는'지 궁금하다. (작업 기대치 확인)
4. 목적을 고려하면 '오렌지'가 더 좋다고 생각한다. (생각/의견 전달)
5. 조금 다르게 접근하면 '레몬'도 시도해볼 만하다. (추가 대안 제시)
0. 이걸 아십니까? (고 스톱)
해당 건에 대해 결정권자가 전혀 모르고 있다면 작업은 무조건 홀드다. 작업 요청자에게 상황을 말하고 잊어버리면 된다. 혹시라도 작업 요청자가 '일단' '먼저' 진행해달라고 하더라도 거절하는 게 좋다. ('책임'을 질 수 있는 사람은 '권한'이 있는 사람이다.) 더 중요하거나 정말 급한 일들은 쌔고 쌨다.
1. 왜 하는 거죠? (배경과 목적 확인)
해당 건에 대해 결정권자가 인지하고 있다면 요청받은 사항에 관해 이야기한다. '과일'이 맞는지보다는 배경과 목적을 확인하는 것이 중요하다.
2. '과일'이 맞나요? (작업 방향성 확인)
'과일'이라면 '귤 같은 것'이 맞는지 조금 좁혀서 대화를 이어간다. '과일'이 아닌 경우에는 '무엇'이어야 하는지 논의한다. (결정권자가 논의할 시간이 없는 경우에는 작업 요청자와 이야기한다.)
3. '귤'이 맞을까요? (작업 기대치 확인)
'귤이면 되는가', '귤이어야 하는가' 두 가지 질문을 통해 작업에 대한 최소 기대치를 확인한다. 비슷하지만 조금 다른데, 첫 번째 질문은 최악의 상황을 대비한(여차하면 그냥 귤만 만들고 일을 끝내기 위한) 질문이고, 두 번째 질문은 삽질을 방지하기 위한(죽어도 귤을 먹겠다는데 사과를 주지 않기 위한) 질문이다.
4. '오렌지'가 좋겠네요. (생각/의견 전달)
지금까지 확인하고 파악한 정보를 바탕으로 내 생각과 의견을 전달한다. 준비한 예시를 사용하면 좋지만, 앞 단계(0~3번)를 통해 작업의 실체가 (예시를 준비할 당시의) 사전 정보와 큰 차이가 있는 것을 확인했다면 (무지 아깝겠지만) 예시를 꺼내지 않는다. (애써 확인한 본질이 훼손되어 방향이 틀어질 수 있다.)
5. 레몬은 어떨까요? (추가 대안 제시)
아무리 시간이 부족하더라도 한 가지 생각에 매몰되는 것을 지양한다. 시작과 동시에 내 마음속 1번이 너무 콕 들이박혔다면 억지로 뽑는 시늉이라도 한다. 시작하기도 전에 애정을 쏟으면 단점을 발견하기 어렵고, 그 아이디어가 채택되지 않았을 때 속상하기만 하다. (아무리 정답같이 보이더라도 그것이 정답일 확률은 그리 높지 않다.) 작업의 시작을 준비하는 단계이기 때문에 너무 많을 필요는 없고 최소 2개의 아이디어를 준비한다. 방향이 분명한 아이디어 3, 4개 정도면 좋다. (차이점이 분명하여 비교하기 쉬워야 한다. 비슷하다면 1개로 본다.)
(쓰다 보니 분량 조절에 실패하여 해야 하는 일 vs 하고 싶은 일 _02에서 계속...)
