업무나 프로젝트 완료의 기준은 다양하고 오해하기 쉽습니다.

끝날 때까지 끝난 게 아니라는 말은 미국 뉴욕 양키스의 포수였던 요기베라가 했던 말로 경기가 끝날 때까지 포기해서도 안되고 방심해서도 안된다는 의미입니다. 야구는 27명의 타자를 아웃시키면 끝나지만 프로젝트의 끝은 복잡합니다.   야구의 끝과 프로젝트의 끝은 다음과 같이 다릅니다.  첫째 야구에서는 아웃의 기준이 동일합니다. 잘 친다고 2 아웃으로 끝나지 않고 못 친다고 4 아웃까지 기회를 주지 않습니다. 그러나 프로젝트 요구사항 완료의 기준은 요구사항마다 다릅니다. 문서로 완료의 기준을 상세하게 정의하면 오해가 줄어들지만 완료에 대한 동상이몽의 해석은 여전히 가능합니다.  둘째 야구는 27명의 타자가 아웃되면 경기가 끝나지만 프로젝트는 모든 요구사항을 완료해도 끝나지 않을 수 있고, 일부 요구사항을 완료하지 않아도 끝날 수 있습니다.  셋째 야구는 아웃에 대해 두 팀이 다툴 때 심판이 판정할 수 있습니다. 심지어 비디오까지 활용하여 심판 판정도 어필할 수 있습니다. 그러나 프로젝트는 완료에 대해 이해관계자와 프로젝트 팀이 다툴 때 이를 조정할 수 있는 심판이 없습니다. 프로젝트의 완료 또는 중요한 요구사항의 완료여부를 놓고 다툴 때 문제해결은 정치의 영역으로 넘어갑니다.      - 다양한 관점의 완료 프로젝트는 끝내기 위해서 시작합니다. 따라서 개별 요구사항의 끝도 중요하고 프로젝트의 끝내는 방법이나 기준도 중요합니다. 프로젝트에는 다양한 관점의 완료가 있습니다.  프로젝트 범위는 요구사항으로 구성되며 요구사항을 완료하기 위해서는 분석, 설계, 개발, 테스트와 같은 일(work)을 수행해야 합니다. • 일 완료와 요구사항 완료 일의 결과는 설계서, 테스트 계획서와 같은 산출물입니다. 산출물에 대한 승인을 요구사항을 승인한 것으로 생각해서는 안됩니다. 산출물은 명시적인 요구사항을 충족하면 됩니다. 그러나 요구사항은 문서에 정의된 명시적인 요구사항 사항뿐만 아니라 문서에 없는 암묵적인 요구사항도 충족시켜야 합니다. 소프트웨어 개발 프로젝트에서는 특히 그렇습니다. 소프트웨어 개발에서 요구사항을 승인하는 것은 작동하는 소프트웨어를 승인하는 것이지 문서를 승인하는 것은 아닙니다.   • 요구사항 완료와 범위 완료  프로젝트 범위를 완료하려면 개별 요구사항 완료 외에 행정적인 프로세스도 완료해야 합니다. 프로젝트 관리시스템에 데이터 등록, 완료보고회, 팀원 평가 등이 행정 프로세스의 예입니다. SI 프로젝트는 고객사의 행정 프로세스 뿐만 아니라 프로젝트 수행사의 행정 프로세스 모두가 프로젝트 범위에 포함됩니다.   • 범위 완료와 프로젝트 완료  범위의 완료와 프로젝트의 완료는 일치하는 것이 정상이지만 범위를 완료해도 프로젝트가 완료되지 않는 경우도 있습니다. 물론 이해관계자가 범위외 요구사항을 명시적으로 요구하지는 않습니다. 기존 요구사항에 대한 보완을 요청하면서 프로젝트 완료를 지연시킬 뿐입니다. 프로젝트 결과물을 운영으로 이관할 준비가 안되었을 때 이런 현상이 발생합니다. 프로젝트 완료는 운영의 시작이기 때문에 운영할 준비가  부족하면 이런저런 사유를 들어 프로젝트 완료에 대한 승인을 지연시킵니다.     - 완료에 대한 잘못된 판단이 프로젝트에 미치는 영향 끝난 일을 끝나지 않았다고 평가할 가능성은 낮습니다. 반대로 끝나지 않은 일을 끝났다고 평가할 가능성은 높습니다. 프로젝트 팀이 이해관계자나 고객을 속인다는 것이 아닙니다. 완료의 기준이 애매하다는 것입니다. 예를 들어 통합테스트를 완료했다는 말을 다음과 같이 다르게 생각할 수 있습니다.  • 통합테스트 시나리오대로 점검을 끝냈습니다.(1)  • 통합테스트 시나리오 점검 시 발견된 결함을 모두 조치했습니다.(2) • 통합테스트 및 결함수정 과정에서 발견된 모든 결함들을 조치했습니다.(3) • 통합테스트 과정에서 고객이 요청한 사항들을 모두 반영했습니다.(4)     먼저‘결함’인지 아닌지를 판정하는 기준도 애매합니다. 이해관계자 관점에서는 결함이지만 프로젝트 팀 입장에서는 프로젝트 팀이 통제할 수 없는 외부의 문제 또는 제약조건일 수도 있습니다. 그렇다고 해도 프로젝트 팀은 (2)의 기준으로 통합테스트를 완료했다고 판단하고 고객은 (3) 또는 (4)의 기준으로 통합테스트를 완료해야 한다고 말할 것입니다.     그래서 가능한 한 요구사항 또는 개별업무의 완료기준을 명확하게 작성하고 이해관계자와 협의하는 것이 바람직하지만 그런 사치(?)를 부릴 여유가 없이 빨리 프로젝트를 수행해야 하는 경우도 많습니다. 그렇게 바쁘게 달려가다 후반부에 이해관계자가 자기를 속였다고 목소리를 높이기도 합니다. 그런 말들은 “서버에 있는 프로그램이 껍데기만 있어 하나도 작동하지 않는다”라는 식으로 확대 증폭되어 다른 사람들에게 전달되기도 합니다.     SI 프로젝트에서는 중도금 수령 마일스톤에 따라 완료된 업무에 비례하여 중도금을  받습니다. 진척률 기반으로 프로젝트 중도금을 받았는데 그 진척률이 과대평가 되었다면 어떻게 될까요? 과대평가한 진척률을 바로 잡기 위해 투입되는 원가는 보상 받을 방법이 없습니다. 업무 수행을 위한 원가에 비례하여 중도금을 받는 것이 고객사와 프로젝트 수행사 모두에게 바람직합니다. 그러기 위해서는 업무완료에 대한 이견을 최소화해야 합니다.     - 완료에 대한 이견을 좁히는 방법   • 개별 요구사항에 대한 인수기준(acceptance criteria)을 정의하고 테스트 시 확인합니다.  개별 요구사항 완료에 대해 고객과 이견이 없으면 프로젝트 완료에 대한 이견도 줄어들 것입니다. 요구사항을 정의할 때 고객과 함께 인수기준을 정의하고 테스트를 통해 확인하는 것이 좋습니다. 그러나 현실에서는 이런저런 이유 때문에 개별 요구사항에 대한 인수기준을 구체적으로 정의하지 않거나 테스트시 형식적으로 확인하는 경우가 많습니다. 인수기준은 아래의 요건을 갖추어야 합니다.       1) 테스트 가능해야 합니다.   인수조건은 테스트를 통해 확인할 수 있어야 합니다. 예를 들어 프로젝트 관리 시스템에서 ‘지연의 위험이 높은 작업’은 주관적인 기준이어서 테스트가 불가능하고 ‘계획대비 지연된 작업’이라는 용어는 명확해 보이지만, 최초 계획대비 지연인지 최종 계획대비 지연인지를 명확하게 정의해야 합니다.    2) 인수기준을 정의하는 형식을 따릅니다.   테스트 코드를 작성할 때 많이 사용하는 사전조건(Given), 사전동작(When), 수행결과(Then)의 형식도 인수기준을 정의하는 형식으로 활용할 수 있습니다. 사전조건은 주어진 환경이나 값, 사전동작은 구현하는 기능의 동작, 수행결과는 구현된 기능의 결과를 의미합니다. 예를 들어 사용자 ‘ID를 받을 때(사전조건), 특수 기호를 포함하지 않은 비밀번호를 받으면(사전동작), 특수기호를 포함하여 다시 등록하라는 메시지를 제공해야 한다.(수행결과)’와 같이 인수기준을 정의합니다.    3) 인수기준 이전에 요구사항을 구체화합니다.  요구사항을 구체화하면 인수조건의 간단하게 기술할 수 있습니다. 반대로 요구사항을 구체화하지 않으면 인수기준에 하위 요구사항에 대한 내용을 포함해야 합니다.    • 업무완료에 대한 기준(DoD Definition of Done)을 정의합니다.  DoD와 인수기준을 구분하지 않고 사용하기도 하지만 구분하여 사용하기도 합니다. 인수기준은 개별 요구사항별로 달라지지만 DoD는 업무완료에 대한 전제조건과도 같아 모든 요구사항에 공통적으로 적용됩니다. 개발이 완료되면 개발리더에게 내용 확인 후 서버에 프로그램을 등록하는 것이 예입니다. 이러한 조건은 모든 프로그램의 개발에 공통적으로 적용되는 기준입니다. 이러한 기준을 적용하면  프로그램 완료를 세 단계로 나누어 평가할 수 있습니다. 개발자 기준의 완료, 개발리더가 확인한 완료, 고객 실무자가 확인한 완료가 그 예입니다. 개발진척률도 세 가지 유형으로 나누어 관리하기도 합니다.     • 완료에 대한 이견은 조기에 확인하도록 노력합니다.  프로젝트를 수행하면서 발생하는 업무완료에 대한 이해관계자와의 이견은 피할 수 없습니다. 이로 인한 부작용을 최소화하기 위해서는 완료에 대한 이견을 빨리 파악해야 합니다. 이견을 조기에 확인하려면 확인하는 업무의 양을 작게 나누어 자주 확인해야 합니다. ======================================================= 제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 을 25년 1월 출간한 소식을 공유합니다. https://product.kyobobook.co.kr/detail/S000215148133