요구사항 변경과 납기의 관계

어느 프로젝트에서나 일정 기간마다 달성할 목표를 세우고 목표를 달성해 가는 과정을 반복합니다. 이를 통해 팀의 퍼포먼스를 측정해 팀의 역량과 기간에 알맞는 목표를 수립할 수 있게 되고 또 목표마다 우선순위를 설정해 더 중요한 목표와 그렇지 않은 목표를 구분해 더 효율적으로 개발할 수 있게 됩니다. 거의 모든 조직에서 이 과정을 ‘스플린트'나 ‘마일스톤’ 같은 이름으로 불렀는데 전자는 애자일 어쩌구 방법론을 깊은 고민 없이 그냥 도입하려다가 익숙하고 안정감을 주는 여러 습관을 버릴 결정을 내리지 못해 이도 저도 아닌 규칙이 이름만 남곤 할 때 주로 사용했고 후자는 딱히 뭔 방법론을 염두해 두지 않더라도 좀 더 긴 기간 동안 달성할 더 여러 가지 목표를 같은 기간에 개발할 때 사용하곤 했습니다.

마일스톤을 시작하기 전에는 이번 마일스톤에서 달성할 여러 가지 목표에 따라 계획을 수립하는데 종종 계획 각각은 서로 같은 맥락으로 묶기 어려울 때가 있었습니다. 마일스톤 하나에 포함된 여러 목표들을 깔끔하게 한 가지 맥락으로 묶어 설명해 내는 것은 종종 디렉터 이상에 요구되는 스토리텔링 자질이기는 하지만 이를 잘 해내는 사람은 거의 없었습니다. 이들은 경영진이나 고객들에게는 그럴듯하게 말하곤 했지만 개발팀을 향해서는 그러지 못했는데 그럴 필요를 느끼지 않았거나 그럴 능력이 없었을 수도 있는데 개발 진행에 문제가 생기지는 않았습니다. 더 올릴 여지가 있던 팀의 사기가 그만큼 오르지 않을 수 있지만 이는 가능성에 불과하며 측정 가능하지 않기 때문입니다.

마일스톤의 여러 목표에 따라 개발을 진행하다 보면 계획 단계에서 비용 추정에 실패한 항목들이 나타납니다. 개발 경험이 쌓임에 따라 비용 측정이 용이한 항목과 그렇지 않은 항목을 어느 정도 구분할 수 있기는 하지만 그럼에도 예상 밖의 상황이 생겨 비용 추정에 실패한 항목들이 나타나 마일스톤 계획을 다시 점검해 비용에 따라 개발 수준을 조절하거나 목표를 제거하거나 초과근무를 하는 등의 여러 가지 대책을 세우곤 합니다.

예상할 수 있겠지만 여러 의사결정자들은 비용 추정에 실패할 때 계획을 수정하기 보다는 초과근무를 쉽게 택하는데 이유는 이 결정이 쉽기 때문입니다. 포괄임금제이거나 비포괄임금제이거나에 관계 없이 목표를 건드리기는 쉽지 않습니다. 어떤 의사결정자라도 마일스톤 계획 변경은 본인보다 윗 사람에게 보고해야 하는 그리 단순한 일이 아닙니다. 추가로 나타난 개발 비용에 대응해 다른 계획을 취소하고 이를 보고하기 위한 비용을 사용하기 보다는 추가로 인건비를 지출하건 지출하지 않건 간에 초과근무를 선택해 계획을 유지하고 변경 보고를 할 일을 아예 만들지 않는 쪽이 훨씬 편한 방법입니다.

한편 비용 예측 실패가 항상 비용 증가로 이어지는 것 만은 아닙니다. 종종 계획을 보수적으로 세운 나머지 확실하지는 않지만 이번 마일스톤은 후반에 약간 느슨하게 일해도 될 것 같다는 느낌을 받을 때가 있습니다. 계획을 보수적으로 세우는 이유는 아직 팀이 낼 수 있는 퍼포먼스가 어느 정도인지 확실하지 않거나 이전에 해본 적 없는 일을 추진해야 하기 때문일 수 있는데 후자의 경우 비용을 추정할 수 없는 상황 자체를 위험요소로 판단해 비용을 높게 잡았는데 진행해 보니 예상보다 비용이 훨씬 낮아 마일스톤 전체에 여유가 생길 수도 있습니다. 이럴 때 당연히 팀을 느슨하게 두기 보다는 뭔가 새로운 목표를 투입해 팀이 적당히 바쁜 상태를 유지하도록 하는 것도 나쁘지 않습니다.

그런데 종종 이런 계획 변경은 목표의 추가, 수정, 삭제 각각에 관계 없이 그저 계획 변경 그 자체가 비용을 일으킨다는 점을 생각하지 않을 때가 있습니다. 이는 직관적이지 않기 때문이라고 생각합니다. 마일스톤에 목표를 추가하면 목표를 추진할 사람이 필요하고 사람들 각각의 퍼포먼스와 일정을 고려해야 합니다. 어떤 일은 팀 내에 특정 인원이 진행해야만 할 수도 있는데 그렇다면 이 목표는 다른 목표에 비해 인원을 선택할 수 없기 때문에 비용이 더 높다고 볼 수 있습니다. 또 목표 수준을 올리면 시간이 더 걸릴 것임을 직관적으로 인식할 수 있습니다. 반대로 목표를 제거하면 당장 그 목표에 할당한 인원들의 일정을 다른데 사용할 수 있게 되니 관리하는 입장에서는 비용이 직관적으로 낮아집니다.

하지만 이런 목표 추가, 수정, 삭제가 그 행동 자체만으로 전체 비용을 증가시키는 것은 직관적으로 납득하기 쉽지 않을 수 있습니다. 하지만 실제로 일어납니다. 누군가는 목표를 구성하는 사양 중 일부가 취소되었음을 인식하지 못하고 개발을 계속하고 있었을 수도 있습니다. 또 누군가는 이미 작성해 놓은 사양이 취소되어 사용할 수 없게 되어 그때까지 투입한 이번 마일스톤에 해당하는 비용이 무의미하게 되었을 뿐 아니라 미래에 이 사양을 그대로 적용할 수 없어 미래의 비용을 부담하게 되었을 수 있고요. 또 변경된 목표를 여러 사람에게 공지하고 인지시키고 회의 때마다 변경된 부분을 잘못 알고 있는 사람들에게 현 시점에 올바른 정보를 전달하는 등 직관적으로 드러나지는 않지만 사양을 제거하더라도 비용은 증가합니다.

이런 상황 속에서 팀에 여유가 있어 보이지 않는데도 목표를 추가하는 행동은 더 이상 설명할 필요도 없이 비용을 증가시키는데 직관적으로 비용 증가는 납기 일정과 양의 상관관계가 있습니다. 그런데 위에 이야기한 계획을 변경하고 이를 보고하기는 어렵지만 초과근무를 통해 기존 계획을 유지하고 변경된 계획을 추가하면서도 납기를 동일하게 유지하는 결정은 하기 쉽습니다. 특히 포괄임금제 체제에서 초과근무를 통해 납기를 지키면 이는 표면적으로 비용 증가처럼 보이지 않아 같은 결정을 반복하게 됩니다.

제목으로 돌아가 요구사항 변경은 이 변경이 기능을 추가하거나 수정하거나 삭제하거나에 관계 없이 항상 납기에 양의 상관관계를 가집니다. 이 사실을 인식하지 않은 채 ‘별 것 아닌 기능을 추가하기 왜 이렇게 힘든가' 혹은 ‘사양을 축소했는데 왜 납기가 충분히 당겨지지 않는가’ 같은 의문을 제기한다면 모두를 불행하게 만들게 됩니다.