프로젝트 가격을 책정하고 범위 크리프를 관리하는 방법

정확한 견적을 작성할 수 있는 마법 같은 가격 책정에 대한 과학적 접근 방식이 있음을 시사하는 비현실적인 기사를 읽었을 것입니다. 또한 스코프 크립은 어떤 대가를 치르더라도 피해야 한다고 믿게 되었을 수도 있지만 현실 세계에서는 항상 일어날 것입니다.

이제 우리는 이 말도 안되는 게임을 그만하고 도박이 아닌 강력하고 안정적인 프로세스를 따르는 방식으로 프로젝트를 시작할 때입니다.

내가 과장하고 있습니까? 가능하지만 디지털 프로젝트에서 자주 잘못되는 부분을 살펴보겠습니다.

프로젝트 프로세스의 문제

내 경험에 따르면 모든 산업 분야의 대부분의 조직은 거의 동일한 방식으로 프로젝트를 실행합니다.

1. 경영진의 누군가가 프로젝트 완료를 요청합니다. 불행히도 이 요청은 종종 결과물 측면에서 세부 사항이 부족하고 모호한 목표만 갖는 경향이 있습니다.
2. 이해관계자 위원회를 구성하여 프로젝트를 세부적으로 정의하고 범위를 결정합니다.
3. 그런 다음 세부 범위를 구축할 팀으로 이동하여 소요 시간과 비용을 추정하도록 요청받습니다.
4. 프로젝트는 시간과 예산 내에서 납품을 강조하면서 사양에 따라 납품됩니다. 결과적으로 스코프 크립은 적이 됩니다.
5. 프로젝트가 전달되고 모든 사람이 작업 목록에서 다음 프로젝트로 이동합니다.

이 접근 방식은 특히 디지털 프로젝트에 적합하지 않습니다. 디지털은 우리에게 사용자 행동에 대한 전례 없는 피드백을 제공하고 (물리적 제품과 비교하여) 변경을 비교적 쉽게 구현할 수 있도록 합니다. 그러나 범위가 정의되고 견적이 제공되면 프로젝트가 잠기고 모두가 프로젝트가 진행됨에 따라 변경하기를 꺼립니다.

그러나 불가피하게 범위가 변경되는 것은 주로 이해 관계자가 무엇을 구축할지에 대한 다양한 해석을 가지고 있거나 프로젝트 중간에 중요한 요소가 잘못되었음을 깨닫기 때문입니다.

사실, 스코프 크립에는 아무런 문제가 없습니다 . 유연성을 유지하고 학습에 따라 적응하는 것은 우수한 디지털 서비스를 만드는 데 기본입니다. 문제는 범위 크리프가 아니라 프로젝트를 실행하는 방식입니다.

불행히도 마감일과 비용이 합의되었기 때문에 이러한 제약 조건 내에서 이러한 변경 사항을 제공하려고 시도하여 모서리가 잘립니다.

일정과 비용이 처음부터 정확했던 것은 아닙니다. 디지털 프로젝트는 복잡하며 종종 전문가와 이해 관계자가 함께 작업해야 합니다. 그 결과 정확한 추정이 어렵기로 악명이 높습니다.

나는 정확한 추정을 위한 방법론을 제안하는 많은 기사를 읽었습니다. 그러나 대부분의 경우 적용하기에 너무 시간이 많이 걸리기 때문에 거의 모든 경우에 현실 세계에서 비실용적입니다. 프로젝트를 추정하는 것은 직관, 경험 및 추측에 달려 있습니다!

이 분야에서 일한 적이 있는 사람이라면 누구나 알겠지만 대부분의 추정치는 허구 입니다. 우리는 일반적으로 올바른 솔루션이 무엇인지 또는 사용자가 이에 대해 어떻게 대응할 것인지 결정하는 것조차 사전에 충분히 알지 못합니다. 따라서 전체 프로젝트를 미리 정확하게 추정하는 것은 불가능합니다.

불행히도, 이러한 모호성은 프로젝트가 불가피하게 기한을 놓치고 예산을 초과할 때 종종 부당하게 책임을 분담하게 만듭니다.

다행히도 정확한 추정치를 제공하고 실행 프로젝트 변경과 관련된 범위 크립을 관리하는 방법이 있습니다. 비밀은 프로젝트를 더 작은 덩어리로 나누는 데 있습니다. 이 접근 방식은 크고 복잡한 프로젝트를 수행하는 것을 방지합니다.

프로젝트를 소규모 참여 시리즈로 나누기

이 시점에서 분명히 해야 합니다. 나는 야심 찬 작업 프로그램이 잘못되었다고 제안하지 않습니다. 저는 상당한 규모의 웹사이트와 방대한 작업 프로그램에서 대규모 고객을 위해 일합니다. 그러나 이러한 계약을 하나의 대규모 프로젝트로 취급하는 경우는 거의 없습니다. 대신 한 번에 하나씩 범위를 지정하는 관리하기 쉬운 프로젝트로 나눕니다.

클라이언트가 디지털 프로젝트(크건 작건)를 수행하기 위해 나에게 접근할 때 일반적으로 다음 순서로 발생하는 네 단계로 나눕니다.

1. 발견,
2. 알파,
3. 최소 실행 가능한 제품,
4. 지속적인 반복 및 최적화.

각 단계는 명확한 결과물이 포함된 별도의 계약입니다. 따라서 나는 전체 프로젝트에 전념하지 않고 첫 번째 단계에만 전념합니다. 그러면 범위 크리프를 훨씬 쉽게 예측하고 관리할 수 있습니다.

예를 들어 다음 단계의 범위만 정의하면 됩니다. 이전 단계가 완료되면 다음 단계를 정의할 때 이를 수용할 수 있으므로 범위 크리프를 더 잘 관리할 수 있습니다.

전체 작업 프로그램을 추정하는 대신 해당 프로그램의 다음 프로젝트를 추정하고 있습니다. 또한 이전 단계를 사용하여 보다 정확하게 추정할 수 있습니다.

각 단계는 발견부터 시작하여 다음 단계를 정의하고 추정하는 데 도움이 됩니다.

1. 발견

발견 단계에서는 이해 관계자와 협력하여 프로젝트를 검증합니다. 프로젝트의 전체 규모에 따라 이것은 몇 번의 회의처럼 간단할 수도 있고 전체 작업 프로그램이 될 수도 있습니다.

일반적으로 다음과 같은 요소가 포함됩니다.

• 사용자 조사 수행
• 경쟁 분석;
• 핵심 성과 지표 식별;
• 성공이 무엇인지 정의하기
• 제약 이해하기;
• 이해 관계자의 의견을 대조합니다.

아이디어는 발견 단계가 사용자 요구, 비즈니스 목표 및 생성해야 하는 것을 포함하여 프로젝트에 대한 보다 정보에 입각한 정의를 제공한다는 것입니다.

가장 중요한 것은 프로젝트가 필요한 가치를 제공할 것인지 검증하는 것입니다.

그런 다음 이 결과물을 사용하여 알파 단계에서 필요한 작업을 정의하고 추정할 수 있습니다. 그렇게 하면 추정이 더 정확해지고 학습한 내용을 기반으로 범위가 조정됩니다.

2. 알파

알파 단계는 디지털 서비스(웹 앱이든 사이트이든)가 작동하는 방식을 정의하고 사용자가 이를 사용하여 긍정적인 경험을 하도록 하는 단계입니다.

이는 일반적으로 프로토타입 생성을 통해 수행됩니다. 소규모 프로젝트에서 이것은 일부 디자인 모형에 지나지 않을 수 있습니다. 더 큰 프로젝트에서는 사람들이 시도할 수 있는 기능적 프로토타입이 될 수 있습니다.

어떤 경우이든 아이디어는 구축 중인 디지털 서비스를 시각화하는 것입니다.

우리는 세 가지 이유로 이것을 합니다.

• 첫째, 시각화는 모든 이해 관계자가 귀하가 만들고 있는 것에 대한 공유된 비전 을 갖도록 합니다. 문서는 다양한 방식으로 해석될 수 있지만 프로토타입에서는 훨씬 더 어렵습니다.
• 둘째, 프로토타입을 사용하면 간과했을 수 있는 모든 항목을 훨씬 쉽게 식별할 수 있으므로 해결하는 데 비용이 더 많이 들 때 범위가 더 좁아지는 것을 방지할 수 있습니다.
• 마지막으로, 유형이 있는 것이 있으면 실제를 구축하는 데 비용을 들이기 전에 사용자와 함께 테스트하여 목적에 맞는지 확인할 수 있습니다.

테스트가 제대로 수행되지 않으면 예산을 초과하거나 일정을 어지럽히지 않고 적응할 수 있는 다음 단계 이전에 여전히 여유가 있습니다.

발견 단계와 마찬가지로 알파를 사용하여 다음 단계에서 필요한 작업을 추정할 수 있습니다. 구축해야 할 사항을 시각화하면 관련된 모든 이해 관계자가 필요한 작업을 훨씬 쉽게 예측할 수 있습니다. 그들은 그들이 구축하도록 요청받은 것을 볼 수 있습니다.

또한 알파 테스트에서 배운 교훈을 사용하여 우리가 만들 항목을 조정할 수 있으며, 다시 한 번 프로젝트를 탈선시키지 않고 범위 변경을 위한 공간을 만들 수 있습니다.

일단 알파가 있으면 우리가 올바른 것을 만들고 사용자가 긍정적으로 응답할 것이라는 것을 알고 자신 있게 빌드로 이동할 수 있습니다.

3. 실행 가능한 최소 제품

저는 이 단계를 '빌드'라고 부르곤 했습니다. 그러나 이해 관계자는 빌드 완료와 프로젝트 완료를 연관시켰습니다. 실제로 디지털 서비스는 가능한 한 효과적인지 확인하기 위해 지속적으로 반복해야 하므로 결코 완료되지 않습니다.

이 문제를 피하기 위해 이 단계를 MVP(Minimum Viable Product)라고 부르기 시작했습니다. 이 단계에서 우리는 디지털 서비스의 초기 버전을 구축하고 출시합니다.

최소한의 실행 가능한 제품으로 언급함으로써 출시 후 반복이 있을 것임을 강조합니다. 이는 출시 후까지 미루어 범위 크리프와 예상치 못한 복잡성을 처리하는 방법을 제공합니다. 그래야 프로젝트가 순조롭게 진행되고 추진력을 유지할 수 있습니다.

부득이하게 빌드 중 일부는 출시 후까지 보류됩니다. 그런 다음 이러한 요소는 최종 단계를 정의하는 기초가 되어 출시 후 최적화에 대한 초기 추정을 할 수 있습니다.

4. 지속적인 반복 및 최적화

출시 후 단계에서는 MVP에서 다루지 않은 기능, 복잡성 및 기타 문제를 다룹니다. 이 개선 사항 목록은 이 시점에서 범위를 지정하기가 비교적 쉬우며 합리적인 정확도로 추정할 수 있습니다.

그러나 이 작업 외에도 디지털 서비스의 효율성을 더욱 개선하기 위한 모니터링, 반복 및 테스트의 지속적인 프로세스가 있어야 합니다.

귀하가 수행하는 이 작업의 양을 추정하는 것은 디지털 서비스의 규모와 복잡성을 기반으로 해야 합니다. 귀하의 추정치는 또한 프로젝트의 나머지 부분에 대한 투자에 비례해야 합니다.

프로젝트를 이 네 단계로 나누고 각 단계를 개별적으로 완료하면 기존 프로젝트 관리 접근 방식을 사용할 때 직면하는 많은 문제를 제거할 수 있습니다.

프로젝트 분해가 작동하는 이유

다음과 같은 방식으로 프로젝트를 세분화하면 4가지 중요한 이점이 있습니다.

• 각 단계는 더 잘 정의됩니다 .
  이전 단계의 결과물이 각 단계를 정의하기 때문에 방향에 대한 명확한 비전이 있음을 의미합니다. 이를 통해 이해 관계자는 상황이 어디로 가고 있는지 이해하고 나중에 불쾌한 놀라움을 피할 수 있습니다.
• 프로젝트가 더 정확하게 추정 됩니다.
  예를 들어, 상당한 수의 미지수가 있는 중요하고 모호한 프로젝트를 제공하는 데 시간이 얼마나 걸릴지 추측할 필요 없이 다음 단계만 예측하고 이전 단계의 결과물을 기반으로 수행합니다.
• 더 나은 디지털 서비스를 제공 합니다.
  프로젝트 아이디어가 사용자와 함께 검증되고 테스트되기 때문에 최종 제품이 목적에 부합할 것이라는 확신을 가질 수 있습니다. 또한 가능한 최상의 결과를 제공할 수 있도록 단계 간에 범위와 기능을 조정할 수 있는 여지가 있습니다.
• 덜 위험한 접근 방식 입니다.
  디지털 서비스를 위탁하는 회사는 전체 프로젝트를 사전에 커밋할 필요가 없습니다. 발견 단계에서 프로젝트의 실행 가능성을 검증하는 데 실패하면 약간의 손실과 함께 중단될 수 있습니다. 마찬가지로 알파 프로토타입이 사용자에게 잘 테스트되지 않으면 비용이 너무 많이 들기 전에 조정할 수 있습니다.

이 마지막 요점은 외부 공급업체를 처음 사용하는 경우 안심할 수 있습니다. 제공할 수 있는지 여부를 모른 채 실질적인 프로젝트에 대행사에 등록하는 대신 클라이언트는 발견 단계에 참여하여 자신이 어떤 것인지 확인할 수 있습니다. 그들이 좋다면, 그들은 그들과 계속 일할 수 있습니다. 그렇지 않은 경우 손실 없이 다른 기관에 결과를 가져올 수 있습니다.

에이전시를 운영하거나 프리랜서라면 이것이 나쁜 생각처럼 들릴 수 있습니다. 당연히 전체 프로젝트에 대해 클라이언트를 등록하는 것을 선호할 것입니다. 그러나 클라이언트가 작은 초기 투자에 대해 위험을 감수하고 있다고 느끼지 않았기 때문에 나는 이 접근 방식으로 많은 경쟁 입찰을 피했습니다. 또한, 그들이 나를 좋아하지 않으면 쉽게 전환 할 수 있기 때문에 다양한 공급 업체와 이야기 할 필요를 느끼지 않았습니다.

또한 이 단계적 접근 방식을 사용하면 다음 고정 가격 프로젝트의 범위를 지정하고 가격을 책정하는 것이 훨씬 쉬워집니다. 물론, 마술처럼 추정치를 제공하거나 범위 이동을 방지하지는 않습니다. 그러나 한 번에 한 부분만 범위를 지정하기 때문에 추정을 더 쉽게 관리할 수 있습니다. 또한 스코프 크립을 억제하는 대신 스코프 크립으로 작업할 수 있습니다.

따라서 사내에서든 외부에서든, 크든 작든 상관없이 제 조언은 프로젝트를 단계로 나누지 않고 프로젝트를 추정하고 범위를 지정하려는 시도를 중단하라는 것입니다. 대신 한 번에 한 단계를 수행하고 배운 내용을 사용하여 다음 단계를 알립니다 . 그렇게 하면 더 정확하게 추정하고 학습한 내용을 기반으로 적응할 수 있는 여지가 있으며 프로젝트 관리가 더 간단하다는 것을 알게 될 것입니다.