앞서 두 종류의 성장이라는 글에서 도메인과 스킬에 대해 이야기 해보았다. 스킬 이야기 중 첫 번째로, 아주 간단하고도 강력한 스킬인 task design에 대해 논해보려고 한다.

Task design이란, 말 그대로 업무를 디자인하는 것이다.

업무 디자인이 무슨 소리지? 업무가 무슨 인테리어도 아니고.. 라고 생각 할 수 있는데, 업무 디자인은 생산성을 높이기 위해 매우 중요한 스킬이다.

Task design

여기 신입사원 누렁이가 있다고 해보자. 리더가 NASA서버에 설치하라고 했다. 그렇다면 누렁이는 이 업무를 어떻게 정의 할까?

아마, NAS를 A서버에 설치 라고 정의 할 것이다.

사실 대부분의 신입사원들은 이렇게 업무 정의를 마칠 것이다. 하지만 조금만 더 나아간다면, 왜 NAS를 A 서버에 설치하라고 했지?라고 의문을 품게 될 것이다. 여기서 나오게 되는 개념이 task design의 핵심 요소인 WHY 이다.

누렁이는 리더에게 업무의 이유를 물어봤다. 그러자 리더가 말한다. 응~ 모델러들끼리 중복되는 데이터가 많아서 공유 좀 되게 할라고~ 라고 이유를 답한다.

그렇다면 다시 생각해보자, 모델러끼리 데이터 공유하게 하는 방법은 A서버에 NAS를 설치하는게 최선인가?

여기서 WHAT을 생각해 내야 한다. 여기서 WHAT모델러 간 데이터를 공유하게 하는 시스템 혹은 비슷한 무언가 이다. (시스템이라고 특정 짓지 않고 무언가라고 한 이유는, 뒤에서 설명하겠다.)

정리하자면,

WHY : 모델러들간 중복되는 데이터가 많다
WHAT : 데이터 공유 시스템 등의 무언가
HOW : A서버에 NAS 설치

가 된다.

보통 상명하복의 조직에서는 리더가 WHYWHAT 등을 디자인하고 부하직원에게 HOW를 던지게 된다. 말 그대로 던진다. 그래서 왜 하는지 이유를 물으면 까라면 그냥 까라고 대답하는 경우도 있다.

물론 부하에게 공유를 못하는 합당한 이유가 있는 경우도 더러 있지만, 그냥 공유가 번거롭거나 하기 싫어서 등 답답한 경우도 많다. 하지만, 그래도 업무를 수행하는 사람은 되도록 WHYWHAT을 생각하려 해야 한다.

앞서, WHAT에서 왜 시스템 혹은 비슷한 무언가라고 에둘러서 표현했는지 설명하겠다고 했다. 자, 다시 위의 WHY, WHAT, HOW를 봐보자. 뭔가 이상하지 않은가? 구체적으로, 뭔가 빠져 있지 않은가? 사실 지금 위의 디자인에선, WHY 조차도 불분명하다.

저기에는 지금 ROOT CAUSE가 빠져있다. 모델러들간 중복되는 데이터가 왜 많을까? 이 모든 문제가 어디서 시작되었고, 왜 저것이 원인으로 지목 되었을까?

이 문제는 알고보면 모델러들끼리의 의사소통 부족으로 발생한 문제 일 수도 있다. 알고보면, 모델러들끼리 의사소통을 해서 데이터 관리 정책을 만들어, 아주 쉽게 문제를 해결 할 수도 있는 것이다.

위의 예제를 다시 정리하면,

WHY(w/ ROOT CAUSE) : 모델러들간 소통 부재로 중복 데이터가 많이 발생함
WHAT : 데이터 공유 시스템 등의 무언가
HOW : A서버에 NAS 설치

와 같이 적을 수 있을 것이다. 이게 바로 내가 말하는 task design 스킬이다. 단순히 리더가 시키는데로 업무를 수행하는 것이 아닌, 아니 단순히 업무를 수행하더라도 위와 같이 생각을 하며 진행을 해야 한다. 그래야 “효율적”으로 일을 할 수가 있다.

어쩌면 리더가 A서버에 NAS 설치하라고 누렁이 말고 다른 신입사원에게도 동시에 업무를 지시했을 수 있다.

누렁이는 이유를 따지고 묻고 다른 신입사원은 하루 밤새 NAS 를 설치했다고 치자

이때 리더는 다른 신입사원에게 일을 더 잘한다고 칭찬 할 수도 있다. 그럴때, 아, 이유 묻지 말고 저렇게 바로바로 해야 칭찬 받는 구나 라고 생각하면, 당장 그 리더 밑에선 일을 잘 한다고 칭찬을 많이 들을 순 있지만, 내 스스로의 성장은 많이 막힐 수 있다.

사실 보다 큰 문제는, 이러한 사람들이 경력을 쌓고 높은 위치에 올라갔을때, WHAT은 커녕 WHYROOT CAUSE를 인지조차 못해 파악조차 하지 않으려고 하는 경우가 있다는 것이다. 그렇게 되면 일은 어마어마하게 많이 하는데 산출물이나 결과물은 나오지 않고 허탕만 칠 수가 있다.

마치며

요즘 난 스스로 코딩을 하는 개발자에서, 문제를 해결하는 엔지니어가 되자. 라고 되뇌이고 있다. 그래서 그런지 예전에는 문제를 푸는 주요 방법이 코딩이었는데, 이제는 의사소통이라고 생각한다.

문송합니다라는 말은 문과가 하는 일은 누구나 할 수 있어서 취업시장에서 안 좋은 포지션에 있는 것을 표현하는 말이기도 하다. 내 생각엔 이과, 공대도 마찬가지가 될 것이다. 왜냐면 문과도 첨부터 저러진 않았거든.

요즘은 코파일럿이 코딩도 해주고 ChatGPT가 검색도 대신 해주고, 내 할일도 대신 정해 준다. 이런 세상에서는 도메인 지식’만’을 쌓으려고 해선 안된다. 문제 파악 능력 및 업무 디자인 등의 스킬을 기르는 것이 나의 경쟁력이고, 더 많은 생산성을 추구하는 방법이라 생각한다.

댓글남기기