소프트웨어 개발자 김수보님의 글을 모비인사이드에서 소개합니다.
훌륭한 프로그래머의 기본은 단연 소프트웨어 기술 대한 폭넓은 이해와 풍부한 개발경험입니다.
하지만 회사라는 장소에 오면, 디자이너와의 회의, 상사 보고 등 업무 스킬도 매우 중요하게 됩니다.
일반적으로 많은 개발자들이 How(어떻게 해야 구현이 될 것인가?)에 대해서 정통하지만, What(최종적으로 무엇을 만들고 있나?)이나 Why(왜 이것을 만들고 있나?)에 대해서는 무관심합니다.
What이나 Why의 영역은 전략과 사업의 영역이기 때문이죠. 개발자들은 자신들이 ‘익혀야할 기술이 아니다.’라고 생각합니다.
하지만, 혼자 골방에 틀어앉아 개발할 것이 아니고, 좋은 결과를 내기 위해 여러 사람과 협업을 해야 하는 환경에서는, 어느 시점(When)에 누구(Who)와 무슨(What) 이야기를 하고, 어디서(Where) 이야기를 해야 하는지에 대한 업무 스킬이 매우 중요합니다.
특히 기술적 깊이가 중요한 사업일수록 개발자의 역할도 매우 중요해지는데, 개발자가 아니고서는 이해하기 힘든 문제들이 여러 군데 발생이 되기 때문입니다. 하지만, 경험적으로 이런 어려운 상황에서 사업 부문과 원활하게 커뮤니케이션하는 개발자를 거의 본 적이 없는 것 같습니다. 문제가 조기 발견되지 못하고 늦게 포착되거나, 수습이 되지 않아 피해를 크게 보는 경우도 몇 번 보았습니다.
매우 힘들었던 경험을 통해 얻었던 교훈은 기획자와 개발자 간의 세계는 산과 바다처럼 완전히 서로 다른 세계다.라는 것이었습니다.
알고리즘에 충실한 프로그래머 특성상 고급의 업무 스킬을 기대하기는 힘듭니다. 하지만, 이 스킬의 부족으로 인해 수많은 개발팀들이 삽질을 합니다. 그러나, 안타깝게도 이 업무적 스킬은 책을 통해 가르치거나 배울 수가 없습니다.
물론 한 쪽 만의 노력을 강조할 수는 없지만, 프로그래머들이 회사라는 조직 내에서 협업하고 생존하려면, 이 업무스킬을 익혀야 하는 것은 필수적이라 할 수 있습니다.
혼자서 일하지 마라.
개발자가 why와 what에 무관심하면 어떤 일이 벌어질까요?
각 개발자들이 모여서 일할수록 일이 더 잘 안되거나 잘못된 결과물이 나올 가능성이 큽니다. 개발자들은 일반적으로 시스템 속에서 일하기를 원하는데 시스템이란게 쉽게 만들어지지 않습니다. 결국 협업은 안되는 악순환이 발생합니다.
전체가 부분의 합보다 커지려면 소통을 통해 부족한 부분을 서로 메꾸어야 되는데, 이 문화가 정착이 되면 더 많은 사람을 뽑을수록 더 많은 일들을 더 잘 할 수 있게 됩니다.
그래서, 업무스킬의 기본은 소통에서 시작합니다.
사내에서 사용할 수 있는 가장 쉬운 소통은 말하기와 메일쓰기입니다. 하지만, 소통에서 중요한 것은 누구(who) 입니다.
수직적 조직구조가 익숙한 우리나라 개발자들은 매니저와 소통하려는 경향이 있습니다. 그 범위를 넘어선 소통은 예외라고 생각합니다.
자신에 일에 대한 이유(why)를 이해하고, 문제나 어려움(what)을 식별하여, 매니저의 매니저나, 동료와도 소통을 해야 합니다. 이것은 매우 중요합니다.
소통은 “전달이 짧을수록”, “넓어질수록”, “빈번할수록” 그 힘이 커집니다.
개발 용어로 말하자면, 스스로를 component 화 하십시요. 그리고, interface를 열어 communication 하십시요. 그리고, 스스로의 throughput 을 높이십시요. 더 많은 business logic을 수용하기 위해서, interface 를 다양하게 만드십시요. JSON,XML로도 통신하고 socket으로도 통신하십시요. business call 에 종속적인 상위 class 별로 overriding function 을 만들고, return type 을 달리하십시요.
암묵지를 형식지화하고, 이를 지혜로 바꾸어라.
개발자가 오랜 경험을 통해 쌓은 지식처럼, 주관적이고 경험화되기 힘든 지식을 ‘암묵지(지식)이라고 합니다. 반면 형식화되고 외부에서 관찰이 가능한 지식을 형식지라고 합니다. 아래는 형식지의 종류를 나눈 것입니다.
암묵지를 형식지화 시키면, 소통이 가능한 Object 나 document 가 만들어집니다. 명확한 의견이 없으면, 소통할 수 없습니다. 소통하기 전에 의견(Object)을 만들어야 합니다. 또는 Return Type 이 원하는 Type이 아니라면 소통에 Fail 이 납니다.
일반적으로 개발자가 보유한 지식은 사물지이거나 사실지입니다. 하지만, 업무스킬의 출발은 방법지이어야 합니다. 협업이란 문제를 해결하는 과정이기 때문에, 사실지를 늘어놓아봐야 의미가 없습니다.
하지만, 일을 하다보면 소통에도 에러가 존재합니다. 이 에러와 방법지를 가미해서 지혜를 만들어야 합니다.
지혜는 상황에 따라 달라지는 해법입니다. 지식에 머무르지 않고 지혜화하는 것이 업무스킬의 궁극이 아닐까 합니다.
벤치마킹 : 성공한 비즈니스맵의 업무스킬
아래는 일반적인 비즈니스맨을 위한 “업무스킬” 가이드입니다. IT도 100년, 200년의 역사가 쌓이면 아래와 같이 정형화된 도표가 생기지 않을까요?
설명에도 기술이 필요하고, 제안에도 기술이 필요합니다.
회사나 조직 속에서 일을 한다면, 전문 기술을 배우는 것 외에 일반 회사생활을 위한 “업무스킬”을 익히는 것이 필수입니다.
하지만, 짧은 IT역사로 인해 참고할만한 교재들이 없습니다. 조금 다르긴 하지만 다른 산업군으로부터 업무기술을 벤치마킹해서 익혀나갈 필요가 있습니다.
[IT의 중심에서] 시리즈 이전 글
(12) 가트너의 Hype Cycle을 아시나요?
(11) DevOps 란 무엇일까?
(10) 개발상식1. 콘웨이의 법칙
[fbcomments url=”http://ec2-13-125-22-250.ap-northeast-2.compute.amazonaws.com/2018/01/19/subokim-businessskills/” width=”100%” count=”off” num=”5″ countmsg=”wonderful comments!”]
