한빛출판네트워크

프로젝트를 진행할 때 가장 먼저 알아야 할 것은 바로 마감 일정입니다. 항상 그런 식으로 생각되죠. 앞에서 본 그림에 △표는 마감일을 뜻합니다.

마감일까지 해야 하는 것은 무엇일까요? 당연히 전부 다 해야 합니다. 일정이란 그런 것입니다. ☆표는 우리의 계획입니다. 계획상으로는 마감일까지 모든 것이 끝나야 합니다. 문제없죠.

하지만 계획대로 진행되지만은 않습니다. 피처를 제대로 배포하지 못하거나 일정이 늦어질 수도 있고 둘 다 일어날 수도 있습니다. 앞의 그림에서 ??표는 이런 상황을 의미합니다. 맙소사! 원했던 것보다는 더 적은 피처를 얻게 되겠네요. 아마 이후에는 모든 피처를 추가하라고 요구받겠죠.

원하는 피처 모두를 얻을 수는 없습니다. 프로젝트를 그대로 두기보다는 현실적으로 관리해봅시다. 프로젝트에 몸만 담지 말고, 직접 방향을 조정해봅시다. 어디로 향하든 말이죠.

최근 참여한 프로젝트에서 제대로 진행되지 않은 일 중 중요한 일이 있었는지 생각해봅시다. 제대로 진행했지만 실제로는 시간만 낭비했던 일은 무엇이었나요? 너무 늦었거나 늦을 뻔했던 적이 있었는지도 생각해봅시다.

소프트웨어 프로젝트가 진행되는 일반 과정

수많은 프로젝트는 활동activity을 기반으로 계획을 세웁니다. 분석(A), 설계(D), 코딩(C), 그리고 마지막으로 테스트(T) 과정을 거칩니다. 이 그림에서 ☆표로 향하는 화살표는 프로젝트의 계획입니다. 꽤 좋아 보입니다. 하지만 분석이 제시간에 끝나도 설계나 코딩이 제시간에 끝난다는 보장은 전혀 없습니다.

소프트웨어를 직접 보기 전까지는 프로젝트 진행 상황을 알 수 없습니다. 코드를 테스트하는 단계가 오면 어떤 일이 일어날까요? 보통 좋은 일은 일어나지 않습니다!

프로젝트에 생긴 문제를 해결하기에는 시간이 너무 짧았나요? 실제로 무슨 일이 일어났는지 더 일찍 알았다면 그것이 정말로 가치가 있었을까요? 그 모든 노력을 떠나 조금의 가치라도 얻을 수 있길 바랐던 적은 없나요?

더 나쁜 것은… 프로젝트가 계획대로 가는 일은 정말 드물다는 것입니다.

마침내 우리는 코드를 살펴보고 테스트할 때가 왔습니다. 그러나 현실은 그리 좋지 않습니다. 예상한 대로 일정은 생각보다 훨씬 늦어졌습니다. 완성된 피처들도 생각보다 더 적네요. 그동안 해왔던 일은 생각만큼 잘 진행되지 않았습니다.

실제로 할 수 있는 것보다 더 많이 요구됐음을 알고 있습니다. 목표를 설정할 때 흔히 일어나는 일입니다. 하지만 우리의 상황을 알게 되고 무언가를 진행하기에 는 이미 때가 늦었음을 깨닫습니다.

경각심을 더 가졌다면 작은 피처들로 구성된 제품을 제때에 배포할 수 있었을지도 모릅니다. 이제 몇 가지 선택지만이 남아있습니다. 하나는 프로젝트 실패를 선언하는 것입니다. 우리의 경력은 큰 타격을 받겠죠. 또는 이대로 끈기를 잃지 않고 느릿느릿 프로젝트를 진행하는 것입니다. 조직이 포기하기 전에 무엇이라도 배포하길 바라면서요. 두 방법 모두 좋지 않습니다. 아니, 정말 안 좋습니다!

상태가 나쁜 소프트웨어를 배포해본 경험이 있나요? 여전히 너무 많은 결함이 있었나요? 소프트웨어를 바꾸기에 너무 어려웠나요? 핵심 피처들을 완성하지 못했나요? 중요한 아이디어가 있는데 추가하기에는 너무 늦은 적은 없었나요?

활동을 기반으로 한 제품은 100kg짜리 돌덩어리 같습니다.

이 돌덩어리 같은 프로젝트는 막바지에 들어서면 비용을 줄일 방법이 거의 없습니다. 요구 명세서에 만들 수 없는 것까지 이미 적었으니까요. 심지어는 절대 완성될 수 없는 것을 위해 설계를 하고 코드를 써 나갔습니다. 모든 작업이 시간만 낭비한 꼴이 됐습니다.

프로젝트를 진행할 때 진실을 알았다면 불필요한 작업은 연기했을 것입니다. 프로젝트를 ‘모 아니면 도’라는 사고방식으로 진행해 왔습니다. 모든 것을 분석하고 설계했습니다. 모든 코드를 써 내려 갔습니다. 그리고 모든 피처를 가질 수 없다는 사실을 너무 늦게 깨달았죠.

모든 피처를 한꺼번에 계획하고 개발하는 일은 모두를 힘들게 합니다. 변경할 시간도 없고, 시간이 있다 하더라도 어떻게 할 도리가 없습니다.

이제부터는 처음부터 여러 배포 일정을 계획하세요. 배포 일정을 여러 번으로 계획하면 가치를 빨리 전달할 수 있고 프로젝트를 관리하기도 쉽습니다. 심지어 그렇게 계획하는 것만으로도 소프트웨어를 더 쉽게 개발할 수 있습니다.

계획, 분석, 그리고 설계와 개발, 테스트 단계 순서로 진행하는 것이 과연 프로젝트를 관리하는 데 도움이 될까요? 원하는 순서대로 조금씩 피처를 추가할 수 있다면 시작부터 그렇게 하는 것이 프로젝트를 더 쉽게 관리할 수 있지 않을까요?

한번 살펴봅시다.

피처 단위로 프로젝트를 진행한다면 더 잘 예측할 수 있습니다.

배포 일정 단위로, 피처 단위로 제품을 배포하는 것이 가치를 더 빨리 전달할 수 있다는 것을 보았습니다. 그렇다면 이런 활동에 필요한 방법을 가이드하고, 프로젝트를 관리하기 위한 능력은 어떻게 길러야 할까요?

그림의 실선은 그동안 해왔던 평범한 프로젝트입니다. 이 프로젝트는 계속 웅얼거리기만 하고 매우 적은 정보만을 전달했습니다. 심지어 그 일정도 늦어졌죠.

하지만 새로운 선(—○—○—)은 실제로 일어나는 일, 가치 있는 피처들을 주기적으로 보여줍니다. 무엇이 일어나는지 바로 알 수 있죠. 소프트웨어를 볼 수 있는것입니다.

눈으로 확인할 수 있는 피처들로 관리하는 것이 훨씬 쉽다는 것이 느껴지나요? 진행 상황에 맞게 프로젝트의 가치를 최대로 끌어낼 수 있을 것 같지 않나요? 위험 요소(risk)면에서는 어떤가요? 제품을 항시 작동하게끔 만들면 프로젝트 위험요소를 평가하거나 줄일 수 있지 않을까요? 시험적인 작은 피처를 추가해 마케팅 위험 요소도 미리 대처할 수 있지 않을까요?

피처 단위 개발은 더 나은 정보, 더 나은 가이드, 더 많은 결과물을 만듭니다. 

피처 단위로 개발할 때는 상황이 나아집니다. 피처 개발이 얼마나 끝났고 얼마나 빨리 진행 중인지 볼 수 있습니다. 주어진 기간에 얼마나 많은 것을 할 수 있을지 더 쉽게 예측할 수도 있습니다.

우리는 다음에 개발할 가장 중요한 피처를 선택해야 합니다. 그리고 원하는 배포 일정에 가장 가능성 있는 제품의 형태를 만들어 나갑니다. 원래 일정보다 더 앞선 날짜라고 해도 말입니다. 심지어 더 나은 아이디어가 생기거나 사용자의 요구가 변경됐을 때는 피처를 변경하거나 새로운 피처를 추가할 수도 있습니다.

프로젝트를 피처 단위 개발로 진행할 때는 현재 어떤 일을 진행하고 있는지 알 수 있습니다. 비즈니스 담당자나 경영진의 요구 사항이 변경돼도 적절하게 대응할 수 있습니다. 이 방법으로 소프트웨어를 개발하기 위해서는 무엇이 필요할까요? 개발하고 싶은 것이 무엇인지조차 이해할 수 없는 상황에서는 어떻게 프로젝트를 계획해야 할까요?