현재 상황에 대한 고찰 그리고 문제 정의 방법론

흔히 회사에서의 성장은 문제 해결을 위한 구체적인 업무지시를 받고 결과물을 만드는 것에서 시작된다. 이를 충분히 수행해내는 사람이 되면 이젠 문제 자체를 받아 이를 해결하기 위한 구체적인 업무를 도출해내는 단계로 나아가고, 이조차 문제없이 수행할 수 있게 된다면 이젠 문제를 직접 찾아내고 더 나아가 가치를 창출해내기 위해 고민해야하는 위치로 도달하게 된다.

나는 한 조직에 오래 머물렀기 때문인지 어쩌다보니 위의 과정을 순식간에 거쳐 벌써 가치를 창출해내는 위치에 서있게 되었다. 이 덕분에 빠르게 성장할 수 있었다만 아쉽게도 경험 많은 이들을 직접 보며 배울 기회는 적었던 것 같다.

 

절대적인 경험의 양이 부족하니 요즘들어 어떻게 해야할지 고민하는 나날들이 많아지고 있다.

문제가 있는 부분이 보이기는 하는데 이를 정의하는데 오랜 시간이 걸리기도 하고, 가치를 창출해내야 하는 부분이 인지는 되는데 이를 어떻게 구체화 해야할 지 막막하다. 또한 수많은 문제들의 우선순위를 나열하는 것도, 이를 팀원들에게 나누는 일도 어디서부터 시작해야 할 지 등 뭐 하나 명확하게 하는 것이 없는 것 같다. 

 

한동안 이러한 상태가 지속되나보니 그냥 자진해서 다른 사람 밑으로 들어가 좀 더 경험을 겪는 것을 택할까 고민하여 상담도 하고 이것저것 알아보기도 했다. 하지만 생각을 거듭한 결과, 역시 이를 스스로 극복하고 싶다는 생각이 더 강하게 들었다. 

직접 경험으로부터 배우지 못한다면 내가 선택할 수 있는건 이론과 간접 경험일 것이다. 수없는 사람들이 가치를 창출하는 역할을 담당했고 성공한 사람들도 널려있는 세상이다. 그리고 감사하게도 이들은 이에 대한 경험을 기록물로 남겨두거나 루틴화 시켜서 하나의 방법론으로 만들어 놓은 경우가 많다. 따라서 내가 선택한 방법은 이러한 방법론들을 찾아보고 습득하여 나에게 적용해보는 것이다. 내가 어떤 상황에서 막히는 지 명확히 정의해보고 이러한 상황에서 어떻게 해결할 수 있을지 방법론이나 경험을 블로그에 정리한 후 천천히 루틴화하며 실제 생활에 녹여보는 것을 할 것이다. 

 

그렇다. 지금까지는 서론이었다. 내가 앞으로 뭘 쓸지에 대해 정의! 

이전까지는 개발 관련 글만 썼다가 새로운 주제에 대해 쓰는 것이다보니 왜 갑자기 방향을 틀게 된 것인지 미래의 나에게 남겨놓고 싶었다!

 

 

문제가 있는 것 같은데...뭘 어떻게 해결해야할 지 감도 안잡히네.

내가 현재 겪고 있는 일이다. 지금 상태가 정답이 아닌 것은 알겠는데 뭐가 정답인지도 모르겠고 뭐가 정답인지 모르니 뭘 해야할지도 모르겠고. 

몇 년 전에 비슷한 상황이 있었다. 개발자로써 지금 상태가 불만족스럽고 더 성장하고 싶은데 뭘 어떻게 해야할 지 몰라서 방황하던 때였다. 그래서 시작한 것이 이 블로그에 매 주 글 하나씩 쓰는 것이었다. 뭘 할지는 모르겠지만 뭐라도 해야할 것 같아서 다짜고짜 정한 룰이었다.

그런데 글을 쓰려니 뭘 써야할 지도 모르겠더라. 뭘 할지에서 뭘 쓸지를 또 고민하다 문득 내가 가려하는 이 "개발자"란 무엇인지가 궁금해졌다. 그래서 첫 글은 개발자가 무엇인지에 대해 정의한 것이었다. 개발자에 대해 정의를 내리니 이렇게 정의한 개발자가 꼭 알아야할 지식이 무엇인지가 궁금해졌기에 이를 또 정의했다. 이렇게 정의해나가니 내가 배워야 할 것이 뚜렷해지기 시작했고 점점 써야할 글 소재가 많아졌으며(지금은 너무 많아서 죽겠다) 결국 이는 어떻게 성장해 나가야하는 지에 대해 지표가 되었다.

 

문제를 인지했는데 해결할 방법을 전혀 모르겠다면 의외로 뭐가 문제인지도 모르는 경우가 많다. 문제가 정의되지 않았으니 뭘 해결해야할지도 모르는 것. 과거의 예시에서 내가 개발자가 무엇인지 정의를 내리는 것이 우연찮게도 문제를 정의내리는 과정에 해당하게 되었다. 개발자의 정의를 내림으로써 그 정의가 가야할 방향이 되었고 방향이 생기니 해야할 것도 뚜렷해진 것이다. 

해결은 정의로부터 시작되는 것이다. 문제를 정의하면 해결할 수 있는 상태가 된다. 

 

 

문제 정의 방법론

자 그럼 이제 문제를 정의하면 되는 것인데, 문제 정의는 어떻게 내리는 지 또 막막해진다. 정의가 쉬웠다면 진즉 내 뇌가 알아서 처리해줬겠지. 위의 사례에서는 우연찮게 정의됐지만 매번 우연을 바랄 수는 없으니 방법론을 찾아 이러한 상황이 되면 바로 적용해보려한다.

 

🟧 AS-IS /TO-BE 분석

문제가 너무 많다고 하는데 뭐가 문제인지 물어보면 대답을 제대로 못하는 경우가 있다. 이는 지금까지 지나간 문제들을 붙잡지 않고 흘려보냈기 때문이다. 뭐가 불만인지를 정의하지 않으면 해결은 당연히 할 수 없을 것이다.

문제가 너무 많고 내가 뭘 원하는지도 모르겠을 때는 AS-IS /TO-BE 분석을 활용해보자. 이는 현재 상태를 나열하고(AS-IS) 내가 원하는 이상적인 상태를 나열하여(TO-BE) 붕 떠있던 문제들을 고착화시키는데 도움이 된다.

참고로 아래의 방법을 진행할 때는 생각을 과하게 하지 말고 브레인스토밍처럼 흘러나오는 데로 한다면 좀 더 편안하게 진행 할 수 있을 것이다.

 

예시를 들어보자

AS-IS	TO-BE
회의만 하면 항상 지쳐	회의가 짧게 진행되고 결과가 확실했으면 좋겠어
요구사항이 너무 사방팔방에서 들어와	요구사항을 하나의 창구에서만 들어오게 하고 싶어
내가 하는 일의 우선순위를 모르겠어	우선순위를 분배할 수 있는 루틴이 있었음 좋겠어

 

이렇게 문제를 정의해두고 어떤식으로 바뀌었음 좋겠는지 적게되면 어떻게 해결할지에 대한 고민을 시작할 수 있을 것이다.

 

 

 

🟧 Whys를 통한 문제 정의

일반적으로 막막한 문제라 하면 구체적인 문제 사항을 드러내는 것이 아닌 감정적인 불만 형태라던가 뭉뚱그린 형태로 나온다. 예를 들어 "회의만 하면 지쳐", "처리해야할 업무도 많은데 내가 정리해야할 사안이 너무 많아" 등과 같이 불만의 형태로 드러나게 된다. 

위의 AS-IS/TO-BE에서도 AS-IS에 해당되는 것에 감정적인 불만 형태로 있는 것도 있을 것이다.

 

이 불만의 형태를 Whys를 활용하여 구체적인 문제로 정의해보자.

"회의만 하면 항상 지쳐"

-> 왜 지쳐?: 문제가 있는 부분을 각자 토로하듯 쏟아내기만 하다보니 그냥 쉬익쉬익대다가 끝나는 기분이야
-> 왜 문제를 토로하듯 쏟아내? 사전에 회의 주제도 안주니 그냥 다 모인김에 다 풀어내는거겠지
-> 왜 사전에 회의 주제를 안줘? 회의 호출자가 일단 모이고나서 얘기해준다해서 그래
-> 왜 사전에 안주고 모여서 준다해? 귀찮으니깐
-> 왜 귀찮아? 회의가 필요한 상황에 대해서 글로 적기보다는 그냥 일단 모여서 말로 설명하는 것이 빠르니깐

문제 정의: 글로 정리해서 문제를 공유하는 역량의 부족 + 시스템의 부재

 

Whys를 이용한다면 문제의 정의가 좀 더 구체적으로 되어서 해결방법도 더 빠르게 찾을 수 있을 것이다.

 

 

 

🟧 보너스! 불만 기록장을 통해 패턴 찾기

아주 속에 불을 일으키는 불만도 있지만 자잘한 불만들은 참고 넘어가게 되는 경우가 많다. 자잘하더라도 이것이 반복되면 염증처럼 쌓이게 되는데 만성화되면 워낙 익숙해져서 내가 뭐에 불만이 있는지도 모르는 채로 그냥 속에 화가 많은 사람이 되어버리는 경우가 있다.

이를 타파하기 위해 기간을 정해서 불만 기록장을 작성해보자. 아주 간단하다. 기록할 곳을 마련해놓고 불만이 생기면 날짜와 함께 적어놓으면 된다. 혹은 하루의 마지막에 내가 느낀 불만이 무엇이 있었는지 회고하며 적어도 상관없다. 

그리고 정해진 기간이 끝나면 시간을 내어 해당 리스트를 정리해보자. 중복되는 것 끼리 모아놓고 얼마나 잦은 지도 분석해보자. 이렇게하면 이 불만은 사소한 것이 아닌 꽤 중요하게 해결해야하는 불만이었음을 깨달을 수 있다.

 

 

 

---

 

오늘은 문제 정의 방법론에 대해서 알아보았다. 아직 실제로 진행해본 것은 아니고 루틴화를 할 방법을 적어놓은 것인지라 어떻게 진행될지 궁금하고 기대된다. 

직접 해보고 불편했던 부분이나 현실적이지 않은 부분은 꾸준히 수정해나가보려한다!