지난번에 위험(risk)의 원인, 식별, 위험관리 프로세스에 대해서 이야기했습니다.

위험이라고 하는 것은 드러나기 전에 처리하는 것이 가장 좋기 때문에 이런 위험 관리가 필요합니다.
실제로 위험이 발생한 이후 처리한다면 프로젝트에 타격도 그만큼 크겠죠..

4. 위험 관리

그래서 이번에는 위험을 관리하는 방법에 대해서 먼저 살펴보도록 할께요..
위험을 관리한다고 해서 모든 위험요소를 제거할 수는 없을 겁니다.
그러나 위험관리를 통해서 위험을 회피하거나 위험요인을 줄이거나 위험 발생시 비상대책을 수립하는데 도움이 될 수 있습니다.
이러한 위험관리에 대해서 정리해 봅니다.

1) 획득 (Procurement)
프로젝트 수행 중에 기술적인 위험요소가 발생한다면, 그런 기술을 가지고 있는 사람이나 조직을 구해서 해결하는 겁니다.
언뜻 보기에는 가장 쉬운 방법 같지만, 실제 프로그래밍에서는 추가 비용이 들어가는 문제가 나올 수 있습니다.
뿐만아니라 프로젝트 참여자가 늘어나면서 발생하는 Communication overhead도 무시할 수는 없을 겁니다.

2) 비상계획 (Contingency Planning)
실제 위험이 발생되었을 때, 위험을 완화하거나 피해를 최소화 하기 위해서 수립하는 계획을 말합니다.
발생 위험의 원인별로 비상 시나리오를 작성하여 위험 발생시 즉각 조치를 취할 수 있도록 하는 것도 포함합니다.

비상조치계획에는 위험항목, 위험정도, 위험발생부위, 비상대책전략, 예상되는 비용, 대책별 추진 담당자, 비상 대책 수행일정 등의 정보를 포함해야 한다고 합니다.

3) 대체 전략 (Alternative Strategies)
예정된 방법이 아닌 다른 방법으로 위험요소를 예방하거나 피하는 방법입니다.
예를 들면, 초기 단계에 위험요소에 대한 설계 변경을 함으로써 구현단계에서 발생할 수 있는 설계위험을 줄이는 것을 들 수 있습니다.

4) 보험 (Insurance)
외주와 같이 외부와 공동 작업을 해야 하는 경우, 발생할 수 있는 위험 요소로 부터 보호받기 위한 건데요..
실제 보험에 드는 걸 말합니다. 요즘은 보증보험증권인가 하는 것을 받기도 하죠..

5) 위험 관리 계획 (Risk Management Plan)
프로젝트 전 과정에서 발생할 수 있는 위험들을 관리하는 절차를 문서화 한 것을 말합니다.
RMMMP(Risk Mitigation, Monitoring and Management Plan)이라는 위험 완화, 모니터링 관리 계획에 포함할 수도 있습니다. RMMM에 대해서는 밑에서 한번 더 정리하도록 하죠..

6) 계약 협정
불명확성이야말로 프로젝트를 실패로 이끄는 지름길입니다.
그래서 이런 불명확성을 계약시에 협의하거나 조건을 부여하는 것을 말하는데요..

글쎄요.. 중소기업의 경우 실제 프로젝트에서 이렇게 할 경우, 계약을 성사시킬 수 있을지 의문이 듭니다.
일정 규모 이상이 되는 기업에서는 제안 단계에서 이런부분에 대해 심의하는 팀이 별도로 있는 걸로 알고 있습니다.

7) 위험관리 및 모니터링
계획만 세워놓고 실제 위험이 발생한 것을 알아차리지 못한다면 아무 소용이 없겠죠..
위험은 초기에 발견하고 해결을 해야 그 피해를 최소화 할 수 있습니다.
그런 의미에서 위험 관리 계획 못지 않게 중요한 것이 위험 모니터링입니다.

또한, 고객의 정책 변경으로 위험요소가 없어져 버리거나 솔루션 업그레이드로 인해 기술적 위험요소가 사라지는 등 초기에 위험요소라고 판단했던 부분이 제거되기도 하므로 모니터링을 통해서 지속적으로 관찰해야 할 겁니다.

5. 위험 완화, 모니터링 및 관리계획(RMMMP - Risk Mitigation, Monitoring and Management Plan)

앞서 설명한 TL 9000에 보면 프로젝트 기획 활동 중에 위험관리 및 우발사건 계획서(Risk Management and Contingency Plan)의 작성을 요구하고 있습니다.
프로젝트 관리자는 이 요구사항을 만족하기 위해서 RMMMP를 작성할 수 있습니다.

RMMMP는 앞에서 이야기한 개념들을 토대로 프로젝트 성향에 따라 적합하게 작성하고, 작성된 계획에 따라 위험관리를 수행하면 됩니다.
실제 프로젝트에서 보면 계획서와 실제 활동이 따로 수행되는 경우가 많은데요..
RMMMP뿐만 아니라 모든 프로젝트 관리 프로세스에서 초기 계획의 수정과 보완으로 지속적으로 활동과 맞춰주는 작업이 필요합니다. (말은 쉽지만, 실제 행동이 어려운 부분이죠.. -.-)

RMMMP에 대한 템플릿이 있어 옮겨봅니다. 참고하시면 도움이 될 듯 하네요..

1.0 서론
    이 부분은 RMMMP의 전체적인 개요를 설명한다.

    1.1 RMMM 활동의 범위 및 정도
        RMMM의 목표, 조직의 책임, 활동의 범위 및 정도를 기술한다.

    1.2 위험관리 조직 역할
        위험관리를 위한 책임을 가지고 있는 사람이나 조직을 기술한다.

2.0 프로젝트 위험들
    이 섹션은 이미 알려진 프로젝트 위험들을 기술한다.

    2.1 위험 테이블
        모든 위험들의 발생 확률 및 영향들을 테이블 형태로 제시한다.
   
        2.1.1 위험 M에 대한 기술
            위험 M을 관련된 조건에 따라 기술한다.

        2.1.2 위험 M에 대한 발생 확률 및 영향
            위험에 대한 발생 확률과 영향도를 기술하며, 각각의 위험을 M개까지 기술한다.

    2.2 위험 정제
        높은 발생 확률의 위험과 높은 영향을 미치는 위험들만을 구분하여 기술한다.

3.0 위험완화, 모니터링 및 관리
    이 섹션은 각각의 위험에 대한 위험 완화, 모니터링 및 경영 활동에 대해 기술한다.

    3.1 위험 M을 위한 완화
        위험을 어떻게 피할 수 있는지를 기술하며, 각각의 위험에 대해 M개까지 기술한다.

    3.2 위험 M을 위한 모니터링
        어떤 조건에서 M이 증가하거나 줄어드는지를 결정하기 위한 모니터링 방법에 대해 기술한다.

    3.3 위험 M을 위한 관리
        위험 M이 발생할 때 어떤 비상조치 계획에 따라 관리할 것인지를 기술한다.

4.0 기타 특수 조건들
    프로젝트에 치명적인 위험을 야기하는 특수한 기타 조건들에 대해 기술한다.

6. 위험 정량화

RMMMP를 보면 중간에 "위험 M에 대한 발생 확률 및 영향"이란 말이 나옵니다.
즉, 위험(Risk)을 정량화 해서 발생 확률이나 영향을 추출해야 한다는 것인데요.
이것을 정량화 하는 것이 그리 쉬운 작업은 아닐 겁니다.
그러나 대략적인 느낌만으로 위험을 감지하는 것보다는 수치화해서 체계적으로 관리하는 것이 바람직 하겠죠..

정량화라고 하는 것이 복잡한 요소가 많아서 빼려다가 그냥 정리해 봅니다.
나중에라도 도움이 되겠죠.. ^^

위험을 정량화 하기 위한 먼저 해야 할 작업은 위험 표를 만들어보는 겁니다.
어떤 위험들이 존재하고, 첫번째 글에서 설명한 어떤 위험인지 분류하고, 위험이 발생할 확률은 어떻게 되고, 어떤 영향을 미치는지 정리해 보는 겁니다.

먼저 예를 보고나서 정리를 하도록 하죠..

분류는 다음과 같습니다.
PS : 프로젝트 크기 위험
ST : 엔지니어의 위험
DE : 개발환경에 대한 위험
BU : 비즈니스의 위험

위험 표에서 영향 부분의 값을 결정하기 위해서 고려해야 할 사항은 다음 세가지 입니다.
위험의 성질 : 위험이 발생할 경우 일어날 수 있는 사건들
위험의 범위 : 위험이 존재하는 전체 구역을 나타내는 범위
위험의 타이밍 : 위험이 언제 얼마 동안 영향을 미치게 될지 고려

그래서 영향 부분의 값을 결정할 때는 1 - 재앙적인, 2 - 심각한, 3 - 별로 중요하지 않은, 4 - 무시할 수 있는 정도로 구분합니다.

위 표를 토대로 위험의 발생확률과 영향에 대한 그래프를 다음과 같이 그려서 위험 관리 포인트를 결정할 수 있습니다.

위험 영향과 확률은 관리 관점에 서로 다른 영향을 줍니다. 큰 영향을 미치더라도 확률이 매우 낮은 위험 인자에 대해서는 많은 관리시간을 소비하지 말아야 한다고 합니다. 그러나 높은 확률에 중간 정도의 영향을 미치는 위험과 낮은 영향력을 갖지만 발생 확률이 높은 위험은 반드시 중점 관리하여야 합니다.

앞의 표를 보면서 어떤 생각이 들었나요?
정량적이라면서 수치를 결정하는 방식에서 기준이 없다고 느끼지 않으셨는지요?

그래서 위험의 발생확률을 결정하기 위한 방법들이 여러가지가 있습니다.
수학 및 통계적 계산 방법을 사용하는 몬테 카를로 기법(Monte Carlo Method)가 있구요..
의사결정을 위한 의사결정 나무 기법(Decision Tree Method)가 있습니다.
이런 방법에 대해서는 나중에 기회가 되면 다시 한번 정리해 보도록 하죠..

좀 쉽게 계산할 수 있는 방법으로는 다음과 같은 공식을 적용할 수도 있다고 합니다.

R = P(h)*P(a)*l

여기서 R은 위험이고, P(h)는 위험의 발생 확률, P(a)는 사고나 손실을 유발하는 위험의 발생 확률, 그리고 l은 손실을 양을 나타냅니다.

아니면 아예 정량적인 방법이 불가능할 경우, 위험 요소를 정성적으로 판단하는 것이 유용하게 사용될 수도 있습니다.
정성적인 방법은 위험 요소에 따라 수치가 아닌 A, B, C, D로 나누고 관리하는 형태를 취하면 된다고 하네요..

이상으로 위험관리에 대해서 대략적으로 정리 해 봤습니다.
도움이 되었는지 모르겠네요~ 앞으로 블로그가 약간 아카데믹해지더라도 이해해 주세요 ^^

프로젝트가 실패하는 가장 큰 요인은 바로 발생할 수 있는 문제점들을 드러내서 함께 논의하지 않고
나중에 해결하면 되겠지... 하는 안일한 생각으로 방치하기 때문이지 않을까 합니다.

그래서 이러한 문제점을 체계적으로 관리할 수 있는 위험관리에 대해서 정리해보려고 합니다.

위험관리를 포함한 품질관리와 관련된 규격으로는 TL 9000이 있습니다.
ISO 9000이란 규격은 많이 들어 보셨을 텐데요..

TL 9000은 ISO 9000에 비해 IT 분야에 특화되어 있고, 품질기획/프로젝트계획/구성관리계획등 계획에 초점을 맞추고 있습니다.
Telecommunication Leader 9000의 약어로 QuEST 포럼에서 ISO 9001을 기반으로 1999년 제정했으며,
IT 분야의 특성에 따라 하드웨어/소프트웨어/서비스 분야로 나누어져 있습니다.

그러나 TL 9000 요구사항에는 구체적인 위험관리에 포함하여야 할 프로세스의 종류에 대해서는 언급하고 있지 않기 때문에 여기에서는 소프트웨어 프로젝트에서 주로 수행하고 있는 위험관리 프로세스에 대해서 정리하도록 하겠습니다.

1. 위험의 원인

먼저 프로젝트를 수행할 때, 이런 위험한 상황들이 왜 발생하는지 살펴보도록 하죠..
가장 많은 경우는 고객 요구 사항의 변경이라고 합니다.
실제로 프로젝트를 요청한 고객 중 그 프로젝트를 제대로 이해하고 있는 고객은 드물다고 생각합니다.
그래서 진행 중에 계속적으로 요구를 변경하거나, 아니면 다른 사이트(대형 포털)와 똑같이 해주세요...
하는 요구들이 많죠..

다음으로는 설계 오류가 있습니다. 개발자가 환경변화나 요구분석을 잘못해서 설계 자체가 자주 바뀌는 경우도 있죠.. 이런 경우는 대부분 부적절한 인력 투입 때문에 발생하기도 하는데요..
심한 경우 프로젝트를 수행하면서 다른 프로젝트와 함께 진행한다던지, 그 프로젝트를 수행하는데 필요한 기술이 부족한 개발자들로 구성된 경우, 아무리 뛰어난 프로젝트 관리자라 해도 난감하겠죠.. -.-

마지막으로는 불분명한 책임과 역할 분담이나 잘못된 예측 및 추정이 있을 겁니다.
관리자의 역량이 필요한 부분이기는 한데, 프로젝트의 규모/복잡성/소요비용/일정등을 잘못 계산해서 프로젝트 기간이 한없이 늘어나는 경우가 종종 있기도 합니다.

2. 위험의 식별

그렇다면 이런 위험을 어떻게 알아낼 수 있을까요?
위험을 식별하기 위한 방법들을 각 분야별로 간략하게 정리해 봅니다.

- 프로젝트 사이즈 위험
프로젝트의 규모를 예측하기 위한 방법으로는 LOC(Line of Code), FP(Fuction Point), COCOMO등이 있는데요. 이런 방법은 프로젝트의 M/M를 계산하기 위해서 주로 사용하죠..
위험관리 측면에서는 이런 사이즈와 더불어 프로젝트 결과물의 사용자 수, 요구사항 변경 회수, 소프트웨어의 재사용등도 살펴봐야 한다고 하네요..

- 비즈니스 영향 위험
비즈니스 측면은 기술적인 측면과는 관점에 있어 차이가 있습니다.
회사의 이익과 프로젝트 결과의 효과, 고객의 니즈, 함께 운용할 시스템 수, 인도 지연에 따른 비용, 결함시 처리에 들어가는 비용등을 고려해야 하죠..

- 고객관련 위험
가장 힘든 부분이 아닐까 합니다. 정말 불량한 고객을 만나면 답답하죠.. -.-
결국 해결책은 대화밖에 없는데, 대화로 이끌어 내기 위한 인간적인 교류도 중요하겠죠..
먼저 고객이 원하는 것을 제대로 이해하고 있는지 파악하는게 중요합니다.
그게 안된다면 고객과 의사소통할 수 있는 채널을 만들고, 회의에 적극적으로 참여하도록 해서 요구사항을 명확하게 하는게 필요하다고 합니다.

- 개발 프로세스 위험
프로젝트는 결국 프로세스입니다. 절차에 따라 진행이 되기 때문이죠..
참여자들이 프로세스를 이해하고, 그에 따라 개발을 진행하는 것이 중요합니다.
프로젝트 형상관리를 문서화를 위한 귀찮은 작업으로 생각하지 않고, 정말 개발에 필요한 단계로 이해하는 것이 중요합니다.
프로젝트 결과가 제품만 있다면 이것은 하나의 프로그램(program)에 불과합니다.
메뉴얼을 비롯한 각종 문서화와 프로세스가 합쳐졌을 때 그 제품이 바로 시스템(system)이 되는 겁니다.

그외에도 프로젝트를 수행할 기술을 가지고 있는지 파악하는 기술 위험, 효율적으로 사용할 수 있는 툴들을 이해하고 있는지에 대한 개발환경 위험,  기술진의 규모와 경험관련 위험 등을 통해 위험을 식별할 수 있습니다.

3. 위험 관리 프로세스

그렇다면, 이렇게 식별한 위험을 관리하는 프로세스는 어떻게 정의되어 있을지 살펴보기로 하죠..
위험관리 프로세스는 다음과 같이 두개의 서브 프로세스로 나누어져 있습니다.

- 위험 평가(Risk Assessment) 프로세스 : 프로젝트에 영향을 미칠 것으로 예상되는 위험 요인의 식별(Risk Identification), 식별된 위험의 분석(Risk Analysis), 위험의 우선순위를 결정(Risk Prioritization)

- 위험 관리(Risk Control) 프로세스 :  위험관리 계획 수립(Risk Management Plan), 발생된 위험의 해결(Risk Resolution)과 위험 요소에 대한 지속적인 모니터링(Risk Monitoring)

이를 도식화 하면 다음과 같습니다.

위에 나와있는 프로세스는 매우 중요한 의미를 가집니다.
앞에서도 설명했듯이 위험 요소를 식별하는 것은 가장 중요한 문제이구요..
이어서 이를 분석해서 발생확률이 높고, 중요성도 높은 것을 결정해야 합니다. 이것이 우선순위겠죠..

그러나 실질적인 위험관리는 위험이 발생했을 때, 처리해야 하는 계획을 수립하고 (아마도 비상계획 - Contingency Plan) 실제로 해결을 해야 할 겁니다. 그를 위해서 계속적인 모니터링이 필요한 거구요..

참고로 위험을 식별해서 발생확률이 100%였다면, 이것은 아주 중요한 위험요소일까요?
보통 프로젝트 관리에서는 이런 경우, 위험요소로 관리하기 보다는 프로젝트의 제약조건(Constraint)로 다루는 것이 낫다고 합니다.

이것을 관리루프로 만들면 다음 그림과 같습니다.

한번에 다 정리하려니 너무 많네요.. -.-
다음에 이어서 위험 관리 방법, RMMM, 위험 정량화에 대해서 추가로 정리하도록 하겠습니다.

프로젝트 관리에 대해서 너무 애자일 부분만 정리하는 듯 해서 당분간은 전통적인 방법들을 정리해 보려고 합니다.

바라바시가 쓴 링크라는 책에서는 웹에서의 visibility에 대해 이야기 하고 있습니다.

웹에서의 visibility(가시성)의 척도는 바로 링크의 개수이다. 당신의 웹페이지로 들어오는 링크가 많으면 많을수록 그것은 가시적이다.

웹에서의 visibility는 매우 중요하죠.. 만약 내 페이지에 대한 링크가 전혀 없다면, 아무도 제 블로그를 찾아오지 않을 테니까요..

다음으로 서점에 가서 책을 살 때 여러분은 어떤 것을 중점적으로 보나요?

물론 상품평이 좋고, 유명한 책을 고르겠죠.. ^^
저의 경우는 글자 크기와 폰트를 봅니다. 책을 읽는데 부담이 없어야 하기 때문이죠..
어떤 분은 그림이나 표가 많은 책을 산다고 합니다. 글로 주절주절 적어놓은 것보다 하나의 그림이 더 많은 이야기를 해주고 있으니까요..

이런 것들이 바로 visibility에 대한 예가 아닐까 합니다.

마지막으로 프로젝트 관리에 있어 visibility에 대해 생각해 봅시다.
프로젝트 관리에 있어 의사소통의 문제를 많이 이야기 합니다.

어떤 문제에 대해 이야기 할 때 서로 다른 것을 상상하고 대화합니다.
고개를 끄떡이며 회의를 끝내고 서로 자신들의 의견이 통과되었다고 확신하죠..
하지만 프로젝트가 마무리 되어 갈때.. 문제제기를 합니다. 이게 아니었다고...

이런 문제에 대해 visibility를 높여서 보여주는 것이 바로 다음 그림입니다.
(예전에 인터넷에서 많이 떠돌던 그림이죠.. )

위 문제를 글로 설명하는 것보다 그림이 훨씬 이해가 빠를 겁니다.
아마도 의사소통의 문제가 발생하는 것도 이런 visibility를 높여서 논의한다면 충분히 해결할 수 있을 거라고 봅니다.

프로젝트 관리에 있어서도 제안 작업을 할 때, 진도를 추적할 때, 산출물을 작성할 때, 이런 visibility를 고려한다면 보다 쉽게 고객에게 설명할 수 있을 거라고 봅니다.

프로젝트를 진행할 때, 현업에서 사용하는 방법론은 여러가지가 있습니다.
방법론!! 몇몇 사람들 특히 개발자들은 방법론은 쓸데없는 것이고 개발에 전혀 도움이 되지 않는다고 이야기 합니다.
저 역시도 RUP, 마르미, 이노베이터 등의 방법론을 토대로 프로젝트를 진행해 본 경험이 있습니다만,
솔직히 방법론이 무용지물이라는 생각을 해본 적이 꽤 있습니다.

이유는 바로 방법론에 맞추어 개발하고 산출물을 만드는 것이 아니라, 프로젝트 완료 시점에 방법론의 산출물을 한꺼번에 작성하거나 초기에 대충 작성해 놓고 나중에 한꺼번에 변경하는 것이 문제가 되는 것이었습니다.
그러다보니 오히려 방법론이 개발팀에 있어서는 짐이 되는 것이죠..

또, 방법론은 모든 프로젝트를 염두에 두고 만들어 놓은 것이므로.. 프로젝트의 특성에 따라 다시 재구성해서 진행할 필요가 있는데도 불구하고... 그냥 지난번에도 이런이런 것을 적용했으니 이번 산출물에도 이것들은 넣어야 해.. 하는 식으로 사용하므로 문제가 되는 것 같습니다.

일단, 제가 현재 사용하고 있는 제 나름대로의 방법론이 아닌 프로젝트 관리를 나열해 보고자 합니다.
물론 SI 프로젝트로서 고객에게 산출물을 제출해야 하는 경우에는 어쩔 수 없이 협의를 통해 방법론에 따른 산출물을 정의하지만.. 이것은 회사 내부 개발이나 저 혼자 개발할 경우.. 주로 사용하는 것입니다.

첫째, CVS와 같은 소스코드 관리는 필수입니다. 이게 없으면.. 소스에 대한 백업이나 통합등 여러가지를 수동으로 처리해야 하는 문제가 발생합니다. 먼저 CVS를 세팅하고 개발팀 전체가 사용할 수 있어야 합니다.
매일 CVS에 업데이터를 해야 하구요.. 프로젝트 관리자의 입장에서 수시로 들어가서 현재 진행상태를 눈으로 확인해 보는 겁니다.
소스코드의 버전관리는 이전 글(http://xmlmanager.tistory.com/6)을 참고하시기 바랍니다.
또한, CVS와 ANT를 이용해 서버에 배치하는 스크립트를 짜서 활용하기도 합니다.

둘째, 간트차트를 이용한 프로젝트 일정관리를 초기부터 합니다. 툴로는 MS Project를 사용하는데요.
여기서 중요한 점은 간트차트를 통한 일정관리를 1주일 단위로 초기에 전체적으로 잡아 놓습니다.
그리고 매주 업데이트 한다는 것입니다.
일정이라는 것이 늦어지는 경우가 많기 때문에 초기 계획시 늦어질 경우에 대한 버퍼도 마련해 두고요..
하지만, 개발팀에 절대 일정을 다그쳐서는 안됩니다. 매일 야근에 날새면서 개발한 것 치고 제대로 된 것이 없거든요.. 다만, 긴장이 풀어졌다는 느낌이 들지 않도록 유지하는게 중요하다고 봅니다. (이게 정말 어려워요.. -.-)

셋째, DB 설계입니다. DB 설계에서는 ER-Win으로 ER 다이어그램을 만들고요.. (logical, physical 두개 다 만듭니다.) CVS에 함께 공유합니다. 개발중에 DB 필드가 변경되는 경우가 종종 있는데요.. 그때는 공유된 다이어그램도 함께 변경하도록 해서.. 다이어그램과 실제 DB와 똑같이 유지시킵니다.
그리고 DB에서 사용하는 상태값들이 있습니다. 이건 메모형태로 ERD에 포함시켜 둡니다.
ER 다이어그램을 그려 놓으면 나중에 DB 관련 문서들을 만들기 편리합니다.

넷째, MiniSpecification이라는 문서를 하나 만듭니다.(MS-Word를 사용하고, 스타일을 적용함다) 초기에는 여기에 구성도, 전체 흐름, 기본 요구사항등을 자유형식으로 정리합니다. 프로젝트 진행 중에는 각 부분에서 비즈니스 로직이 들어갈 경우.. 해당 로직을 여기에도 정리해 놓습니다.
저는 이 스펙 문서를 꽤 중요하게 생각합니다. 추후 유지보수나 여러 측면에서 활용하려고 하는데요..
만약 이것이 없다면 소스코드를 추적해야 하니.. 시간이 더 걸리겠죠..
하지만, 개발자들은 이걸 그리 최신으로 유지하려고 하지 않습니다. 아무래도 소스코드 바꾸고 잊어버리는 경우가 많은 것 같습니다. 그래서 저는 소스를 확인할 때, 제가 직접 이부분을 정리하는 방향으로 하고 있습니다.
어차피 코딩을 안할 경우, 간트챠트 보고.. DB 확인하고.. 스펙 문서 다듬는 것이 기본 작업이 되니까요..

다섯째, 마지막으로 버그나 기능개선을 위한 엑셀 문서를 하나 만듭니다. 개발완료후, 사용할 것인데요..
Debug와 Enhancement 탭으로 나누고요..
우선순위, 수정여부, 수정일, 기록일, 버그재현단계, 예상수행결과, 실제수행결과, 수정처리자, 비고
의 형식으로 정리합니다.
이것 또한 CVS에 올려놓고 누구나 추가, 수정할 수 있도록 하지만.. 역시 제가 주기적으로 내용을 점검합니다.
(버그질라와 같은 것도 생각해 봤는데, 아직 적용하지는 않고 있슴다.)

이상이 프로젝트 관리만 할 때, 제가 하는 방법입니다. 문서는 MS-Project 파일, ERD 파일, Word 파일, Excel 파일 1개가 만들어집니다.
이렇게만 해도 프로젝트 진행을 관리하는데 바쁩니다. ㅋㅋ 그리고 산출물도 운영하는데 전혀 지장이 없을 만큼 충분히 나오지요..

앞으로 해보고 싶은 것은 개발자들에거 본인이 만든 로직에 대한 테스트코드를 생성하라는 주문을 하고 싶습니다. 어떤 프로젝트에서 개발자 부담을 덜어주려고 제가 직접 JUnit을 이용해 해봤는데요.. 거기까지는 힘들더라구요.. 시간이 너무 많이 걸리고.. 해당 개발자가 인터페이스나 메소드를 변경하면.. 따라서 고쳐줘야 하는데.. 관리자가 할 몫은 아니더군요..

아~ 그리고 최근에는 칠판을 하나 추가했습니다.
프로젝트별 "계획", "완료", "이번주"의 내용을 박스안에 간단하게 기록하는데요..
위 문서들을 CVS에 접속해서 직접확인하지 않는 윗사람들을 위해서.. 한눈에 볼 수 있도록 항목만 정리해 놓은 겁니다. XP 책에 있길래 해봤는데.. 나름 괜찮은 것 같더라구요..  *^^*