목록PM Story (40)
Joypia
일기기 전에 - 이 글은 무려 7년 전에 작성한 것이어서 상당한 오류가 발생했을 수 있다. 그럼에도 불구하고 아직도 여전히 이런 구성의 프로젝트 관리도구를 시도한 예를 찾아보지 못했다. SI 프로젝트가 힘든 이유 중 하나는 불확실성 아니 좀더 가깝게 표현하면 불가시성이다. 누구나 현재 계획대로 프로젝트가 진행되는 지 바로 즉시성 있게 알고 싶어한다. 또는 일정대로 진행되지 않는다면 과연 그 원인은 어디서 기인하는지 객관적이고 정확한 정보를 그것도 단시간에 얻기 원한다. 이에 대해 많은 사람들이 노력하여 관리툴들을 쏟아내고 있지만 마땅한 것이 없다. 그나마 쓸만한 것은 가격이 비싸거나 개발자들에게 또다른 일거리를 안겨주는 부담이 있다. 한편으로 오픈소스를 이용해서 프로젝트의 전체 영역과 전주기를 자동으로 ..
앞서 얘기 하고자 했던 것은 우리가 개발방법론이라는 것을 여러가지 도입해서 사용하고, 또 각각 방법론을 조합해서 사용하기도 하지만, 실제 얼마나 도움이 되는지는 안따지고 막연히 최면에 빠져 사용하는 게 아닌가 하는 점을 들었다. 과연 생산성이 올라가고, 품질이 높아졌는가 하는 것이다. 오히려 문서 작성으로 개발자를 괴롭히고는 몰라서 그런다. 능력이 없다라고 하면서 억지 춘향을 부렸다고 나도 양심고백을 하면서, 다른 PM 들도 다르지 않을 것이라고 감히 생각한다. 혹 동의 못하시는 분들에게, 한가지 예를 들고 넘어가자. 처음부터 개발하지 않고, 2차 또는 3차 개발 사업에 투입되었을 경우, 그 전 산출물을 얼마나 참조하는가? 그 많은 종류의 산출물 중에 몇가지나 들쳐 보는가? 다른 문제이긴 한데, 그 산출..
지금 부터 하는 얘기는 상당한 오류를 포함할 수 있다. 이글은 무려 7년 전에 작성했던거고, 내가 SW 공학 전문가도 아니요, 솔직히 개발방법론 가이더나 모델러도 아니기 때문이다. [생각하기 1] 개발방법론은 SW 개발을 성공시키는 필수 방정식이다. 공학이란 모름지기 수학이나 다른 기초과학처럼 이론에서 발전하는 것이 아니라, 상당한 경험을 분석하여 발전시키는 것이니, 개발방법론 또한 수많은 SW 개발 사례를 분석하여 나온 결과인 셈이다. 따라서 적합한 방법론을 적용한 것이라면, 그 방법론대로만 하면 그 개발은 반드시 성공할 것이다. [생각하기 2] 내가 프로그램을 짜기 시작한 후 상당 기간 동안은 나름대로의 방법으로 알아서 개발했다. 1990년대 말부터 개발방법론을 발주처에서 요구하기 시작했고, 처음 정..
프로젝트 진행에 있어서 고객이 가장 큰 리스크인 이유는 그를 만족시켜야하는 의무가 있기 때문이다. 고객이 만족해야 우리는 보수를 받을 수 있다. 문제는 잘 알고 있듯이 고객이 발주를 내었음에도 불구하고, 그들은 자기의 요구사항을 모른다는 것이다. 다라서 개발팀에게 가장 훌륭한 고객은 요구사항 뿐마 아니라 SI 의 전반적인 것에 잘 알고 있어서 개발자와의 의사소통이 원할하고, 기술적 제약에 대해 충분히 이해해 주는 것이다. 그 다음으로 개발팀이 도움이 되는 고객은 전혀 모르는 고객이다. 이 경우 보통 고객은 개발팀을 매우 신뢰하고 전문가 집단으로 대우한다. 알아서 '잘' 해주기를 바란다. 물론 프로젝트가 진행될수록 고객도 지식이 생겨서 더 많은 것을 요구하는 위험이 있긴하다. 가장 문제가 되는 고객은 아이..
SI 회사는 그 특성상 직원들이 회사에 있지 않는다. SI 프로젝트는 대부분 그 발주처에 상주하여 개발하기 때문이다. 간혹 본사에서 개발하기도 하나 극히 드문 현상이다. 그리고 이 경우 별로 좋은 결과가 나지 않는다. 발주처내에 작업공간을 마련하지 못한다면 차라리 근처에 사무실을 얻어서 작업장을 꾸미는 것이 훨씬 프로젝트를 위해서는 좋다. 따라서 오히려 본사에 직원들이 많이 있다는 것은 곧 회사가 안돌아 간다는 것을 뜻한다. 대부분의 사장님들은 이럴 경우에 극도의 스트레스를 받는다. 나역시 실행 총괄을 맡아 회사 전체의 사업관리를 할 때에는 본사에 직원들로 북적되면 여간 신경 쓰이는 것이 아니었다. 그런데 이런 특성으로 인해 반대의 문제가 하나 생긴다. 직원들이 대부분 나가있는 데다 그 기간이 적어도 6..
요즘 SI 개발업체 인력운영의 가장 큰 특징은 수행조직을 철저히 분업화하여 운영하는 것이다. 따라서 PM 및 사업관리를 제외하고는 다른 팀원들은 전체 프로젝트 기간에 투입되지 않는다. 아마도 인건비 절약이 가장 큰 이익조건이 되기 때문일 것이다. 우선 PL 및 상당한 기간의 유경험자(중급 개발자 이상)가 설계를 하고 설계에 대한 승인이 나면, 단순 코딩을 하는 일반 개발자들이 투입된다. 좀 더 규모가 크거나 예산이 풍부할 경우 또는 예산이 풍부하고 갑, 을 모두 프로젝트 성공에대한 열망이 대단한 경우 테스트 전담인력을 마지막에 투입한다. SI 업체의 경영적인 측면에서는 보기 좋을지 모르겠지만, 수행팀 입장에서는 생각보다 프로젝트가 쉽게 진행되지 못한다. 원인이나 고려해야할 사항이 여러가지가 있겠지만 여기..
고객은 개발 중 기능변경은 쉽게 이루어 질 수 있다고 생각하는 경우가 많다. CBD 등 여러 방법론을 어설프게 알고있는 경우는 그 경향이 더 심해지는 것 같다. 본격적인 개발 중이거나 개발단계가 끝나고 나서 일어나는 변경은 개발팀 입장에서 볼 때 매우 치명적이다. 이런 현상이 발생되는 원인은 여러가지가 있으며, 복합적이다. 우선 고객의 담당자가 이원화되었을 때이다. 공공기간의 경우 실제 사용할 부서가 있지만 보다 확실한 사업수행을 위해서 전산을 담당하는 부서와 같이 진행하거나 아예 주도하는 경우가 많다. 앞의 경우(전산부서가 옵저버인 경우)는 좀 나을 수 있으나 전산부서가 주도하는 후자의 경우, 실 컷 개바랬는데 정작 테스트 단계에서 실제 사용자들의 불만이 터져나오기 일쑤다. 두 번째로 개발하고자 하는 ..
프로젝트 수행 중 가장 큰 리스크 중에 하나가 바로 고객이다. 이유나 원인은 여러가지가 있겠지만 그 중 가장 큰 것은 고객 자신이 발주를 냈음에도 정작 본인들이 무엇을 원하는지 모른다는 것이다. 즉 요구사항이 불분명하다. 해서 자주 그 요구사항이 바뀐다. 그것도 끝날 때 까지. 이는 개발에 대한 방법론만 강조하고 중요시 했지 정작 고객이 발주를 내기위한 방법론이나 가이드가 전혀 없어서 일어나는 현상이다. 그나마 한다는 것이 ISP 이다. 일반적인 비즈니스가 통용되는 민수기업의 경우는 모르겠지만, 공공기관은 대한민국에 딱 하나밖에 없는 경우(어떤 것은 전세계에 하나밖에 없다)가 대부분이다. 그런데도 뻔뻔스럽게 대부분의 ISP 업체는 일반적인 비지니스 프로세스의 템플릿을 갖고 ISP 를 수행한다. 따라서 개..
다음 일반적인 공공프로젝트 수행시 체크하고 준비해야할 PM의 업무체크 리스트이다. 이외 필요한 부분을 추가 및 수정하여 원할한 사업관리가 되도록 한다. - 착수시 1. 과업내용서 작성(요즘은 작성하지 않는 경우가 더 많아지고 있다) 2. 사업수행계획서 작성 3. 착수계 작성(공문, 용역책임자계, 보안각서), 산출내역서(FP산정), 주요의사결정자 인적정보 4. 착수보고 일시 협의, 참석자, 보고서 제본, 다과(사전 발주처 담당자에게 반드시 문의 필요) 및 필기도구, 빔포인터, 착수보고 장소 5. 착수보고 후 식사 여부 확인 6. (식사를 할 경우)식사 장소 섭외(반드시 발주처 담당자와 비용 처리를 협의) 7. 작업장 파악: 책상 및 의자 등 집기류, 회의실, 프린트, 복사기, 팩스, 랜선 및 전원, 기타 ..
다른 사업은 어떤지 모르겠지만, SI의 경우 진짜로 고객과 수행사가 한 배를 탄 것과 같다. 두 주체가 사업전체에 항상 맞물려 돌아가기 때문이다. 해서 서로가 서로에게 마치 우리가 자동차를 구입할 때 처럼 어느 정도 행운이 따라줘야 한다. 우리는 자동차를 살 때 선택권이 없다. 운이 나쁘면 - 멀쩡해 보이지만 잘 못 조립된 차가 걸리면 - 계속 속을 썩이게 되고, A/S 받는 것이 짜증나며, 100% 완료가 안되어 스트레스를 받는다. 따라서 고객 입장에서도 아주 훌륭한 PM 과 열정적인 개발자를 만나는 것이, 수행사 입장에서는 무리한 요구나 전혀 논리가 맞지않고 '갑질'이 선수인 담당자를 만나지 않는 것이 엄청난 행운이다. 이미 얘기한 것처럼 프로젝트는 사람이 하는 것이라 담당자와 친밀한 관계가 유지되면..