it is power

모든 스타트업에게 '좋은 개발자를 뽑는 것'은 아주 중요한 일입니다. 혼자서 모든 개발을 다 할 생각이 아니라면 더더욱 그렇죠. 그렇다면, 좋은 개발자를 뽑으려면 어떻게 해야 하는 걸까요?

1. 어떤 개발자가 필요한지를 명확하게 하라

개발자는 만능이 아니므로 '필요한 개발자가 어떤 부류인지' 명확하게 해 놓으면 도움이 됩니다. 필요한 분야에 맞지 않는 개발자를 전부 경력 부족으로 치부할 필요는 없겠지만, 뽑아야 하는 개발자가 갖추어야 할 기술이 어떤 것인지 명확하게 해 놓으면 도움이 되죠.

2. 회사의 비전을 공개하라

비전은 여러 가지 측면으로 구성되는데, '성공할 것으로 보이는 아이템'도 그 중 하나겠지만, 유무형의 적절한 보상 체계도 거기 포함됩니다. 자기 개발 가능성도 빼 놓을 수 없겠죠. 그런데 어쨌든 중요한 것은, 이런 비전들이 내부적으로만 공유되는 것이 아니라 외부로도 공개되어야 한다는 것입니다. 회사 웹 사이트를 잘 구축해 놓거나, 회사가 자체적으로 운영하는 블로그 등이 그런 목적을 달성하는 데 유용합니다. 그러니 그런데 쏟는 노력을 아까와 하지 않는 것이 좋겠어요.

3. 회사의 문화를 명확하게 하라

애플, 마이크로소프트, 구글 등등은 전부 회사의 개발 문화가 명확합니다. 좀 단순한 면이 없잖아 있지만 이 세 회사의 개발 문화를 각각 한줄로 요약해 보면:

(1) 애플: 까라면 까라. 대신 너희는 세상을 바꾸는 일에 동참하게 된다.

(2) 마이크로소프트: 인재를 인재답게 대우해준다. 최대한의 대우를 약속하지만 자유는 포기하라.

(3) 구글: 개발자가 원하는 모든 형태의 자유를 준다. 그 자유를 회사를 위해 써라. (?)

회사의 문화가 명확하고 공개되어 있으면, 개발자가 회사를 선택하는 일이 좀 수월해집니다. 여러분의 회사도 마찬가지입니다. 이 때 중요한 것은 회사 문화에 대해서 거짓말을 하면 곤란하다는 겁니다. 그런 짓을 하면 나중에 '악평'을 덤으로 얻을 수 있습니다.

4. 쾌적한 근무환경을 만들어라

몇 명으로 시작하는 초기 단계에서는 어쩔 수 없는 일일지도 모릅니다만, 그렇더라도 회사의 근무환경은 최대한 쾌적하게 꾸밀 필요가 있습니다. 초기 단계에서 이 작업은 파티션 등을 쌓아올리는 구조적인 작업이라기 보다, 자유와 자율을 중시한다는 느낌을 주는 심미적인 측면에서 접근할 필요가 있습니다.

5. 인맥을 적절히 활용하라

언제나 그렇습니다만, 구인 광고만 올린다고 사람이 오진 않습니다. 회사 홍보는 좋은 개발자를 뽑는 데 필수일 수밖에 없고, 지명도가 올라간 이후에도 꾸준히 이루어져야 하는 활동입니다. 그리고 보통 이 바닥에서 '홍보'의 한 수단으로 가장 효과적인 것 중 하나가 바로 인맥이죠. '한 다리 건너 아는 사람'이 좋은 개발자일 확률은 굉장히 높습니다. 중간에 낀 '한 다리'가 바로 그 '아는 사람'과 일해본 경험이 있는 경우가 대부분이기 때문이죠. 일해본 사람은 그 사람이 어떤 사람인지 알고, 서로 무엇이 아쉬운지 잘 알게 마련이죠.

출처 : http://www.buggymind.com/m/509

이번 개발문화 이야기는 '회의 문화'다.

회의 문화는 IT 분야에만 국한된 얘기가 아니다. 이미 많은 논의가 있었고, 회의 문화가 개선된 회사들도 많다. 그러나 변화가 필요한 회사들도 아직 많다.

회의가 많은 회사는 망한다는 속설도 있는데, 하루종일 회의하느라 정작 일은 퇴근 시간 지나서야 할 수 있다고 하소연하는 고참 개발자나 팀장들을 많이 봤다. 회의를 많이 하는 증상이 있는 회사는 회의 자체의 문제보다 근본적으로 해결해야 할 문제들이 따로 있을 가능성이 높다.

회의를 하는 방식 자체보다는 근본적인 원인에 대해서 얘기를 해보고자 한다.

첫째, 우리나라 회사들은 재택근무가 쉽지 않다. 이것은 여러 문화의 결과이기도 하다. 업무지시를 서로 만나서 해야 하고 얼굴을 봐야만 얘기가 되는 상황이라면 재택근무로 일하기 어렵다.

지금 같이 일하고 있는 동료들이 모두 집에서 일한다고 생각하면 어떻게 될지 상상을 해보자. 전혀 일이 진행되지 않거나 효율이 너무 떨어진다면 다시 한번 생각해봐야 한다.

회의를 통해서 해결하는 안건의 상당수는 만나지 않고 시스템을 통해서 온라인으로 충분히 의논할 수 있는 것들이다. 물론 회의를 통해서 해결하는 것이 효율적인 안건들도 있다. 이런 안건도 만나서 난상토론을 하기 보다는 이슈를 다 정리한 후에 공유하고 몇가지 핵심 결정사항만 회의를 통해서 해결하면 된다.

굳이 만나서 해결할 필요도 없고 전화나 화상회의로도 충분히 가능하다. 내용은 이미 공유되어 있고 핵심 사항만 의논하고 결정하면 되기 때문에 시간도 얼마 걸리지 않는다. 그리고 일하는 과정이 시스템을 통해서 투명하게 공유가 되면 굳이 만나서 회의를 해야 할 일은 대폭 줄어들게 된다.

SI 프로젝트를 진행하다 보면 고객이 개발자의 출석체크를 한다는 얘기도 있다. 모아 놓고 일을 하지 않으면 일이 제대로 진행 되지 않는다고 생각하고 안보이면 제대로 일을 하고 있다고 믿지도 못하는 것이다. 이 또한 투명하게 일이 진행되지 않는 것이 주요 원인 중 하나다.

재택근무 대신 모여서 일을 한다고 해도 재택근무가 가능한 형태로 일을 해야 더 효율적이다. 현재 재택근무가 불가능하다면 근본 원인을 생각해보자.

둘째, 경영진에 보고하는 회의가 비효율적이다.

주간회의와 같은 형태로 주기적으로 정리를 해서 한주간의 업무를 부서별로 취합, 정리해서 보고를 하는 형태의 회의는 우리나라에서 아주 흔하게 볼 수 있다. 다른 분야에서는 어떨지 모르겠지만 소프트웨어 분야에서 이런 형태의 보고회의는 많은 문제를 유발한다. 이런 회의가 없어야 한다는 것은 아니다.

그러나 이런 회의는 준비과정에 많은 시간이 걸리고 대부분의 회사에서 개발자를 겸하고 있는 개발팀장들의 시간을 많이 소모한다. 그리고 취합되고 정리되는 과정에서 많은 핵심정보는 사라지고 예쁘게 꾸며진다. 경영진은 적나라한 개발현황은 보고 받지 못하고 화장이 잘 된 보고를 받게 된다.

앞에서도 얘기했지만 모든 개발과정은 시스템을 통해서 투명하게 공유되어야 하고 경영진은 이 시스템들을 통해서 개발 진행상황을 직접 볼 수 있어야 한다. 경영진이 약간의 노력을 보여주는 것도 필요하지만 시스템이 경영진이 필요한 보고서를 실시간으로 만들어 낼 수 있어야 하고 우선적으로 개발문화가 투명하게 바뀌어야 한다.

경영진은 실시간으로 모든 개발상황을 파악할 수 있어야 하고 시스템을 통해 이슈 관련 논의에 직접 참여해야 한다. 앉아서 보고를 받고 구도로 지시하는 방식으로는 너무 비효율적이고 느리다. 회의시간에는 중요한 이슈 몇가지만 논의하면 된다. 시스템에 있는 정보를 굳이 다시 보고를 받을 필요는 없다.

회의에 관련해서 몇가지 이슈를 섞어서 얘기를 했지만 이 또한 여러 개발 문화와 얽혀있다. 공유가 부족하면 수시로 만나서 물어봐야 하기 때문에 회의가 많아진다. 문서화를 싫어하니 정리한 후에 간단히 결정만 해도 될 회의를 만나서 얘기로 다 풀어야 한다.

시스템을 통해서 논의를 했으면 자동으로 공유가 되는데 만나서 논의한 내용은 기록에도 남지 않는다. 나중에 딴 소리를 하기도 하고 다른 사람들이 내용을 모르니 똑같은 사안을 또 물어본다. 시스템에 개발 현황이 투명하게 공개가 안되니 일일이 만나서 공유해야 한다.

뭐든 빨리 빨리 해결하려고 하니 일단 이슈가 생기면 시간이 약간 더 걸리더라도 효율적인 시스템을 이용하지 않고 즉시 만나서 해결하려고 한다. 문서를 작성하고 공유하는 것에 습관이 안돼 있으면 회의를 하면서도 기록을 하지 않고, 그렇다보니 결정사항을 추적하는 것도 쉽지 않다.

이처럼 이제부터 회의문화를 개선해보자고 회의 방법만 고쳐본들 별로 나아지는 것을 없을 것이다. 재택근무가 마치 옆에서 일하는 것처럼 효율적으로 가능할 정도로 근본 원인을 하나씩 개선해야 한다. 그러려면 프로세스, 기반시스템도 바뀌어야 하지만 무엇보다 전반적인 개발문화가 바뀌어 나가야 한다.

그래야 회의 문화도 조금씩 개선이 되고 회의 횟수와 시간도 줄며 좀더 효율적인 회의문화가 정착 될 것이다.

객체 지향 프로그래밍의 방법론을 그림으로 나타내는 수단

정의 : http://terms.naver.com/entry.nhn?docId=862881&cid=2636&categoryId=2636

구성 : http://prosigi.tistory.com/141