[그림1] 프로젝트 진척보고서(예시)
프로젝트를 진행하는 과정에서 우리는 종종 계획 대비 완료 정도를 보여주는 달성률에 초점을 맞추곤 한다. 달성률이 높다는 것은 계획 대비 진척이 원활하게 진행되고 있다는 것을 의미하기 때문이다. [그림1]의 경우 각 영역별 진척의 달성률을 신호등 체계로 정리하여 한눈에 잘 들어온다는 장점이 있다. 하지만 해당 지표를 개발 단계에서 사용하는 것이라면 주의가 필요하다. 자세히 보면 일부 파트의 진척률은 타 영역에 비해 상대적으로 저조함에도 불구하고 달성률이 100%를 넘는다는 이유만으로 Green(적정)으로 표시되어 있다. 달성률은 계획 물량 대비 실적 물량을 의미한다. 개발 과정에서 물량 변동이 자주 발생한 점을 고려하면, 단순히 달성률이 높다는 것으로 해당 부문의 진척이 제대로 되고 있다고 판단하는 것은 위험하다.
개발 단계에는 현업 사용자의 피드백을 받아서 실제로 개발해야 할 물량을 조정해야 한다. 사용자 테스트 단계에서 새로운 요구사항이 쏟아져 나오는 경우가 있기 때문이다. 단순히 개발 물량을 기준으로 프로젝트 진척을 관리하다 보면, 가동일이 다가오면서 진척률이 요동치는 경험을 하게 된다. 이러한 혼란을 방지하려면 초기 개발은 핵심 기능 중심으로 관리하고, 현업 사용자가 본격적으로 참여하는 필드 테스트 과정을 통해 보완 기능을 추가하는 공정 설계가 필요하다. 얼마나 많은 개발 물량을 소화했느냐를 가지고 진척을 측정하는 것이 아니라, 고객의 요구사항이 제대로 반영된 화면을 얼마나 만들었는지 추세를 보며 진척을 측정하는 것이 중요하다. 개발 프로세스는 개발자가 배정된 물량을 개발하면 수행사와 고객사가 단위테스트를 수행하게 된다. 고객사는 개발 진척뿐만 아니라 테스트 실적, 테스트 성공률, 재테스트율까지 확인하고 싶어 한다. 개발자의 개발 진척률과 더불어 고객의 테스트 성공률을 함께 보면서 품질과 진척을 동시에 관리할 수 있는 지표로 [그림2]를 예로 들 수 있다.
[그림2] 다양한 관점이 반영된 진척률 도표
[그림2] 방식의 진척률 도표는 개발단계에서 중요하게 봐야하는 개발 진척과 테스트 성공 물량을 한번에 표현함으로써 더 많은 정보를 제공한다. 이러한 지표로 일정 기간마다 반복적으로 자료를 정리해 놓을 경우 현 시점 이후의 추세까지 보여주며 프로젝트 관리에서 생산성을 예측 가능하게 해준다. 해당 지표를 조금 더 자세히 살펴보면 더 많은 정보를 분석할 수 있다.
[그림3] 진척률 도표 해석 사례
개발 물량과 고객사의 테스트 사이의 간격을 나타내고 있는 [1]은 개발자가 개발 완료 하는 시점으로부터 고객사의 테스트가 끝나기까지 걸리는 시간을 의미한다. 또한 설계자의 테스트 결과를 나타내고 있는 [2]는 설계자 테스트 결과 조건부 통과 물량과 통과 물량 사이의 비중을 보여주고 있다. 마찬가지로 고객사의 테스트 결과를 나타내고 있는 [3]은 고객사의 테스트 결과 조건부 통과가 계속해서 증가하고 있음을 보여주며 품질 관점에서 관리가 필요하다는 것을 보여주고 있다.
올바른 지표 사용과 정확한 분석의 필요성
지표는 행동하기 얼마나 좋은가(Actionable), 접근할 수 있는가(Accessible), 현실을 반영하는가(Auditable), 3A의 중요성을 인지하여 선정되어야 한다.
1. Actionable: 행동에 옮기기 좋다는 것은 원인과 결과가 명확하다는 말과 같다. 그렇지 않다면 이것은 허무 지표가 된다. 원인과 결과가 명확히 이해될 때 사람들은 더 잘 배울 수 있다.
2. Accessible: 접근하기 좋다는 것은 실무자와 경영자가 의사 결정을 하는데 참고 하기 쉬운 보고서를 의미한다. 데이터를 효율적으로 활용하기 위해서는 첫째, 보고서를 아주 쉽게 만들어 모든 사람들이 이해할 수 있게 해야 한다. 둘째, 거버닝 문구 작성 시 해당 장표의 내용이 함축되어 있는 내용으로 작성해야 한다.
3. Auditable: 현실을 반영한다는 것은 데이터가 프로젝트 직원들에게 충분히 이해되었음을 잘 확인하는 것이다. 데이터 정확성에 대한 도전은 흔하게 발생한다. 진척도에 의해서 지적을 받게 되는 현업 오너는 진척도 수치에 민감하게 반응한다. 때로는 진척도 회의가 현실을 제대로 논의하지 못하게 되는 경우도 있다. 이러한 일을 피하기 위해서는 현업 오너를 포함하여 이해당사자들과 사전에 충분하게 커뮤니케이션해야 한다. 올바른 의사결정은 정확한 상황인식이 없이는 불가능하다는 점을 인식시키는 것이 중요하다.
프로젝트에 따라 다양한 측정지표(Metric)들이 사용되고 있다. 단계별 상황에 맞는 지표를 선정하여 관리한다면, 측정과 해석, 피드백 의사결정 등을 통해 프로젝트 상황을 투명하게 하고, 위험요인에 빠르게 대처할 수 있게 된다. 하지만 잘못된 지표는 오히려 왜곡된 정보를 제공하며 프로젝트를 잘못 이끌어 갈 수 있게 할 수도 있다. 프로젝트 상황과 특성을 토대로 3A를 고려하여 적절한 지표를 선정하는 것이 중요하다. 프로젝트 관리 시 빈번하게 발생하는 위기 속에서 적정한 지표 하나가 새로운 국면으로 전환할 수 있는 해결책이 될 수도 있다.
'02.SW' 카테고리의 다른 글
SW 아키텍처 - UML - 상태 다이어그램 (State Diagram) (0) | 2020.06.24 |
---|---|
SW 개발 보안 - 난독화 (0) | 2020.06.24 |
SW 테스트 - 정적 테스트 (0) | 2020.06.24 |
감리 - 정보화사업 공통감리 - 상주감리 (0) | 2020.06.24 |
감리 - 정보화사업 공통감리 (0) | 2020.06.24 |