IT 이야기/IT와 사람 19

아키텍트,PM,개발자의 차이...(1)

PM,아키텍트,개발자.. 모두 프로젝트에서 없어서는 안될 사람들이다. IT 생활을 하다보니 각자의 역할이 명확하게 다르고 거기에 요구 되는 능력도 다르다는것을 알게 되는데. 반대로 제역할을 못하는 사람들과 일을 하게 되면 참으로 고달퍼 지는건 사실이다. * 프로젝트 메니져 프로젝트 메니져의 역할은 어떻게든 프로젝트를 성공적으로 끝내는 것이다. 인원이나 일정에 대한 관리뿐만 아니라, 특히 돈 (Budget)과 위험요소(Risk)에 대한 관리가 중요하다. 무엇보다 중요한것은 Communication이다. 고객과의 의사소통과 팀원들과의 의사소통이 가장 중요한 역할이다. 그 과정에서 RISK들이 자연스럽게 도출되고, 각자의 능력을 최대화해줄 수 있는 방법을 찾을 수 있게 된다. 경험상 많은 프로젝트 관리자들을 ..

IT를 하면서 필요한것...

언제 한번 시간 나면 정리할려고 했던건데.. 마소에서도 요청이 왔었고.... 후배 개발자들을 위해서 필요한것들... VIew & Vision 보는 시야가 틀려져야 한다.. 구멍가게 시스템만 개발하다 보면 구멍 가게에 필요한 비젼과 시야만을 가지기 때문에 발전할 수 없다. 한국 개발자들도 세계에서 맹활약하는 사람들이 많다. 결코 한국 엔지니어가 세계 시장에서 뒤떨어지지 않는다.. 특유의 성실함과 집요함은 아마 세계 최고가 아닐까? Passion 열정... 열정없이 하는 일이 재미있고 제대로 될리가 없다.. 열정이 가장 중요하지 않을까? 하려고 하는 의지만 있다면 결국은 하게 된다. 연금 술사라는 책에서 나와 있듯이.. "우주는 자신이 간절히 바라는 방향으로 움직이게 된다." Exprience 경험 역시 매..

프로젝트를 가장 쉽게 망치는 방법

들은건 많고 좋은것을 많이 알고 있을때... RESOURCE (시간과 인력)은 확보하지 않고 기능과 요건만 추가할때... 열역학 제 1 법칙 에너지 보존의 법칙 "우주의 총 에너지 합은 변하지 않는다..." 고로 요건을 추가하고 RESOURCE가 변화하지 않을때, 소프트웨어의 품질은 떨어진다. 프로젝트를 망치기 가장 쉬운방법은 RESOURCE 에 상관없이 많이 욕심을 부리면 됩니다.

이런 오픈소스 라이센스 정책이 있었으면 좋겠다..

어느나라나 개발에서 무리한 야근이 있는것은 자명한 사실인것 같고... 그래서 다음과 같은 오픈소스 정책이 있었으면 좋겠다.. == 이 소프트웨어는 상용이든 무슨 목적으로던지 사용할 수 있으며 단 이 소프트웨어를 개발하는데 사용된 리소스에 대해서 개발 조직이 야근을 할 경우에는 해당 개발자 시간당 수당의 * 1.2를 한 금액을 개발자에게 야근 수당으로 지불해야 하며 주말 근무의 경우에는 *2배의 금액을 지불해야 한다. 만약 이러한 라이센스 규약을 위반이 적발된 경우 개발자 임금을 소급적용하여 지불하고... 본 소프트웨어의 LIST PRICE의 10배 금액을 배상한다.. 등등등 == 이런걸 Apache랑 GPL 라이센스에만 적용해줘도... 개발자들이 살만하지 않을까? ㅎㅎ 금주에 있을 빡쎈 야근 모드를 생각..

HP 비리...

드디어 걸렸다. IT 업계에서 비리 뇌물, 단합이 하루이틀일이 아닌데.. HP가 제일 먼저 걸렸네. 몇년전에 IBM에서도 이런일이 있었는데.. 그나마 깨끗하고 룰을 지켜가며 일하는 HP가 이정도였다니.. 나름 충격이네.. 한국에서 골프장 사용고객층의 가장 많은 부분이 IT쪽이라니.. 할말 다한거 아닌가? 이글을 보면서.. 내가 영업쪽이 아니라 기술쟁이인것이 한편으로는 다행이고.. 이런 비리에 무감각해져있던 내 모습을 되돌아보면서... 자칫하면 큰일나겠다도 싶다.. 항 상 이야기 하지만 공급업체가 바뀌어야 하겠지만.. 무엇보다 고객이 가장 많이 바뀌어야 하지 않을까? 아직도 고객 회식자리에는 영업이 회식비 내주러 오는 경우가 종종 있으니.. 이런걸 미안해 하지도 않고 당연시 하는 문화가 이런일들을 계속 만..

깨진 창문 이론

요즘 어찌어찌 하다 보니 앤드류 헌트의 펜이 되어버렸다. Pragmatic 시리즈의 저자인데, 요즘 유행하는 Agile 방법론등의 시초가 되는 실용주의 방법론을 외치는 사람이다. 형상 관리, 빌드 자동화 책을 보다가 어찌어찌 해서 실용주의 프로그래머라는 책을 읽었는데. 재미있는 글이 하나 있어서 기록해 놓는다. 이른바 "깨진 창문 이론" 깨진 창문 이론이란, 도시에 있는 한 건물에 창문이 하나 깨지게 되면, 그로 인해서 주변이 지저분해지고 낙서도 많아지고 결국에는 그 지역이 할렘화 된다는 이야기이다. 즉 작은 문제 하나를 방치해 놓으면 모르는 사이에 그것들이 점점 커져서 나중에는 대치할 수 없는 문제가 된다는 이야기다. 소프트웨어 개발이나 인생 살이도 다른게 하나 없는것 같다. 사소한 BUG하나가 나중에..

프로와 아마추어의 차이

프로는 불을 피우고, 아마추어는 불을 쬔다. 프로는 자신이 한 일에 대해 책임을 지지만, 아마추어는 책임을 회피하려고 급급한다. 프로는 기회가 오면 우선 잡고 보지만, 아마추어는 생각만 하다 기회를 놓친다. 프로는 돌다리도 두드리고 건너지만, 아마추어는 두드리고도 안 건넌다. 프로는 자신의 일에 목숨을 걸지만, 아마추어는 자신 일에 변명을 건다. 프로는 여행가이고, 아마추어는 관광객이다. 프로는 남의 말을 잘 들어주고, 아마추어는 자기 이야기만 한다. 프로의 하루는 25시간이지만, 아마추어의 하루는 24시간뿐이다. 프로는 뚜렷한 목표가 있지만, 아마추어는 목표가 없다. 프로는 행동을 보여 주고, 아마추어는 말로 보여준다. 프로는 너도 살고 나도 살자고 하지만, 아마추어는 너 죽고 나 죽자고 한다. 프로는..

평가의 방법

오늘 인턴 사원 평가를 했다. 예전 팀장 시절에는 체계가 없어서 제대로된 평가를 한적이 없었는데. 오늘은 인턴사원이지만 평가를 하면서 시니어로써의 무게를 느껴봤다. 하나 얻은 교훈은 "피드백을 할때, 좋은 것을 80%, 나쁜것을 20%" 이야기 하라는 것이다. 맞는말인지, 의미는 잘 모르겠지만, 예전에 내가 평가를 받을때의 느낌을 생각해보면 맞는 말 같다. 사실 피드백에서 나쁜점들이 50%이상 나온다면, 이미 그 사람은 회사에서 존재하기 어려운 사람이 아닐까? '칭찬은 고래도 춤추게 한다'고, 업적을 찬양해서 일할 수 있는 동기를 부여하고, 부족한점은 메꿔 나가게 하는것이 메니져로써의 역할이 아닐까?