프로젝트 인도물 품질 내재화에 대해서 고찰해보겠습니다. 프로젝트 인도물 품질 내재화는 프로젝트의 이해 관계자들을 만족 시키는 매우 중요한 요소입니다. 프로젝트 품질은 프로젝트를 진행할 때 계약서나 수행 계획서 등의 공식적인 문서를 통해 정의된 인수 조건을 충족시키는 것 뿐만 아니라 프로젝트 이해 관계자들의 기대 사항을 충족시키고 요구 사항들을 만족 시키는 것까지 포함합니다.
프로젝트를 통해 구현하고 구축하는 시스템 인도물과 결과물에 대해서 품질을 중요시하고 품질을 높이는 활동들은 프로젝트의 성공과도 밀접하게 연결되는 매우 중요한 사항인데 이를 평가하는 기준도 반드시 필요합니다. 프로젝트 인도물 품질을 평가하는 관점은 인수 기준에 부합하는지 여부를 평가하는 방법이 있습니다. 프로젝트 인도물 품질에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 인도물 품질 내재화
프로젝트에서 품질 관리는 프로젝트 이해 관계자들이 프로젝트에 기대하는 기대 사항을 충족시키고 비즈니스 요구 사항을 충족시키기 위한 활동들입니다. 프로젝트를 진행하면 인도물과 결과물이 나오게 됩니다. 이러한 인도물과 결과물에 대해서는 인수 기준을 정의하면서 만들게 되며 이러한 인수 기준을 충족시키는지 여부를 나중에 평가하게 됩니다. 품질은 인도물의 인수 기준을 충족하는데 초점을 맞추게 되고 프로세스 관점에서 적절하게 진행하였는지도 평가하게 됩니다. 따라서 프로젝트 품질은 인도물 관점과 프로세스 관점에서 모두 중요하다고 볼 수 있습니다.
품질은 제품과 서비스, 그리고 결과의 고유한 특성이 요구 사항을 충족하는 정도를 의미합니다. 품질은 프로젝트를 진행할 때 매우 중요한 요소입니다. 프로젝트를 진행하는 방식을 회사 내부 인력을 사용하는 방식이 아닌 외부 업체를 선정하여 계약을 통해 진행할 경우 외부 업체 입장에서는 주어진 계약 사항만 이행하면 되기 때문에 품질 보다는 진행 여부를 더 중요하게 보는 경향이 있습니다. 하지만 프로젝트를 발주한 회사 입장에서는 진행 여부 보다는 품질이 더 중요한 것입니다. 프로젝트 매니저는 품질에 관해서는 양보하지 말아야 합니다. 프로젝트는 결국 품질 높은 결과물을 통해서 편익과 가치를 제공하기 위한 목적으로 진행되기 때문입니다. 품질이 높은 시스템 결과물을 만드는 것은 회사 입장에서는 매우 중요한 문제인 것입니다.
품질 활동의 기준과 효과 이해
품질은 수행사와 고객사의 관계에 있어서 고객사가 명시하는 요구 사항들을 모두 충족시키는지 여부일 수 있고, 프로젝트의 산출물 중 요구 사항 정의서에 기재되어 있는 내용들을 모두 충족시키는지 여부가 될 수 있습니다. 프로젝트 매니저는 프로젝트를 통해서 구현하고 구축하고자 하는 시스템에 대해 프로젝트 인도물의 인수 기준 충족 여부와 사용 적합성 관점에서 평가하고 해당 기준들 충족시키도록 진행하고 만들어야 합니다. 프로젝트 결과물이 인수 기준을 만족하지만 실제 사용하기 불편하면 안됩니다.
프로젝트는 결과물을 만들었다는 것에 초점을 맞추기 보다 결과물을 통해 편익과 가치를 제공하는 것에 더 초점을 맞춰야 합니다. 프로젝트 매니저는 품질 활동 프로세스의 효과성과 효율성에 대해서도 지속적으로 모니터링하고 확인해야 합니다. 프로젝트의 품질은 프로젝트의 개발 방식과 상관 없이 모두 중요한 것입니다. 인수 기준 관점에서 프로젝트에서 만드는 인도물들이 요구 사항을 충족시키는지 여부를 확인하는 방법에 대해서 정의하는 것이 중요하고 반드시 달성해야 할 목표를 포함 시켜야 합니다. 인수 기준에 대해서는 프로젝트 이해 관계자들이 작성하는 것이 가장 바람직하고 올바릅니다. 품질에 대해서 평가하는 것도 결국 이해 관계자들입니다.
프로젝트 인도물 품질 내재화
프로젝트 품질은 이해 관계자들의 기대 사항과 프로젝트 비즈니스 요구 사항을 충족해야 합니다. 품질은 제품과 서비스의 특성들이 요구 사항을 충족시키는 정도입니다. 요구 사항에 대해서 명시적으로 문서화할 수 있는 것도 있지만 문서화하기 힘든 암묵적 요구 사항들도 분명히 존재합니다. 대표적인 예로는 사용성과 편의성, 그리고 디자인이 있습니다. 사용성과 편의성, 그리고 디자인의 경우 문서화하기 매우 어려운 부분들입니다. 품질은 개발 방법론에 따라 그 중요도가 달라지지 않지만 품질을 바라 보는 기준은 다를 수 있습니다.
개발 방법론에 따라 높은 품질의 기준이 다릅니다. 워터폴 방식의 프로젝트에서는 높은 품질의 기준을 프로젝트 산출물 중 요구사항 정의서에 기재되고 정의된 기능들과 비기능들이 잘 작동하고 만족하는 상태로 정의할 수 있습니다. 애자일 방식의 프로젝트에서는 제품 백로그에 정의된 기능들이 잘 작동하는 상태로 정의할 수 있습니다. 워터폴 프로젝트에서는 품질에 대해 프로젝트 종료 시점에 프로젝트에서 만든 시스템 결과물과 인도물이 인수 기준을 잘 충족하는지 여부와 프로세스가 적절했는지 여부로 평가합니다. 애자일 프로젝트에서는 기능이 잘 작동되고 고객이나 시장에서의 반응이 긍정적인지를 평가할 수 있습니다.
워터폴 프로젝트에서는 품질을 높이기 위해서 프로젝트 단계 중 가장 마지막 단계에서 테스트 단계를 배치하고 테스트 진행합니다. 테스트를 단위 테스트, 통합 테스트, 사용자 인수 테스트로 분류하고 진행을 하게 되는데 개발 단계에서 개발한 내용들이 문제 없이 요구했던 내용대로 잘 작동하는지 여부를 확인하고 인수 기준 충족 여부와 사용의 적합성에 대해서도 평가합니다. 평가하는 방법은 다양합니다. 성능 테스트의 경우는 프로그램이 작동해서 결과를 얻어내는데 걸리는 시간 측정을 통해서 품질을 측정합니다. 높은 품질의 결과물을 만들고 시스템을 오픈 하는 것이 무엇 보다 중요합니다. 낮은 품질의 시스템을 오픈 하면 그 이후의 일들은 부정적인 상황이 될 것입니다.
품질이 포함하는 차원들 설명
품질은 서로 다른 여러 차원에서 평가될 수 있습니다. 품질의 평가 기준으로는 성과, 적합성, 신뢰성, 복원력, 균일성, 만족, 효율성, 지속 가능성의 관점이 있습니다. 성과는 인도물이 프로젝트 매니저와 프로젝트 팀, 프로젝트 이해 관계자가 의도하는 대로 잘 기능하는지 여부입니다. 적합성는 인도물이 사용하기에 적합하고 사양을 충족하는지 여부입니다. 신뢰성은 인도물의 품질 수준이 항상 일관된 수준을 유지하는지 정도입니다. 복원력은 예상하지 못한 실패에 대해서 신속하게 대처할 수 있고 복구할 수 있는 것입니다.
복원력은 고가용성이라고도 부릅니다. 이는 쉽게 복구할 수 있는 능력을 의미합니다. 만족은 인도물에 대해서 고객이 만족하는 정도입니다. 여기에서는 고객 관점에서 사용 편의성과 사용자 경험을 포함합니다. 균일성은 동일한 방식으로 생산된 결과물에 대해서 균일한 품질을 유지하는지 정도입니다. 효율성은 최소한의 투입과 노력으로 최대의 산출물을 생산하는지 여부입니다. 지속 가능성은 인도물이 사회와 환경에 끼치는 영향력입니다. 프로젝트 인도물들은 서로 다른 차원에서의 인수 기준들을 모두 충족시켜야 합니다.
프로젝트 인도물과 프로세스 품질에 주의를 기울이게 되면 다양한 관점에서 긍정적인 결과를 만들어 낼 수 있게 됩니다. 인수 기준에 부합하는 프로젝트 인도물을 만들 수 있고 프로젝트 이해 관계자들의 기대와 비즈니스 목표를 만족 시키는 인도물을 만들 수 있습니다. 또한 시스템을 오픈 하였을 때 결합이 없거나 결함이 최소화된 상태로 오픈 할 수 있습니다. 프로세스를 지속적으로 개선할 수 있고 고객의 불만을 감소 시킬 수 있게 됩니다.
품질 활동의 중요한 설명
프로젝트에서는 프로젝트 초반에 요구 사항을 정의합니다. 프로젝트 요구 사항을 정의할 때 일반적으로 인수 기준도 함께 정의합니다. 프로젝트 인수 기준에서는 프로젝트 레벨의 인수 기준이 있고 코드 레벨에서의 인수 기준이 있습니다. 인수 기준에서는 품질의 특성 중에서 중요한 특성들을 선별하여 포함 시키게 됩니다. 품질 활동을 진행할 때는 낭비와 비용을 최소화 시키는 것도 중요합니다. 품질 활동에도 비용이 투입될 수 있습니다. 품질 활동에 투입되는 비용을 품질 비용이라고 부릅니다. 품질 비용은 인도물을 만든 다음 테스트를 진행하는 과정에서 발생할 수도 있습니다.
인도물을 만드는 과정에서 결함을 없애고 품질을 확보하는 것이 중요합니다. 품질은 일반적으로 테스트 단계에서 오류를 잡아내고 요구 사항에 맞게 잘 개발되고 구축 되었는지를 확인하는 절차로 진행됩니다. 이를 위해 단위 테스트에서부터 통합 테스트, 그리고 사용자 인수 테스트 순서로 진행합니다. 인도물 뿐만 아니라 인도물을 만드는 프로세스의 경우도 프로젝트 품질의 평가 대상이 됩니다. 프로세스 품질을 평가하는 것을 일반적으로 품질 보증(QA, Quality Assurance) 활동이라고 합니다. 인도물에 대한 품질 평가는 품질 통제(QC, Quality Control)이라고 합니다. 인도물의 품질 평가는 검사와 테스트를 통해서 진행되고 프로세스에 대한 품질 평가는 검토와 감사를 통해 진행됩니다. 이 두 가지 품질 활동은 모두 오류와 결함을 감지하고 예방에 중점을 두고 있습니다.
프로젝트 범위 정의와 목표 변동의 이해
프로젝트 범위는 프로젝트에서 제공할 제품과 서비스, 그리고 결과를 포괄하는 집합을 의미합니다. 프로젝트 범위는 수집된 요구 사항들을 기반으로 정의됩니다. 프로젝트 범위가 정의된 이후에도 더 많은 상세한 요구 사항들이 식별될 수 있습니다. 프로젝트 팀은 공식적인 과업에 대한 범위를 범위 기술서에 기술하게 됩니다. 범위는 업무 분류 체계(WBS)를 통해 하위 수준으로 세분화하여 구체화 시킵니다. 그럼 프로젝트 범위 정의와 목표 변동에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 범위 정의에 대한 이해
프로젝트 범위는 프로젝트에서 진행할 업무 범위와도 밀접한 관련이 있습니다. 프로젝트 팀에서는 범위 기술서를 통해 프로젝트의 범위를 설명하고 주요 인도물과 인수 기준, 그리고 제외 사항들을 기재합니다. 프로젝트에서는 업무 분류 체계라고 하는 중요한 문서를 만들게 됩니다. 프로젝트를 시작하면서 업무 분류 체계를 만들고 이를 기반으로 프로젝트 범위와 일정을 관리하게 됩니다. 업무 분류 체계는 WBS(Work Breakdown Structure)라고 부릅니다. WBS(Work Breakdown Structure)는 프로젝트 팀에서 목표를 달성하고 필요한 프로젝트 인도물을 산출하기 위해서 수행해야 할 작업의 전체 범위를 계층적으로 분할한 문서입니다.
여기서 작업의 의미는 활동 자체가 아니고 활동의 결과로 창출되는 결과나 인도물을 의미합니다. 작업 패키지는 작업의 최소 단위입니다. 작업 패키지에는 일정과 원가 산정의 기준으로 활용됩니다. 계층 구조의 하위 수준은 인도물을 생성하기 위해서 필요한 작업에 대한 상세 수준의 정보를 표시합니다. 업무 분류 체계 사전(WBS Dictionary)은 업무 분류 체계(WBS)의 작업 패키지 항목에 대한 상세한 정보를 기술한 것으로 작업 설명과 수행 기간, 투입 자원, 원가 추정치, 계약 정보 등을 포함합니다.
업무 분류 체계 사전은 업무 분류 체계(WBS)의 각 구성 요소와 관련된 상세한 정보를 제공합니다. 업무 분류 체계 사전에는 작업 설명과 가정 사항, 제약 사항을 기재하고 담당 조직, 일정 마일스톤, 필요한 자원, 원가 산정치, 품질 요구사항, 인수 기준 등을 포함합니다. 시스템을 개발하고 구축하는 소프트웨어 개발 프로젝트에서는 업무 분류 체계를 중요하게 활용합니다. 무엇을 개발할 것인지에 대한 요구사항을 근거로 어떻게 개발하는지에 대해 생애 주기의 관점에서 분할하고 정의하게 됩니다. 업무 분류 체계는 일반적으로 워터폴 방식의 프로젝트에서 주로 사용됩니다. 애자일 프로젝트에서는 업무 분류 체계의 개념을 잘 사용하지 않습니다. 애자일 프로젝트에서는 로드맵, 백로그, 에픽, 기능, 유저 스토리를 주로 사용합니다.
프로젝트 범위 정의와 개발 방법론의 구분
프로젝트 범위는 범위 기준선에 의해서 정의될 수 있고, 범위 기준선은 범위 기술서와 업무 분류 체계(WBS), 그리고 업무 분류 체계 사전(WBS Dictionary)에 의해서 구성됩니다. 범위 기준선은 실제 결과와 비교하는 기준으로 활용될 수 있습니다. 범위 기준선은 공식적인 변경 통제 프로세스에 의해서 만 변경이 가능합니다. 프로젝트의 범위에 대해서는 프로젝트 개발 방법론에 따라서 다르게 접근 됩니다. 적응형 접근 방식의 프로젝트에서는 범위를 분할합니다.
애자일 헌장과 로드맵을 기반으로 제품과 서비스의 전략적 목표인 테마를 식별합니다. 테마를 달성하기 위해서 대규모 유저 스토리를 포함한 에픽을 개발합니다. 에픽은 제품의 특정 동작을 나타내는 기능으로 분할 됩니다. 기능은 사용자 관점에서 작성된 요구 사항인 유저 스토리들로 구성됩니다. 프로젝트 범위에 대한 정의는 사용하는 개발 접근 방식에 따라서 인도물 구현 완료와 프로젝트 완료를 설명하는 방법이 달라집니다. 예측형 접근 방식의 워터폴 프로젝트에서는 범위 정의를 어떻게 설명하는지 알아봅시다.
예측형 접근 방식의 인수 기준이나 완료 기준은 고객이 인도물을 승인하거나 프로젝트가 완료된 것으로 간주하기 위해서 충족해야 하는 기준들을 달성하였을 때 입니다. 예측형 개발에서는 프로젝트 범위를 정의하기 위해서 프로젝트 착수 시점에서 상세한 업무 분류 체계를 정의합니다. 예측형 접근 방식의 인수기준과 완료기준은 범위 기술서에 문서화하게 됩니다. 기술 성과 측정에 대해서 제품의 기술 사양은 별도의 문서로 문서화합니다. 기술 성과 측정에 대해서는 업무 분류 체계(WBS)를 확장하여 업무 분류 체계 사전(WBS Dictionary) 형태로 문서화할 수 있습니다.
애자일 프로젝트의 범위 정의 설명
적응형 접근 방식의 애자일 프로젝트에서의 프로젝트 범위 정의에 대해서 이어서 알아봅시다. 적응형 접근 방식에서는 완료 정의와 준비 정의가 있습니다. 완료 정의는 DoD(Definition of Done)이라고 부릅니다. 완료 정의(DoD)는 적응형 접근 방식의 소프트웨어 개발 프로젝트에서 사용하는 개념입니다. 완료 정의는 고객이 사용할 수 있는 수준으로 완료된 인도물로 간주하기 위해서 충족해야 할 모든 기준들을 명시한 체크 리스트입니다. 완료 정의는 애자일 개발에서 사용하는 개념으로 요구 사항에 대한 완료 기준을 의미합니다.
완료 정의는 고객이 사용할 수 있는 수준의 인도물이라고 간주하기 위해서 충족해야 할 모든 기준과 점검 목록인 것입니다. 사용자 스토리의 완료 기준을 예로 들어 보면, 단위 테스트 통과나 코드 리뷰, 인수 기준 충족, 비기능 요구사항 충족, 프로덕트 오너의 승인이 사용자 스토리의 완료 기준이 될 것입니다. 애자일 개발 팀에서는 엔지니어 관점에서 업무 협업을 위해서 완료 정의를 정의하기도 합니다. 애자일에서는 품질 기준이 완료 의미의 일부입니다. 모든 품질 기준을 충족해야 하고 프로덕트 오너(PO)가 결과를 검증하고 동의하고 승인해야 합니다. 이는 코드 리팩토링과 검증, 마스터 브랜치 통합, 스테이징 환경에 배포를 통해 검증할 수 있습니다. 적응형 접근 방식에서는 준비 정의의 개념이 있습니다. 준비 정의는 DoR(Definition of Ready)라고 부릅니다. 준비 정의(DoR)은 개발 팀이 스프린트 계획 회의에서 유저 스토리를 받아들일 수 있도록 프로덕트 오너(PO)가 수행해야 하는 것들을 말합니다.
준비 정의는 요구 사항 개발의 착수 기준을 의미합니다. 준비 정의는 프로덕트 오너가 확인한 다음, 프로젝트 팀에게 개발 요청이 들어가야 합니다. 준비 정의를 예로 들어 보면, 테스트가 가능한 명확한 유저 스토리나 유저 스토리의 인수 기준의 정의입니다. 투입 공수와 기간 산정이 가능해야 하고, 백로그 상 우선순위에 대한 확인이 가능해야 합니다. 애자일 팀이 작업 수행을 위해서 필요한 일련의 체크 리스트입니다. 프로덕트 오너와 개발 팀은 유저 스토리에 대한 대화를 통해 합의가 이루어지는데 이것을 준비 정의로 볼 수 있습니다. 또한 유저 스토리는 비즈니스 가치에 명확하게 부합해야 합니다. 유저 스토리는 단일 스프린트에서 구현하기에 충분할 정도로 분할 되어 있어야 합니다.
프로젝트 범위와 완료 목표 변동 설명
프로젝트를 진행할 때 프로젝트를 진행하는 과정에서 완료 목표가 변동 될 수 있습니다. 불확실하고 빠르게 변화하는 환경 속에서 진행되는 프로젝트는 완료 목표가 변동 될 수 있는 것입니다. 예를 들어, 경쟁사의 새로운 신제품이 출시되었거나 경쟁사에서 자사에서 서비스 기능을 추가하기 전에 계획된 기능이나 업데이트가 추가되었거나 새로운 기술 트랜드에 따라서 요구 사항 방향이 바뀌거나 새로운 요구 사항들이 추가될 수 있습니다. 프로젝트 기간이 길어질수록 완료라고 하는 목표에 대해서 변동 가능성은 더 높아질 수 밖에 없습니다. 이를 완료 지연이라고 부릅니다.
프로젝트 팀은 완료 진행률과 비교하여 계획된 프로젝트 목표 달성율을 추적해야 합니다. 안정적인 환경에서 운영되는 프로젝트에서도 범위 추가가 발생할 수 있습니다. 범위 추가는 프로젝트 일정과 예산, 그리고 자원 조정 없이 진행되는 범위 확장을 의미합니다. 프로젝트에서는 범위 추가를 방지하기 위해서 변경 통제 시스템을 활용하게 됩니다.
변경이 프로젝트에 가져오게 될 잠재적 가치와 이를 실현하는데 필요한 자원과 예산, 그리고 프로젝트 일정에 대한 평가를 수행해야 합니다. 공식 승인을 거버넌스 기관, 스폰서, 프로덕트 오너에게 의뢰하여 진행될 수 있습니다. 특정 작업을 완료했다는 것은 다음 작업을 착수할 준비가 되었다는 것을 의미합니다. 완료의 결과를 넘겨주는 사람과 완료된 결과를 활용하는 사람 사이에 완료에 대한 명확하고 정확한 기준이 있어야 불필요한 갈등과 혼선을 줄일 수 있습니다. 서로 완료에 대한 기준을 정확하게 정의해 놓지 않으면 이로 인해 재 작업이 발생할 수 있고 갈등이 발생할 수 있습니다.
완료에 대해서 명확하게 정의하면 오해를 최소화할 수 있고 업무 생산성도 향상 시킬 수 있습니다. 프로젝트를 진행할 때 정의 해야 할 대표적인 완료 기준에 대해서도 알아봅시다. 프로젝트를 완료했다는 기준을 충족시키기 위해서는 계획서나 계약서에 명시된 인도물의 완성, 이해 관계자의 승인 문서, 통합 테스트 결과, 품질 목표 달성 결과 등에 대한 기준들을 충족해야 합니다. 프로젝트 완료 전에 개별 인도물에 대한 인수 기준을 명확하게 정의합니다. 일반적으로 체크 리스트를 활용하여 해당 부서에서 평가한 후 인수 여부를 결정할 수도 있습니다. 인도물이 달성해야 할 성능 목표를 정의하였으면 이를 달성해야 합니다. 소프트웨어의 경우 응답 속도나 동시 접속이 가능한 사용자 수, 보안 침해 방지 등이 프로젝트 성능 목표와 관련된 달성 되어야 할 대표적인 목표 예시입니다.