꿈꾸는코난

의사소통의 중요성은 다들 잘 아시리라 생각됩니다.

힘이나 상하관계에 의한 일방적인 커뮤니케이션이 아니라 상호 *소통*이 중요하다는 것을…

물론 *소통*을 다른 개념으로 사용하고 있는 듯한 사람이 있긴 하죠.

뇌 용량이 지극히 부족한 누구처럼…

주어진 일을 할 때 100% 판단 가능한 근거를 가지고 일을 시작하는 것은 거의 불가능에 가깝습니다. 아무리 많은 시간이 주어지더라도 어떤 것에 대해 100% 이해하고 시작하는 것이 쉬울까요?

따라서 일을 하면서 한정된 판단 근거를 가지고 판단해야 하는 과정이 반복됩니다. 그리고 그때마다 올바른 판단이 이루어진다면 주어진 일은 목적지를 향해 한발씩 더 다가가는 형태가 될 겁니다.

이때 올바른 판단을 위해 여러 가지 방법을 사용합니다. 예를 들어 다른 사람의 의견을 많이 듣고 판단한다거나 다양한 시스템(도구)을 활용하여 제대로 된 판단 근거를 유도하는데 사용하는 것입니다.

하지만 아무리 많은 좋은 데이터가 있더라도 결정은 사람이 하는 것입니다.

100% 올바른 데이터는 없기에… 또한 잘못된 데이터가 있기에…

그걸 잘 가려내어 올바른 판단을 할 수 있는 능력이 중요할 것입니다.

어떤 일을 할 때 각자 고유한 방식이 있습니다.

여기서 말하는 고유한 방식이란 게 사람마다 조금씩 다른 뭔가를 얘기하는 것이 아니라 좀 근본적인 두가지 측면을 말합니다.

A 스타일은 어떠한 문제가 주어졌을 때 그 문제를 분석하고 어떻게 해결해나갈지 방향을 생각하고, 또 그 내용을 정리하고 정리된 내용을 분석하고 그런 과정을 반복적으로 수행합니다. 근데 이 스타일이 너무 강해지면 문제의 본질을 망각해버리는 상황이 발생하게 됩니다. 예를 들어 주어진 문제를 풀어보니 코끼리를 그려야 한다면 처음에는 전체적으로 필요한 것을 파악하고 고민하고 그러다가 어느순간 코끼리는 사라지고 코만 계속 그리고 지우고 하는 과정이 되는거죠. 시간이 많이 흐른 다음에 “내가 뭘하고 있지” 느끼게 될 때가 있는데 이미 많이 늦어진거죠.

B 스타일은 어떠한 문제가 주어졌을 때 일단 구체화 과정까지 가보는 겁니다. 개발을 예로 든다면 어떤 문제가 있으면 일단 코드부터 수정을 해보는 거죠. 해보다가 안되면 다른 방법을 찾고 또 해보고 이러한 과정이 반복되는 것입니다. 근데 이 스타일이 너무 강해지면 시도해보지 않아도 빤한 일을 시도하는 경우가 생기고 빠뜨려지는 부분이 항상 생긴다는 겁니다. 예를 들어 동물원을 그려야 된다면 일단 대충 생각해서 호랑이, 사자, 곰 등을 그립니다. 다 그려놓고 다른 사람이 보니 동물원 건물 자체가 없습니다. 고민을 하게 되죠. 다 지우고 동물원 건물부터 다시 그려야 하나 아님 일단 그린 동물 사이사이에 동물원 건물을 그려 넣을까…

둘 다 극단적인 예입니다. 대부분의 사람들이 A 스타일과 B 스타일을 다 가지고 있습니다. 다만 어느 스타일 측면을 가지고 있냐에 따라 일하는 방식이 조금씩 다를 뿐이죠. 둘이 적절히 잘 조화를 이루게 되면 가장 좋겠지만 말만큼 쉬운 건 아니죠.

하여튼 어떤 일을 해야 할 때 세부적으로 내용을 잘 정리하고, 정리된 내용을 바탕으로 각각을 해결해 내갈 방안을 잘 고민하고 생각하는 게 중요합니다.

적어도 자신이 뭘 해야 하며 어떻게 해야 하는지는 계속적으로 고민해 나가는 것이 꼭 필요합니다.

그렇지 않으면….

예전에 프로젝트를 진행할 때 팀원 중에 이런 사람이 있었습니다.

개발계획서를 작성하고 프로젝트에 대한 일정을 생각해서 달라고 하니 아직 개발(여기서는 코딩을 말함)도 시작 못했는데 일정을 어떻게 알 수 있냐고 했습니다. 그럼 언제 개발이 완료될지 알 수 있냐고 했더니 개발이 끝나봐야 알 수 있다고 하더군요(OTL).

물론 무슨 일을 시작할 때 문제점이 무엇인지, 어떻게 문제점을 해결해 나갈지, 진행하면서 무슨 새로운 일이 생길지 알 수 없는 상태에서 일정을 도출해 내기란 불가능에 가까울지 모릅니다.

하지만 어떠한 조직에서 일을 할 때 일에 대한 예측 없이 진행한다는 것은 앞으로의 계획을 전혀 만들 수 없다는 것과 같습니다(언제 끝날지 모르는데 앞으로 계획을 세우는게 가능할까요?)

특히 개발이라는 무형의 괴물(?)을 봤을 때 언제 어떤 식으로 돌변해서 자신을 덮칠지 모르기 때문에 일정을 예측하기는 더욱 어려운 것 같습니다.

다만 일정을 예측할 때 지난 경험을 바탕으로 다양한 시나리오(앞으로 발생 가능한 일, 문제점 등등)를 감안하여 최대한  잘(?) 만드는 것이 중요할 것입니다.

근데 혹시 student syndrome이라고 아시나요?

해야 할 일을 미루고 있다가 결국 마지막 순간이 되어서야 실행하는 습관을 말합니다.

방학숙제를 쌓아두고 개학 전날 시작한다거나, 기말고사 준비를 시험기간 직전에 몰아서 한다거나 하는 식의 학생들의 버릇을 빈댄 거죠.

사실 회사 업무도 비슷한 경향이 있는 것 같습니다. 데드라인이 있으면 논리적으로는 그 전 언제 까지 어떻게 하는 등의 일정 수립을 합니다. 그러나 이상하게도 심리적으로는 데드라인이 가까이 오기 전까지는 시작을 하지 않는 경향이 있답니다. 항상 날짜가 많이 남아있어 보이죠. 그래서 막판까지 가다가 지금 시작하지 않으면 데드라인을 맞추기 어려울 것 같은 시점에서 드디어 발등에 불이 떨어지는 것을 느끼고 시작하게 되는 것이죠. 근데 그 깨닫는 시점이 늦을 수록 결과는 엉망이 되는 것입니다.

대부분의 회사에서 개발에 관련된 사항을 프로젝트화 해서 진행하고 있습니다.

“프로젝트”란 주어진 요구사항을 주어진 자원을 이용하여 주어진 기간동안 수행하는 것을 말합니다.

일상적인 업무와 프로젝트의 차이점이 바로 주어진 기간 동안 한시적으로 운영된다는 것이죠.

사실 조그만 조직에서는 프로젝트화 하는 것이 필요 없을 지도 모릅니다.

개발에 참여하는 인원이 소규모이고, 따라서 하는 일이 빤히 보이는 상황이기 때문에 프로젝트화한다는 것이 별로 의미가 없어 보일 수도 있죠.

하지만 항상 이 정도의 규모로만 개발이 진행된다고 볼 수 없기 때문에 프로젝트 기반으로 업무를 수행하고 체계화해 나가는 분위기를 익히고 경험하는 것은 매우 중요하다고 할 수 있습니다.

규모나 참여 인원에 따라 프로젝트 관리 방법도 상당히 많이 다르겠지요.

그래도 기본적으로 해야 할 일을 명확히 정의하고, 그 일을 누가, 어떻게, 언제까지 할 것인지를 미리 결정하고 진행하는 것은 기본이라고 볼 수 있습니다.

그리고 중간 중간 진행 상황에 대해 검토하고, 그 결과에 따라 다음 진행 방향에 대해 보완해 나가는 것이 필요하죠.

소프트웨어 공학에서 얘기하는 것처럼 시스템적이고 체계적이고 이론적인 부분이 현실에 적용되기는 상당히 어렵습니다. 다만 근본적인 개념을 이해하고 그 개념을 속해있는 조직의 현실에 맞게 접목하는 것이 가장 중요하다고 볼 수 있습니다.

앞으로 당분간은 일을 진행할 때 각자가 사전에 많은 생각을 하도록 유도하고, 기술적인 부분 검토나 아이디어 도출에 좀 더 많은 시간을 할애할 수 있도록 할 계획입니다.

모든 프로젝트가 그렇다고 할 순 없지만, 대부분 사전에 많은 고려를 하게 되면 나중에 완전히 엉뚱한 방향으로 일이 잘못 나아가는 것을 최소한으로 방지할 수 있습니다.

그리고 코딩 들어가기 전에 머리 속으로 체계화시킬수 있는 능력도 좀더 키우는 것이 필요할 것이라고 생각됩니다. 누가 대신해 줄 순 없지만 그렇게 하도록 유도할 순 있겠죠….