S프로젝트 품질관리자 일기(3)

Lessons Learned
* CMMI PA 관점에 따라 기술

1. Process Management (OPF, OPD, OT)

- S사에서 발주한 프로젝트는 고객사에서 정의된 프로젝트 관리 절차에 따라 착수, 이행, 종료 검수등의 Task 순서로 진행된다. 고객사 IT지원팀이라는 부서에 품질관리자가 있으며, 또한 수행사 소속QA가 고객사에 파견근무식으로 일을 하며 프로세스를 관리하는 점이 특이사항이다.

프로젝트 참여인원은 수행사와 협력업체 개발자 이외에 고객쪽도 업무시스템별로 파트리더가 선정되어 있어 분석, 설계. 테스트에 적극적으로 참여하였기 때문에 모든 교육은 고객 포함 모두들 대상으로 항상 실시하였다.

프로젝트 교육 계획이 사전에 정의되어 관리되지는 못하였다. 교육 출석부 등 결과는 최소한으로만 관리되고 교육 효과성 평가등의 관리는 이루어지지 못하였다.

 

2. Project Management (PP, PMC, IPM. RSKM)

1) 전사 또는 사업부 표준에 의거 별도 프로젝트 계획서를 작성하지 않고 사업수행계획서를 프로젝트 계획으로 간주하고 고객과 합의하여 관리하였다. 따라서 프로젝트 관리 모든 영역이 세부적으로 정의되지는 못했다. 사업수행계획서의 변경관리도 제대로 이루어지지 못했는데 이유는 고객이 계획서의 중요성을 인지 못하였기 떄문이다.

프로젝트 진척관리에 대한 분석 및 의사결정은 수행사가 아닌 고객사 PMO 중심으로 주도하고 고객 CIO에 의해 좌우되었다.

범위관리는 CSR Freezing 등 엄격하게 이루어지지 못하고 오픈 직전까지 계속 이어졌다. 구시스템 프로세스와 프로젝트 기간중 발생된 CSR이 프로젝트에 정확하게 반영되지 못하였으며, 어느 프로젝트에서나 종종 보이는 현상으로 모든 일들이 PL들에게 몰려 병목현상으로 개발자들의 인원은 많으나 전체적으로 효율적으로 업무로드가 배분되고 관리하지 못하였다. PL들을 수행사 정직원 중심으로만 배치하여 이것이 하나의 원인이라고도 할 수 있다. 개발인력에 비해 관리인력이 전반적으로 과다했다.

요즘 프로젝트에서는 업무 경험없는 인원이 신규 프로젝트에 참여해서 어려운 프로젝트가 많은데 여기는 10년이상의 업무를 수행한 베테랑이 대부분 프로젝트 핵심인원이라서 업무 리딩에는 문제가 없었다. 이행본부 소속 인원과 SM사업부 소속간의 이해관계로 인해 막판에 인수인계 인원철수 시점등의 이슈가 발생되기도 했다.

비용관리 측면에서는 프로젝트 인원이 최전선에 있는 부대원이라면, 후방에 있는 막대한 지원군인 SM인원이 받치고 있었고, 테스트단계부터는 직접적인 참여로 프로젝트 추가 비용도 거의 발생되지 않았다. CP 내용과 거의 유사하게 실적이 집계되었다.

조달 및 협력업체관리는 Mainframe 과 Cobol 언어라는 특성으로 개발자들이 평균 50대에 육박함. 상대적으로 젊은 PL들이 개발자들을 익숙하게 다루지 못함. 상대적으로 큰 규모의 2~3개 업체를 균등하게 참여시켜, 문제 발생시 리스크를 완화시켰다. 서로간의 선의의 경쟁모드가 되었다.

의사소통관리는 고객과의 의사소통이 너무 활발해서 프로젝트 팀원들이 피곤할 지경이었다. 프로젝트 시작과 동시에 모닝 미팅으로 매일 고객과 프로젝트 상태에 대한 이슈 토론이 이루어졌으며 매주 CIO가 참석하는 진척관리 보고도 빠짐없이 수행되었다. 7월부터는 매일 CIO주관 진척보고 회의가 개최되었다.

리스크관리는 고객이 관리하는 리스크 및 이슈가 너무 타이트하게 관리되어 내부용 이슈/리스크와 별개로 관리할 수 밖에 없었다. 프로젝트 관리시스템에 리스크를 등록해서 관리할 수 있는 기능은 존재하나, 모든 인원이 프로젝트관리시스템을 이용하지 않고 고객과 공유하기 어렵다는 사유로 별도 excel로 이슈/리스크 관리대장으로 관리하였다.

매주 월요일 PM주관 자체 그룹장회의에서 이슈/리스크 식별 및 식별된 이슈/리스크에 대한 Status를 리뷰하기는 했으나 지속적으로 꾸준히 관리하지는 못했다. 대부분의 프로젝트 수행자는 이슈와 리스크에 대한 개념을 분리하고 싶어하지 않고 헷갈려하기 때문에 분리해서 관리하지는 않았다.

 

3. Engineering Process(REQM, RD, TS, PI. VER, VAL)

1) 현업 부서가 직접 요구사항정의서를 작성하였고 IT부서가 요구사항 상세 분석서를 작성한 후 양사 합의 후 현업부서 서명하였다. 현업부서별로 명확하게 과제라는 이름으로 선정된 418개 요구사항이 현업부서에 의해서 정의되고 수행사로 넘겨져서 요구사항 분석서로 상세화 된 후 현업 TFT의 확인(서명)을 받은 후 부적절한 내용에 대해서는 시정조치를 거친 후 요구사항 확정을 하는 프로세스 였다.

현업 주관부서와 관련 부서를 구분해서 오너쉽을 주관부서에 부여 했으나, 향후 상세 분석 시 여러부서에 걸친 내용인 경우, 주관부서에서 책임지지 못하겠다는 경우가 일부 발생하기도 했다.

요구사항 정의 이전에 현업 부서별로 과제라는 이름으로 명확하게 책임을 부여했는데 과제명에 관련 부서명을 넣고 주과, 관련 과제라는 형태로 관리하였다. 예) 기영_002(기업영업팀의 두번째 과제)

요구사항 추적매트릭스 작성 후 매 단계별 업데이트 수행후 고객 제출하였다.

2) Maingframe 환경의 기술적인 지원 툴을 활용하여 개발환경, 통합환경, 운영환경으로 이관작업을 단계적으로 수행해나갔다. 보통 시스템 오픈 시 기존 운영환경을 업데이트 하는 방식을 취하기 마련인데, 여기는 기존 운영환경은 그대로 놔둔 채 별도의 통합환경을 만든 후 그 환경을 그대로 운영환경으로 오픈하는 형태를 취함으로써 운영이관에 대한 리스크를 줄일 수 있었다.

3) 단위테스트의 결함관리는 명시적으로 관리되지는 못했다. 통합테스트 이후 단계의 모든 결함은 결함관리시스템(MANTIS)에 등록하여 분석관리하였다. 시나리오/케이스는 Test Director라는 상용툴을 구입해서 기록하고 성공/실패 여부를 체계적으로 관리하였다.

사용자 성은테스트 개념의 현업테스트를 세차례 수행하면서 시나리오, 케이스를 자그마치 현업TFT 100명의 Full Time Member가 6000여개의 시나리오를 도출하여 테스트를 수행하고 결함을 등록 관리하였다.

 

4. Support Process (MA, CM, PPQA)

고객과 함꼐 단계별 지표를 정의하여 주기적으로 수집하고 분석활동을 수행하였다. 주요 지표는 개발진척률, 테스트수행률, 결함률(통합테스트 이후 단계), 시나리오 커버리지, 성공율, 데이터 전환 검증율 등 이었다.

변경관리에 대한 명확한 인식부족으로 소스 관리 중심으로 이루어졌다. 소스관리는 통합테스트 단계 이후, Cobol 등 Mainframe은 ENDEVOR 라는 Tool 로 Web은 Harvest라는 툴로 형상관리를 하고 변경 요청은 고객사 자체로 개발된 SDMS시스템을 통해서 변경관리 요청이 되어야만 이관할 수 있었다. 변경 불일치 사항에 대해서는 자동적으로 식별되어 관리자에게 메일로 송부되고 담당자에게는 불일치 사유를 기록하게끔 시스템이 만들어져 있었다.

고객사 PMO, 품질관리자가 External PPQA 역할을 강하게 수행했다고 보면 된다. 자사 품질관리는 데이터 수집담당자, 작성산출물에 대한 표준 측면의 검토 시정조치를 수행하는 지원 역할이었다고 생각한다.

고객PMO의 관점은 진척관리에 Focusing 하였으므로 Product에 대한 품질 보다는 결과에만 중점을 둘 수밖에 없는 한계를 보였다.

최종적으로 단계말 검토 개념인 검수보고서를 고객 IT지원팀 품질담당자가 작성하여 수행사에 부적합, 권고등의 시정조치를 통보하고, 이에 대한 시정조치가 이루어지고 차기 단계말 검수 요청 시 해당 항목에 대한 시정조치 여부를 확인하는 절차로 진행되었다.