// 방법1 // 방법2
  • 2023. 8. 7.

    by. 푸른솔개의 꿈

    개발 단계를 리뷰하고 승인하는 과정에 운영되는 문서와 개발이 완료된 후에 진행하는 Postmortem에 대해 알아보겠습니다. 각 개발 단계가 완료되면 그 단계의 수행 활동을 검증하고 평가하여 차기 개발 단계로 넘어가도 Risk 요인이 없는지 확인하는 절차로 단계 검토 회의 (Review)와 단계 승인 회의 (Approval)가 있습니다.

     

     

    각 마일스톤 (Milestone)의 최종 결과이자 개발 과제의 진행 중단 (Drop)을 결정할 수 있는 매우 중요한 절차이므로 명확하고 정확한 의사 결정을 내리기 위해 회의체의 규정과 책임 권한 등이 구체적으로 수립되어 실행되어야 합니다.

     

    개발단계-문서와-Postmortem-섬네일
    개발단계 리뷰와 승인문서 그리고 Postmortem

     

    검토서 (Review Document)와 승인서 (Approval Document)

    개발 프로세스 상에서 검토 (Review)와 승인(Approval)을 구분하는 요소는 승인권자입니다.

    아래에서 각각에 대해 정리하겠습니다.

     

    검토 (Review) 활동 책임자와 검토서 (Review Document)

    검토 (Review)는 통상적으로 연구소와 개발팀 자체적으로 기술적인 내용을 점검하고 검토하는 행위를 의미합니다. 각 제품을 구성하는 세부 기능(Sub Function) 별로 설계에 문제가 없는지, 이전 유사 기종에서 발생했던 문제점들을 검토하여 설계에 반영했는지, 공정의 마진을 감안하여 강건한 (Robust) 설계가 되었는지 등을 연구소장 또는 개발팀장과 같은 개발 조직의 의사 결정권자가 각 개발 과제의 설계 수준을 확인하는 활동을 진행하는 것을 검토 (Review)라고 합니다.

     

    검토서 (Review Document)로 운영되는 문서로는 설계 자주 평가 검토서 (Design Verification Review Document, DVR Document)가 있습니다. 개발 설계 (Design)의 완성도와 품질 수준을 확인 (Verification) 한 결과를 정리하는 문서입니다.

    개발 검증 검토서 (Product Validation Review Document)는 DVR Document의 설계 완성도 결과에 제품의 공정 검증을 통한 재현성 확보 내용까지 추가하여 개발 제품 (Product)의 유효성 (Validation)을 확인한 결과를 최종 정리하는 문서입니다.

     

     

    승인 (Approval) 활동 책임자와 승인서 (Approval Document)

    제품개발 표준프로세스 바로가기
    제품개발 표준 프로세스 바로가기

     

    승인 (Approval) 절차의 책임자 (Process Owner)는 구성된 Task와 업무 Scope에 따라 다르게 지정됩니다. 시장 관련 내용이면 마케팅 팀장, 품질 검증 절차이면 품질 팀장, 제조 기술 관련 절차는 제조 기술 팀장, 생산과 관련된 것은 생산 팀장이 책임자가 됩니다. 경우에 따라 구매 팀장, 경영 본부장이 책임자가 될 수도 있고 모든 부서에 공통되어 전사적인 책임이 필요한 절차는 대표이사 (CEO)가 책임자가 되어 승인권을 가집니다.

     

    승인서 (Approval Document)는 종류가 많아 명칭만 나열하겠습니다. 명칭으로 대체적인 의미를 유추해 볼 수 있습니다. 상품 기획 확정 승인서 (DIA Document), 개발 구현 승인서 (PIA Document), 양산 승인서 (PRA Document), 출하 승인서 (SRA Document), 단종 승인서 (EOL Approval Document) 등이 있습니다.

     

    개발단계별 승인서 이미지
    개발 단계별 승인과 리뷰 문서 (이미지 클릭하면 확대됩니다.)

     

    개발 제품의 출하 승인 (Ship Release Approval)이 완료되어 해당 프로젝트의 개발 활동이 완료되면 개발에 참여한 TFT 팀은 복기 (Postmortem)라는 프로세스를 진행하고 복기 보고서 (Postmortem Document)를 작성하여 상신하게 됩니다. 아래에서 복기에 대해 간략히 정리하겠습니다.

     

     

    복기 (Postmortem) 프로세스의 개념

    바둑 중계를 보면 바둑 경기가 끝나고 돌을 거둔 후 대국을 한 두 기사가 첫 돌부터 다시 한번 수를 놓아가며 이런저런 상황을 되돌아보는 장면을 본 기억이 있을 것입니다. 이런 것을 복기라고 하는 데 개발 프로세스에도 그대로 적용하는 개념입니다. 

     

    프로세스 적으로는 향후에 발생할 가능성이 있는 모든 Risk 요인을 감안하여 계획을 수립하라고 하지만 예상치 못한 Risk가 개발 과정 중에 수없이 발생하고, 선정한 부품 간의 Miss Matching, 휴먼 에러에 의한 재 설계, 관련 부서 간 일정 조율 실패, 부품 수급 문제 등 많은 문제점들이 발생하여 결국 개발 일정 차질, 개발 목표 미달이 예상되어 개발 계획을 수정하는 일이 다반사로 발생합니다.

     

    이렇게 개발 과정 중에 발생한 모든 문제 요인 들을 개발이 완료된 후에 처음부터 다시 한번 되돌아 반추해 보는 활동을 복기 (Postmortem)라고 합니다.

     

    Postmortem은 출하승인 (SRA)을 완료하고 진행하며 개발에 참여한 협업팀 (TFT)이 모두 모여 개발 과정 중에 잘된 점과 반성할 점을 4M 1E (Material, Mathod, Man, Machine, Environment) 측면에서 토론하고 정리합니다. 

     

     

    잘된 점은 Best Practice 사례로 전파하고 개선해야 할 내용은 실패사례로 List Up 하여 차기 과제 수행 시 참조하여 계획을 수립합니다.         

    다음 포스팅에서는 제품 개발 마스터플랜에 대해 정리하겠습니다.