지난해 10 월, 미국의 북동부 지역은 어딜 가나 아셀라 ( Acela ) 광고 천지였다. 아셀라란 암트랙 ( Amtrak ) 이 워싱턴-보스턴간 노선에서 운행할 새로운 초고속 열차의 이름. 끊임없이 쏟아지는 TV 광고와 전광판 광고, 도처에 나붙은 포스터들을 보면서, 누구라도 이 정도의 물량 공세라면 이 새로운 초고속열차 서비스에 대한 수요 창출에 상당히 기여했으리라 생각했을 것이다.
글쎄, 그랬는지도 모르지. 하지만, 정작 암트랙사는 이를 확인해 볼 기회가 없었다. 아셀라 프로젝트가 계속 지연되는 바람에 상용 서비스가 개시되지도 않은 상태에서 광고 캠페인만 진행되고 있었던 것이다. 어떤 회사의 신제품 시판을 한 달 앞두고 이 제품이 우수한 평가 등급을 받자 마케팅 책임자가 했다는 말이 떠오른다. "대단한 홍보 효과야! 이럴 때 시장에 물건만 풀 수 있었으면 얼마나 좋았을까!"
남성 호르몬이 철철 넘치는 게임 업체들은 자사 웹사이트에 "제품 개발이 완료되는 대로" 새로운 게임이 출시될 것이라고 떠들어대기를 좋아한다. 스케줄? 스케줄 같은 건 필요하지 않다. 그들은 폼 나는 게임 개발자들이니까! 하지만, 대부분의 평범한 소프트웨어 업체들에게는 스케줄이 필요하다. 로터스의 경우가 그 좋은 예로, 로터스사가 처음 123 버전 3.0 의 개발을 완료했을 때 이 소프트웨어는 그 당시만 해도 아직 보급 대수가 많지 않던 80286 기종의 컴퓨터를 필요로 했다. 로터스는 제품 출시를 16 개월이나 미뤘고 그 기간 동안 8086 기종의 메모리 한계인 640K 에 맞춰 제품의 용량을 줄였다. 수정된 제품이 완성되었을 때엔 이미 엑셀을 시판중인 마이크로소프트사가 시장에서 16 개월 정도 앞서나가고 있었으며, 이 무슨 가혹한 운명의 장난인지, 8086 기종은 이미 시장에서 폐물 취급을 받고 있었다!
이 글을 쓰고 있는 지금도 넷스케이프의 인터넷 브라우저 5.0 은 경쟁사에 비해 거의
2 년 가까이 뒤쳐져있다. 개발된 코드를 모두 폐기하고 처음부터 코딩을 다시 시작하는 치명적인 실수를 저질렀기 때문이다. 애시톤-테이트, 로터스, 애플사의 MacOS 등도 똑같은 실수를 저지르는 바람에 소프트웨어 역사의 휴지통 ( Recycle-bin ) 속으로 내던져지는 신세가 되고 말았다. 그 사이 넷스케이프사의 웹 브라우저의 시장점유율은 80% 대에서 20% 대로 곤두박질쳤지만 이 회사는 아무것도 할 수 없었다. 주력 소프트웨어 제품이 산산조각으로 분해되어 있는 상태에서는 달리 손을 쓸 수 있는 방도가 없었기 때문이다. 단 한번의 잘못된 결정이 넷스케이프를 자폭시킨 핵폭탄이 된 셈이었다. ( 더 자세한 내용은 Jamie Zawinski 의 글
![[http]](/wiki2/imgs/http.png)
world-famous tantrum 을 참조한다 ).
그래서, 스케줄 관리가 필요한 것이다. 거의 모든 프로그래머들이 하기 싫어하는 일이 바로 스케줄 관리다. 필자의 경험에 따르면, 대다수의 프로그래머들은 어떻게 해서든 스케줄 같은 건 아예 짜지 않고 버텨 보려고 든다. 스케줄을 짜는 극소수의 프로그래머들도 대부분 상사가 하라고 하니까 억지로 하고 있을 뿐, 그 스케줄대로 프로젝트가 진행되리라고 믿는 사람은 그 상사 밖에 없다. 이 상사는 스케줄을 믿는 한편으로, "기한 내에 완료되는 소프트웨어 프로젝트는 없다" 고도 믿으며 또, UFO 의 존재도 믿는 사람이다.
그렇다면, 왜 아무도 스케줄을 만들려 하지 않을까? 주된 이유는 두 가지다. 첫째는 스케줄을 짜고 관리하는 것이 매우 골치 아픈 일이기 때문이고, 두 번째 이유는 아무도 그것이 그만한 수고의 가치가 있는 일이라고 믿지 않기 때문이다. 스케줄이 지켜지지도 않을 거라면 도대체 왜 그런 수고를 해야 한단 말인가? 스케줄이란 애당초 지켜지는 법이 없고 시간이 지날수록 현실과의 괴리는 점점 더 커지기만 하는데, 뭣 하러 그런 헛수고를 한단 말인가?
여기, 정확하게 지켜지는 스케줄을 만드는 간단하고 손쉬운 방법이 있다.
MS Project 같은 거창한 프로그램을 사용하려 들지 말라. MS Project 는 사용자가 종속성의 문제를 해결하기 위해 많은 시간을 할애할 것이라는 가정하에 만들어진 프로그램이다. 종속성이란, 두 가지 작업을 진행해야 하는 상황에서 하나의 선행 작업이 먼저 완료된 후에만 다음 작업을 시작할 수 있는 경우를 말한다. 소프트웨어 프로젝트의 경우, 작업들간의 종속성은 너무나 당연한 것이기 때문에 굳이 수고스럽게 종속성을 추적할 필요가 없다.
MS Project 를 사용하는 경우에 생길 수 있는 또 다른 문제는 이 프로그램을 사용하다 보면 자꾸 스케줄 "균형 조정" 기능을 실행하고 싶어진다는 것이다. 스케줄 균형 조정에는 불가피하게 모든 작업을 재조정하여 다른 사람에게 재할당하는 과정이 포함되는데, 소프트웨어 프로젝트의 경우 이런 재조정은 말이 되지 않는다. 프로그래머들간의 호환이 불가능하기 때문이다. 가령, 리타가 작업한 코드의 버그를 존이 수정하려면 리타 자신이 수정할 때보다 시간이 일곱 배는 더 걸린다. 또, UI 담당 프로그래머에게 WinSock 과 관련된 문제를 해결하라고 시키면, WinSock 프로그래밍에 익숙해지는 데에만 일주일은 걸릴 것이다. 결론은 MS Project 은 소프트웨어 개발 프로젝트보다는 건축 공사 프로젝트에 적합한 프로그램이라는 것이다.
필자가 이용하는 스케줄 포맷은 너무나 단순해서 한번만 봐도 기억할 수 있을 정도다. 열 ( 컬럼 ) 의 개수는 일곱 개면 된다.
개발자가 여러 명인 경우에는 개발자별로 시트를 각기 따로 만들 수도 있고, 아니면 각 작업을 담당하는 개발자의 이름으로 컬럼을 만들 수도 있다.
3) 하나의 기능은 여러개의 작업으로 분해하라. #
여기서, 기능이란 프로그램에 추가되는 맞춤법 검사 기능 같은 것을 말한다. 실제로 맞춤법 검사 기능을 추가하려면, 프로그래머는 여러 단계의 작업을 수행하게 된다. 스케줄을 짤 때 가장 중요한 부분은 바로 이와 같은 구체적인 작업들의 목록을 만드는 것이다. 따라서 다음 규칙을 명심해야 한다.
4) 코딩을 직접 담당할 프로그래머만이 스케줄을 만들 수 있다. #
관리자가 임의로 만든 스케줄을 프로그래머에게 던져주고는 따르라고 말하는 프로젝트는 실패할 수 밖에 없다. 코딩을 직접 담당할 프로그래머만이 그 기능을 구현하기 위해 어떤 작업들이 필요한가를 구체적으로 예측할 수 있고 각 작업에 어느 정도의 시간이 소요될 것인가도 추정할 수 있다.
실효성 있는 스케줄을 만들기 위해 반드시 유념해야 할 부분이다. 작업량은 날짜가 아니라 시간 단위로 계산해야 한다. ( 몇 일, 또는 몇 주 단위로 작업 기간이 계산되어 있는 스케줄은 처음부터 지킬 생각으로 만든 스케줄이 아니다 ). '작업 단위를 더 잘게 쪼개면 더 정밀한 스케줄이 나오겠지' 정도로 생각하는 독자가 있을지도 모른다. 천만의 말씀! 대략적인 작업 개요를 바탕으로 스케줄을 세워보고, 다시 작업 단위를 보다 세분화하여 스케줄을 세워보면, 단순히 더 정밀한 스케줄이 얻어지는 것이 아니라 전혀 다른 결과가 나온다. 완전히 다른 수치가 나오는 것이다. 어째서 이런 일이 생기는 걸까?
작업 단위를 세분화하기 위해서는 실제 코딩 과정에서 구체적으로 어떤 일들을 수행하게 될 것인가를 생각해보지 않으면 안 된다. 서브루틴을 저작하고, 이러저러한 대화상자들을 만들고, wawa 파일을 읽어내고 ... 등등. 이 같은 각각의 단계에 소요되는 시간을 추정하는 것은 어렵지 않다. 프로그래머라면 서브루틴을 저작하고 대화상자를 만들고 wawa 파일을 읽어내는 작업들은 모두 해봤을 것이기 때문이다.
만일 어떤 스케줄이 적당히 얼버무린 "큰 덩어리" 의 작업들로만 ( 가령, "문법 검사 기능 구현하기" 등 ) 채워져 있다면, 이는 프로그래머가 구체적으로 어떤 일들을 하게 될 것인가에 대해 제대로 생각해보지 않았다는 증거다. 그리고, 어떤 일들을 하게 될 것인지 제대로 생각해보지 않았다면, 거기에 어느 정도의 시간이 소요될 것인지도 알 수 없다.
개별 작업에는 어림잡아 2 시간에서 많게는 16 시간 정도까지가 소요된다. 스케줄에 40 시간 ( 1주일 ) 짜리 작업이 포함되어 있다면, 작업 단위를 충분히 세분화하지 않았다는 이야기다.
스케줄을 짤 때 작업 단위를 세분화해야 하는 또 다른 이유는 그런 과정을 통해 해당 기능을 머리 속으로 설계해 보게 된다는 것이다. 만일 "인터넷 통합" 이라는 손 떨리는 기능에 대한 스케줄을 수립하면서 무턱대고 3 주일을 배정했다면 그 프로젝트는 실패할 수 밖에 없다. 구체적으로 어떤 서브루틴들을 만들어내야 할 것인가를 생각해내다 보면, 그 기능을 명확하게 규정하게 된다. 이 같은 단계에서 미리 계획을 세워봄으로써 소프트웨어 프로젝트와 관련된 불안정성을 크게 줄일 수 있다.
6) 최초 추정시간과 현재 추정시간을 지속적으로 추적하라. #
어떤 작업을 처음 스케줄에 추가할 때는 이 작업에 어느 정도의 시간이 소요될 것인가를 추산한 후, 그 결과를 Orig Est ( 최초 추정시간 ) 컬럼과 Curr Est ( 현재 추정시간 ) 컬럼에 모두 입력한다. 시간이 흐름에 따라, 작업 진도가 당초의 예정보다 지연 ( 혹은 단축 ) 되면, 현재 추정시간 컬럼을 필요에 따라 업데이트할 수 있다. 이 같은 방식으로 관리하다 보면, 특정 작업에 필요한 시간을 보다 정확하게 추정하는 방법을 스스로 터득할 수 있다. 대부분의 프로그래머들은 각각의 작업에 어느 정도의 시간이 소요되는지 잘 모른다. 그래도 걱정할 필요는 없다. 스케줄을 지속적으로 관리하고 그에 따라 업데이트하는 한, 결국 스케줄과 프로젝트 완료 시기는 일치하게 된다. ( 최종 납기를 맞추기 위해 일부 기능이나 항목을 잘라버려야만 하는 경우도 생길 수 있지만, 그와 같은 추려내기가 필요한 시점이 언제인가를 일관되게 보여준다는 점에서 스케줄의 정확성은 여전히 유지될 것이다 ). 필자의 경험으로 볼 때, 대부분의 프로그래머들은 일년 정도만 연습하면 스케줄 짜는 데 도사가 된다.
작업이 완료되면, 현재 추정시간 컬럼과 Elapsed ( 경과시간 ) 컬럼의 값이 똑같아지고 Remain ( 잔여시간 ) 컬럼의 값은 0 이 된다.
물론, 스톱워치를 들여다보며 코딩을 진행할 필요는 없다. 퇴근하기 직전에, 혹은 회사에서 밤을 새워가며 일하는 경우라면 책상 밑에 기어들어가 잠깐 눈을 붙이기 직전에, 하루에 한번만 경과시간을 업데이트하면 된다. 8 시간 동안 근무했다고 가정하고 ( 하하! ), 그날 진행한 작업들에 대한 경과시간 필드에 8 시간을 쪼개서 입력한다. 잔여시간 컬럼의 값은 엑셀이 자동으로 계산해 줄 것이다.
그와 동시에, 현재 추정시간 컬럼도 업데이트하여 변화된 현실을 반영한다. 스케줄을 매일 업데이트하는데 걸리는 시간은 고작 2 분정도 밖에 되지 않는다. 그래서 이 방법을 손쉬운 스케줄 관리법이라고 부르는 것이다. 빠르고 간편하기 때문에.
8) 휴가 기간과 휴일 등도 항목에 포함시켜라. #
1 년 정도 진행되는 스케줄이라면, 그 사이에 프로그래머들의 휴가일 수가 대개 10 일에서 15 일 정도 포함될 것이다. 스케줄의 기능 컬럼에는 휴가, 휴일 및 기타 시간을 잡아먹는 모든 것들에 대한 항목이 전부 포함되어야 한다. 잔여시간 컬럼의 값을 모두 더한 후 이를 40 ( 1 주일 ) 으로 나누면, 휴가 등 모든 요소를 포함하여 작업 기간이 총 몇 주일이나 남아있는지를 산출할 수 있고 제품 출시 일자도 계산할 수 있다.
디버깅은 소요시간을 추정하기가 가장 어려운 항목이다. 가장 최근에 작업했던 프로젝트를 떠올려보라. 아마도 코딩 단계에서 소요된 시간의 100% 내지 200% 에 해당하는 시간이 디버깅에 소요되었을 것이다. 스케줄의 기능 컬럼에는 반드시 디버깅 항목이 포함되어야 하며, 아마도 가장 값이 큰 항목이 될 것이다.
스케줄 업데이트 방법은 다음과 같다. 가령, 어떤 개발자가 wawa 파일을 코딩한다고 하자. 처음 스케줄을 짤 때 예상했던 최초 추정시간은 16 시간이었지만, 현재까지 이미 20 시간이 소요되었고 앞으로도 10 시간 정도는 더 걸릴 것으로 예상된다. 이 경우, 개발자는 현재 추정시간 컬럼에 30 을 입력하고 경과시간 컬럼에 20 을 입력하면 된다.
주요 작업 단계가 완료된 후, 모든 항목들의 값들을 더해보니 상당한 수치가 나왔다. 이론상으로 제품 납기를 맞추자면 몇몇 기능을 잘라내 버려야 한다. 이렇게 시간에 쫓길 때 프로그래머들이 가장 먼저 잘라낼 수 있는 기능이 바로 디버깅 항목이다. 다행히도, 처음 스케줄을 짤 때 디버깅 항목에 많은 시간을 할당해 두었으니까.
원칙적으로, 개발자들은 코딩과 동시에 디버깅을 병행해야 한다. 절대로, 수정할 수 있는 버그를 뒤로 미뤄둔 채 새로운 코딩에 착수해서는 안 된다. 미해결 버그의 수는 가능한 한 최소한으로 유지해야 한다. 그 이유는 두 가지다.
- 버그는 코딩 직후에 곧바로 수정하는 것이 가장 수월하다. 한 달쯤 지난 후에 버그를 수정하려고 하면, 정확한 코딩 방식을 기억하지 못하기 때문에 버그 수정도 더 어려워지고 시간도 더 많이 걸릴 수 있다.
- 버그 수정은 과학적 연구와 비슷해서, 언제 새로운 과학적 사실을 발견할 수 있을지 정확히 예측하기 어려운 것처럼 언제 버그를 해결할 수 있을지 정확히 예측하는 것도 쉽지 않다. 수정해야 할 버그가 한 개나 두 개뿐이라면 제품 출시 시기를 예측하는 것은 어렵지 않겠지만, 미해결 버그가 수백 개나 수천 개쯤 되는 경우에는 이것들을 언제 전부 수정할 수 있을지 예측하기란 불가능하다.
그렇다면, 개발자가 코딩 과정에서 버그를 발견할 때마다 곧바로 버그를 수정하는데 왜 디버깅 스케줄을 따로 만들어야 하는가? 프로그래머가 모든 버그를 그때그때 수정한다 하더라도, 작업 단계가 완료되면 불가피하게 버그 수정 과정이 필요하다. 테스트 ( 내부 테스트 및 베타 테스트 ) 단계에서 정말로 어려운 버그들이 발견되기 때문이다.
여러 명의 프로그래머가 함께 작업하는 경우, 프로그래머들 간에 서로 일치되지 않아 조정이 필요한 부분이 생기게 마련이다. 가령, 유사한 기능의 대화상자를 두 명의 프로그래머가 서로 다른 방식으로 구현할 수도 있다. 또, 여러 명의 프로그래머들이 각자 마음대로 추가한 메뉴 항목이나 키보드 단축키, 툴바 등을 누군가는 전체적으로 정리하고 통일 시켜야만 한다. 두 사람이 코드에 체크인하는 순간 컴파일러 에러가 발생할 수도 있다. 이 모든 것들을 수정할 시간이 필요하며, 이는 별도의 기능 항목으로 스케줄에 포함시켜야 한다.
시간은 늘 모자라게 마련이다. 스케줄을 짤 때 고려해야 할 여분의 시간 ( 버퍼 ) 는 두 가지 종류가 있다. 첫째는 당초 추정했던 것보다 시간이 더 많이 걸리는 작업을 고려한 버퍼이고, 둘째는 관리자가 wawa 구현이 너무나도 중요해서 다음 버전으로 미룰 수 없다고 결정하는 경우 등과 같이, 계획에 없이 갑자기 추가된 작업을 고려한 버퍼다.
혹시라도 휴가, 휴일, 디버깅, 통합 시간 및 버퍼 항목 등을 모두 더한 값이 실제 작업 시간을 모두 더한 값보다 더 크다는 사실을 알고는 놀랄 수도 있다. 이런 사실에 놀라는 독자라면 아마 프로그래밍 경력이 아직 그리 길지 않은 개발자일 것이다. 책임질 자신이 있거든, 이런 항목들을 빼버려도 좋다.
12) 절대로 관리자가 프로그래머에게 스케줄 단축을 요구해서는 안된다. #
풋내기 소프트웨어 관리자 중에는 프로그래머들에게 "빡빡한" ( 비현실적으로 짧은 ) 스케줄을 던져주는 방법으로 그들을 "자극" 하여 작업을 보다 빨리 진행시킬 수 있다고 생각하는 사람들이 많다. 필자의 생각으로는 이런 식의 자극은 멍청한 짓일 뿐이다. 필자의 경우, 스케줄에 뒤쳐지면 오히려 좌절감이 생기고 의욕이 저하되며, 스케줄보다 진도가 빠를 때 활기도 생기고 생산성도 높아진다. 관리자는 스케줄을 심리전의 도구로 이용해서는 안 된다.
그럼에도 불구하고, 관리자가 스케줄 단축을 요구하는 경우에는 이렇게 대처하라. 릭의 추정시간 이라는 새로운 컬럼을 하나 더 추가한다 ( 물론, 프로그래머의 이름이 릭이라고 가정하고. ) 프로그래머 자신이 예상하는 추정시간을 이 컬럼에 입력한다. 관리자가 원하는 새로운 스케줄은 현재 추정시간 컬럼에 업데이트 한다. 관리자의 추정시간은 무시하고 작업을 진행하라. 프로젝트가 완료된 후에 누구의 스케줄이 더 현실적이었는지 비교해 보라. 필자의 경험에 따르면, "누구 스케줄이 더 맞는지 한번 볼까요?" 라고 관리자를 위협하는 것만으로도 놀랄만한 효과가 있다. 자칫하면 프로그래머들과 얼마나 느릿느릿 일할 수 있는지 두고 보자는 식의 내기를 하는 꼴이 되고 만다는 사실을 관리자도 깨닫게 될 테니까!
왜 풋내기 관리자들은 프로그래머의 스케줄을 단축하려고 노력하는가?
프로젝트가 처음 시작되면, 기술 관리자들은 비즈니스 담당자들과 회의를 하고는 그들이 약 3 개월 정도 소요될 것으로 생각하는, 하지만 실제로는 9 개월이 걸리는 제품 기능들이 적힌 목록을 만들어 온다. 어떤 작업들을 수행해야 하는가를 구체적으로 생각해 보지 않고 스케줄을 짜는 경우, 항상 실제로는 3n 시간 이상 걸릴 일이 n 시간 정도 걸릴만한 일인 것처럼 보이게 된다. 현실적인 스케줄을 짜다 보면, 모든 작업 시간을 전부 더하게 되고 이 프로젝트가 당초 생각했던 것보다 훨씬 시간이 많이 걸릴 것이라는 사실을 깨닫게 된다. 현실은 가혹한 것이다.
풋내기 관리자들은 이 같은 문제를 해결하기 위해, 사람들이 보다 빨리 일하도록 만들 수 있는 방안을 찾아내려 애쓴다. 하지만, 이런 식의 접근은 그다지 현실적인 방법이 아니다. 작업 인원을 더 늘릴 수는 있겠지만, 그렇더라도 신입 프로그래머들이 작업에 익숙해질 때까지 상당한 시간이 필요하기 때문에 몇 달 정도는 작업 효율이 50% 정도 밖에 되지 않을 것이다 ( 게다가, 그들에게 일을 가르쳐야 하는 사람들의 작업 효율까지 떨어진다 ). 무엇보다, 소프트웨어 업계에서 쓸만한 프로그래머를 새로 뽑자면 6 개월 정도는 시간이 걸린다.
모든 에너지가 일년 안에 100% 소진될 만큼 팀원들을 쥐어짠다면 혹시 일시적으로 코드 산출량이 10% 정도 늘어날지도 모른다. 하지만, 별로 남는 장사는 아니다. 무엇보다, 이것은 배가 고프다고 종자용 옥수수까지 먹어치우는 것과 비슷한 꼴이다.
모든 사람들에게 아무리 피곤하더라도 꾹 참고 초인적으로 열심히 일해달라고 애원한다면 혹시 코드 산출량이 20% 정도 늘어날 수 있을지도 모른다. 하지만, 디버깅 시간은 두 배로 늘어날 것이다. 이야말로 숙명적으로 실패가 예정된 악수 ( 惡手 ) 라 할 수 있다.
하지만, 아무리 해도 절대로 n 을 가지고 3n 을 이룰 수는 없다. 만일 할 수 있다고 믿는 회사가 있다면, 필자에게 이메일로 그 회사의 나스닥 상장기호를 일러주기 바란다. 필자가 그 상장기호를 반으로 줄여줄 테니까.
집짓기 놀이용 나무 블록이 한 꾸러미 있는데 이걸 주어진 상자에 전부 담을 수가 없다면, 방법은 두 가지다. 좀 더 큰 상자를 구해오거나, 아니면 나무 블록 중에서 몇 개는 포기하는 것이다. 6 개월이면 제품을 완성할 수 있을 거라고 생각했었는데 작업을 진행하다 보니 12 개월짜리 스케줄이 됐다면, 제품 출시를 늦추든가 아니면 몇몇 기능을 포기해야 한다. 나무 블록이 작아지게 만들 수는 없으니까. 만일 작아지게 만들 수 있는 것처럼 행동한다면, 이는 지금 눈 앞에 보이는 것에 대해 스스로에게 거짓말을 함으로써 장래를 예측할 수 있는 기회마저 스스로 박탈하는 일이다.
이와 같은 스케줄 관리를 통해 얻을 수 있는 또 다른 부수적 효과는 많은 기능들 중에서 일부를 포기하게끔 만든다는 것이다. 포기하게끔 만드는 것이 왜 좋으냐고? 여기 두 가지의 기능이 있다고 가정하자. 하나는 진짜로 쓸모 있고 장차 제품을 빛내줄 기능이고 ( 예를 들면, 넷스케이프 2.0 의 테이블 기능 ), 또 다른 하나는 코딩하기도 아주 쉽고 프로그래머가 만들어보고 싶어하지만 쓸모는 별로 없는 기능이다 ( 예를 들면, BLINK 태그 ).
스케줄 없이 프로젝트를 진행할 경우, 프로그래머들은 쉽고 재미있는 기능 먼저 코딩하기 시작할 것이다. 그러다가 나중에 시간이 부족하게 되면, 별 수 없이 유용하고 중요한 기능을 포기하게 된다.
프로젝트를 개시하기 전에 미리 스케줄을 수립하는 경우, 무언가를 포기해야만 하는 상황이 되면, 쉽고 재미있는 기능을 포기하고 유용하고 중요한 기능을 작업하게 될 것이다. 스케줄을 관리하다 보면, 버려야 할 기능들을 프로그래머들이 스스로 추려내게 되기 때문에, 보다 나은 기능들로 구성된 강력하고 좋은 제품을 만들 수 있게 된다.
필자가 엑셀 5.0 개발 프로젝트에 참여했을 때의 일이다. 그 당시 우리 팀이 계획했던 기능들이 워낙 방대한 양이었기 때문에 스케줄을 맞출 수가 없게 되었다. 팀원들은 고민했다. 이를 어쩌나! 전부 다 너무나도 중요한 기능들인데. 매크로 편집 마법사는 절대로 포기할 수 없어!
시간이 촉박해지자 별다른 도리가 없었다. 제품 출시 기한을 맞추기 위해 우리 팀은 "자식 같은" 기능들을 잘라내야 했다. 포기하게 된 기능들에 대해 모두 마음 아파했다. 아픔을 달래기 위해 팀원들은 스스로에게 이야기했다. 이 기능들을 포기하는 것이 아니라 그저 조금 더 중요한 기능들을 위해 엑셀 6.0 버전으로 잠시 미뤄두는 것뿐이라고.
엑셀 5 가 거의 다 완성되어갈 무렵, 필자는 동료인 Eric Michelman 과 함께 엑셀 6 버전에 대한 스펙을 만들기 시작했다. 두 사람은 머리를 맞대고 앉아 엑셀 5.0 스케줄을 조정하면서 "엑셀 6" 용으로 미뤄둔 기능들을 다시 살펴보았다. 우리는 그 기능들이라는 것이 너무나 조악한 것들 일색이라는 데 놀라지 않을 수 없었다. 쓸만한 기능이라고는 하나도 없었다. 물론, 그 기능들은 그 다음, 그 다음 버전에서도 제품화되지 않았다. 스케줄을 맞추기 위해 필요한 기능들만 추려낸 것이야말로 우리 팀이 한 일 중에서 가장 잘한 일이었다. 그렇게 하지 않았다면, 엑셀 5.0 의 개발 기간은 두 배쯤 길어졌을 것이고 아무짝에도 쓸모없는 쓰레기 같은 기능들로 50% 가 채워졌을 것이다. ( 넷스케이프 5.0 이나 모질라 ( Mozilla ) 의 경우에도 분명히 이와 같은 상황이 벌어졌을 것이다. 스케줄도 없고, 확정된 기능 목록도 없고, 쓸만한 기능만 추려내는 건 아무도 원치 않고, 그러다 보니 제품을 출시할 수 없게 된 것이다. 그들은 결국 IRC 클라이언트처럼 시간을 들일만한 가치라고는 없는 기능들만 잔뜩 들어있는 제품을 내놓게 될 것이다. )
부록: 엑셀을 이용할 때 알아두어야할 것들
엑셀이 소프트웨어 스케줄 관리에 편리한 제품이라고 주장하는 이유 중의 하나는 대부분의 엑셀 프로그래머들이 오로지 엑셀 하나만 가지고 스케줄을 관리한다는 사실이다 ( what-if 시나리오 같은 것을 분석하는 사람은 별로 없다... 프로그래머들한테 그런 걸 기대하면 안 되지! )
목록 공유: '파일 / 목록 공유' 명령을 이용하면 팀원 모두가 한꺼번에 파일을 열어두고 편집할 수 있다. 팀 전체가 지속적으로 스케줄을 업데이트해야 하기 때문에, 이 기능은 아주 유용하다.
자동 필터: '자동 필터' 기능은 가령, 특정 프로그래머가 자신에게 할당된 작업만 전부 골라서 보고 싶을 때 스케줄을 필터링하는 데 편리하다. '자동 정렬' 기능과 함께 사용하면, 자신에게 할당될 모든 작업을 우선순위에 따라 순서대로 조회할 수 있다. 그 자체로 효과적인 "작업 계획서" 가 되는 것이다. 끝내주지?
피벗 테이블: '피벗 테이블' 기능은 요약정보나 크로스 테이블을 보고 싶을 때 매우 편리하다. 가령, 각각의 우선 순위에 대해, 각 개발자에게 필요한 잔여시간을 보여주는 도표를 만들 수 있다. 피벗 테이블은 결코 어렵지 않다. 반드시 이 기능을 사용하는 데 익숙해져야 한다. 엑셀을 백만 배쯤 편리하게 써먹을 수 있기 때문이다.
작업일 기능: 엑셀의 분석 툴팩에 포함된 작업일 ( Workday ) 기능을 활용하면 각 스케줄에 해당하는 실제 달력상의 날짜를 손쉽게 확인할 수 있다.
