태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

관리자가 이런 일까지?

2012/02/13 03:43 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다.

물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다.

개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와는 약간 다른 얘기다. 이런 개발 팀장은 SW 개발자에 더 가깝고 관리업무는 부수적인 일이다. 물론 개발도 한다.

하지만 개발에서 손을 완전히 땐 관리자의 경우는 점점 개발과 멀어지게 된다. 이렇게 1~2년만 지나도 섣불리 기술에 대해서 얘기하기가 어려워 진다.

이 외에도 개발 경험은 거의 없는 관리자도 있다. 반대로 이런 관리자도 SW 조직 관리를 2~3년 하게 되면 풍월을 읊게 된다. 개발에 대한 왠만한 용어도 알게 되고 어떻게 돌아가는지 대충 파악이 된다. 그렇다고 기술을 아는 것이 아니다.

그런데, 과거에 개발자였던, 개발을 모르는 관리자던 이들이 개발에 있어서 기술적인 결정들을 좌지우지 하는 경우가 있다. 

조직의 상하를 떠나서 기술적인 결정의 책임은 개발자들에게 있는 것이지 관리자에게 있는 것이 아니다. 좀더 중요한 기술적인 결정은 일개 개발자를 떠나서 기술위원회나 CTO가 결정하는 것이다.

하지만 우리나라에서는 상하관계가 엄격하여 기술적인 결정도 관리자들이 영향을 미치는 경우가 많다.
이를 상하 관계가 아닌 역할의 구분으로 생각하는 것이 좋다.
개발과 관리의 전문적인 역할 구분으로 생각하자.

현재 이러한 판단을 하기 애매한 위치에 있다면 기술이든 관리든 하나를 정하는 것이 좋다. 둘다 잘하기는 거의 불가능하다. 개발팀장으로서 관리도 약간 해야 한다면 작은 조직에서는 그야말로 약간만 하는 것은 괜찮다. 이것도 큰 조직에서는 쉽지 않다.

기술은 기술자의 몫이다.
 
image by Brain farts
저작자 표시 비영리 변경 금지

전규현 개발조직

Trackback Address: http://allofsoftware.net/trackback/249 관련글 쓰기
  1. 이글을 지금 일하는 사업의 PM이 봤으면 좋겠네요 ㅋ
    매번 잘 보고 갑니다~

QA팀은 없다고 생각하라

2010/10/11 18:41 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



저는 여러 소프트웨어 회사를 접할 기회가 많기 때문에 우리나라의 소프트웨어 현실을 다양하게 보게 됩니다.

많은 회사들이 전문 QA팀없이 개발자가 테스트를 하곤합니다. 제가 접한 소프트웨어 회사들의 대략 70% 이상이 전문화된 QA가 없었습니다. 심지어는 대기업에 속한 회사들도 QA팀 없이 개발자나 팀장이 테스트를 하는 경우도 있습니다.

그 이유야 제가 이전에 여러번 언급했듯이 주먹구구식 개발이나 형식에 치우친 프로세스를 채용한 회사들은 개발자가 아니면 그 기능을 속속들이 잘 모르기 때문에 개발자나 팀장이 테스트를 할 수 밖에 없고 누가 좀 도와준다고 하더라도 Random 테스틑 밖에 수행을 하지 못합니다.

이 이슈는 차치하고 소수의 QA팀을 가지고 있는 회사들에서는 QA테스트가 제대로 이루어지고 있는지 확인을 해볼 필요가 있습니다. 제 경험에 의하면 많은 회사들이 QA팀이 있다고 하더라도 QA팀을 충분히 활요하지 못하고 있었습니다. 이런 경우들이 존재합니다.

- QA팀에게 개발자의 일을 떠넘기는 경우
QA팀이 무슨일을 하는 것인지 정확하게 모르는 경우입니다.

- QA팀에게 테스트를 할 수 있는 충분한 정보를 제공하지 않는 경우
QA팀이 있다고 해도 또 주먹구구식으로 테스트를 하거나 QA팀이 제품의 기능을 알아내기 위해서 제품을 일일이 써보는 수밖에 없는 경우입니다. 수박 겉핧기씩 테스트를 할 수 밖에 없고 많은 버그는 고객들이 찾아줍니다. 

- QA팀의 테스트 결과를 비난하는 경우
QA팀의 책임이 무엇인지 모르는 경우입니다.

이 중에서 첫번째에 대해서 얘기를 해보려고 합니다. 
소프트웨어 회사들이 QA팀 없이 개발을 하다가 QA팀이 생기고 또는 테스트 전담 인원이 생기면 개발팀의 자신들이 그동안 해 왔던 테스트를 QA팀에서 대신 해줄 것으로 착각을 하곤합니다.

엄밀히 말하면 이는 잘못된 생각입니다. 대부분의 개발자들이 하는 테스트는 QA테스가 아닙니다. 개발자들이 개발과정에서 당연히 해야할 유닛테스트와 통합테스트일 뿐입니다. 

개발자들은 자신들이 하던 테스트를 도와줄 사람이 생겼다고 생각하고 대충 구현을 해서 QA팀에 넘겨버립니다. 그러면 QA팀에서는 버그투성이인 제품을 테스트하느라고 시간을 낭비하곤 합니다. 그래서 정작 제대로 된 테스트는 해보기도 어려운 경우가 허다합니다. 이런 회사들의 특징은 개발자와 QA팀이 타이트하게 붙어서 개발자가 개발을 하는대로 바로바로 테스트를 해줍니다. 혹시 이런 형태로 개발을 하고 있다면 QA팀을 전문가로 생각하지 않고 개발팀의 심부름꾼 정도로 생각하고 제대로 활용하지 못하고 있고 생각할 수 있습니다.

개발자들은 QA팀이 없다고 생각하고 완벽하다고 생각하는 코드를 작성해서 QA팀으로 넘겨야 합니다. QA팀은 이렇게 만들어진 제품을 제대로 검증할 책임이 있습니다.

먼저 QA팀의 역할이 무엇인지 정확하게 이해해야만 QA팀이 제 역할을 할 수 있습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by episode8
 


저작자 표시 비영리 변경 금지

전규현 개발조직 qa, 테스트

Trackback Address: http://allofsoftware.net/trackback/197 관련글 쓰기
  1. QA팀이 없다고 생각하지 않아도 실제로 없는게 참...
    좀더 많은 회사에서 제대로 된 QA팀이 운영되기를 바랍니다. ㅎㅎ

  2. 안녕하세요. 제주소년님
    회사의 규모가 얼마나 되나요? 개발자의 인원수에 따라서 QA팀을 운영하는 방법이 달라질 수 있습니다.

  3. QA팀이 개발자의 심부름꾼정도라.. 정말 동감이죠 'ㅅ'
    개발 하다가 나름 QA쪽의 비젼을 보게 되었고, 계속 개발 관련 공부도 하고 QA관련 공부도 계속하는데..

    현실은 답답하기만 하네요.
    적은 규모의 QA팀도 아니고 나름 조직 자체는 제대로 세팅되었다고 하는데..

    가장 큰 문제는 말씀해 주신대로 전체 조직의 인식인 것 같습니다.

  4. Noel님 반갑습니다.
    QA팀이 일단 세팅되면 또 새로운 도전이 시작됩니다. ^^

  5. Blog Icon
    qahuni

    반갑습니다.

    충분한 testbasis를 얻기 위해 개발프로세스와 QA의뢰절차를 개선하고 있습니다.
    개발조직에서는 문서쓰는 것을 힘들어 하고, 심지어 소비적으로 느끼고 있습니다.

    V-Model 등에서는 각 단계별로 testbasis가 산출되어야 하고, 테스트 후 testware가 산출되어야 한다고 정의합니다.

    개발조직에서는 요즘같이 빠르게 변모하고 있는 시대에 매우 뒤처질만한 행동이라고 반박합니다.

    저는 그래도, Agile이라 하더라도 정의되고 리뷰되어야 할 것들은 문서가 반드시 필요하다고 생각합니다.
    기능명세나, 기본설계서 정도는 필수라고 생각하지요.

    실제 다른 회사들은 이 문제를 어떻게 풀고들 계신지요?
    기능명세 없이 테스트를 기획할 순 없지 않을까요?

개발팀장과 프로젝트관리자(PM)

2010/10/04 11:13 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


오랫만에 찾아뵙니다.
요즘 워낙 바쁜 날을 보내고 있다는 핑계로 블로그 포스트를 자주 못하고 있습니다. 다시 힘을 내서 시작하려고 합니다.

최근에 컨설팅에 많은 시간을 보내고 있는데, 컨설팅을 하면서 주로 겪게 되는 현실적인 얘기 위주로 적어볼까 합니다. 그 중에서 가장 흔히 보게 되는 것이 개발팀장의 애매한 포지션입니다.

당신이 개발자라면 또는 개발팀장이라면 어떠한 일을 하고 있는지 잘 살펴 보시기 바랍니다. 제가 여러 회사를 컨설팅하면서 만나본 개발팀장의 역할은 천차만별이었습니다. 

공통점은 있습니다. 개발자로서 오랫동안 일을 하다가 개발팀장이 되었다는 것입니다. 
하지만 현재 하고 있는 일들은 천차 만별입니다.

어떤 개발팀장은 여전히 코딩에 90% 매진하고 있고, 어떤 사람은 프로젝트 관리만 하고, 어떤 사람은 회사 경영회의 쫒아다니면서 바쁜 나날을 보내고 있고, 어떤 사람은 코딩도 하고 관리도 하고 정신 없이 시간을 보내는 사람도 보았습니다.

개발팀장은 "개발팀"의 "장"이란 의미를 가지고 있어서 관리자로서의 역할을 요구하고 있는 듯하지만 대부분의 소프트웨어 회사에서는 가장 경험이 많고 뛰어난 개발자들이 맡고 있습니다.  

하지만 회사에서는 "장"이라는 의미에 따라서 개발자로서의 뛰어난 역할도 계속 해주기를 원하면서 관리도 하기를 원하는 경우가 많습니다. 개발팀에서 필요한 관리란 일반관리와 프로젝트관리인데, 보통 개발팀에서 일반관리는 할일이 별로 많지 않습니다. 일반관리 이슈가 매우 크다면 프로세스나 시스템을 개선해야 할 것입니다. 

따라서 이슈가 되는 것은 프로젝트 관리인데, 이것이 그렇게 만만한 일이 아닙니다. 즉, 개발팀장이 최고의 개발자로서 스펙도 잡고, 설계, 코딩도 하면서 할 수 있을 만큼 프로젝트관리가 간단하지 않습니다. 보통 어디하나 펑크가 나게 되어 있습니다. 

제 경험상 보통 프로젝트 관리에서 문제가 생기는 경우가 많습니다. 개발팀장은 개발자체는 원래 하던일이고 익숙하지만 프로젝트 관리는 경험도 적고 대부분 방법도 모르기 때문에 상식선에서 개발하느라고 바쁜 시간에 짬을 내서 하기 때문에 문제가 생기기 십상입니다.

그래서 필자는 개발팀장은 계속 최고의 개발자로서 개발 조직을 기술적으로 이끌고, 프로젝트 관리는 전문 PM(Project Manager)에게 맡기는 것을 권장합니다. 물론 개발자 출신으로 꼼꼼하고 관리를 좋아하는 사람이 PM으로 성장하는 것도 좋습니다.

개발조직이 10명 미만이고 대부분 소규모 프로젝트만을 진행한다고 하면 PM을 따로 두지 않아도 어떻게든 프로젝트가 진행이 될 수 있을 겁니다. 하지만 조직이 커지고 프로젝트가 복잡해지고 많은 프로젝트를 수행한다면 프로젝트의 성패는 요소기술에 달려 있지 않다는 것을 알게 될 것입니다. 이쯤되면 전문 PM이 없다면 가장 뛰어난 개발팀장들은 기술에 매진하지 못하고 잘하지도 못하는 프로젝트 관리에 허덕일 것입니다.

개발팀장은 쉽게 대체가 되지 않지만 PM은 외부에서 영입을 하는 것도 가능합니다. 즉 외부에서 영입한 사람이 할 수 있는 일을 회사에서 가장 바쁘고 가치 있는 일을 하는 개발팀장에게 맡기는 것은 비효율적입니다.

그렇다고 PM이 아무나 할 수 있다는 뜻은 아닙니다. 이또한 전문적인 일로서 전문가가 해야 하는 일입니다.

지금 일반관리자, 개발팀장, PM 등이 마구 섞여서 일을 하고 있다면 일단 임무를 나누어서 생각하는 습관을 들여야 할 것입니다. 그리고 현재 어느부분에서 문제가 생기고 있고 어느 역할을 보충해야 할지 계획을 세워서 조직을 튼튼하게 해야 합니다. 그렇지 않고 개발자 인원수만 늘여서는 현재의 많은 문제들이 해결되지 않습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by Dunechaser

저작자 표시 비영리 변경 금지

전규현 개발조직

Trackback Address: http://allofsoftware.net/trackback/196 관련글 쓰기
  1. Blog Icon
    csj

    예전 피터 드러커의 책에 나온 비슷한 내용이 생각납니다.
    직위가 올라갈 수록 계속 역할은 바뀌는데, 그 바뀐 역할을 빨리 인지해야 성공할 수 있다는..
    뭐 그런 이야기 였는데요 아마 비슷한 맥락이 아닐까 생각합니다.
    아쉽게도 학부 때 읽은지 오래되어서 책 재목이 생각나지 않는군요 ㅎㅎ
    하지만 현실에선 개발자는 슈퍼맨이 되어야만 하죠 ㅠ.ㅜ

  2. 안녕하세요. csj님
    일부 비슷한 맥락이 있을 수도 있겠네요. ^^ 요지는 전문적인 Role이 중요하다는 뜻입니다.

  3. 안녕하세요 규현님.
    전 PM과 팀장이 나뉘어져 있던 프로젝트를 경험한 적이 있습니다.
    효율적으로 보였으나 그들간의 업무가 중복되었고, 팀장은 실제 프로젝트에서 무엇을 하는지 모를정도로 얼굴을 비추지 않더군요. 간혹 그런케이스를 제외하곤 역시나,.. 큰 프로젝트 일수록 팀장과 PM을 분리하여 역할을 분담하는 것이 더 효율적이라고 생각합니다.
    오랜만에 글이 올라와서 오랜만에 기분좋게 댓글 달고 가요~~ 파이팅~~!

  4. moova님 안녕하세요.
    PM은 전문적인 롤로서 나름대로 표준적인 뜻을 가지고 있지만, 팀장은 그야말로 천차만별로 회사마다 뜻이 다릅니다. 이런 경우는 관리자로서의 팀장을 말하는 것 같습니다.
    PM은 프로젝트 관리, 팀장은 팀 일반 관리를 나눠서 하다보면 Conflict가 나는 경우가 있고, 개발자는 중복 보고를 하기도 합니다. 회사가 워낙 크고 관리가 복잡한 경우라면 모를까 대부분의 경우 소프트웨어 회사에서 개발자에 대한 일반관리는 그렇게 많이 필요하지 않습니다.
    관리를 하는 사람이 둘이 있으면 말씀 하신 것과 같이 문제가 종종 발생하죠.

    제가 말하는 팀장이란 대부분의 소프트웨어 회사에서 그러하듯이 테크니컬 리더를 말합니다. 이런 경우 PM의 중요성에서 대해서 말하고자 합니다.

  5. Blog Icon
    장림

    개발팀장과 PM이 다를 경우에 발생할 수 있는 문제점은 잘 모르겠군요.
    어떤 문제점들이 있을까요?

  6. 안녕하세요. 장림님
    회사마다 팀장의 롤이 다르기 때문에 PM과 Conflict가 나는 경우에는 문제가 발생할 수도 있겠네요. ^^

개발자의 파워는 어디에서 오는가?

2010/08/03 17:37 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



뛰어난 개발자를 관리자로 써먹는 것 같이 개발조직에 비효율적인 일은 별로 없습니다.

하지만 현실에서는 이런 일이 흔히 벌어지고 있습니다. 실제로 저도 여러 회사에서 자주 접하고 있습니다.
여러가지 이유가 있을 수 있겠지만 주요 이유는 회사에서 개발자로서 꾸준히 성장할 수 있는 Career Path를 보장하기 않기 때문입니다.

회사에서 파워를 가지려면 팀장이 되어야 하고, 그래야 개발자들을 거느리며 힘을 행사할 수 있게 됩니다.
하지만 일단 팀장이 되고나면 개발에 전념할 시간은 점점 줄어들게 됩니다. 그렇다고 개발을 포기하고 관리만 하기에는 관리할 일의 양도 얼마 되지 않고, 파워가 줄어들게 될 까봐 걱정을 하게 됩니다.

흔히들 개발자는 행정적인 파워가 없어도 기술력에 따른 카르스마에서 파워가 생긴다고 하지만 이는 실제 현장에서는 공허한 얘기가 됩니다.

제대로 세팅된 소프트웨어 회사라면 개발팀은 관리할 것이 그렇게 많지 않습니다. 하지만 그렇지 못한 회사는 이래저래 관리할 일이 점점 늘어나게 되서 불필요하게 팀장의 관리에 많이 의존하게 됩니다.

이렇게 뛰어난 선임개발자들이 개발과 관리를 넘나드는 사이에 기술은 점점 멀어지게 되고 돌아올 수 없는 강을 건너는 경우가 예사입니다.

결국 100원짜리 개발자를 10원짜리 관리자로 만들고 맙니다.

물론 개발자 중에는 관리능력도 뛰어나서 관리자 역할을 훌륭하게 수행해 내는 사람도 있습니다. 
이 경우 개발자가 개발보다 관리에 관심이 많고 관리 능력이 더 뛰어나다면 관리자로 전환하는 것도 좋을 겁니다. 하지만 개발과 관리 둘다 능력이 좋다면 개발을 선택하는 것이 좋을 겁니다. 개발이 훨씬 부가가치가 높으며 다른 사람으로 쉽게 대체할 수가 없습니다. 둘다 훌륭하게 수행해내기를 바란다면 욕심입니다. 

뛰어난 개발자를 개발자로 있게하려면 회사에서 경력을 보장해줘야 합니다. 
개발자로 꾸준히 성장할 수 있는 Position을 만들어야 하고 연봉에서 대우을 해줘하고 관리자 이상의 파워를 가질 수 있는 제도를 마련해줘야 합니다. 그렇지 않는다면 뛰어난 개발자들이 개발과 관리사이에서 끊임없이 고민하다가 많은 개발자들이 관리자로 전환되면서 회사에 손해를 끼치게 될 겁니다.

수평적인 조직구조를 가진 외국의 회사들과 다르게 수직적인 조직구조를 가지고 있는 우리나라 회사에서 개발자에게 힘을 실어주기란 쉽지 않습니다. 그래서 제도적으로 뒷받침이 되지 않으면 어렵다는 것입니다.

현실적으로 쉽지 않은 일임을 공감합니다. 개발에 대한 전문성을 인정해주는 분위기가 같이 성장을 해야 개발자 경력 보장도 점점 이루어질 것입니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by xJasonRogersx
저작자 표시 비영리 변경 금지

전규현 개발조직

Trackback Address: http://allofsoftware.net/trackback/195 관련글 쓰기
  1. 2010/10/12 00:10
    허니몬의 생각 Tracked from sunfuture's me2DAY
  1. 글 잘 읽고 갑니다. :D

  2. 안녕하세요. 우울한 딱따구리님...
    요즘 워낙 바빠서 블로그 포스팅이 뜸해지네요.
    그래도 언제나 글을 읽어주셔서 감사합니다.

  3. 개발과 관리를 둘 다 잘 하는 사람이 있으면 관리를 시키는 것이 낫지 않을까 싶습니다.

    관리 잘 하는 사람이 많은 것 같아도 사실 개발자와 프로젝트를 관리 할 수 있는 관리자는 정말 뛰어난 개발자보다 더 소수가 아닐까 싶거든요.

    이런 관리자가 있어주어야 그 밑에서 정말 개발만 잘 하는 사람들이 편하고 효율적으로 일 할 수 있지 않을까 싶기도 하구요.

  4. 안녕하세요. bookworm님
    우리는 흔히 팀장과 PM을 혼동하곤 하는데, 위에서 언급한 내용은 팀장, 즉 일반관리자 역할입니다.
    팀장은 관리자트랙인데 비해서 PM은 특수한 영역으로서 개발자와 관리자의 중간쯤에 있는 트랙입니다. 즉 개발도 잘 이해하고 관리도 잘할 수 있는 사람들의 영역입니다.

    일반적인 작은 회사나 작은 개발팀은 전문적인 PM이 필요하지도 않고 관리도 그렇게 많이 필요하지 않습니다. 그냥 선임 개발자가 대춤 겸업을 해도 큰 문제가 발생하지 않습니다.
    그래도 우리는 보통 마구 혼동해서 사용합니다. 하지만 규모가 커지기 시작하면 모든 영역이 매우 전문화가 되어야 합니다.

    말씀하신 내용은 PM에 가까운것 같습니다. 프로젝트가 커지면 PM의 역할이 정말로 중요하고 뛰어난 PM이 프로젝트 성공에 가장 큰 역할을 하며 책임도 큽니다. 개발자중에서 PM 트랙을 선택하는 것도 좋은 선택중 하나라고 생각합니다. 단, 우리나라에서는 PM의 역할에 대해서 제대로 정의가 안된 회사가 많기 때문에 자칫 이직시 애매해지는 경우가 많은 것 같습니다.

    아무튼, 아직 개발자, PM, 관리자에 대한 전문성에 대한 이해가 전반적으로 부족한 분위기는 차츰 바꿔나가야 하겠습니다.

  5. 말씀하신 부분에 공감합니다.

    우리나라는 아직 일반 관리자, PM, 개발자 등의 역할이 전문화가 안 된 것 같습니다.

    개인적으로 개발자로 하고 싶은 것이 많은데 일반 관리부터 PM까지 겸업하려니 고민과 갈등이 많습니다.

  6. 관리자라고 한다면 피플매니징이 주요 업무여야 한다고 봅니다. PM은 말 그대로 프로젝트만을 관리해야 하는 거구요.

    예전까지는 팀장 = 관리자 = PM이었는데(종종 프로젝트에 따라서 PM이 아닌 경우는 있었지만), 외국계는 이 매니저와 PM이 확실하게 다른 캐리어 트랙을 타더군요.

  7. 안타까운 현실에 우울하죠.
    몇 년 뒤면 이제 40이 되는데, 등 떠밀려 선택을 하게 되겠죠? ㅡ,.ㅡ;;

  8. whiterock님 안녕하세요.

    계속 개발을 하고 싶은 개발자들이 등떠밀려 관리자가 되는 것은 개인이나 회사에 모두 손해입니다.
    본인의 의지를 회사에 피력을 해보시죠. 회사 사정은 정확하게 모르지만 시도를 해보시는 것이 어떨가요?

  9. 앞으로의 진로를 고민하는 사람으로 말씀하신 것처럼 문화가 바뀌기를 바라고 있지만, 현실적으로 한국 기업문화에서는 쉬운 부분은 아니라고 생각합니다. 저 또한 그렇게 만들고 싶고 그러기 위해서는 힘(?)이 있어야 하고, 힘을 가지려면 관리자가 되어야하니까요..아쉬운 현실입니다.
    님께서 가지고 계신 가치관이 많이 전파되었으면 하는 바램입니다. 글 감사합니다.

  10. 꼬부가빠님 안녕하세요.
    기업이 생존을 위해서는 어쩔 수 없이 이렇게 하지 않으면 안됩니다. 한국의 기업문화 그대로 따라서는 살아남을 확률이 너무 많이 떨어집니다.
    변화는 선택의 문제가 아니고 생존하느냐 죽느냐의 문제입니다.

  11. Blog Icon
    thankee

    제가 잘 몰라서 그런지, 너무 타성적으로 들리네요. 직장을 잃는 것이나, 평소의 삶이(특히 안좋은 쪽으로) 변화될 수 있다는 두려움때문에 오히려 자신의 꿈을 다른 요인에 의해서 이룰 수 없다고 스스로 합리화하고 있는 것 아닌가요? 자신의 꿈이 확고하다면 어떠한 변화도 감수할 수 있는 태도와 생각이 당연 생기게 마련이라고 생각합니다.

  12. thankee님 안녕하세요.
    무슨 말쓴인지?

  13. Blog Icon
    godway

    Postion 이라고 쓰신 부분이 Position 맞죠?

  14. 안녕하세요. godway님

    당연히 오타죠. - -; 바로 수정했습니다.

  15. Blog Icon
    대한민국 개발자

    마지막 까지 살아남는자가 최고의 승자이죠

  16. 외국에서는 10년 정도 개발하면 이제 조금 하는 구나
    하는데 우리나라는 5년정도 개발하고 관리자로
    빠지니 관리도 못하고 기술도 잘 모릅니다.
    그러면서 기술은 중요하지 않다라고 하죠.

  17. beyondj2ee님 안녕하세요.
    10년차와 20년차가 또 다르죠.
    그런데 우리나라 대부분의 SW 개발자들은 그 차이가 별로 없는 경우가 많습니다. 고참 개발자들이 신참과는 다르게 무슨 일을 어떻게 해야 하는지 모르는 경우가 대부분입니다.

  18. 우리나라의 대부분의 SW업체가 중소기업이지만....
    워낙 작은 회사는 모든 구분이 참 애매모호합니다.
    또한 회사 업무 내용이나 개발 규모등에 따라서도 많이 틀려지겠죠

    우리회사 같은 경우에는 한두사람이 하나의 프로젝트를 개발하고
    다수의 기존 프로젝트 유지보수까지 끌고 가는 상황이라
    별도의 관리자나 PM등이 있지도 않고요
    개발자가 계속 경력을 쌓고 개발을 할 수 있도록 지원할 생각은 하고 있습니다.

    개발자에게 힘을 실어주는 제도라는게 구체적으로 어떤 예가 있을까요?

  19. 크레브님 안녕하세요.
    작은 회사에서는 한사람이 여러 프로젝트를 진행하기도 하고 여러 역할을 겸임하기도 합니다. 아주 일반적인 현상입니다.
    단, 여러일을 겸임할 때도 역할의 구분을 하는 것이 좋습니다. 즉 최소화를 해야 좋지만 문서도 만들고 프로세스도 따른 것입니다. 그래야 조직이 조금씩 커지면서 자연스럽게 업무들이 분배됩니다.
    혼자 여러일을 한다고 혼자만 알 수 있게 또, 구분없이 일들을 마구 섞어서 하게 되면 인원이 늘어가도 효율적으로 돌아가지 않습니다.

    개발자에게 힘을 실어주는 제도 중 하나는 행정적으로 의사결정을 할 수 있는 권한, 예산을 집행 할 수 있는 권한을 부여한는 것입니다. 사실 회사의 의사결정 중에서 기술적인 것들은 개발자들이 해야 하는 것입니다. 특히 회사의 최고 개발자들이 결정을 해야 합니다. 하지만 개발과 관리가 애매한 회사에서는 기술적인 결정임에도 불구하고 관리자들에 의해서 많이 좌지우지 됩니다. 따라서 기술적인 결정이 개발자에 의해서 결정될려면 회사의 최고 기술자가 최고의 임원자리를 차지하고 있어야 합니다. 그래서 CTO가 필요한 법이지요. CTO에는 개발자에게 Role model이 될 수도 있습니다.

    그럼에도 많은 회사에서 CTO가 관리자의 역할을 하는 것을 보면 사실 CTO가 아닌것이지요. 그냥 연구소장인 것입니다.

    경영자가 기술의 중요성과 전문성을 이해해야만 이 모든 것이 가능합니다.

  20. 드물겠지만 개발을 하고 싶은 사람도 있는데 관리직으로 떠밀린다면 우울할꺼 같아요

  21. 구차니님 안녕하세요.
    개발자도 고참이 되어도 개발자로서 계속 가치를 부여하기 위해서는 달라져야 합니다.
    경력이 많아지는 것만 가지고는 부족합니다.
    뷰도 넓어져야 하고, 비즈니스도 잘 알아야 하고, 많은 프로젝트와 후배들에게 영향을 많이 줘야 합니다.
    그러기 위해서는 회사의 프로세스와 시스템이 잘 갖춰져 있어야 하며 문서화와 리뷰가 잘 이루어져야 합니다.

  22. 공감합니다.
    아직 개발을 더 하고 싶은데 관리자로 되면 힘들것같아요;;

    아직 저는 신입 개발자이지만

    관리자로서 준비를 해두어야 할지
    개발자로서 살길을 찾아야할지 고민입니다.

  23. acude님
    대한민국에서는 어려운 결정입니다.
    아직 신입이시니까 더 좋은 여건입니다. 이미 머리가 굳은 경력이 많은 개발자들은 쉽게 마인드를 바꾸기가 어렵습니다.
    지금부터 꾸준히 소프트웨어 공학에도 관심을 가지고 경력을 쌓아보세요.

  24. 안녕하세요. 오랜만에 들려봅니다. ( 그동안 병원생활하느라;;;)
    여전히 깨어있는 글. 무척이나 공감합니다.
    얼마전 해외에서 일하는 후배와 이야기를 하다가,
    암담한 한국의 소프트웨어 업계와, 그래도 캐리어를 꾸준히 보장해 주는 해외 소프트웨어 업계를 비교해 보고 참.. 한국의 기업들이 개선해야할 부분이 너무 많은것 같아서 답답하기까지 하더라구요.

    물론 해외기업과 한국기업이 문화태생부터 다른 것은 사실이지만 같은 소프트웨어를 다룬다는 입장에서는 똑같을 듯 싶은데.. 왜 한국 기업은 공학인들에게 당연히 보장해 줘야 될 부분들을 그렇게 늘~~ 그늘에 놔두려고 하는지..참 안타깝기 까지 했습니다.

    그리고 기술밥먹는 사람들은 기술밥먹는 사람끼리 뭉쳐서 타 도메인에 대한 상생을 좀 무시하는 경향이 있는것도 같구요.

    또, 말씀하신것처럼 개발자도 소프트웨어공학에 대한 지식을 꾸준히 연마해야 한다고 봅니다. 기업에 프로젝트를 하러 다니면 소프트웨어공학에 대해 관심도 없고, 배우려고 하지 않는 곳이 꽤 많았습니다. 단지 API의 어떤 기술만 외쳐댈뿐이었지요. (숲을보는 인재가 별로 없는 듯) 어디서부터 잘못된 문화인지... 그 원인을 분석하고 개선할 수 있다면 정말 좋겠지만.. 아직까지 먼 세상이라고 느껴집니다.
    부디 깨어있는 분들이 계속 개선점을 고치고 알리어 꾸준히 바뀌어 나가길 희망합니다.

  25. 안녕하세요. moova님
    오랫만입니다. 그동안 쾌차하셨는지요?

    그래도 저와 저의 회사에서는 그동안 여러 회사를 컨설팅하면서 마이드를 많이 바꾸고 있습니다. 그래서 점점 이러한 것들이 파급되고 있다고 생각합니다. 그 일환으로 책도 쓰고 블로그도 하는 것입니다.

    이땅에서 소프트웨어 개발자가 최고의 직업이 되는 날까지 저는 뜁니다. ^^

  26. Blog Icon
    Kevin

    안녕하세요, 이전에 'SVN' 이란 것을 검색하다가 게시된 글들에 흥미를 느껴 간간이 들리고 있는 IT분야 취업 준비생입니다. 간단히, 저의 소개를 하자면 국내 컴퓨터공학과를 졸업했으며 오는 하반기에 국내취업을 목표로 하고있는 젊은 청년입니다. 또한, 현재 Wipro라고 하는 인도 SI업체에서 프로젝트를 맡아 수행중이기도 합니다.
    앞으로 저보다 앞서서, 미래를 그려나가는 선배님들께 좋은 말씀도 들었으면 합니다.
    잘 부탁 드리겠습니다 : )

  27. Keyvin님 안녕하세요.

    새술은 새부대에 보관해야죠...
    경력이 오래된 개발자들은 마인드가 쉽게 바뀌지 않습니다. 그동안 이룩해 놓은 것들과 몸에 밴 습관을 버릴 수가 없기 때문에 그렇습니다.

    그래서 kevin님과 같은 신진들이 더욱 중요합니다.
    처음부터 올바르게 시작해야 합니다. 하지만 현장에서 실제로 일을 하다보면 반대된는 도전에 수없이 직면할 것입니다. 그것이 지금 우리나라의 현실입니다. 여기에 좌절말고 꾸준히 정도를 걸어나가면 뛰어난 개발자가 될 수 있을 겁니다.

    요소 기술만 신경 쓰지 마시고 소프트웨어 공학고 꾸준히 공부를 하고 경험을 하는 것이 중요합니다. 소프트웨어 공학은 공부만 해서는 절대로 익힐 수 없는 것이고 제대로된 경험을 하는 것이 익히는 유일한 방법이며 시간도 많이 걸립니다.

    현장에서 여러 도전에 부딪힐 때 저를 비롯한 선배들이 도움을 줄 수 있기를 바랍니다.

SW회사, 이런 사장이 문제

2009/11/10 16:07 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

모든 회사가 마찬가지이지만, SW회사에서 경영자의 중요성에 대해서는 여러 번 얘기를 했습니다.

여러 경영자 중에서 어설프게 아는 경영자가 아예 잘 모르는 경영자보다 더 무섭습니다.
많은 SW회사 경영자들을 만나보면, 소시적에 코딩도 좀 해보고 밤새우면 개발도 해봤다고 SW 개발을 아주 잘 이해하고 있다고 착각하는 경우를 자주 접하게 됩니다. 또 본인이 상당한 수준의 전문가라고 착각하기도 합니다.

이런 경영자일수록 자신이 잘 알고 있다고 생각하므로 진짜 전문가인 내부 개발자들이나 외부의 목소리에 귀를 기울이지 않게 됩니다.
이는 마치 바둑 7,8급 정도 두는 실력으로 1,2단 실력을 가진 개발자들 머리 위해서 마음대로 휘두르는 것과 같습니다. 

비록 자신이 모르더라도 전문가를 채용하고 전문가의 의견을 존중하는 경영자가 오히려 낫습니다.

이런 어설픈 전문가 증상개발자 출신 경영자에게서 종종 나타납니다.
이러한 경영자들은 회사가 커지면서 부딪히는 문제들을 자신의 경험을 토대로 해결하려고 하곤 합니다. 그러면서 개발자들이 자신이 왕년에 개발하는 것처럼 열심히 안 한다고 한탄하기도 합니다. 본인은 과거에 꽤 괜찮은 소프트웨어를 개발하여 회사를 이만큼 키워 놓았지만, 잘 개발했던 것은 아닙니다. 회사가 작고 개발 인원이 얼마 안되니 그냥 주먹구구식으로 개발을 했어도 별 문제 없이 개발이 되었던 것일 뿐입니다.

차라리 소프트웨어 개발에 대해서 잘 몰라도 전문가의 말에 귀를 기울이고 이해를 하려고 노력하는 경영자가 어설픈 전문가 경영자보다 낫습니다. 물론 진짜 소프트웨어 전문가인 경영자가 있다면 좋겠지만, 이것은 거의 불가능한 일이고 그렇다면 그런 사람은 CEO보다는 CTO역할을 하는 것이 맞겠죠. 이러한 연유로 우리나라 SW회사에는 제 역할을 하는 CTO를 만나는 것이 쉬운 일이 아닙니다.

최고의 SW전문가는 아니더라도 경영자가 적절히 SW개발에 대해서 이해를 하고 있고 내부 개발자들의 의견을 존중하고 전문가의 말에 귀를 기울이고 개발팀에 적극적으로 투자를 해준다면 금상첨화입니다. (물론, 이런 경영자도 많이 만나 봤습니다.)

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by tiarescott
저작자 표시 비영리 변경 금지

전규현 개발조직 CEO, CTO, 경영자, 전문가, 조직

Trackback Address: http://allofsoftware.net/trackback/156 관련글 쓰기
  1. 2009/11/11 14:03
    영업 마인드 & 엔지니어 마인드, 결국은 CEO 마인드 Tracked from 엔시스의 정보보호(보안) 따라잡기
  1. Blog Icon

    비밀댓글입니다

  2. funeasy님 안녕하세요. 오타를 지적해주시다니 감사합니다. 블로그 글은 꼼꼼히 리뷰를 하지 않는 편이어서 가끔 문장도 어색하고 오타가 있기도 하더군요. 어쨋든 황당한 오타 잡아주셔서 감사합니다.

  3. Blog Icon

    비밀댓글입니다

  4. Chanwoo님 안녕하세요.
    오타를 두 분이나 지적해주셨네요. 감사합니다.

  5. Blog Icon

    비밀댓글입니다

  6. 전상수차장님 오랫만이네요.
    잘계시죠? 저는 당연히 잘있죠.

  7. Blog Icon

    지식의 저주를 되새기게 해주는 글이군요
    정작 읽어야봐할 책은 책장이 꽂히지 않다는 지식의 겸손에 대한 움베르토 에코의 반서재의 교훈과 함께요
    오늘도 행복한 하루 되시길...^^

  8. Lee님 안녕하세요.
    공학의 근본은 지식보다는 경험이죠. 실전에서 필요없는 지식은 방해만 되고, 그런 지식을 신봉하는 이론가들은 제발 학교로 돌아가서 연구나 하면 좋겠습니다.

  9. 영업출신 사장이 해보지도 않고 할줄도 모르면서
    어디서 주워들은것만 나열하는거 보다는 그래도 나은 상황이 아닐려나요 ^^;

    사장이라고 해서, 고용주라고 해서
    자신이 고용한 사람들을 믿지 못하는 게 가장 큰 문제 같습니다.
    신뢰를 받지 못하는 사람도 힘들고
    사장도 힘드니 말이죠.

  10. 구차니님 안녕하세요.
    SW회사에서 영업출신 사장도 자칫 위험지기 쉬운 부류중에 하나죠.
    단기적인 이익에만 집착해서 소프트웨어 아키텍쳐를 완전히 망가뜨리는 일을 쉽게 하고 하죠.
    사실 경영자가 무슨 출신이냐보다는 무슨 마인드를 가지고 있느냐가 더 중요하다고 생각합니다.

  11. 완전 공감합니다. 저희 회사 사장님은 잘 모르겠지만 실장님이나 팀장님들중에 그런분들이 조금 있습니다.ㅠㅠ
    사장님도 개발자 출신인데 왜 단기적인 이익만 보시는지 모르겠습니다.ㅠㅠ
    근데 여기 오늘 처음 왔는데 좋은 글이 너무 많아서 행복합니다. 마니 읽고 자주 오겠습니다^^ 감사합니다~

내가 오래 일하면 일 처리 속도가 느린 것이고, Boss가 오래 걸리면 ...

2009/10/23 22:54 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
재미 있는 유머입니다.

My Boss & I
직장 상사와 나

When I take a long time, I am slow.
When my boss taking a long time, he is thorough.
내가 일을 오래 끌면 일 처리 속도가 느린 것이고,
나의 상사가 일을 오래 끌면 일을 철저히 하는 것이다.
 
When I don't do it, I am lazy.
When my boss doesn't do it, he is too busy.
내가 그 일을 하지 않으면 게으른 것이고,
나의 상사가 그 일을 하지 않으면 너무 바쁜 것이다.
 
When I do something without being told, I am trying to be smart.   
When my boss does the same, that is initiative.  
내가 시키지 않은 일을 하면 잘난척하는 것이고,
나의 상사가 시키지 않은 일을 하면 솔선수범하는 것이다.
 
When I please my boss, I am apple-polishing. 
When my boss pleases his boss, he's co-operating.  
내가 상사를 기쁘게 하면 아첨하는 것이고,
나의 상사가 자신의 상사를 기쁘게 하면 협력을 잘하는 것이다.
 
When I do well, my boss never remembers.  
When I do wrong, he never forgets.  
내가 잘한 일은 상사가 절대 기억하지 못하고,
내가 잘못한 일은 상사가 절대 잊지 않는다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.



저작자 표시 비영리 변경 금지

전규현 개발조직

Trackback Address: http://allofsoftware.net/trackback/151 관련글 쓰기
  1. 이제 입사한 지 얼마 되지 않은 개발자로써 믿고 싶지 않은 구절입니다만, 꽤 많은 수의 회사 내 상/하급자의 관계가 이와 유사하기에 심심치 않게 이런 글을 볼 수 있는거겠지요?
    아직 막내이기에 믿고 싶지 않은 현실이지만 나중에 제가 저런 상사가 되지 않도록 처음부터 심신수양을 잘 해나가야 할 것 같습니다.

    .덧붙임. 항상 좋은 글 많이 올려주셔서 진심으로 감사드립니다.

  2. 그냥 유머입니다.
    내가 보스가 되면 또 반대 입장이 되곤 하죠.

  3. IT라고 하면 '삭막하다'는 생각을 하는 사람이 과반수라는 설문도 있다고 하는데 사실 IT 관련에도 여느 직종과 다를 바 없이 이런 유머도 굉장히 많죠.

  4. 하나님 안녕하세요.
    그래도 IT, SW가 재미 있어서 붙어 있는 사람들이 많은 것 아닐까요?

  5. ㅎㅎㅎㅎㅎ 유머라 생각하고 웃고 갑니다
    [진실을 외면하려는 .... ]

  6. 이용상님 안녕하세요.
    블로그에 올리신 동영상 보고 한참 웃었습니다.

  7. 공감가네요.. 재밌게 보고 갑니다.

  8. 버드나무님 안녕하세요.
    들려주셔서 감사합니다. 버드나무님 블로그에 재미 있는 내용이 많군요. 종종 들르겠습니다.

SW가내수공업

2009/10/01 21:49 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
우리나라 SW회사들의 개발 상황을 보면 크나 작으나 가내수공업 형태를 벗어나지 못한 경우가 많습니다. 회사가 작을 경우에는 이런 가내수공업 형태의 개발이 큰 문제를 일으키지 않기도 하지만, 회사 규모가 가파르게 커 나가는데도 계속 그런 형태를 유지한다면 회사의 효율성은 급격하게 떨어지게 됩니다.

마치 원생동물이 군집생활을 하는 것 같은 이런 조직은 서로 같이 일함으로써 상승효과를 얻기는커녕 점점 비효율적으로 바뀌게 됩니다.

SW개발조직은 정교하게 진화된 생체조직과 같이 서로 분업이 잘 이루어져 있고 각 역할은 전문적으로 발전을 해야 하고 시스템적으로 커뮤니케이션이 원활하게 진행이 되어야 합니다. 이러한 조직을 회사가 커진 이후에 준비를 하려고 하면 이미 늦습니다. 회사가 아주 작거나 심지어는 혼자서 회사를 하더라도 조직과 시스템을 갖춰놔야 자연스럽게 회사의 성장에 맞춰서 효율적인 조직을 유지할 수 있습니다.

아직도 전적으로 각 개발자 한 명, 한 명에 너무 크게 의존을 하고 개발의 대부분이 코딩이며, 프로젝트의 성패는 소수의 개발자에 달려 있다면 원생동물의 군집생활과 비슷한 조직이라고 보면 됩니다.

이런 조직을 효율적이고 리스크가 적은 조직으로 탈바꿈하기 위해서는 가장 먼저 필요한 기반시스템을 통해서 모든 개발 과정과 커뮤니케이션을 투명화 하면서 잘 분업화된 전문조직으로 하나씩 바꿔나가야 합니다. 물론 이 과정이 그렇게 쉬운 일도 아니고, 책보고 따라 하기도 쉽지 않죠. 그래도 일단 이 정도만 해도 상당한 효과를 볼 수 있죠. 그만큼 투명한 개발이라는 것은 대단한 변화를 가져옵니다. 그리고 나면 각 개발자들의 역량 향상인데, 이는 대단히 오래 걸리는 일입니다. 

가내수공업형태를 못 벗어난 여러 SW회사들이 미국에 진출한다고 해서 수많은 실패를 경험한 것을 잘 알고 있습니다. 동네 축구 좀 한다고, 월드컵에 나가 보겠다고 하는 것처럼 무모하게 들리기도 합니다. 물론 동네축구에도 정말 뛰어난 인재들이 있습니다. 하지만 박지성이 기회 없이 계속 동네 축구만 했다면 세계적인 선수가 못되었겠지요. 조직은 전문화가 되고 개발자는 진짜 개발자에게 필요한 역량을 키워나가고 해야만 그나마, 게임이 좀 될 수 있습니다.  

이 와중에 이를 해결해보고자 방법론들을 기웃거린다면 문제가 될 수 있습니다. 왜냐하면 방법론에서는 조직이나 시스템에 대해서는 별로 가이드를 하지 않기 때문에 엉뚱한 곳에서 헤맬 수가 있습니다. SW를 효율적으로 잘 개발하는 방법은 특별한데 있지 않습니다. 우리가 소홀히 하는 아주 기초적인 것들에 있습니다. 기본에 충실해야 할 때입니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지

전규현 개발조직

Trackback Address: http://allofsoftware.net/trackback/146 관련글 쓰기
  1. 2009/10/05 08:34
    toracle의 생각 Tracked from toracle's me2DAY
  1. Blog Icon
    stmind

    방법론이라는것이 조직에 대해서는 가이드를 하지 않고 있다는 것은 공감합니다. 물론 기초적인 부분도 점거을 해 봐야겠지요. 경험적으로 프로젝트를 진행해 보면 차 후 항상 어떤 방법론과 비슷하게 되는 과정을 간접/직접적으로 느낄 때가 많습니다. 물론 이론적인 방법론에 충실한 것은 아니겠지만요.
    체계가 없고 난잡한 상황에서도 꾸준히 체계를 잡아서 나아가다 보면 어떤 방법론과 흡사해 지는 과정처럼
    방법론을 미리 본다고 그것이 문제가 될 수 있는 것는 아닌것 같습니다. 대게 나와있는 방법론들은 충분히 경험적인 바탕으로 나온것들이기때문에참고정도는 할 수 있겠죠.
    문제는 현 시점에서 어떤 것들을 도입하면 좋은가.필터링 할 수 있는 것때문에 헤매는것 같습니다. 저 같은 경우 최근 예전에 한번 본 애자일관련 방법론을 다시한번 보고 있습니다. 어떤 것을 해결 하겠다고 보는것이 아니라 그것에서 장점을 추려내기 위함이죠..

  2. 안녕하세요. stmind님
    잘못된 방법론이라는 것은 존재하지 않죠. ^^ 하지만 우리에게 알맞은 방법론은 있습니다. 문제는 경험이 부족하면 어떤 것이 알맞은지 알기 어려운 것이죠.
    애자일을 시도해 보셨다고 하는데, 아주 좋은 시도입니다. 그 과정에서 장단점도 파악이 되고 회사에 알맞게 변화를 줄 수도 있습니다.
    딱 하나의 방법론을 따르기 보다 여러 방법들을 혼합해서 쓰는 경우도 많고, 한 회사에서도 프로젝트의 성격에 따라서 다른 방법들을 써야 합니다. 따라서 너무 엄격한 프로세스 규칙은 효율성을 떨어뜨립니다.

  3. 안녕하세요 전규현님.
    전규현님의 좋은 글들 항상 잘 보고 있습니다.
    전규현님께서는 많은 글에서 경영자의 의지가 중요하다, 경영자부터 바뀌어야 한다 하시는데 맞는 말이지만 정작 직원으로서 영향을 미치기는 힘든 부분이 아닌가 싶습니다. 전규현님의 글을 보시는 분들중에는 경영자 보다는 일반 개발자들이 훨씬 더 많을 것이라고 생각이 듭니다. 그래서 말인데 혹시 경영자의 마인드를 어떻게 바꿀수 있는지에 대한 글을 부탁드려도 될까요?

  4. C-Thinker님 안녕하세요.
    항상 글을 보고 계신다니 감사합니다.
    사실 축구선수 하나가 축구팀을 바꾸는 것보다는 감독이 미치는 영향이 훨씬 큽니다. 10배 이상일 겁니다.
    개발자들 스스로 회사를 바꿔나갈 수 있는 것도 있지만, 많은 부분은 경영자의 후원이 필요합니다. 경영자 스스로가 SW를 잘 알고 있다면 괜찮겠지만, 우리나라에서는 흔한 일이 아닙니다.
    이런 경우 CTO가 있어서 기술적인 부분을 담당해준다고 하면 되지만, CTO가 없는 회사가 대부분이고, 있다고 하더라도 제 역할을 못하는 경우가 더 많습니다.

    그렇다면 개발자들이 경영자의 기술적인 부분을 보충해줘야 하는데, 그럴려면 개발자가 개발자의 용어로 얘기를 해서는 안됩니다. 또, 개발자의 사고방식에만 머물러서는 경영자와 얘기도 안됩니다. 또, 경영자는 개발자 마인드에만 머물러 있는 개발자의 판단을 믿지 않습니다.
    개발자가 성장을 할 수록 회사 전체, 시장 전체를 보고, Business 마인드가 없다면 경영자를 설득할 수 없습니다. CTO가 기술과 경영마인드를 다 갖고 있는 사람이죠.
    따라서, 경영자를 탓할 것이 아니라, 개발자가 경영자의 신뢰를 얻어야 합니다.

    저는 수많은 경영자들과 얘기를 많이 하기 때문에 경영자들이 개발자의 기술력은 믿지만, 그들의 전략적인 판단이나 경영마인드에 대한 믿음은 별로 없는 경우가 많다는 것을 잘 알고 있습니다.
    결국 어려운 일처럼 들리지만, 어려운 일 맞습니다. 저와 같은 외부 전문가가 경영자를 설득하는 일은 더 쉽지만, 개발자들이 내부에서 스스로 경영자를 설득하는 일은 좀더 어렵습니다.

    추후 이에 대한 글을 한번 올려 보도록 하겠습니다. 감사합니다.

항상 보스가 먼저 말하게 하라.

2009/08/21 19:29 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


오늘 재미있는 글을 봤습니다. 그래서 공유를 할까 합니다.

A junior manager, a senior manager and their boss are on their way to a meeting.
신참 부장과 고참 부장, 그리고 사장이 회의장으로 가는 길이었다.
On their way through a park, they come across a wonder lamp.
이들은 공원을 지나다가 신기한 램프를 발견했다.
They rub the lamp and a ghost appears.
 램프를 문지르자 한 유령이 나타났다.
The ghost says,
유령이 말했다.
"Normally, one is granted three wishes but as you are three, I will allow one wish each"
"보통 한 명에게 세 가지 소원을 들어주지만, 너희는 셋이니 한 명당 하나씩 소원을 들어주겠다."
So the eager senior manager shouted,
그러자 성격 급한 고참 부장이 소리쳤다.
"I want the first wish. I want to be in the Bahamas , on a fast boat and have no worries."
“제가 먼저 소원을 빌게요. 저는 바하마 제도에 가서 쾌속정을 타면서 근심․걱정을 떨쳐버리고 싶어요.”
Pfufffff, and he was gone.
휭 소리와 함께 고참 부장은 사라졌다.
Now the junior manager could not keep quiet and shouted
이번에는 신참부장이 얌전히 있지 못하고 소리쳤다
"I want to be in Florida with beautiful girls, plenty of food and cocktails."
“저는 플로리다에 가서 맛있는 음식과 칵테일을 마시면서 예쁜 여자들과 지내고 싶어요.”
Pfufffff, and he Was also gone.
휭 소리와 함께 후임 과장도 사라졌다.
The boss calmly said,
그러자 사장이 나직한 목소리로 말했다.
"I want these two idiots back in the office after lunch at 12.35pm."
“나는 이 멍청한 두 녀석이 점심 먹고 오후 12시 35분까지 사무실로 돌아오길 바랍니다.”
 
* MORAL OF THE STORY IS: "ALWAYS ALLOW THE BOSSES TO SPEAK FIRST."
* 이야기의 교훈: “항상 윗사람에게 먼저 말할 기회를 양보하라.

(image from plastereddragon)


저작자 표시 비영리 변경 금지

전규현 개발조직 램프, 보스, 영어, 유머

Trackback Address: http://allofsoftware.net/trackback/141 관련글 쓰기
  1. 2009/12/04 10:39
    김기사의 생각 Tracked from kimgisa's me2DAY
  1. Boss, you win! ㅋㅋ

  2. Blog Icon
    csj

    ㅋㅋㅋ 재미있군요 ㅎㅎ

  3. Blog Icon
    레흐

    퍼갑니다

  4. Blog Icon
    microflower

    재미있네요 퍼갈께요.

우리는 개발자가 테스트도 다 해요.

2009/08/09 21:10 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

별도의 테스트팀이 없는 회사는 정말 많습니다.

별도의 테스트팀이 없이 개발자가 또는 팀장이 테스트에 참여하는 이유는 개발자가 아니면 제품의 기능을 속속들이 알 수 없어서 테스트를 하기가 어렵기 때문입니다. 이렇게 되는 이유는 제품의 스펙이 따로 문서화되어 있지 않기 때문에 개발자가 아니면 스펙을 알지 못하기 때문입니다.

하지만, 개발자는 인건비도 비쌀 뿐더러 테스트를 잘 하지도 못합니다. 그리고 아무리 테스트 능력이 있는 개발자라고 할지라도 자신이 작성한 기능을 테스트 하는 것은 좋은 방법이 아닙니다. 본인은 내부 동작방식을 잘 알기 때문에 기능이 정상적으로 동작하는 방식 위주로 테스트를 하기 마련입니다.

테스트는 반복적이고 전문적인 작업이기 때문에 개발자가 담당하고 있는 이상 정상적으로 이루어지고 있다고 보기 힘듭니다. 

테스트팀을 따로 두기 위해서는 기본적으로 제품의 스펙이 있어야 합니다. 그렇지 않다면 테스트 팀은 그냥 Random 테스트를 마구 해주는 아르바이트생 수준의 역할 밖에 할 수가 없게 됩니다. 실제 수많은 테스트 팀들이 그 정도 수준에서 밖에 테스트를 할 수 없는 열악한 상황에서 일을 하고 있습니다.

기본적으로 제품에 스펙이 존재를 해야 이를 토대로 테스트케이스를 만들어 낼 수 있고, Regression Test가 가능해 집니다. 그리고 테스트팀이 있다면 테스트 자동화에 대해서 좀더 연구를 하게 되고 테스트 효율성을 높이기 위한 작업들을 진행할 수 있습니다.

테스트팀을 두는 것이 비용을 줄이면서도 제품의 품질을 높일 수 있는 방법입니다. 개발 조직을 효율적으로 운영하고 싶으면 전문 테스트팀에 대해서 심각하게 고려해봐야 합니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
(image by cobalt123)
저작자 표시 비영리 변경 금지

전규현 개발조직 스펙, 테스트, 테스트케이스, 테스트팀

Trackback Address: http://allofsoftware.net/trackback/139 관련글 쓰기
  1. 확실히 자기의 잘못을 자신이 알 수 없듯, 테스트는 작성자가 해서는 안된다는 사실에 매우 공감합니다.

    그래서 가끔은 전혀 모르는 사람에게 그냥 써봐~ 라고 하면서 던져줘보곤 하죠 ㅋ

  2. 구차니님 안녕하세요.
    그것도 테스트 방법 중 하나죠. 그 방법이 유일한 방법은 아니겠죠?^^

사업부가 소프트웨어 조직에 미치는 영향

2008/12/23 15:24 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
주변 소프트웨어 회사에서 사업부 형태의 조직을 접하는 것은 어려운 일이 아닙니다.
사업부라는 조직 구조가 꽤 인기를 끈 것은 사실입니다.
사업부란 특정 시장에 집중하고 시장의 요구에 빠르게 대응하기 위해서 만든 특수한 형태의 조직입니다.
보통 사업부는 상당히 많은 독립권을 가지고 있고 대부분의 결정을 사업부 내부에서 독립적으로 할 수 있습니다.
하지만 작은 회사를 사업부로 나눠서 각 사업부에 독립적인 책임과 권한을 주게 되면 득보다 실이 더 많아집니다.
하지만 사업부가 가지고 있는 단기적인 성과에 대한 욕심 때문에 사업부 조직 형태에 현혹이 되곤 합니다. 하지만 장기적으로는 잃는 것이 더 많을 수 있습니다.
사업부는 장점도 가지고 있는 조직 구조이지만 다음과 같은 단점들을 가지고 있습니다.

  • 사업부 간에 지식과 정보가 서로 공유하기 쉽지 않다.
  • 사업부 간에 인력을 공유하기가 어려워져서 한쪽 사업부의 인력이 모자라도 인력을 공유하는 등의 효과적인 인력활용이 어렵다.
  • 사업부 간에 기반시스템이 달라지고 개발 표준이 상이해져서 전사적인 개발 효율이 떨어지고, 미래에 다시 통합을 하려고 해도 쉽지 않게 된다.
  • 영업 위주로 개발을 하게 되어서 제품의 아키텍처가 점점 취약해진다. 버그가 많아지고, 시간이 흐를수록 신규 개발보다는 유지보수에 시간을 많이 소비하게 된다.
  • 단기적인 성과에 집착하여 개발자들의 역량 향상에 소홀해지고 장기적으로는 개발 생산성이 떨어진다.
  • 각 기능 조직의 인원이 분리되어 사업부끼리 기능이 중복되고 각각의 전문성도 떨어진다.
  • 사업부의 이익과 회사의 장기적인 이익이 서로 일치하지 않을 수 있다.

사업부를 시행하기 적당한 조직의 크기는 몇 백명 단위가 아닙니다. 몇 천명, 몇 만명의 조직 정도의 규모가 되어야 사업부를 시행할 수 있는 조직이라고 할 수 있습니다.
조직규모가 대단히 크거나 특수한 시장 상황에 대응하기 위한 특별한 목적이 있는 경우라면 상관이 없지만, 회사의 규모가 몇 백명 이하라면 개발조직은 한 조직에 속해서 관리되는 것이 좋습니다.
이미 사업부를 시행하고 있는 조직이라면 각 사업부의 개발 및 기술 전체를 통제할 수 있는 조직이나 CTO가 필요합니다. 그리고 가능하면 개발 조직은 하나로 합쳐서 전사적인 개발조직으로 움직이는 것이 좋습니다.
사업부 조직으로 인해서 개발조직이 이미 통합이 어려운 상태라면 개발 조직을 쪼갤 때보다도 몇배의 배용을 치뤄야 합니다.
따라서 개발조직은 장기적인 안목으로 신중하게 다뤄야 합니다.


저작자 표시 비영리 변경 금지

전규현 개발조직

Trackback Address: http://allofsoftware.net/trackback/43 관련글 쓰기
관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..