미니의 꿈꾸는 독서, 그리고 프로그래밍 이야기

새해가 밝았습니다. 올 한해는 모두 소망하는 것들이 이루어지기를 바라겠습니다. 작년의 프로젝트를 정리하고 올 한해의 계획을 세우면서 다시 한번 느낀점이 바로 기획의 부재였습니다. 단순히 이런 아이디어가 좋다라는 것으로 시작해서 개발을 하다 보면 예상하지 못한 이슈들에 부딪히고 결국 흐지부지 되어 버리고 말죠. 누구의 말처럼 새로운 사업을 하는데 있어서 가장 흔한 것이 바로 아이디어가 아닌가 합니다. 사람들은 자신의 아이디어가 아주 훌륭한 것처럼 이야기 하지만 결국 누구나 다 생각하고 있는 것이 바로 이 아이디어가 아닐런지요? 이런 아이디어를 구체화 하고 실현 가능하도록 만드는 것이 더욱 중요한 부분이라고 봅니다. 그런 측면에서 작년에는 기획이라는 부분의 필요성을 확실히 느꼈습니다. 현재 기획자들이 경험이..

프로젝트 관리자가 관리해야 할 항목은 보편적으로 다음의 9가지를 이야기 합니다. - 품질관리 - 범위관리 - 위기관리 - 통합관리 - 일정관리 - 원가관리 - 인력관리 - 의사결정 - 구매관리 모두 중요합니다만, 프로젝트를 진행하면서 느끼는 점은 결국 사람이 만든 문제는 사람이 해결해야 한다는 점입니다. 즉 인력관리가 가장 복잡하면서도 어렵지 않나 생각합니다. 프로젝트 관리자가 되면, 프로젝트 수행을 위한 팀원을 적든 많든 배정받게 됩니다. 물론 슈퍼맨을 배정받으면 좋겠지만, 대부분은 일반적인 개발자를 만나게 될 겁니다. 이런 경우, 진정한 리더는 팀원들 자체에 신경쓰기 보다는 그 팀원들의 가능성을 식별해야 한다고 합니다. 가능성.... Project Management - A systems approa..

지난 글에서 프로젝트 성공 요인 중 변경관리, 희의관리, 이해관계자, 변화관리에 대해서 살펴봤습니다. 이번에는 이슈화, 리스크관리, 인적자원, 현실과 지표의 괴리에 대해서 알아보겠습니다. 다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다. 5. 사소해 보이는 문제도 '이슈화' 하자 프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다. 이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다. 이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행..

2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다. 4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다. 1. 업무 변경 관리로 프로젝트 성공률을 높이자. 첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다. 방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요 변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요. 단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미..

지난번에 위험(risk)의 원인, 식별, 위험관리 프로세스에 대해서 이야기했습니다. 위험이라고 하는 것은 드러나기 전에 처리하는 것이 가장 좋기 때문에 이런 위험 관리가 필요합니다. 실제로 위험이 발생한 이후 처리한다면 프로젝트에 타격도 그만큼 크겠죠.. 4. 위험 관리 그래서 이번에는 위험을 관리하는 방법에 대해서 먼저 살펴보도록 할께요.. 위험을 관리한다고 해서 모든 위험요소를 제거할 수는 없을 겁니다. 그러나 위험관리를 통해서 위험을 회피하거나 위험요인을 줄이거나 위험 발생시 비상대책을 수립하는데 도움이 될 수 있습니다. 이러한 위험관리에 대해서 정리해 봅니다. 1) 획득 (Procurement) 프로젝트 수행 중에 기술적인 위험요소가 발생한다면, 그런 기술을 가지고 있는 사람이나 조직을 구해서 해..

Don't call me names! 언뜻 보면 "내 이름을 부르지 마라" 일 것 같지만, 실제 의미는 "욕하지 마라", "약올리지 마라" 라는 뜻으로 사용되는 문장입니다. names가 복수가 아닌 단수형인 name으로 사용되었다면 이름이라는 의미 그대로 쓰였겠지만, 복수가 되면서 여러개의 이름 즉, 별명으로 보기 때문에 위와 같은 뜻이 되었을 거라고 합니다. 이름이라는 것은 하나의 고유한 의미를 가져야 합니다. 그리고 이름을 지어준다는 것은 그 객체(물체이건 상황이건)에 생명력을 불어넣는 계기가 됩니다. 빅무(Big Moo)라는 책에 나오는 이야기 인데요.. 뉴턴이 중력을 발견해서 유명해진 것으로 알고 있지만, 실제로 뉴턴이 발견한 것은 미적분과 반사 망원경이라고 합니다. 뉴턴은 미적분과 연금술 연구에..

바라바시가 쓴 링크라는 책에서는 웹에서의 visibility에 대해 이야기 하고 있습니다. 웹에서의 visibility(가시성)의 척도는 바로 링크의 개수이다. 당신의 웹페이지로 들어오는 링크가 많으면 많을수록 그것은 가시적이다. 웹에서의 visibility는 매우 중요하죠.. 만약 내 페이지에 대한 링크가 전혀 없다면, 아무도 제 블로그를 찾아오지 않을 테니까요.. 다음으로 서점에 가서 책을 살 때 여러분은 어떤 것을 중점적으로 보나요? 물론 상품평이 좋고, 유명한 책을 고르겠죠.. ^^ 저의 경우는 글자 크기와 폰트를 봅니다. 책을 읽는데 부담이 없어야 하기 때문이죠.. 어떤 분은 그림이나 표가 많은 책을 산다고 합니다. 글로 주절주절 적어놓은 것보다 하나의 그림이 더 많은 이야기를 해주고 있으니까요..

개발자로서 살아가는 것은 정말 쉬운 일이 아닙니다. 왜냐하면 끊임없이 변해야만 하기 때문이니까요.. 보통의 직업은 한번 익힌 기술을 가지고 어느정도는 평생 먹고 살수가 있습니다. 물론 그들도 끊임없이 자기 발전을 위해 노력하는 면은 있을 겁니다. 그러나 우리 개발자만큼은 아닐거라고 생각합니다. 끊임없이 나오는 새로운 용어와 기술들, 발전하는 하드웨어, 진보하는 플랫폼, 여기에 새로운 언어들까지.. 새로운 것을 배워서 2~3년 써먹다 보면 어느덧 구석기 시대의 기술이 되어버리는 느낌이라고나 할까요? 변하기 위해서는 끊임없이 배워야 하지만, 의외로 개발자들은 변화에 익숙하지 않은 것 같습니다. 새로운 것을 받아들이는 것을 두려워하기보다는 귀찮아하는 면이 많은 것 같습니다. 지금 기술로도 충분한데.. 왜 그걸..

리펙토링을 실제로 어떻게 수행하는지.. 마틴 파울러(Martin Fowler)의 리펙토링 책에 나온 내용을 요약합니다. 여기에 정리한 내용은 인덱스 정도로 활용하시고.. 실제 리펙토링을 위한 예제나 자세한 설명은 책을 참고하시기 바랍니다. 1. 메소드 정리 (Composing Methods) Extract Method (136) 그룹으로 함께 묶을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다. Inline Method (144) 메소드 몸체가 메소드의 이름 만큼이나 명확할 때는, 호출하는 곳에 메소드의 몸체를 넣고 메소드를 삭제하라 Inline Temp (146) 간단한 수식의 결과값을 가지는 임시변수가 있고, 그 임시변수가 다른 리펙토링을 하..

프로그래머들은 한번쯤 리펙토링이라는 것을 들어봤을 겁니다. 리펙토링이 좋다는 것은 익히 들어 알겠는데 실제로 못하는 경우가 대부분입니다. 왜 그럴까요? 우선, 리펙토링이 무엇이고 어떻게 하는 것인지 모르기 때문인 것 같습니다. 솔직히 저도 리펙토링 관련 책을 이번에 읽어보기는 했지만, 아직도 어떤 경우에 리펙토링을 해야 하는지 느낌이 확 오지는 않습니다. -.- A->B로 변경하는 것이 설명되어 있으면, 바로 B->A로 바꾸는 것도 설명되어 있습니다. 즉, 경우에 따라 적용하는 리펙토링이 다르다는 것인데.. 이건 경험이 필요한 것 같습니다.~ 끊임없이 생각해보고 변경하다보면 어떤 것이 올바른 리펙토링인지 알수 있지 않을까 합니다. 다음으로는 리펙토링을 하고 있으면, 윗분들은 아무것도 하지 않고 있다고 생..