다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다.
5. 사소해 보이는 문제도 '이슈화' 하자
프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다.
이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다.
이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행 모니터링 -> 이슈 종결 내용 공지
이슈가 문제가 되면 리스크(위험)이 됩니다.
그럼에도 불구하고 이슈가 발생할 것 같으면 쉬쉬하고 내부적으로 해결해 보려는 노력을 많이 합니다.
프로젝트에서는 이슈가 언제든지 발생할 수 있습니다. 이런 문제를 내부에서만 조용히 해결하려다 더 큰 문제가 많이 발생할 수 있습니다.
사소한 이슈라도 제대로 파악하고 챙기는 프로젝트 관리자가 되어 보시기 바랍니다.
프로젝트를 추진하다 보면 예상치 못한 문제에 부딪쳐 진행이 순조롭지 않은 경우가 있다. 이럴 경우 담당자는 문제 발생 초기에 나타나는 현상을 사소하게 보거나 대수롭지 않게 생각하기 쉽다. 그래서 이를 공개적으로 문제화하지 않고 담당자 혼자 또는 관련자 몇 사람이 모여서 토의하는 수준에서 자체적으로 해결하려고 한다. 이런 과정을 통해 문제가 완전히 해결되면 다행이지만, 그렇지 않고 대증적 처방에 머물러 문제를 잠복시키게 되면 프로젝트 전체 일정에 지장을 초래하게 된다.
프로젝트팀은 프로젝트 초기에 예측 가능한 범위 내에서 최대한 정교한 프로젝트 계획을 세우게 된다. 하지만 시간에 따라 변하는 현실 상황을 감안하기에는 어려움이 따른다. 그 때문에 프로젝트를 진행하면서 계획을 수정하거나 보완하게 되는 경우가 발생하게 된다.
이렇게 프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때, 이런 경우를 '이슈의 발생'으로 정의하자. 먼저 이슈가 생겼을 때 어떻게 처리할 지에 대한 절차를 세워야 한다. 절차를 세우면서 제일 먼저 '어떤 것을 이슈라고 할 것인가'라는 이슈 관리 기준을 정해야 한다. 이런 절차 및 기준은 회사별로 다를 수 있으며, 또 프로젝트 규모 등 성격에 따라 달라질 수 있다.
예를 들면 어떤 사안이라도 일정에 차질을 초래하면 이슈로 인식하는 것이다. 이슈로 인식하는 일정 차질의 일수를 며칠로 할 것인가라는 기준은 프로젝트 기간에 따라 정할 수 있다. 6개월 이상 되는 프로젝트의 경우 전체 일정의 1～2%에 해당하는 일수를 일정 차질 기준 일수로 정하는 것도 한 방법이다. 이런 일이 생기면 미리 수립돼 있는 이슈 관리 프로세스를 따르게 해야 한다. 그 절차는 6단계로 나뉘어 있다.
첫째, 이슈 발생의 인지다. 정해진 기준에 따른 일정 지연의 사안이 발생하면 프로젝트 관리 조직에서는 이슈를 인지하게 된다. 이슈의 인지는 프로젝트 관리의 자동화 및 정교화 정도에 따라 프로젝트 관리 조직이 자동으로 인지할 수 있거나 해당 프로젝트 팀원 및 관련자가 신고하도록 해야 한다.
둘째, 인지된 이슈의 분류다. 사전에 이슈 관리 등급을 정해야 한다. 예를 들면 파급되는 영향의 규모, 프로젝트 내부 해결 가능 여부, 추가 투입 자원 규모 등을 분류해야 한다. 분류된 이슈는 중요도에 따라 우선 순위를 부여해 관리하도록 한다.
셋째, 이렇게 이슈에 관한 분류 작업이 이뤄지고 나면 이에 따른 대응 방안을 세워야 한다. 우선 자체적으로 해결될 수 있는 이슈라면 자체 대응 방안을 세우도록 해야 한다. 물론 이럴 때 추가 자원이 필요하다면 이에 따른 자원 투입 의사결정을 정해진 기준에 따라 받아야 한다. 프로젝트 관리 조직이 해결할 수 있는 범위 내에서는 즉각 승인하고 범위를 벗어나면 의사결정권자의 승인을 신속하게 받도록 해야 한다.
하지만 프로젝트 내부가 아니라 외부와 관련된 이슈인 경우에는 프로젝트 관리 조직에서 관련자들과의 협의 과정을 거쳐 대응 방안을 수립해야 한다. 예를 들어 비즈니스 부분에서 당초에 예상돼 있지 않은 추가 요건이 발생한다든지, 비즈니스의 의사결정이 이뤄지지 않아 지연되는 문제에 대해서는 프로젝트 관리 조직에서 비즈니스를 관장하는 의사결정권자에게 신속히 이슈를 알려주고 이로 인해 일정이 지연되고 있음을 주지시키고, 아울러 CEO에게도 이런 사실을 같이 알리는 장치가 있어야 한다. 이렇게 필요한 의사결정이 적시에 이뤄지지 않아 일정에 차질이 빚어지는 경우가 많음에도, 이런 문제가 제대로 알려지지 않는 경우 또한 많다.
넷째, 대응 방안이 수립되고 이에 따른 영향도가 평가되고 나면 프로젝트 관리 조직에서는 프로젝트 팀원들이 정해진 일정에 따라 대응 절차를 진행하도록 해야 한다. 이렇게 이슈의 발생으로 인해 처리되는 일들은 계획에서 벗어나 있는 일로, 신속하게 처리해 원래 수립된 계획이 제대로 진행되도록 해야 한다.
다섯째, 프로젝트 관리 조직에서는 대응 방안에 따라 프로젝트 조직이 수행하고 있는지 모니터링해야 한다. 모니터링 작업을 통해 이슈가 해결되고 있는지를 해당 프로젝트 팀원은 물론, 관련 조직에게 공지해야 한다.
여섯째, 이슈가 종결됐을 때는 프로젝트 팀원은 물론, 관련 조직에게 이슈 종결 내용을 공지해야 한다. 또 이슈 처리 과정을 빠짐없이 기록해 향후 유사한 문제가 발생하지 않도록 참고 자료로 활용할 수 있게 해야 한다.
프로젝트를 진행하면서 '이슈의 발생'에 해당하는 문제가 전혀 발생하지 않기를 기대하는 것은 어렵다. 문제는 어떻게 하면 발생한 이슈를 조기에 발견해 발빠르게 처리하도록 할 수 있느냐는 것이다. 사소해 보이는 이상 징후를 놓치지 않고, 조기에 이슈화해 해결책을 찾음으로써 나중에 가래로도 막기 어려워질 것을 호미로 막을 수 있을 것이다.
6. 프로젝트의 조기 경보기 "리스크 관리"
리스크를 프로젝트나 프로젝트 내의 일부분이 정해진 기간 내에 주어진 예산으로 완료되지 못할 위기에 빠질 수 있는 정도나 기대한 성과가 달성되지 못할 가능성이라고 정의하고 있습니다.
프로젝트 특성상 발생할 수 있는 리스크에 대해서 비슷한 프로젝트를 진행한 경험에서 축적된 지식으로 예측할 수 있으며, 이렇게 예측된 리스크를 관리 우선 순위별로 분류해 리스크 관리 체크 항목을 가지고 리스크를 관리해 나갈 수 있다고 합니다.
그래서 미리 막을 수 있는 대응책과 실제 발생했을 때 처리 방법이 있어야 한다고 이야기 합니다.
또한, 지표를 통해 리스크를 지속적으로 모니터링 할 수 있어야 함은 기본사항이구요..
앞에서 리스크/위험 관리에 대해서는 #1, #2로 정리한 내용이 있습니다.
리스크 완화, 회피, 모니터링, 관리에 대해서 이야기 했었습니다.
이런 위험 관리는 모든 프로젝트에서 중요한 요소라고 다시 한번 강조하고 싶네요..
현재 프로젝트가 계획대로 진행되고 있더라도 프로젝트 관리자는 프로젝트가 완료될 때까지 긴장을 늦추지 못한다. 프로젝트를 진행하다 보면 예상치 못한 상황이 벌어지고, 이에 따른 여러 가지 문제가 발생하게 된다. 이렇게 발생한 문제들은 이슈로 관리돼 대응책을 만들고 문제를 해결하게 된다.
하지만 프로젝트가 진행되면서 계속 변하는 프로젝트 내부와 외부 환경으로 인해 프로젝트 진행에 장애를 일으키는 문제가 발생할 가능성이 있다. 이렇게 프로젝트나 프로젝트 내의 일부분이 정해진 기간 내에 주어진 예산으로 완료되지 못할 위기에 빠질 수 있는 정도나 기대한 성과가 달성되지 못할 가능성을 '리스크'라고 정의해보자.
프로젝트를 진행하다 보면 여러 가지 리스크를 안게 마련이다. 예를 들어 업무 범위가 갑자기 외부 요인에 의해 대대적으로 변경될 수도 있고, 프로젝트를 진행하고 있는 인적 자원이 예기치 못한 사정으로 갑자기 교체돼 진행에 적잖은 차질을 초래할 수도 있다. 또 프로젝트 예산이 줄어들자 자원이 원활하게 수급되지 못해 프로젝트 규모를 축소해야 하는 일이 생길 수도 있다. 이렇게 프로젝트를 둘러싸고 있는 내/외부 환경의 변화는 프로젝트의 진행에 지대한 영향을 주게 마련이다.
물론 초기에 예상할 수 있는 리스크를 감안해 프로젝트를 기획하고 풍부한 자원을 갖고 프로젝트를 수행하고 있다면 예상치 못한 문제가 생기더라도 프로젝트 진행에 크게 지장을 주지 않을 수도 있다. 하지만 대부분 프로젝트는 주어진 일정이나 자원에 여유가 없거나 부족한 상황에서 진행하게 되며, 이렇게 여유가 없는 상황에서 예상치 못한 문제로 인해 프로젝트가 늦춰지면 이에 따른 책임과 손실을 감당하기가 매우 어렵다.
프로젝트를 진행하면서 그 프로젝트의 특성상 발생할 수 있는 리스크에 대해서는 비슷한 프로젝트를 진행한 경험에서 축적된 지식으로 예측할 수 있다. 이렇게 예측된 리스크를 관리 우선 순위별로 분류해 리스크 관리 체크 항목을 가지고 리스크를 관리해 나갈 수 있다.
이런 체크 항목에 등재된 리스크에 대해서는 대응책을 마련해야 한다. 이 대응책에는 미리 막을 수 있는 대응책과 실제로 리스크가 발생했을 때를 구분하는 게 필요하다. 예방할 수 있는 리스크는 발생하기 전에 대응책에 따라 대비하는 것이 제일 좋다. 실제 리스크가 발생했을 때의 대응책은 실질적으로 조치가 가능한 수준의 방안이어야 한다. 이 대응책에는 자원의 조달에 관한 대책이 명시돼야 한다. 대부분 대응 방안에는 반드시 자원이 추가로 소요되게 마련이다. 이런 자원을 구체적으로 어떻게 조달할 것이지, 그리고 어떻게 의사결정을 지체하지 않고 받을 수 있는지에 대해 미리 합의해 두어야 한다.
프로젝트 관리팀은 리스크 체크 항목을 정기적으로 점검해 리스크를 끊임없이 모니터링해야 한다. 효과적인 모니터링 작업을 위해 리스크를 산술적으로 측정할 수 있는 지표를 만들어야 하고, 이 지표에 의해 리스크의 양을 구해야 한다. 이 때 예측이 가능한 리스크는 지표에 의해서 리스크량이 산출되지만, 예측이 어려운 리스크는 경험에 의한 추정치를 구해야 한다. 이것조차 어려우면 몇 번의 프로젝트를 진행하면서 경험치로 계산된 리스크량에서 산출된 일정 비율로 더하는 방법이 있다.
이렇게 각각의 리스크량을 산출해 더하면 프로젝트 리스크의 총량이 계산된다. 그리고 프로젝트 관리팀은 프로젝트 내/외부의 상황이 변해 리스크가 해결되거나, 자동으로 소멸되거나, 새로 발생하는 리스크 변화 부분을 리스크 측정지표에 의해 다시 산출해야 한다. 그래서 현재 시점에서 리스크 총량이 얼마인지 파악하고 어떻게 변화하고 있는지 알고 있어야 한다.
시간이 지나면서 리스크 총량이 감소하는 게 바람직하다. 프로젝트가 성공하려면 시간이 경과되고 완료 시기가 다가올수록 리스크의 총량은 줄어들어야 한다. 만약 리스크의 총량이 감소되지 않고 정체 상태이거나 오히려 늘어난다면 프로젝트의 성공을 바라기가 매우 어려울 것이다. 프로젝트의 리스크 총량을 줄이려면 프로젝트 팀원이나 관리자를 막론하고 끊임없이 리스크 관리에 관심을 두어야 한다. 정기적으로 프로젝트 내/외부에서 변하는 상황과 관리하고 있는 리스크를 비교, 분석해 이를 방지할 수 있도록 최선을 다해야 한다.
전쟁 중에 조기경보기는 하늘에서 적진의 움직임을 감시하면서 공습에 대비하고 아군의 승리를 위해 지원하듯이, 리스크 총량 관리는 프로젝트의 조기경보기 역할을 수행하면서 프로젝트의 성공에 일조할 수 있을 것이다
7. 인적 자원의 파악, 가볍게 여기면 큰 코 다친다.
의욕이 앞서 보유한 자원의 총량을 초과해 프로젝트를 수행하다 보면 프로젝트가 제대로 진행되기 어렵습니다.
특히 인적자원은 사람의 수 뿐만 아니라 그 사람이 보유한 역량의 수준까지도 파악해야 한다고 합니다.
또한 아웃소싱에 의존하는 비율도 미리 정한 것을 초과하지 않도록 해야 하는데, 이유는 추후 유지보수나 관리에 문제가 발생할 소지가 있기 때문입니다. 프로젝트의 핵심 업무는 내부 인력으로 처리하는게 바람직하다고 하네요..
프로젝트 뿐만 아니라 모든 일은 결국 사람이 해결할 수 밖에 없다고 봅니다. 프로젝트에 있어서 갑자기 인력이 교체되거나 역량이 부족한 인력으로 수행하게 되면 댱연히 문제가 발생할 수밖에 없을 겁니다.
아웃소싱에 의존하는 업체도 아웃소싱 인력의 능력에 따라 프로젝트의 성패를 맡겨야 하니 불안할 수밖에 없을 거구요..
손자병법에 '지피지기면 백전백승'이라는 말이 있다. 전쟁을 할 때 적군의 전력이나 상황을 정확히 알면 그에 따른 대책을 세워서 이길 수 있다는 얘기다. 이때 전제되는 것은 아군의 전력이나 상황을 정확히 아는 것이다. 아군의 전력이나 주어진 내/외부 상황을 파악하지 못한 상태에서 대책을 수립한다면 소용없는 일이다.
프로젝트에 착수하기 전에 기업의 자원을 정확히 파악해야 한다. 의욕이 앞서 기업이 보유한 자원의 총량을 초과해 프로젝트를 수행하다 보면 제대로 프로젝트가 진행되기 어렵다. 경우에 따라서는 프로젝트의 우선 순위나 중요도에 관계없이 자원 조달과 관련한 프로젝트 책임자의 역량이나 외부 환경에 의해 프로젝트의 성공과 실패가 결정되기도 한다.
먼저 프로젝트와 관련된 주요 자원에는 인적 및 재무 자원 등이 있다. 인적 자원은 단순히 사람 수만이 아닌 어떤 역량을 가진 사람이 있는지 파악해야 한다. 또 그 사람이 보유한 역량의 수준까지 파악해야 한다. SI 프로젝트를 아웃소싱할 때 과학기술처에서 기술 숙달 정도에 따라 고급/중급/초급으로 분류해 역량의 차이에 따라 임금 체계를 나누고 있다. 재무 자원은 프로젝트 수행에 필요한 예산 외에 리스크를 감안한 여유 분이 확보돼야 한다. 흔히 예비비라는 비목으로 별도 책정하기도 한다.
기업에서는 일반적으로 차기 연도 사업 계획과 소요 예산을 4～5개월 전부터 세우기 시작한다. 2～3개월 정도의 기간을 두고 조정 작업을 거쳐 이사회에 보고 및 승인 절차를 거쳐 확정한다. 대부분 사업 계획에는 다수의 프로젝트가 포함돼 있으며, 각각의 프로젝트를 결정할 때 소요되는 재무 자원인 투자 금액과 투자 효과에는 관심을 기울이지만, 프로젝트를 수행하게 될 인적 자원 조달 계획의 타당성 등에는 상대적으로 관심도가 낮은 경향이 있다.
인적 자원을 계산하는 방법에는 주의해야 할 사항이 있다. 먼저 각 사업본부에서 일상적으로 일어나는 업무에 드는 인력의 총량을 계산해야 한다. 그리고 해당 본부에서 추진하는 프로젝트에 소요되는 인적 자원의 총량도 구해야 한다. 물론 프로젝트에 소요되는 인적 자원의 수준에 맞는 역량을 가진 인적 자원을 계산해야 한다. 그리고 다른 본부의 프로젝트에 소요되는 지원 인력에 관해서도 정확히 계산돼야 한다. 지금까지 많은 기업의 프로젝트에서 간과해온 지원 인력의 계산 부문은 잘 드러나진 않지만 프로젝트의 성공으로 가는 길에 상당히 중요한 요소로 작용하고 있다.
이렇게 계산하다 보면 대체적으로 모든 사업이나 프로젝트에 소요되는 인적 자원의 총량은 가용 인적 자원보다 초과되게 마련이다. 이런 경우 부족 인력을 아웃소싱해야 하는 경우가 발생하는데, 이럴 경우 아웃소싱 인력은 사전에 설정한 적정 비율을 넘지 않도록 주의해야 한다. 부족하다고 아웃소싱 인력에만 의존할 경우 프로젝트가 종료된 뒤 프로젝트에 종사했던 아웃소싱 인력이 빠져나가 유지보수 업무에 많은 차질을 초래하는 경우가 종종 발생하고 있기 때문이다. 되도록 프로젝트의 핵심 업무에는 유지보수가 가능한 자체 인력을 투입하는 게 바람직하다.
이렇게 계획된 모든 프로젝트와 일상 업무에 소요되는 인적 자원이 기업이 보유한 인적 자원의 총량을 넘지 않도록 주의해야 한다, 만약 소요되는 자원이 소유하고 있는 인적 자원과 일정 비율의 아웃소싱 자원의 합을 초과한다면 인적 자원을 제대로 지원 받지 못할 것으로 예상되며, 전략적으로 우선 순위를 조정해 프로젝트의 부실화를 예방해야 한다.
의욕이 앞서는 것은 좋으나 이렇게 인적 자원이 제대로 파악되지 않아 적절한 인적 자원을 지원받지 못해 프로젝트가 실패한다면 너무나 어리석은 짓이다. 하지만 많은 기업에서 이렇게 인적 자원이 부족할 것을 알면서도 강행하는 경우에는 프로젝트를 진행하는 책임자들은 프로젝트의 본업보다 프로젝트에 필요한 인적 자원을 확보하려고 노력하고 이에 많은 시간을 소비하게 된다. 많은 경우 사람 때문에 다투거나 제대로 지원을 받지 못해 어려움에 처하는 경우를 보게 된다. 특히 인적 자원이 필요한 시기에 못 받거나 적절하지 못한 사람을 받아 프로젝트를 진행하는 과정에서 어려움에 봉착하는 경우를 많이 보게 된다.
이제까지 소홀히 했던 인적 자원에 대해 프로젝트의 수립 단계부터 정확히 계산해야 한다. 역량에 맞는 인적 자원을 제대로 확보할 수 없다면 처음부터 프로젝트를 시작하지 말아야 한다. 전략적으로 중요한 프로젝트라면 다른 프로젝트를 중단하거나 연기해서라도 충분한 지원이 가능할 때 시작해야 한다. 기업에서 일어나는 사업이나 일들에 사람이 중요하지 않은 일이 없지만 프로젝트야말로 사람이 성공의 핵심 요소임을 인식하고 이에 대한 준비를 철저히 해서, 시작한 프로젝트는 성공으로 이끌어야 한다.
8. 현실과 지표 사이의 괴리를 메우자
프로젝트를 진행하면서 나오는 몇 % 진행되었다는 숫자에 대한 문제점을 지적하고 있습니다.
산출물 기준으로 진척도를 계산하게 되면 외형은 확인할 수 있지만, 품질은 확인이 곤란하다는 겁니다.
그리고 개발자의 감으로 진척도를 이야기 하면 테스트에 대한 부분이 포함되어 있지 않으며 객관적이지 않은 진행 상황일 수밖에 없다고 합니다.
그래서 전체 진척도와 단계별 진척도를 별도로 관리하고 테스트와 검토 단계의 비중을 높여서 계산해야 한다고 합니다.
어디서 보니까 어른들은 숫자를 참 좋아한다고 합니다. 모든 데이터를 정량화 하는 것은 프로젝트 관리에서도 중요한 작업임에 틀림없습니다.
그러나 그 정량화에는 반드시 현실이 제대로 반영되어 있어야 합니다. 그러기 위해서는 기준이 중요하고, 프로젝트에서도 개발 속도 뿐만 아니라 품질까지도 포함해야 한다는 것이죠..
프로젝트를 진행하게 되면 늘 보는 숫자가 있다. 오늘 현재 공정상 계획은 70%인데 달성은 77%라고 하는 숫자다. 과연 이 숫자는 어떤 의미를 가질까. 대부분 이 숫자를 보면서 계획 대비 7% 초과이므로 계획보다 잘 돼 간다고 생각한다. 과연 숫자만큼 내용도 잘 돼서 믿을 만한 것일까. 도대체 이 숫자는 어떻게 산출됐으며 무엇을 시사하고 있을까.
일반적으로 프로젝트 공정 계획을 세울 때 설계/구현/테스트 등으로 단계를 세분화하게 되고, 단계별로 투입될 인적 자원의 양을 계산하게 된다. 예를 들어 프로젝트 전체 중 설계 단계에 30%, 구현 단계에 40%, 테스트 단계 30%의 인적 자원이 소요된다고 예상하면 전체 투입될 인적 자원을 단계별 투입 비율로 계산해 공정지표로서 활용한다. 물론 각 단계에서는 다시 세부 단계를 나누어 정교하게 공정지표들이 산출된다.
이런 계획에 따라 단계별로 인원이 투입되고, 계획된 일정대로 이상이 없으면 비율만큼 진행된 것으로 계산해 지표로서 활용한다. 하지만 여기에 맹점이 있다. 외형상 진행됐는데 실제 내용은 미진할 수 있기 때문이다. 이런 현상을 방지하고자 단계별로 정해진 산출물을 확인하게 돼 있다. 문제는 이 산출물의 외형은 확인할 수 있는데 품질은 확인하기가 대단히 곤란하다. 뿐만 아니라 그 내용물의 품질을 정확하게 확인하려면 작업하는 사람보다 내용을 더 잘 아는 전문가를 투입해야 하는데, 그런 인력을 투입하기엔 현실상 힘들다. 또 품질 확인을 위해 추가 인력을 투입하는 것 자체도 자원의 증가를 의미하므로 어렵다.
이런 어려움으로 인해 단계별 진척도가 정확한지 따지는 건 쉽지 않은 일이다. 이러다 보니 대부분 개발자 자신들의 신고에 의한 진척도를 활용할 수밖에 없다. 이 상황에서 정확한 진척도를 가늠하기란 어려울 수밖에 없다. 프로젝트 책임자는 모든 부문의 진척도를 세세히 알기 어렵다. 언뜻 보면 목표 진척도대로 진행돼 가는 것으로 알고 있지만 어디까지 진실을 반영하고 있는지 불안할 수밖에 없다.
이런 일이 발생하는 것은 SI 프로젝트가 여러 세부 프로세스로 나뉘어 있고, 개별 프로세스도 많은 프로그램으로 이루어져 있기 때문이다. 대부분 개발자들은 자신이 맡고 있는 응용 프로그램을 작성하는 것인데, 프로그램은 작성자의 의도에 따라 같은 언어를 사용하더라도 구현 방법이 다양하기 때문이다. 작성하면서 프로그램의 논리적인 착오는 찾아내지만 실제 고객이 사용할 수 있는지 여부는 개별 테스트를 거쳐 프로젝트의 거의 끝 단계에서 전체 테스트를 실시하면서 발견하는 경우가 많다. 그래서 전체 테스트를 수행하기 전에는 프로그램의 착오를 찾아내는 게 매우 힘들다.
이런 전체 연결 테스트를 수행하면서 착오도 발견하고 또 논리적 모순을 집어내기도 한다. 이런 테스트에 생각보다 많은 시간이 걸린다. 경우에 따라서는 다시 프로그램을 작성해야 한다. 이러면 지금까지 예상 진척도대로 진행됐다는 것이 의미가 있는 것일까, 반문하게 된다.
이런 이유로 우리가 흔히 관리하고 있던 진척도는 상당히 의미를 상실한다. 실제 상황을 표시하기엔 문제가 많다. 방법이 없을까. 그러면 전체 테스트가 완료되기 전에는 진척도 자체가 의미가 없는 것일까. 진척도 자체는 전체 자원의 투입을 의미한다. 하지만 내용과 품질 면에서는 의문이 남는다. 그리고 정확히 알려면 일 그 자체보다 더 많은 자원이 필요할 수도 있다. 딜레마가 아닐 수 없다.
여기서 대안으로 진척도를 산출할 때, 전체 진척도와 별도로 단계별 진척도를 관리하는 것이다. 예를 들어 설계 단계에서는 설계도를 작성할 때까지 진척도를 표시한다. 그리고 설계도 작성이 끝날 때 설계도 검토 과정을 넣어 설계도 검토 후 통과 판정을 받았을 때 비로소 설계 단계의 완성으로 보는 것이다. 프로그램의 작성 단계 또한 프로그램의 작성 단계의 비중은 낮추어야 한다. 오히려 테스트와 검토 단계의 비중을 높여야 한다. 예를 들어 프로그램의 완성도 측면에서 보면 작성자의 비중은 50%, 개별 테스트 10%, 전체 테스트 20%, 그리고 수정 절차에 20%를 배정하는 것이다. 이런 과정을 거쳐서 전체 완성도가 이룩됐을 때 완료된 것으로 해야 한다.
전체 관점에서 일괄적으로 진척도를 산술로 표시하는 것은 실제 상황을 왜곡하는 경우를 많이 낳는다. 이런 왜곡을 방지하려면 전체 진척도는 참고 자료 정도로만 사용하면 될 것이다. 대신 각 단계별로 진행 정도를 지금 산정 방식보다 절반 정도로 비율을 낮추고, 전체 테스트가 완료됐을 때 비로소 완료되는 것으로 간주하는 게 그나마 왜곡을 상당히 막을 수 있을 것이다.
여기에 더해 전체 테스트에는 이 프로젝트가 마무리됐을 때의 사용자가 반드시 참여해야 한다. 실제 상황에서 가동돼야 하고 실제 사용자가 사용하기에 문제가 없어야 한다. 지금까지 프로젝트 진행에서는 주어진 설계도대로 작성하는 데 주력했다면 이젠 그 범위를 넓혀 제품의 최종 사용자가 참여해 품질과 내용에 대해 처음부터 참여하고 같이 검토해야 한다. 그래야만 완성도를 높일 수 있기 때문이다. 모든 산업에서 최종 사용자인 고객의 참여가 필수인 시대에 SI 업계에서도 프로그램을 작성하는 전문가들의 분야에서 고객까지 범위를 넓혀야 한다. 이럴 때 고객이 만족할 수 있으며, 고객이 인정하는 지표로서 가치가 있게 되는 것이다.
프로젝트를 진행할 때 현실과 지표 사이의 괴리를 메우는 방법은 멀리 있지 않고 고객 관점에서 진척도를 배정하고 점검하는 것이다. 이렇게 고객이 사용하기에 품질과 편리성에 문제가 없어야만 프로젝트가 끝날 수 있다는 사실을 명심해야 한다.
이상으로 프로젝트의 성공 요인에 대해 정리해봤습니다. 일반적으로 생각하는 부분과 큰 차이가 없어서 정리해봤습니다.
