Joypia

프로젝트를 진행하다 보면 매번 소홀히 하는 것이 있다. 그 중 하나가 메뉴얼 작업이다. 메뉴얼 작업이 소홀한 이유는 크게 두 가지로 생각된다. 첫 째, 글재주도 없고 작성 가이드가 너무나 개발자 위주이다. 작성 가이드가 얼마나 형편 없는가 하면 화면설계서에서 항목을 조그만 바꾸면 사용자 메뉴얼이 된다. 이렇게 하지 않고 무언가 그래도 마지막으로 작품(?)을 남기고 싶어서 일반적인 형태의 크라운판 메뉴얼을 만든다고 해도 실제 사용자는 알아보기 힘들게 만들어진다. 아무리 알기 쉽게 쓴다고 해도 그것은 작성자 기준이다 보니 생기는 현상이다. 그러니 설령 소홀히 하지 않았다고 해도 보는 사람은 대충 만들었다고 느낄 수밖에 없을 것이다. 둘 째, 대부분의 개발이 끝난 끝물에 작업하기 때문이다. 보통 SI 프로젝트..

앞서 얘기 하고자 했던 것은 우리가 개발방법론이라는 것을 여러가지 도입해서 사용하고, 또 각각 방법론을 조합해서 사용하기도 하지만, 실제 얼마나 도움이 되는지는 안따지고 막연히 최면에 빠져 사용하는 게 아닌가 하는 점을 들었다. 과연 생산성이 올라가고, 품질이 높아졌는가 하는 것이다. 오히려 문서 작성으로 개발자를 괴롭히고는 몰라서 그런다. 능력이 없다라고 하면서 억지 춘향을 부렸다고 나도 양심고백을 하면서, 다른 PM 들도 다르지 않을 것이라고 감히 생각한다. 혹 동의 못하시는 분들에게, 한가지 예를 들고 넘어가자. 처음부터 개발하지 않고, 2차 또는 3차 개발 사업에 투입되었을 경우, 그 전 산출물을 얼마나 참조하는가? 그 많은 종류의 산출물 중에 몇가지나 들쳐 보는가? 다른 문제이긴 한데, 그 산출..

지금 부터 하는 얘기는 상당한 오류를 포함할 수 있다. 이글은 무려 7년 전에 작성했던거고, 내가 SW 공학 전문가도 아니요, 솔직히 개발방법론 가이더나 모델러도 아니기 때문이다. [생각하기 1] 개발방법론은 SW 개발을 성공시키는 필수 방정식이다. 공학이란 모름지기 수학이나 다른 기초과학처럼 이론에서 발전하는 것이 아니라, 상당한 경험을 분석하여 발전시키는 것이니, 개발방법론 또한 수많은 SW 개발 사례를 분석하여 나온 결과인 셈이다. 따라서 적합한 방법론을 적용한 것이라면, 그 방법론대로만 하면 그 개발은 반드시 성공할 것이다. [생각하기 2] 내가 프로그램을 짜기 시작한 후 상당 기간 동안은 나름대로의 방법으로 알아서 개발했다. 1990년대 말부터 개발방법론을 발주처에서 요구하기 시작했고, 처음 정..

프로젝트 진행에 있어서 고객이 가장 큰 리스크인 이유는 그를 만족시켜야하는 의무가 있기 때문이다. 고객이 만족해야 우리는 보수를 받을 수 있다. 문제는 잘 알고 있듯이 고객이 발주를 내었음에도 불구하고, 그들은 자기의 요구사항을 모른다는 것이다. 다라서 개발팀에게 가장 훌륭한 고객은 요구사항 뿐마 아니라 SI 의 전반적인 것에 잘 알고 있어서 개발자와의 의사소통이 원할하고, 기술적 제약에 대해 충분히 이해해 주는 것이다. 그 다음으로 개발팀이 도움이 되는 고객은 전혀 모르는 고객이다. 이 경우 보통 고객은 개발팀을 매우 신뢰하고 전문가 집단으로 대우한다. 알아서 '잘' 해주기를 바란다. 물론 프로젝트가 진행될수록 고객도 지식이 생겨서 더 많은 것을 요구하는 위험이 있긴하다. 가장 문제가 되는 고객은 아이..

고객은 개발 중 기능변경은 쉽게 이루어 질 수 있다고 생각하는 경우가 많다. CBD 등 여러 방법론을 어설프게 알고있는 경우는 그 경향이 더 심해지는 것 같다. 본격적인 개발 중이거나 개발단계가 끝나고 나서 일어나는 변경은 개발팀 입장에서 볼 때 매우 치명적이다. 이런 현상이 발생되는 원인은 여러가지가 있으며, 복합적이다. 우선 고객의 담당자가 이원화되었을 때이다. 공공기간의 경우 실제 사용할 부서가 있지만 보다 확실한 사업수행을 위해서 전산을 담당하는 부서와 같이 진행하거나 아예 주도하는 경우가 많다. 앞의 경우(전산부서가 옵저버인 경우)는 좀 나을 수 있으나 전산부서가 주도하는 후자의 경우, 실 컷 개바랬는데 정작 테스트 단계에서 실제 사용자들의 불만이 터져나오기 일쑤다. 두 번째로 개발하고자 하는 ..

PM이 가장 먼저 신경쓰는 것이 팀원 구성이다. 그리고 그 구성된 팀원을 어떻게 잘 이끌어 가는가가 프로젝트의 성패를 좌우한다. 팀원이 구성되는 경우는 대게 3가지 경우이다. - PM의 의사와 상관없이 팀원이 구성되는 경우, - 어느 정도 자기가 원하는 팀원으로 구성되는 경우, - 팀원의 일부 또는 전부가 계약직(프리랜서)으로 구성되는 경우 이다. 두번째를 제외하고 첫번째와 세번째는 PM 입장에서 여간 난감한 게 아니다. 우선 쉬운 두번째의 경우를 보자, 이런 경우는 보통 회사 사정이 여유가 있을 때 발생한다. 사업을 준비하는 단계부터 PM 으로 내정되고, 자기와 소통이 잘되고 실력 있는 팀원을 물색하여 해당 팀원의 동의도 받아 놓을 정도로 준비과정 부터 탄탄하다. 여기엔 PM의 리더로써 자질만 있으면 ..

자 그럼 일정 계획을 세워보자. 가장 힘든 작업이다. 단순 패키지를 커스텀마이징하는 것과는 달리 미래예측이기 때문이다. 가장 큰 이유는 그 주체가 '사람'이기 때문이다. 그래도 계획은 세워져야 한다. 그나마 다음과 같은 경우는 근미래(?)를 예측할 수 있다. 따라서 아래와 같은 사업을 계획했는데 큰 변경이 일어난다면 그 PM은 혼나야 한다. 1) 연차사업으로 해당 업무를 개발한 경험이 있는 경우 2) 타 기관에서 동일한 사업을 수행한 경험이 있는 경우 3) 이미 개발된 시스템을 재개발하는 경우 사실 위 1)번 사업을 제외하고는 2), 3) 번도 나름 리스크가 존재한다. 그래도 처음으로 개발되는 사업에 비하면 그 정도가 매우 낮다. 더 쉽게 설명하자면 경험이 중요하다는 것이다. 이 부분에 대한 모순을 해결..