개발자의 파워는 어디에서 오는가?
'개발조직' 카테고리의 다른 글
| QA팀은 없다고 생각하라 (5) | 2010/10/11 |
|---|---|
| 개발팀장과 프로젝트관리자(PM) (6) | 2010/10/04 |
| 개발자의 파워는 어디에서 오는가? (27) | 2010/08/03 |
| SW회사, 이런 사장이 문제 (11) | 2009/11/10 |
| 내가 오래 일하면 일 처리 속도가 느린 것이고, Boss가 오래 걸리면 ... (8) | 2009/10/23 |
| SW가내수공업 (4) | 2009/10/01 |


|
|
| QA팀은 없다고 생각하라 (5) | 2010/10/11 |
|---|---|
| 개발팀장과 프로젝트관리자(PM) (6) | 2010/10/04 |
| 개발자의 파워는 어디에서 오는가? (27) | 2010/08/03 |
| SW회사, 이런 사장이 문제 (11) | 2009/11/10 |
| 내가 오래 일하면 일 처리 속도가 느린 것이고, Boss가 오래 걸리면 ... (8) | 2009/10/23 |
| SW가내수공업 (4) | 2009/10/01 |
우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..
수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..
'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..
우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..
최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..
우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..
우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..
며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..
프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..
"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..
글 잘 읽고 갑니다. :D
안녕하세요. 우울한 딱따구리님...
요즘 워낙 바빠서 블로그 포스팅이 뜸해지네요.
그래도 언제나 글을 읽어주셔서 감사합니다.
개발과 관리를 둘 다 잘 하는 사람이 있으면 관리를 시키는 것이 낫지 않을까 싶습니다.
관리 잘 하는 사람이 많은 것 같아도 사실 개발자와 프로젝트를 관리 할 수 있는 관리자는 정말 뛰어난 개발자보다 더 소수가 아닐까 싶거든요.
이런 관리자가 있어주어야 그 밑에서 정말 개발만 잘 하는 사람들이 편하고 효율적으로 일 할 수 있지 않을까 싶기도 하구요.
안녕하세요. bookworm님
우리는 흔히 팀장과 PM을 혼동하곤 하는데, 위에서 언급한 내용은 팀장, 즉 일반관리자 역할입니다.
팀장은 관리자트랙인데 비해서 PM은 특수한 영역으로서 개발자와 관리자의 중간쯤에 있는 트랙입니다. 즉 개발도 잘 이해하고 관리도 잘할 수 있는 사람들의 영역입니다.
일반적인 작은 회사나 작은 개발팀은 전문적인 PM이 필요하지도 않고 관리도 그렇게 많이 필요하지 않습니다. 그냥 선임 개발자가 대춤 겸업을 해도 큰 문제가 발생하지 않습니다.
그래도 우리는 보통 마구 혼동해서 사용합니다. 하지만 규모가 커지기 시작하면 모든 영역이 매우 전문화가 되어야 합니다.
말씀하신 내용은 PM에 가까운것 같습니다. 프로젝트가 커지면 PM의 역할이 정말로 중요하고 뛰어난 PM이 프로젝트 성공에 가장 큰 역할을 하며 책임도 큽니다. 개발자중에서 PM 트랙을 선택하는 것도 좋은 선택중 하나라고 생각합니다. 단, 우리나라에서는 PM의 역할에 대해서 제대로 정의가 안된 회사가 많기 때문에 자칫 이직시 애매해지는 경우가 많은 것 같습니다.
아무튼, 아직 개발자, PM, 관리자에 대한 전문성에 대한 이해가 전반적으로 부족한 분위기는 차츰 바꿔나가야 하겠습니다.
말씀하신 부분에 공감합니다.
우리나라는 아직 일반 관리자, PM, 개발자 등의 역할이 전문화가 안 된 것 같습니다.
개인적으로 개발자로 하고 싶은 것이 많은데 일반 관리부터 PM까지 겸업하려니 고민과 갈등이 많습니다.
관리자라고 한다면 피플매니징이 주요 업무여야 한다고 봅니다. PM은 말 그대로 프로젝트만을 관리해야 하는 거구요.
예전까지는 팀장 = 관리자 = PM이었는데(종종 프로젝트에 따라서 PM이 아닌 경우는 있었지만), 외국계는 이 매니저와 PM이 확실하게 다른 캐리어 트랙을 타더군요.
안타까운 현실에 우울하죠.
몇 년 뒤면 이제 40이 되는데, 등 떠밀려 선택을 하게 되겠죠? ㅡ,.ㅡ;;
whiterock님 안녕하세요.
계속 개발을 하고 싶은 개발자들이 등떠밀려 관리자가 되는 것은 개인이나 회사에 모두 손해입니다.
본인의 의지를 회사에 피력을 해보시죠. 회사 사정은 정확하게 모르지만 시도를 해보시는 것이 어떨가요?
앞으로의 진로를 고민하는 사람으로 말씀하신 것처럼 문화가 바뀌기를 바라고 있지만, 현실적으로 한국 기업문화에서는 쉬운 부분은 아니라고 생각합니다. 저 또한 그렇게 만들고 싶고 그러기 위해서는 힘(?)이 있어야 하고, 힘을 가지려면 관리자가 되어야하니까요..아쉬운 현실입니다.
님께서 가지고 계신 가치관이 많이 전파되었으면 하는 바램입니다. 글 감사합니다.
꼬부가빠님 안녕하세요.
기업이 생존을 위해서는 어쩔 수 없이 이렇게 하지 않으면 안됩니다. 한국의 기업문화 그대로 따라서는 살아남을 확률이 너무 많이 떨어집니다.
변화는 선택의 문제가 아니고 생존하느냐 죽느냐의 문제입니다.
제가 잘 몰라서 그런지, 너무 타성적으로 들리네요. 직장을 잃는 것이나, 평소의 삶이(특히 안좋은 쪽으로) 변화될 수 있다는 두려움때문에 오히려 자신의 꿈을 다른 요인에 의해서 이룰 수 없다고 스스로 합리화하고 있는 것 아닌가요? 자신의 꿈이 확고하다면 어떠한 변화도 감수할 수 있는 태도와 생각이 당연 생기게 마련이라고 생각합니다.
thankee님 안녕하세요.
무슨 말쓴인지?
Postion 이라고 쓰신 부분이 Position 맞죠?
안녕하세요. godway님
당연히 오타죠. - -; 바로 수정했습니다.
마지막 까지 살아남는자가 최고의 승자이죠
외국에서는 10년 정도 개발하면 이제 조금 하는 구나
하는데 우리나라는 5년정도 개발하고 관리자로
빠지니 관리도 못하고 기술도 잘 모릅니다.
그러면서 기술은 중요하지 않다라고 하죠.
beyondj2ee님 안녕하세요.
10년차와 20년차가 또 다르죠.
그런데 우리나라 대부분의 SW 개발자들은 그 차이가 별로 없는 경우가 많습니다. 고참 개발자들이 신참과는 다르게 무슨 일을 어떻게 해야 하는지 모르는 경우가 대부분입니다.
우리나라의 대부분의 SW업체가 중소기업이지만....
워낙 작은 회사는 모든 구분이 참 애매모호합니다.
또한 회사 업무 내용이나 개발 규모등에 따라서도 많이 틀려지겠죠
우리회사 같은 경우에는 한두사람이 하나의 프로젝트를 개발하고
다수의 기존 프로젝트 유지보수까지 끌고 가는 상황이라
별도의 관리자나 PM등이 있지도 않고요
개발자가 계속 경력을 쌓고 개발을 할 수 있도록 지원할 생각은 하고 있습니다.
개발자에게 힘을 실어주는 제도라는게 구체적으로 어떤 예가 있을까요?
크레브님 안녕하세요.
작은 회사에서는 한사람이 여러 프로젝트를 진행하기도 하고 여러 역할을 겸임하기도 합니다. 아주 일반적인 현상입니다.
단, 여러일을 겸임할 때도 역할의 구분을 하는 것이 좋습니다. 즉 최소화를 해야 좋지만 문서도 만들고 프로세스도 따른 것입니다. 그래야 조직이 조금씩 커지면서 자연스럽게 업무들이 분배됩니다.
혼자 여러일을 한다고 혼자만 알 수 있게 또, 구분없이 일들을 마구 섞어서 하게 되면 인원이 늘어가도 효율적으로 돌아가지 않습니다.
개발자에게 힘을 실어주는 제도 중 하나는 행정적으로 의사결정을 할 수 있는 권한, 예산을 집행 할 수 있는 권한을 부여한는 것입니다. 사실 회사의 의사결정 중에서 기술적인 것들은 개발자들이 해야 하는 것입니다. 특히 회사의 최고 개발자들이 결정을 해야 합니다. 하지만 개발과 관리가 애매한 회사에서는 기술적인 결정임에도 불구하고 관리자들에 의해서 많이 좌지우지 됩니다. 따라서 기술적인 결정이 개발자에 의해서 결정될려면 회사의 최고 기술자가 최고의 임원자리를 차지하고 있어야 합니다. 그래서 CTO가 필요한 법이지요. CTO에는 개발자에게 Role model이 될 수도 있습니다.
그럼에도 많은 회사에서 CTO가 관리자의 역할을 하는 것을 보면 사실 CTO가 아닌것이지요. 그냥 연구소장인 것입니다.
경영자가 기술의 중요성과 전문성을 이해해야만 이 모든 것이 가능합니다.
드물겠지만 개발을 하고 싶은 사람도 있는데 관리직으로 떠밀린다면 우울할꺼 같아요
구차니님 안녕하세요.
개발자도 고참이 되어도 개발자로서 계속 가치를 부여하기 위해서는 달라져야 합니다.
경력이 많아지는 것만 가지고는 부족합니다.
뷰도 넓어져야 하고, 비즈니스도 잘 알아야 하고, 많은 프로젝트와 후배들에게 영향을 많이 줘야 합니다.
그러기 위해서는 회사의 프로세스와 시스템이 잘 갖춰져 있어야 하며 문서화와 리뷰가 잘 이루어져야 합니다.
공감합니다.
아직 개발을 더 하고 싶은데 관리자로 되면 힘들것같아요;;
아직 저는 신입 개발자이지만
관리자로서 준비를 해두어야 할지
개발자로서 살길을 찾아야할지 고민입니다.
acude님
대한민국에서는 어려운 결정입니다.
아직 신입이시니까 더 좋은 여건입니다. 이미 머리가 굳은 경력이 많은 개발자들은 쉽게 마인드를 바꾸기가 어렵습니다.
지금부터 꾸준히 소프트웨어 공학에도 관심을 가지고 경력을 쌓아보세요.
안녕하세요. 오랜만에 들려봅니다. ( 그동안 병원생활하느라;;
여전히 깨어있는 글. 무척이나 공감합니다.
얼마전 해외에서 일하는 후배와 이야기를 하다가,
암담한 한국의 소프트웨어 업계와, 그래도 캐리어를 꾸준히 보장해 주는 해외 소프트웨어 업계를 비교해 보고 참.. 한국의 기업들이 개선해야할 부분이 너무 많은것 같아서 답답하기까지 하더라구요.
물론 해외기업과 한국기업이 문화태생부터 다른 것은 사실이지만 같은 소프트웨어를 다룬다는 입장에서는 똑같을 듯 싶은데.. 왜 한국 기업은 공학인들에게 당연히 보장해 줘야 될 부분들을 그렇게 늘~~ 그늘에 놔두려고 하는지..참 안타깝기 까지 했습니다.
그리고 기술밥먹는 사람들은 기술밥먹는 사람끼리 뭉쳐서 타 도메인에 대한 상생을 좀 무시하는 경향이 있는것도 같구요.
또, 말씀하신것처럼 개발자도 소프트웨어공학에 대한 지식을 꾸준히 연마해야 한다고 봅니다. 기업에 프로젝트를 하러 다니면 소프트웨어공학에 대해 관심도 없고, 배우려고 하지 않는 곳이 꽤 많았습니다. 단지 API의 어떤 기술만 외쳐댈뿐이었지요. (숲을보는 인재가 별로 없는 듯) 어디서부터 잘못된 문화인지... 그 원인을 분석하고 개선할 수 있다면 정말 좋겠지만.. 아직까지 먼 세상이라고 느껴집니다.
부디 깨어있는 분들이 계속 개선점을 고치고 알리어 꾸준히 바뀌어 나가길 희망합니다.
안녕하세요. moova님
오랫만입니다. 그동안 쾌차하셨는지요?
그래도 저와 저의 회사에서는 그동안 여러 회사를 컨설팅하면서 마이드를 많이 바꾸고 있습니다. 그래서 점점 이러한 것들이 파급되고 있다고 생각합니다. 그 일환으로 책도 쓰고 블로그도 하는 것입니다.
이땅에서 소프트웨어 개발자가 최고의 직업이 되는 날까지 저는 뜁니다. ^^
안녕하세요, 이전에 'SVN' 이란 것을 검색하다가 게시된 글들에 흥미를 느껴 간간이 들리고 있는 IT분야 취업 준비생입니다. 간단히, 저의 소개를 하자면 국내 컴퓨터공학과를 졸업했으며 오는 하반기에 국내취업을 목표로 하고있는 젊은 청년입니다. 또한, 현재 Wipro라고 하는 인도 SI업체에서 프로젝트를 맡아 수행중이기도 합니다.
앞으로 저보다 앞서서, 미래를 그려나가는 선배님들께 좋은 말씀도 들었으면 합니다.
잘 부탁 드리겠습니다 : )
Keyvin님 안녕하세요.
새술은 새부대에 보관해야죠...
경력이 오래된 개발자들은 마인드가 쉽게 바뀌지 않습니다. 그동안 이룩해 놓은 것들과 몸에 밴 습관을 버릴 수가 없기 때문에 그렇습니다.
그래서 kevin님과 같은 신진들이 더욱 중요합니다.
처음부터 올바르게 시작해야 합니다. 하지만 현장에서 실제로 일을 하다보면 반대된는 도전에 수없이 직면할 것입니다. 그것이 지금 우리나라의 현실입니다. 여기에 좌절말고 꾸준히 정도를 걸어나가면 뛰어난 개발자가 될 수 있을 겁니다.
요소 기술만 신경 쓰지 마시고 소프트웨어 공학고 꾸준히 공부를 하고 경험을 하는 것이 중요합니다. 소프트웨어 공학은 공부만 해서는 절대로 익힐 수 없는 것이고 제대로된 경험을 하는 것이 익히는 유일한 방법이며 시간도 많이 걸립니다.
현장에서 여러 도전에 부딪힐 때 저를 비롯한 선배들이 도움을 줄 수 있기를 바랍니다.