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