천객만래 [千客萬來] (It has an interminable succession of visitors)
오늘은 개천절.

주중 hump dump
주중 딱 좋은 휴일이다.
가을 날씨가 좋지만 오늘은 자격증 시험을 준비하기 위하여
공부를 하기로 한다.

교재가 수업용 교재의 커리큘럼과 동일해서
이 책을 두 번 이상 정독하고 시험을 봐도 될까하는 생각도 해본다.

초급 자격증인 CTFL 이지만 조금이라도 도움이 될꺼라 생각하며 학습에 임하고 있다.

잘 해 보 자.
혼 자 만 의 인 생 이 아 니 다.

Posted by SB패밀리

SW 개발자의 길, 아니다 싶으면 포기하라!




20일 오전에 MS가 주관하는 ‘2007 데브데이’ 행사에 참석했다. IT업계에 종사하는 사람이라면, 아마도 한번쯤은 MS의 독점성과 라이선스 정책 등에 대해 불만을 품어봤을 만하다. 그럼에도 불구하고 SW 개발자들의, MS에 대한, 관심은 어느 행사보다 뜨거움을 느낄 수 있었다.

기자는 오전 행사 중 한국MS의 최고기술임원인 김명호 박사(혹은 이사, 왠지 모르지만 박사라는 호칭이 더 어울린다)의 기조연설만 듣고 나서 김박사와의 짧은 인터뷰를 진행할 수 있었다. 그는 기조연설과 인터뷰를 통해 ‘한국에서 SW 개발자가 가야 할 길’에 대해 <희망차고도 암울한> 사회적 딜레마를 이야기해 주었다.

아래의 글은 김명호 박사를 통해 들을 이야기를 바탕으로 작성해 보았다.

[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다.

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다.

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다.

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다.

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다.

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다.

훌륭한 개발자가 되려면?
1) 기본에 충실해야 한다.
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다.

2) 지식의 포트폴리오를 유지하라.
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다.

3) 분야 전문가나 해박한 지식을 갖춰라.
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다.

4) 학습을 두려워 마라.
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다.

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라.

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다.

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?>
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다.

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다.

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다.

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다.

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다.

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다.

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다.

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다.

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다.

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다.
Posted by SB패밀리

[웹] 웹퍼블리셔(Web Publisher)란



웹퍼블리셔(Web Publisher)란

웹표준 및 DOCTYPE를 인지하지 못하는 개발자가 작업하여 나오는 결과물이 IE와 그 외 브라우저에서 특정한 부분만 인식하는 스크립트와 그렇지 않은 스크립트, XHTML과 HTML 태그 사용법 등을 미리 선정하여 큰 문제가 없도록 최대한 디자인을 살려 개발 영역을 넓혀줄 수 있는 역할을 하는 것이 퍼블리셔이다.

 

수행직무)

퍼블리셔는 코더의 역할 뿐만이 아니라, 전체적인 프로젝트의 인식, 그리고 웹 접근성과 크로스미디어, 크로스 브라우저 같은 좀 더 많은 사용자에게 퍼블리싱(인쇄 , 출력)을 할 수 있는 환경을 제공하고자 하는 것에 좀 더 초점이 맞추어져 있다. HTML과 CSS를 활용한 효율적이고 빠른 그리고 수정 용이한 코드 작성을 목적으로 한다.

 

변화를 읽는 자기계발, 흐린 취업시장에서 성공의 길!

뜨는 IT 직종, 웹 퍼블리셔

 

IT 관련 직종의 수명이 짧아지면서, 새로운 직종에 속속 등장하고 있다. 올해 채용시장에 가장 두드러진 직종으로 평가되는 분야는 웹퍼블리셔.

4 11장애인차별금지 및 권리구제에 관한 법률(장차법)’의 시행에 따라 모든 공공기관과 종합병원, 복지시설, 특수학교 및 장애전담 보육시설 등의 홈페이지에 대한 장애인을 위한 웹 접근성이 갖춰지도록 의무화 되었고, 정부 공공기관의 웹 접근성 개선사업이 크게 늘면서 각 취업사이트마다 웹퍼블리셔를 모집하는 공고가 넘쳐나고 있다.

 

웹퍼블리셔는웹 표준 및 웹 접근성 전문가라고 정의할 수 있으며 웹 표준과 그 주변의 다양한 웹 관련 기술에 전문성을 지니고 있는 웹의 구현(출판)을 담당하는 새롭게 부각되는 업무를 행하는 사람을 지칭하기 위한 용어이다.
웹퍼블리셔가 웹표준 구현을 위하여 갖추어야 할 스킬은 아래와 같다.
• HTML, CSS, Javascript
에 대한 관심
• XHTML
마크업 및 W3C DOM을 사용한 자바스크립트 개발 역량
• XHTML
CSS로 구조와 표현 분리 개발 방법에 대한 이해
웹접근성 및 웹표준에 대한 이해
개발자와 디자이너, 컨텐츠 설계자와의 원할한 커뮤니케이션 역량
사용자 중심의 UI에 대한 관심과 이해
소수 사용자를 배려하는 마음

 

급격한 수요 증가에 대응하기 위해 강좌를 개설한 미즈 평생교육원에서는 웹표준/웹접근성 전문강좌를 개설하여 새로운 인터넷 환경을 이끌어갈 인력을 배출하고자 수강생을 모집하고 있다

Posted by SB패밀리

[경영/리더십] 효과적 업무 지시와 커뮤니케이션




팀원들과 멀어져 가는 팀장
예스주식회사의 한방향 팀장은 최근 시장전략팀의 팀장으로 새로 부임했다. 그는 해외영업팀을 3년 동안 이끌면서 빠른 업무처리와 카리스마적 리더십으로 명성을 날렸다. 지난해 회사는 그를 경영자 승계관리 프로그램의 대상자로 선정했고, 새로운 업무 환경에서 그의 잠재력과 성과를 평가해 보기 위해 이번에 시장전략팀으로 인사 발령을 냈다.
 
시장전략팀은 한 팀장이 기존에 맡던 해외영업팀과는 팀 구성과 조직문화가 많이 달랐다. 해외영업팀은 현장 영업 경력이 있는 남자 직원이 대부분이었고, 상황 변화에 대한 일사불란한 조직적 대응이 장점이었다. 그러나 시장전략팀은 MBA를 마치고 스카우트된 외부 인력과 여성, 신입사원 등 다양한 팀원으로 구성돼 있었다. 팀원들이 회식 참여를 꺼리는 등 한 팀장이 생각하기에는 조직문화도 적극성이 부족했다.
 
새 팀을 맡은 지 얼마 되지 않은 어느 날, 직속상사인 홍길동 상무가 한 팀장을 불렀다.
 
“이번 정기 임원회의 때 논의해야 하니 지난번에 조사한 신제품의 시장 환경에 대해 추가적인 자료조사를 해 주게. 자네도 이번 신제품이 회사에 얼마나 중요한 것인지 내가 전에 자세하게 설명해 줘서 충분히 이해하고 있지? 이번에는 신제품이 경쟁사제품과 어떤 점에서 차별성을 가져야 할지를 특별히 고민해 보게.”
 
홍 상무와의 회의를 마친 한 팀장은 자리로 돌아오자마자 해외영업팀에서 하던 대로 팀원들에게 업무 지시를 했다.
 
“홍 상무님이 이번 신제품에 대한 시장조사를 다음 임원회의 때 발표한다고 하시니 여러분이 준비해서 이번 주 목요일까지 나한테 보고해 줘.”
 
그런데 팀원들의 표정이 예사롭지 않았다. 여기저기서 웅성웅성하는 소리도 들렸다. 선임 과장인 전우치 과장이 머리를 긁적이며 말했다.
 
“팀장님, 그 신제품에 대해서는 지난번에 보고를 했습니다. 팀장님 말씀은 조사를 처음부터 다시 하라는 것인가요, 특정한 부분을 보완하라는 것인가요?”
 
“상무님께서 차별화 얘기를 하시긴 했는데, 다시 보고하라는 말씀은 지난번 보고 내용이 충분하지 않았다는 뜻일 거야. 처음부터 다시 철저하게 조사해서 보고해 줘.”
 
목요일 오후 한 팀장은 홍 상무의 방을 찾았다. 그런데 보고 자료를 본 홍 상무의 표정이 일그러졌다.
 
“아니, 한 팀장. 지난번 보고 내용과 별로 다른 점이 없지 않나? 내가 이번에는 특히 경쟁사와의 차별성에 대해 신경을 쓰라고 한 것 같은데…. 다시 해 오도록 하게.”
 
한 팀장과 홍 상무의 미팅이 있는 날이면 팀원들이 모여 자기들끼리 한탄을 하는 경우가 잦아졌다.
 
“또 야근을 해야겠군. 도대체 팀장은 왜 만날 상무님이 지시하는 내용을 잘못 전달해서 우리를 이렇게 고생하게 하는 거야? 그리고 그 업무를 해야 하는 목적이나 업무 효과에 대해서는 한마디도 설명하지 않고 그냥 우리에게 일을 나눠 주기만 하니 대체 뭐가 어떻게 돌아가는지 알 수가 있어야지. 그래 놓고 ‘왜 말을 못 알아듣느냐, 짬밥이 아깝다’는 식으로 쪼아대기만 하면 어떻게 해?”
 
이런 불평불만이 늘면서 한 팀장과 팀원들 사이에는 대화가 끊기고 냉기류가 감돌기 시작했다. 한 팀장이 시장전략팀을 맡은 것을 후회하고 있던 어느 날 인사팀장이 미팅하자는 연락을 해 왔다. ‘무슨 일 때문이지?’ 인사팀으로 가는 그의 마음은 복잡하기만 했다.
 
업무 지시를 올바로 하는 방법
인사팀 김노경 팀장이 “한 팀장님, 새로운 팀을 맡으면서 어려운 점이 많으시죠?”라고 먼저 인사를 건넸다. 한 팀장은 한숨을 내쉬며 “그렇지 않아도 요즘 생각이 많은데, 어디에 논의할 곳도 없고…. 그런데 무슨 일로 저를 보자고 하신 거죠?”라고 말했다.
 
“다름이 아니라, 매년 실시하고 있는 직원성과 몰입도 조사에서 시장전략팀 팀원들의 몰입도 수준이 지난해보다 훨씬 낮게 나왔습니다. 그 원인을 파악하기 위해 잠시 한 팀장님과의 면담을 요청했습니다.”

출처 : [타워스페린의 HR스쿨] 18호(2008.10.01)
Posted by SB패밀리

[개발] 프로그램 진척도 보고 방법



http://blog.empas.com/eosao1973/18198761

프로젝트 진척도 측정에 있어 가장 믿지 못할 수치가 몇 %완료라는 것이다. 개발자들이나 기획자 혹은 디자이너들이 보통 몇 %를 완료했다고 보고하는데, 측정 기준이 없어 과연 그 수치가 어떤 의미를 가지는지 알지 못할 때가 많다. 

필자는 다음과 같은 측정 기준을 제시하고 주간보고서 및 월간보고서에 업무 단위 당 진척율을 기록하게 한다. 본 기준은 웹 프로젝트를 기준으로 함을 밝혀 둔다.

 

1. 문서 

 40%: 문서 작성 완료 

 60%: 프로젝트 팀 리뷰 후 

 80%: 고객 리뷰 후 

 100%: 고객의 승인 후 

 2. 디자인 

 60%: 디자인 완료 

 80%: HTML 코딩 완료 

 100%: 프로그램과 페이지 연결 완료 



3. 프로그램 진척도 보고 방법

 

 20%: 내부 클래스 및 클래스 구조 완료

 40%: 코딩 완료 (컴파일 완료)

 60%: 모듈 테스트 완료 (실행 완료)

 80%: HTML과 연동 완료 (뷰 완료)

 100%: 시스템 테스팅 완료 (검수완료)

 

위의 기준으로 10% 혹은 39%와 같은 애매한 진척도는 없고, 무조건 위의 기준으로만 진척율을 표시하게 한다. 그러나 전체적인 진척도를 측정하기 위해서는 프로그램 혹은 디자인 전체를 대상으로 진척도를 측정해야 하는데 이는 다음과 같이 측정한다. 

 예) 개발되어야 할 모듈이 10개이고, 이중 4개가 코딩이 완료되었고 6개가 모듈 테이트가 완료되었으면 ((4개 X 40%)+(2개 X 60%))/10= 28%의 전체 진도율을 보인다. 
  
 물론 프로젝트 전체 진도율을 측정하기 위해서는 WBS에 나타나는 모든 업무 단위를 위와 같은 측정 기준으로 작성하여 합한 것이 전체 진도율을 나타내게 된다. 




Posted by SB패밀리

쌈꼬쪼려 소백촌닭
출처 : 인터넷




[IT/컬럼] 이런 IT 회사 가지마라

그냥 주관적인 글입니다.
이런 생각도 있으니 참고 하세요.

1. 직원들 얼굴이 어두운 회사

더이상 말이 필요없다.
직원들 얼굴이 현재진행상황을 알려준다.


2. 우수인재 확보 X

쓸만한 인재인데도 기존의 임금수준과 직급을 들먹이며 빈둥빈둥 시간을 끈다.
결국엔 갓 대학 졸업한 싸구려 인력만 뽑는 회사다.

좋은 인재를 찾으려는 노력자체를 하지않는 회사다.
이런 회사는 인재을 코딩하는 소모품으로 정도밖에 생각하지 않는다.
본인도 소모품으로 취급될 것이다. 빨리 나와라.


3. 테스트 기간 없는 회사

겁나게 큰 프로젝트인데도 테스트 기간을 전혀 잡지 않는 회사
이론상 제작 기간의 2배를 테스트 기간으로 잡아야 정상이다.

하지만 우리나라 특성상 -_-; 
대부분 열악한 기업들이 그리 길게 잡지 못한다.
3명이상 플젝이면 최소 최소 최소 아주 작게 잡아도 1주이상 잡아야 한다.
1주일이면 정말 미니멈이다. 
설계자가 1주일도 테스트 기간을 잡지 않는다면 
내일부터 출근하지 마라.
각종 버그에 고객 요구사항에 뒤처리만 하느라 두배로 기간이 늘어난 프로젝트에 빠져 허우적 댈것이다.


4. 월급이 안나오는 회사

IT기업은 지금도 수많은 회사들이 창업하고 망한다.
인권비는 IT계열에서 수익을 얻기위한 가장 기본적인 유지비용이다.
직원들 월급도 못줄 정도라면 정말 회사 사정이 어려워 진거다.
월급이 한달이라도 밀린다면 사정없이 그만둬라.
프로젝트 진행중이라도 상관 없다!!! 무조건 나와라!!

그리고 그만둘때는 다른일을 핑계대고 
그일만 아니라면 무보수로 몇개월씩 있을수 있다고 강조하며
회사가 어려우니 한달 보수 정도는 포기하면서
도의적 책임을 다하고
(플젝 진행중일테니 한달동안은 무보수로 반드시 도의적 책임을 다해라~! 꼭 명심해라!! 법정에서 유리하다. -_-;; )
사장과 기분좋게 끝내라.

직원들 월급도 못주는 IT기업이 회생할 가능성은 정말 낮다.
차라리 로또를 사라. 그게 확률이 높다.
괜히 인간관계 생각해서 몇개월 무보수로 더 일하면 좋은 꼴 절대 못본다.
사람은 돈이 관계되면 정말 치사해 진다.
특히 장사를 하는 사람은 정말 그렇다.
간이고 쓸개고 다 빼줄듯 하다가 회사 망해서 돈이 없으면 싹 돌아설 것이다.
밀린월급 받으려고 소송들이대고 합의보고 하다보면
잘 해봐야 몇개월 밀린 금액의 반정도로 합의 볼 것이다.
그동안 사장이랑 싸우고 맘고생하고..... 손해가 막심하다.


ps. 참고로 회사 이전은 왠만하면 재직중에 알아봐라
백수로 있으면 마음이 다급해져서 아무회사나 들어가는 경우가 많다.
또한, 보통 회사는 백수로 있는 인재보다는 재직중에 있는 인재를 좋아한다.

어디에선가 '쓸모'있는 인재라는 보장이 있기 때문이다.
(다른 회사에서 일 잘한 인재는 여기서도 일 잘할거야~~)


5. PM이 의사결정을 하지 않는 회사

의사결정을 다른이에게 맡기는 사람은 차라리 낫다.

그런 결정 조차도 하지 않는 PM이다.(지가 못하면 갑한테 물어보든가~ -_-; )

원인은 육안으로 잘 보이지 않지만 
증상으로 쉽게 진단할수 있다.

여러분이 똑같은 프로그램을 대여섯번 새로 만든다면 
확실이 이런 타입의 PM이다.
PM이 의사결정을 확실히 하지 않아 이렇게 짯다가 뒤엎고 저렇게 짯다가 뒤엎는다.
일하는건 문제가 아니다.
의사결정을 하지 않는 PM은 
나중에 플젝이 아작 났을때 책임이 없다.
심지어는 책임을 회피하려고 의사결정을 하지 않는 케이스도 있다.
IT쪽에서 일 존내 마니 하다 보면
플젝이 진흙탕에서 허우적 대다가 정말로 아작 나는 경우도 있다.


근데 이런 PM은 아작나도 책임이 별로 없다.

지가 책임질 부분이 적기 때문이다.

아작 났을때 PM을 제외한 하위 직원들이 아~주 난해하다.

조만간 직원들이 임무 %별로 PM보다 많이 프로젝트 보상금을 물고있는 자신을 보게 될것이다.
(돈 벌러 회사 들어가서 꼴아박고 나오는 케이스.)


6. 유지보수는 10분이면 된다는 회사

아마 만줄 코딩하고 허리한번 피게 될거다.

'고생'외에는 별 단점은 없지만
개인적으로 싫어한다.
나도 인간이다. 
어떻게 주7일동안 일만할수 있는가.

여자친구랑 놀시간도 필요하고 
주말에 인라인도 타야되고 사진도 찍어야 한다.
특별히 프로젝트 마무리단계도 아닌데 평상시에도 
주말보장 안해주는 회사는 개인적으로 '즐'이다.


지금도 수많은 열악한 IT회사들이 있습니다.
이상하게도 이바닥은 소프트웨어산업이 
'무'에서 '유'를 창조하는 줄 알고있는 무식한 사람들이 세운 
열악한 회사가 엄청 많습니다.
IT도 분명히 투자금액이 있습니다.
인권비며 사무실 비용이며 엄청나게 돈이 들어갑니다.
그래도 아직 사회적 인식은 소프트웨어는 공짠줄 알죠 -_-;


그래 그런 멍청한 자들이 지돈 존내 꼴아박고 남의 월급도 못주고
남의 경력 걸레로 만드는 겁니다.

물론 좋은 회사면 오래 있어야 합니다.
그래야 근무년수도 늘고 연봉에도 이익이 많쵸.

그래서 글을 끄적여서 올려봅니다.
이곳 저곳 옮기면서 6개월짜리 경력 5개 가지고 3년 채우면
여러분 IT 경력은 정말 걸레가 되는 겁니다.

그걸 막기 위해
어떤 회사가 좋은건지
어떤 회사가 나쁜건지
어떤 회사에 오래 있어야 되는지



여러분 판단에 조금이라도 도움이 될까 개인적인 생각을 끄적여 봤습니다.

위 글은 저자의 동의 없이 함부로 퍼가셔도 됩니다. -_-)v


2011년에 적은 글이넹.... 

Posted by SB패밀리

소백촌닭은 이글을 읽고 많은 공감을 얻었죠. 

그래서, 여러분들과 이 공감을 함께 나누고자 이 글을 올립니다.

이 페이지는 코리아인터넷닷컴에서도 보실 수 있습니다.

 





"도대체 우리 사무실은 어떻게 왜 이렇게 내 말을 못 알아 듣고, 계획대로 되는 게 없는 거야?"

거래처를 달래느라 밤을 새워 들어가지도 않는 술을 마시고, 반쯤은 길모퉁이에 토하고, 새벽엔 사우나에서 강제로 지쳐서 땅으로 꺼져 들어가는 몸을 깨우고 사무실에 들어서면 썰렁한 사무실, 누군가 밤샘을 했는지 회의실에 침낭을 두르고 움츠리고 자는 사람이 있고, 한 10시가 넘어서야 사무실은 잠에서 깨기 시작하고…11시 되면, 먼가 움직이기 시작한다.

심할 때는 12시가 되도 사무실은 멍한 듯 잠에 취한 것 같다.

 

이런 경우는 회사의 대표가 혼자 뛰는 형이다. 그만큼 회사의 멤버들에게 겉으론 웃을지라도 속으론 불만과 답답함으로 가득차게 된다.

그 반대로 모든지 다 회사의 멤버들에게 지시하고, 자신은 결과만을 독촉하는 ‘관리소장형’이 있다. 그러나 이 역시도 회사의 직원들은 거짓 보고와, 허위로 가득차게 되어 역시 현장의 현실과 거리가 먼 이해와 결과의 차이에 대한 불만과 답답함을 벗어날 수 없다.

자신이 열심히 하는가, 열심이 지시하고 관리를 잘 하는가가 회사의 생산력을 높이는 주요한 KEY가 아니라는 말이다.

생산력이란, 어느 한 사람의 힘이나, 강제나 통제에 의해 만들어지기엔 어느 정도부터 명확한 한계를 드러낸다.

 

어떻게 해야, 프로젝트나 조직의 생산력을 높일 수 있을까?

 

첫째, 모든지 말로 시킨다?

 

내가 분명히 다 설명해줬는데도, 아니 개념까지 말해줬건만 그걸 정리만 하면 되는데…허나 분명 한건, 그 말이 어떻게 이 프로젝트의 이런 의미인지 본인도 증명할 길이 없다. 말이니까..

조직의 커뮤니케이션의 핵심은 보고나, 지시 모든 쌍방향에 있어서 간소하고 핵심적이되, 계량화 되고, 명문화되어 져야 한다. 그래야 명확한 근거와 함께 이해와 의미 전달이 쉬워진다.

언제까지 어느 정도 수준으로 원하는 구체적인 상을 도식 혹은 계량적으로 설명해야 한다. 또한 그것은 일방적인 지시, 전달이어선 안된다. 대부분의 경영자와 관리자가 범하는 오류는 일의 강도를 높힌다는 것을 생산성이란 측면이 아니라, 소위 빡세게 많이 던지고 ‘소위 마구 조지는’ 것으로 착각한다.

그것은 이미 지시된 일을 끝내기도 전에 다른 일이 끼어들어오고, 또 전혀 컨셉이나 방향이 다른 내용이 두개, 세개 마구 겹쳐진다. 그렇다면, 그일을 해내는 사람도 있겠지만 그일을 하나하나 집중해서 풀어낼 때의 효과보다 2배, 3배 이상 질이 떨어지는 것을 알아야 한다.

결과가 대강 나오길 바란다면, 그렇게 던져라. 일은 실무자가 일에 집중할 수 있게 충분한 대화와 공감으로 참여의식과 일의 의미가 공유되면서 진행되져야 한다.

 

둘째, 모든지 대강 지시하고, 결과는 엄문(嚴問) 한다?!

 

모든 일을 경영자가 다 정통 할 수는 없다. 예를 들어 회계와 같은 전문적인 영역에 대해 어떻게 지시를 해야 할 지 조차 모르는 경우가 있다. 따라서 모르는 것을 드러내지 않고 싶으니, 대강 애매하게 지시를 한다.

전문가나 전문영역의 실무자는 그래서 고용하는 것이다. 모른다면 자신의 목적과 필요를 전문 실무자에게 말하고 실무자가 자신이 이해할 수 있도록 계량적이고 도식적인 설명을 하게 해야 한다.

또는 원체 일을 지시하는 습관이 그러한 경우도 있다. 언제까지 하란 건지? 하란 건지 말란 건지? 그리고 잘잘못에 대한 책임을 실무자에게 뒤집어 씌우는 경우가 있다.

이러한 경우 실무자의 능력의 십분의 일도 얻지 못하게 될 것이란 것을 각오하라.

내가 직원으로 고용했고, 일을 지시하면 그 사람의 능력은 모두 회사의 것일까?

천만의 말씀!! 그 사람이 그만한 능력이 있다고 판단하고 연봉 계약을 했다 손 쳐도 그 만한 집중력과 생산력이 저절로 월급봉투에 따라 자동 생산되는 것이 절대 아니라는 것을 기억해야 한다.

회사에서 그만한 비용을 지불했으니, 생산력을 쏟아야지…못 쏟으면…나가… 그러나 그 기회비용과 시간, 또한 이러한 태도로 인한 회사의 사기저하와 의욕저하는 더 큰 손실임을 기억해야 한다.

 

셋째, 생산력을 위해 지각과 퇴근에 대해 예민하고 엄중하게 따진다?!

 

생산성 향상과 결과 도출에 대해, 경영진이 IT 부분에 대한 기술자 출신이거나 또 그렇다 해도 모든 영역에 전공할 수 없으므로, 직원들이 제대로 하고 있는지, 열심히 하고있는지를 판단하는 기준으로 대부분, 야근과 철야를 얼마나 하는 가로 판단한다.

밤을 새우고 벌건 눈을 보는 경영진의 뿌듯함?…은 곧 이렇게 열심히 해도 왜 결과가 이 모양일까?라는 해답 없는 딜레마에 빠지게 될 것이다.

필자의 경험으로 철야는 하루나 이틀 어쩔 수 없는 경우를 제외하고, 일상화되어선 안 된다. 그것을 경영진이 원한다는 것을 눈치 빠른 사람이 못 알아차릴 리 없고 그것은 생산성이 아닌 관성이 되며, 밤에는 집중력이나 생산력이 떨어지는 것은 당연하다. 당연히 그러고는 낮 시간에는 여기 저기 사라져 졸다 오거나, 앉아 일한다 하나, 정신은 이미 몽롱한 상태로 다른 곳을 거닐고 있다는 점을 기억해야 한다.

자신이 부지런하고, 철야에 강하다고 모든 직원이 그러길 바라지 말아야 하며, 더욱 정신 나간 경영자는 자신은 칼 퇴근하고, 일찍 출근해 야근하던 직원들이 칼 출근하지 않는 것을 탓하는 부류들이다.

생산력의 향상을 통제하고 관리하는 것은 시간이 아니라, 시스템이다.

경영자의 무지나, 무능력을 회사 직원에게 전가 하는 방법이 시간의 통제다. 일에 대한 체크와 스케줄, 정확한 업무 분장( 해당 업무에 효율성이 높은 인력의 투입), 각 업무에 대한 관계설정과 중간중간 합의 된 일정과 체계에 의한 업무와 생산 현황에 대한 점검과 오류와 문제 점에 대한 피드백 이러한 시스템이 생산성을 높이는 것이지 시간의 통제는 거리가 멀다.

 

넷째, 회사에서 경영자는 무소불위 전지전능한 존재다?!

 

뭐 이런 ‘개 뻥’을 믿고 사는 ‘환자’들도 간혹 있는 것 같다. 이런 유의 사람들은 회사의 문제나 갈등이 있을 때 자신의 책상 앞에 당사자를 불러 놓고 ‘자…화해해’… ‘ 이제 됐지? 화해한 거지?’ 그럼 직원들은 백이면 백, 다 뭐라 대답할까? 답은 “네” 다. 그러나 정작 화해가 될까?

한 프로젝트의 담당자가 일이 꼬여 어려움을 겪고 있는데 그 일을 지원 혹은 해결 책을 제시한다.‘자 이 프로젝트 김 대리가 안되니까. 경영지원 팀 박 대리가 한번 해보고 싶다고 했지. 그럼 해 봐’ …’자 이제 김 대리 문제 해결됐지?’ 역시…답은 ‘네’ 그러나 그것은 잘못 그 실무담당자의 자존심을 상하게 할 수 있고, 또 정작 담당자의 어려움을 던 것이지 문제의 해결책을 찾은 것은 절대 아니다.

즉 이런 유형의 오류는 자신이 모든지 다 지시하고, 판단해서 해결할 수 있다고 믿고 있으며, 직원들의 문제 역시 자신이 불러 들어보면 다 알 수 있고 바로 대책을 만들어 줄 수 있다고 생각한다. 표면적으론 그렇다. 그러나 실상을 더 썩고 있을 수 있다.

대안의 도출, 조직간의 갈등과 유기적 운영과 대책 생산은 경영자의 책임이지 경영자가 생산해야 할 몫이 절대 아니다. 물론 경영자의 선견지명과 식견, 경험은 그 대안 도출의 핵심적 역할을 할 것이며, 무엇보다 도출된 몇 가지 안과 방책( 반드시 길은 하나가 아니기 때문이다)에 대한 “선택”과 “판단”에 대한 책임의 몫을 가지는 것이다.

혹, 경영자가 혼자 결정하고 판단을 해야 할 때 조차, 직원과의 대화는 다각도로 이뤄져야 한다는 점을 기억해야 한다. 회사의 일을 알고 싶은 경영자는 직원과 대화를 시도하지만 사무실에서 이야기가 쉽게 나올 말이 있고, 사석이나 술 한잔을 빌어 이야기 할 것도 있다는 사실이다. 그것도 개인과 부서, 사석과 공석 등의 다각도로 아마 놀라운 이야길 듣게 될 것이다.

그 이야기의 대부분은 공적이 프로젝트에 대한 이야기와 함께 어떤 세상이나 함께 따라다니는 인간과 인간, 부서와 부서간의 갈등과 반목이 얽혀있는 이야기일 것이다. 그러나 경영자는 누구의 편도 들 수 없다.

솔로몬의 지혜는 정말 성실하고, 회사를 위해 기여하고자 하는 실무자에게 더 힘을 실어주는 방향이, 그 방법이 무엇인지를 고민하는 것이지 자신의 맘에 드는 사람을 골라내는 것이 아니라는 점을 주지해야 한다.

문제 자체를 없앨 순 없다. ( 대부분 ) 문제에는 반듯이 긍정적인 면이 있다. 그것을 찾아내고 그 긍정성을 더욱 강화할 수 있도록 해야 한다.

 

다섯째, 모든지 밀어붙여 채찍질을 해서 무조건 끌고 간다!

 

무림에 내공이란 것이 있다. 비즈니스와 경영에서 실기(失機) 하는 많은 이유 중 하나는 기회자체가 아니라, 기회에 맞선 주체의 내공 때문인 경우가 많다. 사실 사업을 하다 보면 기회와 수 많은 제안, 달콤한 제안을 듣고, 받게 된다. 그러나 정작 그 중 어떤 것이 진짜인지 또 정말 우리가 해야 할 것이 무엇인지 고르다가 시간을 보내거나 그 반대로 욕심이 과해 그 모든 것을 다 가지려고 쥐고 있다 어느 하나도 성취하지 못하고 깨지는 경우가 있다.

 

이러한 경우 경영자의 무작위적 잘못된 욕심으로 실무자에게 일을 던지고 무조건 해내라고 하는 경우가 허다하다. 마치 70년대나 80년대식의 한강의 기적(?)을 바라듯이, 당시의 한강의 기적이 정말 밀어부처서만 된 것인지 그 내막에 대한 이야기는 차치하고서도 라도 이런 방식으로 일이 되지도 않을 뿐더러 그 결과가 과연 회사에 온전히 남을런지도 의심스럽다.

 

기회를 자신의 성공적 비즈니스로 만드는 것은 기회를 포착-선택-집중하는 경영자의 선견지명이기도 하지만, 정말로 이 일이 회사 전체를 이롭게 할 수 있는 것인지를 판단해야 하며, 그 판다는 회사의 내공(?) 수준에 대한 판단과 함께 이뤄져야 한다.

지나치게 큰 프로젝트나, 과감한(?) 확장이 오히려 역으로 회사가 기회가 아닌 위기를 맞이하게 하는 원인이 종종 된다는 점을 반드시 기억해야 한다. 자신 소화 할 수 없을 것이란 일에 대한 분석과 조언, 판단을 했을 경우는 빠른 시일 내 더 큰 능력을 가진 회사로 소개하고 소개 커미션 정도로 만족해야 한다.


또한, 일을 진행함에 있어서, 직원들은 아무리 익숙한 실무자라 하더라도 실수나, 느슨해 지기 마련이다. 또한 전체 조직력과 생산력- 자신에겐 문제가 없더라도 ?에 저해하는 개인적 특성과 업무 습관이 있는 경우도 있다. 이러한 것을 수정, 개선하는 방법으로 경영자는 일방적으로 ‘개인’을 비판하거나, 질타를 가하는 것보다 그 사람에게 긍정적 제안을 함으로 그 부정적 측면을 개선하게 유도하거나, 긍정적 면으로 단점을 극복하도록 해야 한다.

 

예를 들어 학생에게 선생님이 너는 왜 이렇게 숙제를 매일 인해오냐? 너 덜 떨어졌냐? 더 맞아야 정신 들래 하고 무작정 패는 것 보다. 긍정적 제안을 통해 숙제를 즐겁게 혹은 기꺼이 할 수 있도록 유도하는 것이 더 효율적이다. 잘 못 해오던 숙제 중 어느 하나 해온 것이 있을 때, 그 것을 매우 기뻐하며 ‘이봐 이렇게 할 수 있고, 잘할 수 있네’라고 긍정적 측면을 부각하거나, 숙제의 방향을 바꿔서 그 학생이 집중할 수 있는 것을 제출 할 수 있게 조치를 취하는 것이 더 효율적이란 것이다.


그것은 조직의 생리에도 마찬가지다. 

채찍은 아편과 같아서 그 약 발은 잠시 일뿐이고, 또 생산력을 향상시키는 듯 하나 그것은 환상일 뿐이고, 실체가 아닌, 진정한 것이 아닌 억지로 뽑아낸 것과 같다.  




Posted by SB패밀리

sobakcc Control Package v 1.0


2005.01.03


컨트롤 팩키지 버전 1.0이 공개되었습니다.


벌써 만들어 놓은지는 몇년이 지났지만 그동안 구석에 놔두다가 이렇게 올려봅니다.
비주얼 컴포넌트의 컨트롤을 모아둔 팩키지입니다.
이 컴포넌트들은 Flat-Style의 모양으로 각종 컨테이너 컴포넌트 상에 위치하게 됩니다.



* FlatStyle의 비주얼 컴포넌트
* 전체 31개의 컴포넌트가 팩키지 안에 들어 있습니다.


* TCCAboutBox, TCCAlignEdit, TCCAnimation, TCCAnimWnd, TCCButton, 
TCCCheckBox, TCCCheckListBox, TCCColorComboBox, TCCComboBox, TCCDBComboBox,
TCCDBEdit, TCCDBLookupComboBox, TCCDBMemo, TCCEdit, TCCGauge, 
TCCGroupBox, TCCHint, TCCLinkText, TCCListBox, TCCMaskEdit,
TCCMemo, TCCPanel, TCCProgressBar, TCCRadioButton, TCCShape,
TCCSound, TCCSpeedButton, TCCSpinEditFloat, TCCSpinEditInteger, TCCSplitter, TCCTabControl


팩키지를 등록할 수 있는 팩키지 파일 *.bpl과 각 컨트롤의 컴파일된 파일인 *.dcu 파일들이 포함되어 있습니다.

컴포넌트 팔레트에 있는 팩키지의 모습입니다.

Win32 버전에 대해서 자주는 아니지만 지속적으로 컴포넌트를 추가할 예정입니다.
버그가 몇개가 있을지는 모르겠습니다만 버그가 발견된다면 게시판으로 알려주시면 감사하겠습니다.

*.bpl을 포함한팩키지 파일이 무료배포 됩니다








Posted by SB패밀리

순진한 개발자가 사내정치에서 살아남는 법




류한석 (IT 컬럼니스트) ( ZDNet Korea )   2008/03/17

 

개발자 K씨를 재회한 것은 8년만의 일이다. 그는 나와 함께 일했던 직장에서 이직한 이후에 4번이나 더 이직을 했는데, 현재는 실직 상태에서 직장을 구하고 있었다. 

 

솔루션을 개발하는 회사에서는 비전이 없어 그만 두었고, 대기업 계열 SI업체를 들어갔으나 개발이 아닌 관리를 시켜서 그만두었고, 포털에 들어갔는데 할 일이 별로 없고 회사 상황이 정치적이어서 그만두었다고 했다. 그리고 마지막 회사는 소위 벤처기업이었는데, 6개월이나 임금을 받지 못한 상태에서 사장이 사실상 야반도주를 해서 회사가 망했다고 했다. 

K씨는 자바를 정말 잘 다루던 개발자였는데, 일반적인 기준에서 볼 때 성격이 좋다고 얘기하기는 힘든 사람이었지만 그 정도면 무난하다고 할 수 있었다. 다만 여느 개발자와 마찬가지로, 타인의 욕구에 관심을 가지거나 커뮤니케이션 스킬이 뛰어난 사람은 아니었다. 다음은 그가 한 얘기이다.

“회사 경영은 나하고 상관이 없다고 생각했어요. 제가 경영이나 관리 같은 것은 잘 모르고요. 회사에서 벌어지는 정치 게임은 질색이에요. 저는 그저 개발만 하고 싶었어요. 그런데 개발에 집중할 수 있는 조직이 참 없더라고요. 이제 저는 어떻게 해야 할까요?”

필자는 그날 K씨와 새벽까지 술을 마실 수 밖에 없었다. 개발자가 개발자답게 일하고 성장할 수 없는 것이 바로 한국의 현실이다. 성장을 하는 것이 아니라 사라져 가고 있다.

개발자는 어떤 사람인가? 문제를 발견하고 문제를 해결하고, 스펙에 따라(또는 창조적으로) 무언가를 만들어 내고, 오랜 시간 동안 한 자리에 앉아서 화면만을 째려보며 몰입할 수 있기에 개발자다. 그것이 그들의 특징이며 그렇기 때문에 개발을 할 수 있는 것이다. 

개발자에 대해 IT업계의 다른 직종들은 어떻게 생각하고 있을까? 단편적이지만 그들의 생각을 살펴보자. 어떤 영업맨은 “저한테 저렇게 열 시간 동안 앉아 있으라고 하면 절대 그러지 못할 거 같네요. 어떻게 저럴 수 있나요?”라고 필자에게 반문하기도 했다.

어떤 마케터는 “그들은 쿠폰에 항상 도장을 찍더군요. 작은 것에 민감한 거 같아요. 시야가 좁고 자신들의 분야 외에는 거의 관심이 없는 거 같더군요. 게임이나 애니, 미드 같은 것을 좋아하고. 업계나 시장 돌아가는 상황에 대해서는 관심도 없고...”라고 얘기했다. 실제로 마케터들은 개발자와 함께 일하는 경우가 별로 없어서 그들을 잘 모른다. 원거리에서 그들을 바라볼 뿐이다.

반면에 개발자와 함께 협업하는 경우가 많은 요구분석가, 웹기획자들 중 상당수는 다음과 같은 얘기를 했다. “그들은 커뮤니케이션 스킬이 없어요. 중요한 대화에는 제대로 응하지 않다가 자신들과 상관이 있는 이슈가 나오면 발끈해요. 무조건 안 된다고만 하죠. 도무지 협상이라고는 할 줄 모르는 사람들이에요.”

혼자서 일하는 1인 개발자가 아닌 이상, 대부분의 개발자는 조직에서 협업을 해야 한다. 프로젝트 매니저와 대화해야 하고, 기획자/디자이너/동료 개발자와 협업을 해야 한다. 프로젝트에 따라서는 고객과 직접적인 커뮤니케이션을 해야 하는 경우도 있다. 그리고 사내정치를 피해갈 수 있는 개발자는 거의 없다. 직간접적으로 영향을 받을 수 밖에 없다.

그런데 한국에서 사내정치는 중소기업에서 대기업, 인터넷기업까지 만연되어 있다. 많은 개발자들이 정치를 싫어한다. 정확히 표현하면 정치가 미치는 부정적인 영향을 싫어한다고 할 수 있을 것이다. 하지만 조직이라는 것은 그 안에 있는 수많은 조직구성원들이 지위 고하에 따라 자신의 목표와 이익을 추구하는 곳이다. 그리고 그들간의 이해관계는 상충될 수 밖에 없다. 그래서 누군가는 희생자가 된다. 안타깝게도 그 대상은 대부분 개발자이다.

개발자는 현실적인 일정 하에서 보다 나은 기술을 이용하여 높은 품질의 소프트웨어를 만들고 싶어하지만, 어떤 사람들은 기술 자체나 품질은 전혀 상관없이 일자 또는 비용만이 그들의 관심사이다. 그렇다면 그것은 잘못된 것인가? 그럴 수도 있고 아닐 수도 있다. 상황에 따라 답이 다르다. 현실은 단순한 흑백논리로 설명되지는 않는다.



패배하지 않기 위해 이것만은 기억하자

사내정치에서 살아남기 위해서 개발자가 알고 있으면 유용할 세 가지 지침을 제시한다. 다음의 세가지 지침은 서로 연동된다.


1. 나의 목표와 주변의 이해관계를 파악하고 있어야 한다. 


자신이 원하는 것이 돈인지 명예인지 지위인지, 아니면 개발을 통한 자아실현인지, 개인생활의 추구인지 명확히 알고 있어야 한다. 또한 나의 목표를 실현하는데 있어 가장 큰 장애물이 무엇인지 알고서 그것을 관리해야 한다. 자신의 목표와 상충되는 목표를 가진 이해관계자의 욕구를 파악하고 그것과의 타협점을 찾아야 한다. 

하지만 사실, 대부분의 경우 목표를 실현하는데 있어서 가장 큰 장애물은 자기자신의 성격이다. 그렇지만 성격을 수양하는 개발자가 과연 몇 %나 될까? 아는 것과 실천은 완전히 별개의 단계이다.

2. “너와 나의 진실은 다르다”는 사실을 이해하고 있어야 한다. 


자신이 믿는 것만이 정의이고 진실이라는 생각이 들 때, 숨을 세 번 크게 내쉬면서 상대편의 입장에서도 과연 그럴까 다시 한번 생각해 보기 바란다. 내가 알거나 느끼는 것을 쉽게 드러내서는 곤란하다. 대부분의 경우 그것은 설익은 판단이고 타이밍이 적절치 않은 경우가 많다. 하지만 자신의 감정을 주체하지 못하고 ‘욱’한 나머지, 준비도 안된 상태에서 회사를 그만 두어 버리고 경력을 망치는 개발자들이 많다. 퇴사 후 놀고 있는 당신을 사내정치인들은 비웃고 있다.


3. “군자에게는 실수를 해도 소인배에게는 실수를 하지 말라”는 격언을 기억하기 바란다. 


이 말은 필자가 회사 생활에서 곤란을 겪는 후배들에게 숱하게 해주었던 말이다. 이 말을 처음 들었을 때의 임팩트는 상당히 크다. 군자(君子)는 점잖고 덕이 있는 사람이다. 그래서 군자는 누가 실수를 해도 그 이유를 스스로 파악하여 너그럽게 이해해준다. 하지만 소인배는 조금만 불이익을 당하거나 무시를 당했다고 느끼면 바로 삐지며, 심할 경우 끝까지 따라다니며 괴롭힌다.

그런데 사람이란 군자에게는 존경심을 갖고서 공손히 대하고 소인배는 무시한 나머지 함부로 대한다. 그것이 인지상정이다. 하지만 만일 그 소인배가 당신의 직장상사라면?

사내정치는 어느 나라에나 존재한다. 한국뿐만 아니라 미국에도 일본에도 있다. 하지만 한국에서 더욱 사내정치가 심할 수 밖에 없는 이유가 있다. 한국은 아직까지 IT업계뿐만 아니라 사회의 여러 분야에서 전문가의 개념이 불분명한 나라이다. 제대로 된 전문가가 출현하고 그 가치를 인정받는 지식사회가 되기까지 앞으로도 꽤 많은 시간이 걸릴 것이다. 

한국은 아직은 선진 지식사회가 아니다. 그러므로 고급지식을 가진 사람들이 별로 없을 뿐만 아니라, 설사 있다고 하더라도 그것을 인정하지 못하며, 설사 인정한다고 할 지라도 필요로 하지 않는다. 실력을 인정하는 기준이 없으니, 사내정치가 판을 친다.


전문가를 필요로 하지 않는 사회, 자기계발이 살길 


궤변으로 들릴 지 모르지만, 우리 업계에 전문가가 없는 것은 전문가를 필요로 하지 않기 때문이다. 조직 내에 사내정치인이 승진하고 인정받는 것은 조직의 상층부가 몰라서 그런 것이 아니라 그런 사람을 선호하기 때문이다. 

성장은 커녕 생존을 이야기해야 하는 현실이 안타깝지만, 일단 생존해야 자기계발을 하고 경력관리를 하면서 기회를 노릴 것이 아닌가? 사내정치를 잘 할 필요는 없지만(그리고 개발자의 특성상 잘 하지도 못 할 것이다), 희생자가 되어서는 곤란하다. 이것이 바로 필자가 개발자 K씨에게 한 말이다.

개발자는 자신의 개발력과 장점을 해치지 않는 선에서, 이해관계자를 파악하고 그들의 욕구를 다루는 능력을 갖추어야 한다. 자신의 목표를 분명히 해야 하며, 감정에 치우쳐서 일을 그르치지 말아야 한다. 그러지 못한다면 결국 희생자가 될 뿐이다.

그러한 희생을 몇 번 당하다 보면, 개발업에 대한 애정이 식어버려 자기계발을 등한시하게 될 뿐만 아니라 성격까지 나빠져서 더욱 더 안 좋은 상태에 처하게 된다. 그렇게 사라져간 개발자들이 참 많다.

이런 조언을 하는 것에 대해 한편으로는 미안하게 생각한다. 언젠가 개발력만으로도 인정받을 수 있는 사회가 오면(너무 낭만적인 표현이다), 사내정치 대신 좀 더 아름다운 세상에 대해 이야기하겠지만 지금은 아니다. 정신을 똑바로 차리고 이 난세에서 생존하기 바란다. 환경을 바꿀 수 없으면 자신을 바꾸어야 하며, 자신을 진화시킨 개발자에게는 반드시 기회가 올 것이다. 세상은 장기적으로 볼 때 스스로 혁신하는 사람의 편이니까 말이다. @

 

출처 : http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39166851,00.htm

Posted by SB패밀리

아래의 글을 보니... 머릿속에 아련히 그리고 있던 내용들....

정확히 파악하고 있지 못했던...


한 부서에 힘을 실어주는건 보스의 태도를 보면 알 수 있다.

개발부에서 구리로 금덩어리를 만든다고 해도 믿어준다면... 그 회사는 개발부의 파워가 있다는 걸 알수 있다.




 



Technical Career Path를 보장하는 방법


그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까?

첫째, 경영자 의식의 변화이다.

경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수 있도록 노력할 리가 없다.

축구는 체력이 떨어지는 30대 중후반이면 더 이상 선수로 뛰기 어렵지만, 소프트웨어 개발자는 체력과 상관없이 평생 시간이 흐를수록 점점 더 뛰어난 개발자로 일할 수 있다. 이렇게 뛰어난 선수로 일할 수 있는 개발자들을 관리나 하라고 낭비하지 않고 계속 선수로 뛸 수 있도록 회사에서 지원을 해야 한다는 것을 경영자들이 절실히 깨달아야 한다.

아직은 경영자들이 이같은 인식이 부족하거나 막연히 개념만 인지하고 현실은 다르게 행동을 하는데 주위에서 설득하려는 노력이 필요하다. 이 칼럼들을 공유해도 좋고 외국의 사례를 보여주는 한 방법일 것이다. 이는 회사를 위하고 개발자도 위하는 길이다.

둘째, 개발 조직의 변화이다.

개발 조직은 워낙 회사마다 서로 달라서 하나의 형태를 지켜야 한다고 말할 수는 없다. 하지만 개발 조직이 전문 개발자들이 제대로 일할 수 있는 구조가 되어야 한다. 우선 개발팀장, 개발리더, 매니저 등 구분 없이 마구 섞여서 일하는 것은 지양해야 한다.

조직이 아주 작아서 혼자 다해야 하는 경우를 제외하고는 관리자와 개발자는 구분을 하자. 팀이 커져서 관리 일이 점점 많아지면 더 이상 개발자가 개발을 겸해서 하기는 어렵다. 전문 관리자를 두는 것이 좋고, 프로젝트에서도 프로젝트매니저를 따로 두는 것이 좋다. 개발자는 개발에 전념할 때 가장 높은 성과를 낸다. 개발 외의 일은 관리자나 프로젝트매니저가 맡아야 한다.

셋째, 공정한 평가이다.

소프트웨어 개발자로 공정한 평가를 받기 매우 어렵다. 그래서 평가 대상보다는 평가자가 되려고 하는 경향이 있다. 공정한 평가가 대단히 어려운 일이지만 나름대로 객관적인 근거에 의한 평가를 위해서 노력해야 한다. 개발자가 어찌 해볼 수 없는 이유로 평가에서 불이익을 받는다면 개발을 계속 하기가 싫어질 것이다. 소스코드관리시스템과 이슈관리시스템의 기록을 활용하고 개발 일정 준수 등의 지표를 활용하는 것도 좋은 방법이다.

넷째, 적절한 대우이다.

많은 회사에서 팀장이 되고 관리자가 되어야 더 높은 연봉을 받을 수 있다. 그 주된 이유는 관리와 개발의 분리가 안되어 있어서 구분이 안되기 때문이다. 관리를 하지 않고 평생 개발을 한다고 해서 연봉이나 대우에서 불이익을 받아서는 안된다. 오히려 동일 경력에서 개발자가 관리자보다 더 높은 연봉을 받는 것이 맞을 수 있다. 관리자나 개발자나 자신의 전문분야에서 회사에 기여하는 만큼의 적절한 대우를 받아야 한다.

다섯째, Career Path 제공이다.

회사에서 다양한 Career Path를 제공해야 한다. 개발자는 이들 중에서 적절한 시점에 선택을 할 수 있어야 한다. 계속 개발자로 경력을 발전시켜 나갈 수도 있고 관리자나 프로젝트매니저가 될 수도 있다. 또는 다른 일을 맡을 수도 있다. 한번 개발자 경력에서 벗어나면 다시 돌아오기 어려우므로 신중하게 결정해야 한다.

여섯째, 개발문화, 개발 프로세스, 기반시스템이다.

너무 광범위한 내용이라서 다 설명하기는 어렵다. 개발자가 제대로 일하기 위해서는 공유를 기반으로 한 투명한 개발문화와 적절한 개발 프로세스가 필요하다. 또한 개발에 필요한 기반시스템을 제대로 갖추고 있어야 한다. 아무것도 갖추지 못한 회사에서는 개발자가 아무리 개발을 오래해도 가치를 높이기가 어렵다.

일곱째, 롤모델이 필요하다.

롤모델이 있다면 개발자들에게 확실한 길을 보여줄 수 있다. 하지만 무늬만 개발자가 아닌 진짜 개발자를 외부에서 영입하기는 쉽지 않다. 내부에서라도 개발자들의 롤모델을 만들도록 노력해 보자. 회사에서 가장 뛰어난 개발자들에게 관리 일은 덜어내고 개발에 전념할 수 있도록 해주고 회사의 제도가 이를 뒷받침하도록 하자. 회사의 개발 조직이 더욱 탄탄해 질 것이다.

개발자 경력 보장 문화는 개발자들의 인생이 달린 일이다. 아직은 척박하지만 우리가 하나씩 바꿔나가야 한다. 가장 어려운 일은 경영자를 설득하고 깨닫게 하는 일이다. 고양이 목에 방울달기 같은 일이지만 어렵다면 주변이나 전문가의 도움도 받아보자. 지금은 3D 취급하는 사람들도 있는 소프트웨어 개발이 좀더 좋은 대접을 받기 위해서는 개발자 경력 보장이 중요한 단초가 될 것이다.

출처: http://techit.co.kr/9775


Posted by SB패밀리

백번 듣는 것 보다 한 번 직접 보는 게 낫다는 말처럼

책으로만 보는 것보다는 직접 만들어보고 경험해보는 것이,

알고 있는 것보다는 직접 가르쳐보는 것이

확실하게 자기의 것으로 만들 수 있다는 것을....


출처: 인터넷

아래의 글을 읽어 보자....



우유를 시켜먹는 사람보다 배달하는 사람이 더 건강하다.  
2004.06.10 10:23  

류(ryujt)   http://cafe.naver.com/codeway/137 

만년 초보 딱지를 달고 다니는 사람들이 있다.  스스로 초보 수준임을 모르는 사람까지 합하면 그 수는 무시 못할 정도에 이르게 된다.


무엇이 문제일까?  물론 수 많은 개발자들의 숫자만큼 수많은 이유가 있을 것이므로 몇 가지 말로 일반화하기란 너무 어렵다.  다만, 만약 지금 내가 거론하려는 조건들이 그대에게 적용된다면 부디 그 거추장스러운 딱지를 어서 떼어내기를 바란다.



1. 우유를 시켜먹는 사람보다 배달하는 사람이 더 건강하다.


대한민국 국민은 참으로 특이하다.  건강에 좋다고 하면 지렁이도 씨가 말라 버린다.  이러한 요상한 취미는 학문을 하는 사람에게도 고스란히 적용된다.  어떤 이의 방석을 훔쳐 앉으면 합격한다든가, 무엇을 어떻게 하면 성적이 오른다는 등의 비법들이 난무한다.


그 정도는 애교로 봐줄 수 있다.  하지만, 전문가의 길을 걷는, 프로의 길을 걷는 개발자들이 의식적이든 무의식적이든 젖어버린 이 비법 중독은 참으로 어처구니 없다.


간혹 좋은 책이 나오고 이것이 소문이 나면 금새 모든 개발자들은 반드시 그것을 읽어야 한다고 생각한다.  그리고, 그 책을 읽고 나면 자신이 무엇인가 업그레이드 된듯한 만족감을 느낀다.  좋은 강좌나 세미나에 참석했을 때는 그 환각증상이 더욱 심각해 진다.


하지만, 그것은 자신의 것이라고 할 수 없다.  아무리 좋은 것을 듣고 아무리 좋은 것을 읽어도 여전히 여러분의 실력은 그대로이다.  무엇인가 깨닫고 무엇인가 느낀 것이 있다면, 이제 여러분 스스로의 이론과 생각을 창조해 내고, 수없이 연마하는 시간이 필요한 것이다.


누구나 배트를 휘둘러 공을 쳐내는

"기술" 자체는 쉽게 이해할 수 있지만,

실재로 멋지게 공을 쳐내기 위해서는

수없이 헛 방망이질을 해야 하는 것처럼...




2. 재능의 부족을 탓하지 마라


재능이 부족한 그대여.  우리 부족한 재능의 덫에 걸려 넘어지지 말자.


자신감 부족이야 말로 가장 심각한 재난이다.  자신감을 잃어버린 자는 마치 사이드 브레이크를 걸어둔 채로 달리려는 자동차와 같다.  여기에 열정마저 잃어버리면 기름마저 떨어진 꼴이 된다.  계속 뒤를 돌아보고 자신의 부족한 위치에 한숨을 짓는 동안 그대의 발걸음은 늪 속으로 빠져들게 될 것이다.


재능의 차이는 있다.  인정해야 할 수밖에 없는 것을 외면하기 위해 시간을 낭비하지 말자.  하지만, 여러분들이 느끼는 것만큼 그 재능의 차이가 심각한 결과를 가져오는 경우는 없다.


가끔 소위 잘나가는 사람들을 보면, 무엇인가 특별하고 능력이 충만하여 보인다.  그리고, 각종 매스컴들은 그 차이점에 조명을 들이대기 시작한다.  그 때문에 그들이 겪었던 수많은 고난과 땀방울에 대해서는 쉽게 지나치게 된다.  그 어느 누구도 재능과 운으로 인해 쉽게 성공의 길에 들어설 수는 없다.  내가 장담한다.


곰곰이 생각해 보라, 자신보다 능력 있는 자들과의 자신의 차이점을.  현재 그 엄청난 차이에는 분명 재능이라는 거리도 있지만, 그들이 열정과 땀을 흘려가면 노력했던 시간이 더욱 크지 않게는 가?




3. 시작은 호기심의 힘으로, 중반은 열정으로, 마무리는 끈기와 신념으로


싹수가 노랗다고 한다.  그렇다.  그 동안 수많은 개발자들의 팀장을 맡으면서 나름대로 관상 보는 능력이 생긴 듯 하다.  싹수가 노란 놈이 보이기 시작한다.  반대로 “저 넘은 무엇인가 해낼 놈이다” 하고 느낌이 꽂히는 때가 있다.


시작부터 요란한 자는 중도에 반드시 포기한다.  잘나가다가 슬럼프에 빠지는 타입이다.  처음에 프로그래밍을 공부할 때는 모든 것이 신기할 뿐이었다.  무엇인가 만들어 보고는 대견한 자신을 뽐내고 싶어서 친구들에게 자랑하지 못해서 안달이 난다.  아직까지는 지극히 정상이다.  하지만, 그 정도를 넘어서 초보의 영역을 뛰어넘고자 안달이 나기 시작하면 일은 틀어지게 된다.


입문자는 반드시 그 호기심과 기본기 연마 사이에서 균형을 잃지 말아야 한다.  무엇인가 화려하고 어려워 보이는 문제에 대한 호기심은 지극히 정상이며 권장할만한 일이다.  하지만, 누군가에게 물어서 해결할 수 있는 일 보다는 자신 스스로 해결할 수 있는 문제에 대한 도전을 통하여 기본기를 연마할 시기에 너무 힘 빼지 말아야 할 것이다.


나중에 돌이켜 보면 입문자 시절만큼 돌아가고 싶은 시기도 없을 것이다.  그때의 그 기분을 다시는 느낄 수 없기 때문이다.


중도의 길을 들어선 자는 거침이 없어야 한다.  이제 서서히 개발하는 재미에 푹 빠져버려서 “이것이 내 천직이다” 하는 말을 거침없이 내뱉는 시기가 온다.  개발에 대한 예찬이 그 입에서 쉴새 없이 쏟아져 나온다.


하지만, 이 시기에서 입문 시기의 호기심으로만 행동하는 자는 반드시 쓰러지게 된다.  호기심과 열정의 차이는 무엇인가?  누군가 멋진 이성을 만났을 때 가슴 떨림이 호기심이라고 한다면, 사랑을 느끼고 그에게 완전히 녹아 버린 모습이 바로 열정이다.


프로그래밍의 세계에 녹아버려라.  일말의 망설임도 없이, 사랑할 때의 그 뜨거운 가슴으로 개발에 몰두하라.  돌부리를 반기고, 어려운 난관을 즐겨라.  절대 뒤돌아 서지 말고 언제나 승부를 걸어라.  해낼 수 있을 까 걱정하지 말고, “반드시 해내자” 하고 스스로를 위로하라.  자신만의 무용담을 훗날 후배들에게 자랑스럽게 이야기하게 될 그날을 기약하면서……


그리고 이제 완성의 시기.  이 시기는 조용하면서도 험난하다.  스스로 정체기를 느끼는 시절이기도 하다.  이제 교만을 버려야 할 시기이다.  어쩌면 이미 주눅이 들었을 지도 모른다.  여러 프로젝트를 통해 성공과 실패를 겪었을 것이고, 실무란 잘한 것보다 못한 것이 엄청난 위력으로 자신을 짓누르기 때문이다.

그대는 이제 잠시 쉬어도 좋다.  다만, 의미 있는 휴식을 취해야 할 시기이다.  객관적인 안목 그리고 보다 넓은 안목으로 개발을 이해하고 공부해야 할 시기이다.

지금까지는 개발이라는 것이 “고객과 나”, “문제와 나”와 같은 이차원적인 시야가 주된 관심사였을 지도 모른다.  하지만, 개발은 고객, 자신의 회사의 경영자, 마케팅 인원, 기획자, 등 수없이 많은 개발 이해관계자들과의 상관관계를 생각하지 않으면 안 되는 시기가 됐을 것이다.

문치무공(文治武功)이라고 했다.  무장도 결국 정치를 알아야 그 힘이 배가되며, 정치하는 자도 힘의 원리를 알고 인정할 줄 알아야 나라를 제대로 다스릴 수 있는 것이다.  이제는 호기심과 열정보다는 책임감과 끈기로 정체된 자신을 한 단계 업그레이드 시켜야 할 시기 인 것이다.


출근 길에 전철과 버스 안에서 이러 저러한 생각에 빠졌다가 생각난 데로 출근하자 마자 적어본 것입니다.  개인적인 생각일 뿐이니 넓은 아량으로 읽어주시길 바랍니다.

Posted by SB패밀리

개발 프로젝트의 단계별로 나타날 수 있는 Risk



개발 프로젝트의 단계별로 나타날 수 있는 Risk | Codeway  
2004.01.27 16:47  

류(ryujt)   http://cafe.naver.com/codeway/15 


1. 입찰 혹은 영업 단계(Proposal Phase) 
   - 사업주 요구조건(Requirements) 이해 부족 
   - 자체 사업수행 능력의 과대평가 
   - 공기 예측의 실패 



2. 사업기획단계 (Planning Phase) 
   - 항목누락(Omissions) 
   - 업무분류체계(WBS:Work Breakdown Structure) 작성미숙 
   - 수집정보의 잘못 이해 및 적용 
   - 견적(Estimating) 기술의 선택 
   - 주요 비용요소(Major Cost Elements) 관리의 실패 
   - 사업위험(Risks) 평가 및 설정의 실패 



3. 계약 협상 단계 (Negotiation Phase) 
   - 성급한 협상 유도 
   - 협상팀의 「Win」전략에만 집중 



4. 계약단계 (Contractual Phase) 
   - 계약내용의 모순 발생(Discrepancies) 
   - RFP 요구조건과 다르게 계약추진 
   - 사업수행팀과 계약협상팀의 의사소통 부재 



5. 기획 단계 ( Phase) 
   - PM 승인 없이 사업주 요구조건 수락 
   - 사업주와의 의사소통 및 제공 자료에 문제발생 
   - 기획검토회의 미숙 
   - 기획 변경에 대한 웹사이트 개발비 영향 평가 생략 



6. 디자인/프로그래밍 단계(Design/Programing Phase) 
   - 솔루션 구매비의 상승 
   - 기획과 실제 구현 가능한 기술과의 차이 발생 
   - 노무관리의 실패 
   - 공기 지연 (단기 집중 작업, 비논리적 작업) 



7. 납품 및 검수 단계(Submission/Test Phase) 
   - 사업주/사업주측 담당자/개발자 간의 책임부재 혹은 전가 
   - Test 절차 및 Test 요원 경험 미숙

Posted by SB패밀리

두서없이 정리된 용어이다. 기본기가 있어야 더욱 더 커뮤니케이션과 실무가 쉽다.


beta version [베타 버전]
소프트웨어를 정식으로 발표하기 전에 미처 발견하지 못한 오류를 찾아내기 위해, 회사가 특정 사용자들에게 배포하는 시험용 소프트웨어. 베타 버전은 시간이 경과하면 사용하지 못하도록 장치가 되어 있거나 정식 제품이 아님을 표시하는 문구가 표시되어 있는 경우가 많다.

Alpha Version [알파버전]
개발 도중의 하드웨어/소프트웨어에 붙는 제품 버전. 개발 초기 단계에서 개발 기업 내 또는 일부의 사용자에게 배포하여 시험하는 초기 버전으로, 일반적으로 불안정한 상태에서 알파 시험(Alpha Test)을 거쳐 문제점을 보완 한 후 다음 단계인 베타 버전으로 진행한다.

시스템 담당자 구분
H/W담당자 : 네트워크, 컴퓨터 및 coat를 관리
Application 담당자 : 업무지원을 위해서 개발 혹은 도입된 소프트웨어 담당자
운영담당자 : 일반사용자에게 업무를 원활하게 지원할 수 있도로고 각종 주요 데이터를 관리

개발 방법론
패키지 솔루션을 적용하여 고객의 Needs에 맞도록 재구축하는 방법론.
어플리케이션 시스템을 구축하는 방법의 사례에서는 라이프사이클에 따른 업무 수행방법과 산출물을 표시하여 효율적인 개발과 유지보수가 되도록 지원하는 체계

산출물 관리방법
산출물에 대한 형상관리 대상인지 표시

reversion : 변경 전후 내용
final : 최종결과
history : 변경이력

제안서
제품설명과 고객의 현재와 미래를 기술한 문서

제품설명서
패키지 솔루션을 고객이 경영전략과 업무전략 차원에서 설명한 자료와 ITA(ISP)측면에서 설명한 자료

컨설팅
도메인 부분의 지식과 솔루션을 이용 고객의 업무효율을 증진시키는 일

형상관리
시간에 따라 문서나 소프트웨어 하드웨어의 변경을 추적하고 관리할 수 있도록 변경사유와 내용을 지속적으로 관리업무

BPR
Business Process Reengineering, 기업내 비효율적인 요소를 파악하여 업무를 재구성하여 업무효율을 높이는 경영전략

Package
비즈니스 도메인 영역의 내용을 미리 구축하여 적용시간을 단축한 소프트웨어 산출물

PI
Process Innovation, 업무 효율을 높이기 위한 업무의 간소화 재구성 추진 업무

PL
Project Leader, 프로젝트에서 PM의 영역을 지원

PM
Project Manager or Project Management, 프로젝트 관리인력 또는 방법

솔루션
고객의 니즈를 반영해 해결할 수 있는 업무 지원 방법이나 도구.
1)기대하는 기능을 구현할 수 있는 정보와 기술력
2)기대하는 기능을 수행할 수 있는 제품을 가진 경우

staff
프로젝트 지정된 담당자들

stakeholder
프로젝트에 관련된 이해 당사자들, 공급자와 고객에게 프로젝트나 결과에 관계되는 모든 사람으로 시스템 운영자도 포함

 

Posted by SB패밀리


소백촌닭은 이글을 읽고 많은 공감을 얻었죠.
그래서, 여러분들과 이 공감을 함께 나누고자 이 글을 올립니다.

이 페이지는 코리아인터넷닷컴에서도 보실 수 있습니다.

"도대체 우리 사무실은 어떻게 왜 이렇게 내 말을 못 알아 듣고, 계획대로 되는 게 없는 거야?"

거래처를 달래느라 밤을 새워 들어가지도 않는 술을 마시고, 반쯤은 길모퉁이에 토하고, 새벽엔 사우나에서 강제로 지쳐서 땅으로 꺼져 들어가는 몸을 깨우고 사무실에 들어서면 썰렁한 사무실, 누군가 밤샘을 했는지 회의실에 침낭을 두르고 움츠리고 자는 사람이 있고, 한 10시가 넘어서야 사무실은 잠에서 깨기 시작하고…11시 되면, 먼가 움직이기 시작한다.

심할 때는 12시가 되도 사무실은 멍한 듯 잠에 취한 것 같다.

이런 경우는 회사의 대표가 혼자 뛰는 형이다. 그만큼 회사의 멤버들에게 겉으론 웃을지라도 속으론 불만과 답답함으로 가득차게 된다.

그 반대로 모든지 다 회사의 멤버들에게 지시하고, 자신은 결과만을 독촉하는 ‘관리소장형’이 있다. 그러나 이 역시도 회사의 직원들은 거짓 보고와, 허위로 가득차게 되어 역시 현장의 현실과 거리가 먼 이해와 결과의 차이에 대한 불만과 답답함을 벗어날 수 없다.

자신이 열심히 하는가, 열심이 지시하고 관리를 잘 하는가가 회사의 생산력을 높이는 주요한 KEY가 아니라는 말이다.

생산력이란, 어느 한 사람의 힘이나, 강제나 통제에 의해 만들어지기엔 어느 정도부터 명확한 한계를 드러낸다.

어떻게 해야, 프로젝트나 조직의 생산력을 높일 수 있을까?

첫째, 모든지 말로 시킨다?

내가 분명히 다 설명해줬는데도, 아니 개념까지 말해줬건만 그걸 정리만 하면 되는데…허나 분명 한건, 그 말이 어떻게 이 프로젝트의 이런 의미인지 본인도 증명할 길이 없다. 말이니까..

조직의 커뮤니케이션의 핵심은 보고나, 지시 모든 쌍방향에 있어서 간소하고 핵심적이되, 계량화 되고, 명문화되어 져야 한다. 그래야 명확한 근거와 함께 이해와 의미 전달이 쉬워진다.

언제까지 어느 정도 수준으로 원하는 구체적인 상을 도식 혹은 계량적으로 설명해야 한다. 또한 그것은 일방적인 지시, 전달이어선 안된다. 대부분의 경영자와 관리자가 범하는 오류는 일의 강도를 높힌다는 것을 생산성이란 측면이 아니라, 소위 빡세게 많이 던지고 ‘소위 마구 조지는’ 것으로 착각한다.

그것은 이미 지시된 일을 끝내기도 전에 다른 일이 끼어들어오고, 또 전혀 컨셉이나 방향이 다른 내용이 두개, 세개 마구 겹쳐진다. 그렇다면, 그일을 해내는 사람도 있겠지만 그일을 하나하나 집중해서 풀어낼 때의 효과보다 2배, 3배 이상 질이 떨어지는 것을 알아야 한다.

결과가 대강 나오길 바란다면, 그렇게 던져라. 일은 실무자가 일에 집중할 수 있게 충분한 대화와 공감으로 참여의식과 일의 의미가 공유되면서 진행되져야 한다.

둘째, 모든지 대강 지시하고, 결과는 엄문(嚴問) 한다?!

모든 일을 경영자가 다 정통 할 수는 없다. 예를 들어 회계와 같은 전문적인 영역에 대해 어떻게 지시를 해야 할 지 조차 모르는 경우가 있다. 따라서 모르는 것을 드러내지 않고 싶으니, 대강 애매하게 지시를 한다.

전문가나 전문영역의 실무자는 그래서 고용하는 것이다. 모른다면 자신의 목적과 필요를 전문 실무자에게 말하고 실무자가 자신이 이해할 수 있도록 계량적이고 도식적인 설명을 하게 해야 한다.

또는 원체 일을 지시하는 습관이 그러한 경우도 있다. 언제까지 하란 건지? 하란 건지 말란 건지? 그리고 잘잘못에 대한 책임을 실무자에게 뒤집어 씌우는 경우가 있다.

이러한 경우 실무자의 능력의 십분의 일도 얻지 못하게 될 것이란 것을 각오하라.

내가 직원으로 고용했고, 일을 지시하면 그 사람의 능력은 모두 회사의 것일까?

천만의 말씀!! 그 사람이 그만한 능력이 있다고 판단하고 연봉 계약을 했다 손 쳐도 그 만한 집중력과 생산력이 저절로 월급봉투에 따라 자동 생산되는 것이 절대 아니라는 것을 기억해야 한다.

회사에서 그만한 비용을 지불했으니, 생산력을 쏟아야지…못 쏟으면…나가… 그러나 그 기회비용과 시간, 또한 이러한 태도로 인한 회사의 사기저하와 의욕저하는 더 큰 손실임을 기억해야 한다.

셋째, 생산력을 위해 지각과 퇴근에 대해 예민하고 엄중하게 따진다?!

생산성 향상과 결과 도출에 대해, 경영진이 IT 부분에 대한 기술자 출신이거나 또 그렇다 해도 모든 영역에 전공할 수 없으므로, 직원들이 제대로 하고 있는지, 열심히 하고있는지를 판단하는 기준으로 대부분, 야근과 철야를 얼마나 하는 가로 판단한다.

밤을 새우고 벌건 눈을 보는 경영진의 뿌듯함?…은 곧 이렇게 열심히 해도 왜 결과가 이 모양일까?라는 해답 없는 딜레마에 빠지게 될 것이다.

필자의 경험으로 철야는 하루나 이틀 어쩔 수 없는 경우를 제외하고, 일상화되어선 안 된다. 그것을 경영진이 원한다는 것을 눈치 빠른 사람이 못 알아차릴 리 없고 그것은 생산성이 아닌 관성이 되며, 밤에는 집중력이나 생산력이 떨어지는 것은 당연하다. 당연히 그러고는 낮 시간에는 여기 저기 사라져 졸다 오거나, 앉아 일한다 하나, 정신은 이미 몽롱한 상태로 다른 곳을 거닐고 있다는 점을 기억해야 한다.

자신이 부지런하고, 철야에 강하다고 모든 직원이 그러길 바라지 말아야 하며, 더욱 정신 나간 경영자는 자신은 칼 퇴근하고, 일찍 출근해 야근하던 직원들이 칼 출근하지 않는 것을 탓하는 부류들이다.

생산력의 향상을 통제하고 관리하는 것은 시간이 아니라, 시스템이다.

경영자의 무지나, 무능력을 회사 직원에게 전가 하는 방법이 시간의 통제다. 일에 대한 체크와 스케줄, 정확한 업무 분장( 해당 업무에 효율성이 높은 인력의 투입), 각 업무에 대한 관계설정과 중간중간 합의 된 일정과 체계에 의한 업무와 생산 현황에 대한 점검과 오류와 문제 점에 대한 피드백 이러한 시스템이 생산성을 높이는 것이지 시간의 통제는 거리가 멀다.

넷째, 회사에서 경영자는 무소불위 전지전능한 존재다?!

뭐 이런 ‘개 뻥’을 믿고 사는 ‘환자’들도 간혹 있는 것 같다. 이런 유의 사람들은 회사의 문제나 갈등이 있을 때 자신의 책상 앞에 당사자를 불러 놓고 ‘자…화해해’… ‘ 이제 됐지? 화해한 거지?’ 그럼 직원들은 백이면 백, 다 뭐라 대답할까? 답은 “네” 다. 그러나 정작 화해가 될까?

한 프로젝트의 담당자가 일이 꼬여 어려움을 겪고 있는데 그 일을 지원 혹은 해결 책을 제시한다.‘자 이 프로젝트 김 대리가 안되니까. 경영지원 팀 박 대리가 한번 해보고 싶다고 했지. 그럼 해 봐’ …’자 이제 김 대리 문제 해결됐지?’ 역시…답은 ‘네’ 그러나 그것은 잘못 그 실무담당자의 자존심을 상하게 할 수 있고, 또 정작 담당자의 어려움을 던 것이지 문제의 해결책을 찾은 것은 절대 아니다.

즉 이런 유형의 오류는 자신이 모든지 다 지시하고, 판단해서 해결할 수 있다고 믿고 있으며, 직원들의 문제 역시 자신이 불러 들어보면 다 알 수 있고 바로 대책을 만들어 줄 수 있다고 생각한다. 표면적으론 그렇다. 그러나 실상을 더 썩고 있을 수 있다.

대안의 도출, 조직간의 갈등과 유기적 운영과 대책 생산은 경영자의 책임이지 경영자가 생산해야 할 몫이 절대 아니다. 물론 경영자의 선견지명과 식견, 경험은 그 대안 도출의 핵심적 역할을 할 것이며, 무엇보다 도출된 몇 가지 안과 방책( 반드시 길은 하나가 아니기 때문이다)에 대한 “선택”과 “판단”에 대한 책임의 몫을 가지는 것이다.

혹, 경영자가 혼자 결정하고 판단을 해야 할 때 조차, 직원과의 대화는 다각도로 이뤄져야 한다는 점을 기억해야 한다. 회사의 일을 알고 싶은 경영자는 직원과 대화를 시도하지만 사무실에서 이야기가 쉽게 나올 말이 있고, 사석이나 술 한잔을 빌어 이야기 할 것도 있다는 사실이다. 그것도 개인과 부서, 사석과 공석 등의 다각도로 아마 놀라운 이야길 듣게 될 것이다.

그 이야기의 대부분은 공적이 프로젝트에 대한 이야기와 함께 어떤 세상이나 함께 따라다니는 인간과 인간, 부서와 부서간의 갈등과 반목이 얽혀있는 이야기일 것이다. 그러나 경영자는 누구의 편도 들 수 없다.

솔로몬의 지혜는 정말 성실하고, 회사를 위해 기여하고자 하는 실무자에게 더 힘을 실어주는 방향이, 그 방법이 무엇인지를 고민하는 것이지 자신의 맘에 드는 사람을 골라내는 것이 아니라는 점을 주지해야 한다.

문제 자체를 없앨 순 없다. ( 대부분 ) 문제에는 반듯이 긍정적인 면이 있다. 그것을 찾아내고 그 긍정성을 더욱 강화할 수 있도록 해야 한다.

다섯째, 모든지 밀어붙여 채찍질을 해서 무조건 끌고 간다!

무림에 내공이란 것이 있다. 비즈니스와 경영에서 실기(失機) 하는 많은 이유 중 하나는 기회자체가 아니라, 기회에 맞선 주체의 내공 때문인 경우가 많다. 사실 사업을 하다 보면 기회와 수 많은 제안, 달콤한 제안을 듣고, 받게 된다. 그러나 정작 그 중 어떤 것이 진짜인지 또 정말 우리가 해야 할 것이 무엇인지 고르다가 시간을 보내거나 그 반대로 욕심이 과해 그 모든 것을 다 가지려고 쥐고 있다 어느 하나도 성취하지 못하고 깨지는 경우가 있다.

이러한 경우 경영자의 무작위적 잘못된 욕심으로 실무자에게 일을 던지고 무조건 해내라고 하는 경우가 허다하다. 마치 70년대나 80년대식의 한강의 기적(?)을 바라듯이, 당시의 한강의 기적이 정말 밀어부처서만 된 것인지 그 내막에 대한 이야기는 차치하고서도 라도 이런 방식으로 일이 되지도 않을 뿐더러 그 결과가 과연 회사에 온전히 남을런지도 의심스럽다.

기회를 자신의 성공적 비즈니스로 만드는 것은 기회를 포착-선택-집중하는 경영자의 선견지명이기도 하지만, 정말로 이 일이 회사 전체를 이롭게 할 수 있는 것인지를 판단해야 하며, 그 판다는 회사의 내공(?) 수준에 대한 판단과 함께 이뤄져야 한다.

지나치게 큰 프로젝트나, 과감한(?) 확장이 오히려 역으로 회사가 기회가 아닌 위기를 맞이하게 하는 원인이 종종 된다는 점을 반드시 기억해야 한다. 자신 소화 할 수 없을 것이란 일에 대한 분석과 조언, 판단을 했을 경우는 빠른 시일 내 더 큰 능력을 가진 회사로 소개하고 소개 커미션 정도로 만족해야 한다.

또한, 일을 진행함에 있어서, 직원들은 아무리 익숙한 실무자라 하더라도 실수나, 느슨해 지기 마련이다. 또한 전체 조직력과 생산력- 자신에겐 문제가 없더라도 ?에 저해하는 개인적 특성과 업무 습관이 있는 경우도 있다. 이러한 것을 수정, 개선하는 방법으로 경영자는 일방적으로 ‘개인’을 비판하거나, 질타를 가하는 것보다 그 사람에게 긍정적 제안을 함으로 그 부정적 측면을 개선하게 유도하거나, 긍정적 면으로 단점을 극복하도록 해야 한다.

예를 들어 학생에게 선생님이 너는 왜 이렇게 숙제를 매일 인해오냐? 너 덜 떨어졌냐? 더 맞아야 정신 들래 하고 무작정 패는 것 보다. 긍정적 제안을 통해 숙제를 즐겁게 혹은 기꺼이 할 수 있도록 유도하는 것이 더 효율적 이다. 잘 못 해오던 숙제 중 어느 하나 해온 것이 있을 때, 그 것을 매우 기뻐하며 ‘이봐 이렇게 할 수 있고, 잘할 수 있네’라고 긍정적 측면을 부각하거나, 숙제의 방향을 바꿔서 그 학생이 집중할 수 있는 것을 제출 할 수 있게 조치를 취하는 것이 더 효율적이란 것이다.

그것은 조직의 생리에도 마찬가지다. 채찍은 아편과 같아서 그 약 발은 잠시 일뿐이고, 또 생산력을 향상시키는 듯 하나 그것은 환상일 뿐이고, 실체가 아닌, 진정한 것이 아닌 억지로 뽑아낸 것과 같다. 

Posted by SB패밀리

팀원들과 멀어져 가는 팀장
예스주식회사의 한방향 팀장은 최근 시장전략팀의 팀장으로 새로 부임했다. 그는 해외영업팀을 3년 동안 이끌면서 빠른 업무처리와 카리스마적 리더십으로 명성을 날렸다. 지난해 회사는 그를 경영자 승계관리 프로그램의 대상자로 선정했고, 새로운 업무 환경에서 그의 잠재력과 성과를 평가해 보기 위해 이번에 시장전략팀으로 인사 발령을 냈다.
 
시장전략팀은 한 팀장이 기존에 맡던 해외영업팀과는 팀 구성과 조직문화가 많이 달랐다. 해외영업팀은 현장 영업 경력이 있는 남자 직원이 대부분이었고, 상황 변화에 대한 일사불란한 조직적 대응이 장점이었다. 그러나 시장전략팀은 MBA를 마치고 스카우트된 외부 인력과 여성, 신입사원 등 다양한 팀원으로 구성돼 있었다. 팀원들이 회식 참여를 꺼리는 등 한 팀장이 생각하기에는 조직문화도 적극성이 부족했다.
 
새 팀을 맡은 지 얼마 되지 않은 어느 날, 직속상사인 홍길동 상무가 한 팀장을 불렀다.
 
“이번 정기 임원회의 때 논의해야 하니 지난번에 조사한 신제품의 시장 환경에 대해 추가적인 자료조사를 해 주게. 자네도 이번 신제품이 회사에 얼마나 중요한 것인지 내가 전에 자세하게 설명해 줘서 충분히 이해하고 있지? 이번에는 신제품이 경쟁사제품과 어떤 점에서 차별성을 가져야 할지를 특별히 고민해 보게.”
 
홍 상무와의 회의를 마친 한 팀장은 자리로 돌아오자마자 해외영업팀에서 하던 대로 팀원들에게 업무 지시를 했다.
 
“홍 상무님이 이번 신제품에 대한 시장조사를 다음 임원회의 때 발표한다고 하시니 여러분이 준비해서 이번 주 목요일까지 나한테 보고해 줘.”
 
그런데 팀원들의 표정이 예사롭지 않았다. 여기저기서 웅성웅성하는 소리도 들렸다. 선임 과장인 전우치 과장이 머리를 긁적이며 말했다.
 
“팀장님, 그 신제품에 대해서는 지난번에 보고를 했습니다. 팀장님 말씀은 조사를 처음부터 다시 하라는 것인가요, 특정한 부분을 보완하라는 것인가요?”
 
“상무님께서 차별화 얘기를 하시긴 했는데, 다시 보고하라는 말씀은 지난번 보고 내용이 충분하지 않았다는 뜻일 거야. 처음부터 다시 철저하게 조사해서 보고해 줘.”
 
목요일 오후 한 팀장은 홍 상무의 방을 찾았다. 그런데 보고 자료를 본 홍 상무의 표정이 일그러졌다.
 
“아니, 한 팀장. 지난번 보고 내용과 별로 다른 점이 없지 않나? 내가 이번에는 특히 경쟁사와의 차별성에 대해 신경을 쓰라고 한 것 같은데…. 다시 해 오도록 하게.”
 
한 팀장과 홍 상무의 미팅이 있는 날이면 팀원들이 모여 자기들끼리 한탄을 하는 경우가 잦아졌다.
 
“또 야근을 해야겠군. 도대체 팀장은 왜 만날 상무님이 지시하는 내용을 잘못 전달해서 우리를 이렇게 고생하게 하는 거야? 그리고 그 업무를 해야 하는 목적이나 업무 효과에 대해서는 한마디도 설명하지 않고 그냥 우리에게 일을 나눠 주기만 하니 대체 뭐가 어떻게 돌아가는지 알 수가 있어야지. 그래 놓고 ‘왜 말을 못 알아듣느냐, 짬밥이 아깝다’는 식으로 쪼아대기만 하면 어떻게 해?”
 
이런 불평불만이 늘면서 한 팀장과 팀원들 사이에는 대화가 끊기고 냉기류가 감돌기 시작했다. 한 팀장이 시장전략팀을 맡은 것을 후회하고 있던 어느 날 인사팀장이 미팅하자는 연락을 해 왔다. ‘무슨 일 때문이지?’ 인사팀으로 가는 그의 마음은 복잡하기만 했다.
 
업무 지시를 올바로 하는 방법
인사팀 김노경 팀장이 “한 팀장님, 새로운 팀을 맡으면서 어려운 점이 많으시죠?”라고 먼저 인사를 건넸다. 한 팀장은 한숨을 내쉬며 “그렇지 않아도 요즘 생각이 많은데, 어디에 논의할 곳도 없고…. 그런데 무슨 일로 저를 보자고 하신 거죠?”라고 말했다.
 
“다름이 아니라, 매년 실시하고 있는 직원성과 몰입도 조사에서 시장전략팀 팀원들의 몰입도 수준이 지난해보다 훨씬 낮게 나왔습니다. 그 원인을 파악하기 위해 잠시 한 팀장님과의 면담을 요청했습니다.”

출처 : [타워스페린의 HR스쿨] 18호(2008.10.01)
Posted by SB패밀리

소프트웨어는 누가 개발해야 하는가?

김국현(IT평론가)   2006/07/27  
    



소프트웨어는 누가 개발해야 하는가? 세상에 이런 우문이 어디 있느냐 생각할지도 모르겠다. 그리고 '개발자'라 짧게 대답할 것이다. 개발자라는 세 글자에는 외부에서 고용된, 그마저도 몇 단계의 하청을 거쳐, SI 업의 하류 공정을 묵묵히 맡고 있는 젊은이의 초상이 투영된다.

정말 소프트웨어는 그들만의 몫일까? 일견 당연해 보이는 이 상식을 이제는 벗어 버려야 할 때다. 소프트웨어란 '갑'이, 그 중에서도 '현업'이 개발해야 하는 것이다. '을'이 개발하고 ‘갑’은 검수를 하는 현재의 안이한 세태로는 기업이 지녀야 할 속도와 유연성은 참 갖추기 힘든 일이다.

요즈음, 기업의 IT 시스템을 짓는 일을 기업의 사옥을 짓는 일에 섣불리 비유하는 일이 위험해지고 있다 생각하게 되었다. 오늘날의 세태를 생각해 보면 사옥을 지으라 시켜 놓고, 팔짱 끼고 있는 발주자의 모습만이 떠오르기 때문이다. 무언가를 만드는 일의 설렘을 총체적으로 잊어 가는 사회 속에서 주인님이 함께 손에 흙을 묻힐 리가 없는 일이다.

건축이란 적어도 100년, 길게는 세기를 넘긴 미래를 만드는 일이다. 그렇기에 장인의 정성, 즉 고용된 프로페셔널 만으로도 가능한 일이다. 한번 타오른 열정, 100년은 갈 수 있으니 아깝지 않다. 그렇지만 기업의 IT는 오늘을 만드는 일이다. 내일의 비즈니스를 위한 오늘을 매일 매일 만들어야 하는 일인 것이다. 이 사실을 잊을 때 시스템에 우환이 찾아 든다. 기업이 맞닥뜨리게 될 변화의 힘과 속도는 팔짱 낀 방관자적 IT를 두고 볼 정도의 여유가 없다.

시스템을 1년에 걸쳐 치밀히 구축해 봤자, 남는 것은 그 시간 동안 변해 버린 환경과 이를 고려하지 않은 시스템뿐이다. 우리는 이러한 풍경을 수도 없이 목격한다. 새 집을 지어 줬다고 생각했지만, 정작 사용자는 낡고 쓸모 없다 구박한다. 현장의 사용자, 즉 현업이 원하는 그들 마음에 쏙 드는 시스템은 영원히 만들어지지 않는다. 이를 회피하기라도 하듯 현업의 요구는 억제되고, 비즈니스의 혁신은 프로젝트 일정에 의해 묵살된다. 누구를 위한 것인지 알 수 없는 개발 프로젝트는 종료를 향해 앞으로만 내달려 간다.

SI에서 일어나는 관습적 악순환이다. 파견직 개발자들은 자신이 쓸 프로그램이 아니므로, 자신이 유지 보수할 프로그램이 아니므로 정성껏 만들지 않는다. '남'을 위해 짜주는 코드와 '나'를 위해 짠 코드의 질이 같을 리가 없다. 개인이나 집단의 태도나 자질의 문제가 아니다. 인간 본성이다. 훌륭한 프로그램은 남의 집에서 만들어지지 않는 것이다.

미래를 살아 남을 기업은 지금과 같은 태평한 시스템 구축을 견디지 못할 것이다. 그들은 혁신을 위해 더 많은 요구를 할 것이고 그 요구가 받아들이지 못하면 다른 길을 찾을 것이다.

미래 기업은 ① 이상계, 즉 인터넷 서비스 기업이 정성껏 만들어 준 온라인 소프트웨어를 사용하거나, ② 현실계에서 현업 사용자 스스로 직접 소프트웨어를 개발할 것이다.

①은 현재 진행형이다. 온라인 너머로 기업 시스템을 옮기는 SaaS(Software as a Service)라는 행위가 벌어지고 있다. 세일즈포스닷컴(salesforce.com)은 대표적 사례다. 어설프게 개발한 시스템, 어설프게 운영되는 전산실보다 아예 경험 많은 이상계 기업에게 자신의 정보를 업로드해도 괜찮을 것 같다는 정서가 본격적으로 도래할지 모른다. 마치 개인들이 자신의 이메일을 포털에 맡기는 것처럼.

②는 허황된 소리로 들릴지 모르겠다. 비즈니스 수행에 바쁜 기업의 직원들이 언제 프로그래밍 공부하겠냐 할 것이다. 그러나 미래 기업에게는 많은 옵션이 생길 것이다. BPMN(Business Process Modeling Notation)이라는 비전문가도 알 수 있는 단순 조작으로 모듈화된 서비스를 재조합하여 늘 새로운 시스템을 만들자는 SOA의 철학은 엔드 유저 컴퓨팅(EUC)이라는 이루지 못한 꿈을 다시 꾼다. 마치 위키를 쓰듯, 기업 시스템을 현업이 스스로 '매시업(mash-up)'해 주무르는 IBM의 QEDWiki는 ‘사용자가 직접 개발’하는 웹 2.0적 '참여의 아키텍처'를 꿈꾼다. 마이크로소프트 오피스 차기 버전에 새롭게 등장한 Excel Services는 엑셀로 서버 프로그래밍을 가능하게 한다. 회계사 겸 서버 프로그래머, 서버 프로그래밍을 할 줄 아는 보험 업무 담당자가 대거 등장할 것이다.

일을 하다가 필요한 부분은 현업이 직접 만들어 쓰는, 그 정도까지는 아니라도 혁신을 위한 변경은 스스로 수행하는 회사에 어떤 기업이 당할 수 있을까? 전산실에 의뢰하고, 전산실은 외부 발주하여 6개월 뒤에나 오픈할 수 있는 기업과, 오늘 판단하여 내일 바뀔 수 있는 기업 중 누가 승리에 가까이 있을까?

처음에만 외주 개발을 하고 유지 보수를 포함한 2차 개발을 스스로 해결하려는 기업이 생겨나고 있다. 이미 실력 있는 개발자를 '전문 위원'이라고 계약 고용을 하고 있는 기업들이 생기고 있다. 그들은 적극적으로 양질의 개발 인력을 직접 확보하려고 애쓰고 있다. 그들은 그들의 변화 속도, 그들의 혁신을 스스로 제어하고 싶은 것이다.

IT를 관리 대상이나 설비로 본다면 이러한 행태는 착오라 해야 할 것이다. 핵심 역량이 아닌 것은 아웃소싱해야 하니까. 그러나 IT를 비즈니스의 거울, 비즈니스 수행의 주체라 생각한다면 ②의 용기를 내는 기업은 내일의 서바이벌이 두렵지 않다.

IT 시스템을 MVC, 즉 모델, 뷰, 컨트롤의 큰 덩어리로 나뉠 때 적어도 모델 정도는 충분히 현업이 만들어 낼 수 있음을 이제는 인지해야 한다. 그러나 현실계의 기업들이 이 가능성을 인지하지 못하고 하도급 공정에 안주한 채 변화에 둔감해 있다면, 그나마 있던 현실의 기회와 가치들은 모두 현실계를 떠나 이상계로 넘어 가 버릴지 모르는 일이다. 적어도 이상계나 환상계는 남을 시키지 않고 자기 스스로 직접 개발하고 있다. 남을 위한 노동은 나를 위한 작품을 보통은 이길 수 없는 법이다.

1970년대에 알란 케이는 그의 꿈 다이나북을 위해, 프로그래밍 언어이자 동시에 사용자 인터페이스인 스몰토크를 구상했다. 짜는 것과 쓰는 것을 떼어 생각하지 않았던 것이다. 그가 꿈꿨던 하드웨어의 미래는 오늘 우리 무릎 위에 있지만, 그가 꿈꿨던 소프트웨어의 미래는, 그리고 그가 꿈꿨던 '소프트웨어를 만드는 사용자'들은 아직 우리 곁에 보이지 않는다. "사용자는 공동 개발자로 여겨져야 한다"는 웹 2.0적 참여의 이상이 익어 갈 무렵에는 '소프트웨어를 만드는 사용자'들을 우리 곁에서 찾아 볼 수 있을까?@

 

출처 : 인터넷

Posted by SB패밀리
쌈꼬쪼려소백촌닭
출처 : 인터넷

[IT/컬럼] 이런 IT 회사 가지마라

그냥 주관적인 글입니다.
이런 생각도 있으니 참고 하세요.

1. 직원들 얼굴이 어두운 회사

더이상 말이 필요없다.
직원들 얼굴이 현재진행상황을 알려준다.


2. 우수인재 확보 X

쓸만한 인재인데도 기존의 임금수준과 직급을 들먹이며 빈둥빈둥 시간을 끈다.
결국엔 갓 대학 졸업한 싸구려 인력만 뽑는 회사다.

좋은 인재를 찾으려는 노력자체를 하지않는 회사다.
이런 회사는 인재을 코딩하는 소모품으로 정도밖에 생각하지 않는다.
본인도 소모품으로 취급될 것이다. 빨리 나와라.


3. 테스트 기간 없는 회사

겁나게 큰 프로젝트인데도 테스트 기간을 전혀 잡지 않는 회사
이론상 제작 기간의 2배를 테스트 기간으로 잡아야 정상이다.

하지만 우리나라 특성상 -_-;
대부분 열악한 기업들이 그리 길게 잡지 못한다.
3명이상 플젝이면 최소 최소 최소 아주 작게 잡아도 1주이상 잡아야 한다.
1주일이면 정말 미니멈이다.
설계자가 1주일도 테스트 기간을 잡지 않는다면
내일부터 출근하지 마라.
각종 버그에 고객 요구사항에 뒤처리만 하느라 두배로 기간이 늘어난 프로젝트에 빠져 허우적 댈것이다.


4. 월급이 안나오는 회사

IT기업은 지금도 수많은 회사들이 창업하고 망한다.
인권비는 IT계열에서 수익을 얻기위한 가장 기본적인 유지비용이다.
직원들 월급도 못줄 정도라면 정말 회사 사정이 어려워 진거다.
월급이 한달이라도 밀린다면 사정없이 그만둬라.
프로젝트 진행중이라도 상관 없다!!! 무조건 나와라!!

그리고 그만둘때는 다른일을 핑계대고
그일만 아니라면 무보수로 몇개월씩 있을수 있다고 강조하며
회사가 어려우니 한달 보수 정도는 포기하면서
도의적 책임을 다하고
(플젝 진행중일테니 한달동안은 무보수로 반드시 도의적 책임을 다해라~! 꼭 명심해라!! 법정에서 유리하다. -_-;; )
사장과 기분좋게 끝내라.

직원들 월급도 못주는 IT기업이 회생할 가능성은 정말 낮다.
차라리 로또를 사라. 그게 확률이 높다.
괜히 인간관계 생각해서 몇개월 무보수로 더 일하면 좋은 꼴 절대 못본다.
사람은 돈이 관계되면 정말 치사해 진다.
특히 장사를 하는 사람은 정말 그렇다.
간이고 쓸개고 다 빼줄듯 하다가 회사 망해서 돈이 없으면 싹 돌아설 것이다.
밀린월급 받으려고 소송들이대고 합의보고 하다보면
잘 해봐야 몇개월 밀린 금액의 반정도로 합의 볼 것이다.
그동안 사장이랑 싸우고 맘고생하고..... 손해가 막심하다.


ps. 참고로 회사 이전은 왠만하면 재직중에 알아봐라
백수로 있으면 마음이 다급해져서 아무회사나 들어가는 경우가 많다.
또한, 보통 회사는 백수로 있는 인재보다는 재직중에 있는 인재를 좋아한다.

어디에선가 '쓸모'있는 인재라는 보장이 있기 때문이다.
(다른 회사에서 일 잘한 인재는 여기서도 일 잘할거야~~)


5. PM이 의사결정을 하지 않는 회사

의사결정을 다른이에게 맡기는 사람은 차라리 낫다.

그런 결정 조차도 하지 않는 PM이다.(지가 못하면 갑한테 물어보든가~ -_-; )

원인은 육안으로 잘 보이지 않지만
증상으로 쉽게 진단할수 있다.

여러분이 똑같은 프로그램을 대여섯번 새로 만든다면
확실이 이런 타입의 PM이다.
PM이 의사결정을 확실히 하지 않아 이렇게 짯다가 뒤엎고 저렇게 짯다가 뒤엎는다.
일하는건 문제가 아니다.
의사결정을 하지 않는 PM은
나중에 플젝이 아작 났을때 책임이 없다.
심지어는 책임을 회피하려고 의사결정을 하지 않는 케이스도 있다.
IT쪽에서 일 존내 마니 하다 보면
플젝이 진흙탕에서 허우적 대다가 정말로 아작 나는 경우도 있다.


근데 이런 PM은 아작나도 책임이 별로 없다.

지가 책임질 부분이 적기 때문이다.

아작 났을때 PM을 제외한 하위 직원들이 아~주 난해하다.

조만간 직원들이 임무 %별로 PM보다 많이 프로젝트 보상금을 물고있는 자신을 보게 될것이다.
(돈 벌러 회사 들어가서 꼴아박고 나오는 케이스.)


6. 유지보수는 10분이면 된다는 회사

아마 만줄 코딩하고 허리한번 피게 될거다.

'고생'외에는 별 단점은 없지만
개인적으로 싫어한다.
나도 인간이다.
어떻게 주7일동안 일만할수 있는가.

여자친구랑 놀시간도 필요하고
주말에 인라인도 타야되고 사진도 찍어야 한다.
특별히 프로젝트 마무리단계도 아닌데 평상시에도
주말보장 안해주는 회사는 개인적으로 '즐'이다.


지금도 수많은 열악한 IT회사들이 있습니다.
이상하게도 이바닥은 소프트웨어산업이
'무'에서 '유'를 창조하는 줄 알고있는 무식한 사람들이 세운
열악한 회사가 엄청 많습니다.
IT도 분명히 투자금액이 있습니다.
인권비며 사무실 비용이며 엄청나게 돈이 들어갑니다.
그래도 아직 사회적 인식은 소프트웨어는 공짠줄 알죠 -_-;


그래 그런 멍청한 자들이 지돈 존내 꼴아박고 남의 월급도 못주고
남의 경력 걸레로 만드는 겁니다.

물론 좋은 회사면 오래 있어야 합니다.
그래야 근무년수도 늘고 연봉에도 이익이 많쵸.

그래서 글을 끄적여서 올려봅니다.
이곳 저곳 옮기면서 6개월짜리 경력 5개 가지고 3년 채우면
여러분 IT 경력은 정말 걸레가 되는 겁니다.

그걸 막기 위해
어떤 회사가 좋은건지
어떤 회사가 나쁜건지
어떤 회사에 오래 있어야 되는지


여러분 판단에 조금이라도 도움이 될까 개인적인 생각을 끄적여 봤습니다.

위 글은 저자의 동의 없이 함부로 퍼가셔도 됩니다. -_-)v
Posted by SB패밀리

20일 오전에 MS가 주관하는 ‘2007 데브데이’ 행사에 참석했다. IT업계에 종사하는 사람이라면, 아마도 한번쯤은 MS의 독점성과 라이선스 정책 등에 대해 불만을 품어봤을 만하다. 그럼에도 불구하고 SW 개발자들의, MS에 대한, 관심은 어느 행사보다 뜨거움을 느낄 수 있었다.

기자는 오전 행사 중 한국MS의 최고기술임원인 김명호 박사(혹은 이사, 왠지 모르지만 박사라는 호칭이 더 어울린다)의 기조연설만 듣고 나서 김박사와의 짧은 인터뷰를 진행할 수 있었다. 그는 기조연설과 인터뷰를 통해 ‘한국에서 SW 개발자가 가야 할 길’에 대해 <희망차고도 암울한> 사회적 딜레마를 이야기해 주었다.

아래의 글은 김명호 박사를 통해 들을 이야기를 바탕으로 작성해 보았다.

[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다.

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다.

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다.

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다.

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다.

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다.

훌륭한 개발자가 되려면?
1) 기본에 충실해야 한다.
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다.

2) 지식의 포트폴리오를 유지하라.
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다.

3) 분야 전문가나 해박한 지식을 갖춰라.
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다.

4) 학습을 두려워 마라.
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다.

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라.

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다.

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?>
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다.

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다.

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다.

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다.

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다.

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다.

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다.

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다.

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다.

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다.

출처 : ZDNet Korea

쌈꼬쪼려 소백촌닭
Posted by SB패밀리

프로젝트를 진행하기 위해서 기획단계에서부터 구현이전단계까지 스토리보드라는 것이 만들어집니다.

그러면, 이 스토리라는 것은 무엇이고 스토리보드에 필요한 것은 무엇인지 알아보자.

스토리보드란 프로젝트를 설계하는 디자인 설명서입니다. 개발 기획서가 프로젝트 개발의 청사진이라면 플로우차트는 타이틀의 인터랙션을 나타내는 것이고 스토리보드는 설계도이자 구체적인 작업지침서입니다.
스토리보드가 완성되면 디자이너는 스토리보드에 명시된 내용에 따라 화면 디자인을 하고 일러스트를 제작합니다.
프로그래머는 스토리보드를 보고 프로그램 설계를 하고 각 세부 로직을 프로그래밍하게 됩니다.
스토리보드는 프로젝트 기획이 완성되었다고 할 수 있는 산출물이며 설계 및 구현을 위한 리소스라고 할 수 있습니다.

스토리보드에 대한 더 자세한 설명이 아래 사이트에 있으니 참조하기 바랍니다.

링크 http://blog.naver.com/jooshe12/100051451581

아래 링크에는 스토리보드 작성법이 설명되어 있습니다.
링크 http://blog.naver.com/jooshe12/100051451534



쌈꼬쪼려 소백촌닭
Posted by SB패밀리

웹사이트를 검색엔진에서 제대로 검색되게 끔 하기 위해 알아야 할 15가지 사이트맵(site map) 제작 규칙에 대하여 알아본다.

사이트맵은 사이트 전체의 메뉴구조나 페이지 분류를 설명할 수 있는 것으로 일종의 가이드라인, 지도, 안내표 라고 할 수 있습니다.
검색엔진에서 로봇이 웹사이트를 들러들러 방문해서 정보,키워드,를 가져갈 때 사이트맵이 있다면... 더 많은 정보를 로봇에게 전달할 수 있을 것입니다...

아래 링크에서 괜찮은 내용을 전달하는 것 같아서 링크를 걸어봅니다.


링크 : http://blog.naver.com/jooshe12/100051453726


쌈꼬쪼려 소백촌닭
Posted by SB패밀리