'프로젝트관리론/프로젝트관리'에 해당되는 글 7건

  1. 2012.01.03 기획자에게 힘을 실어주자~ (2)
  2. 2011.10.04 FP(Function Point, 기능점수) 작성 방법에 대하여~ (2)
  3. 2009.01.04 PSA의 원칙과 실천단계
  4. 2008.09.08 위험관리(Risk Management) 프로세스 #2
  5. 2008.09.04 위험관리(Risk Management) 프로세스 #1
  6. 2008.04.02 Visibility에 대하여
  7. 2007.09.27 프로젝트 관리 어떻게 시작할까요?

기획자에게 힘을 실어주자~

|



새해가 밝았습니다. 
올 한해는 모두 소망하는 것들이 이루어지기를 바라겠습니다.

작년의 프로젝트를 정리하고 올 한해의 계획을 세우면서 다시 한번 느낀점이 바로 기획의 부재였습니다.
단순히 이런 아이디어가 좋다라는 것으로 시작해서 개발을 하다 보면
예상하지 못한 이슈들에 부딪히고 결국 흐지부지 되어 버리고 말죠.

누구의 말처럼 새로운 사업을 하는데 있어서 가장 흔한 것이 바로 아이디어가 아닌가 합니다. 
사람들은 자신의 아이디어가 아주 훌륭한 것처럼 이야기 하지만 결국 누구나 다 생각하고 있는 것이 바로 이 아이디어가 아닐런지요?
이런 아이디어를 구체화 하고 실현 가능하도록 만드는 것이 더욱 중요한 부분이라고 봅니다.

그런 측면에서 작년에는 기획이라는 부분의 필요성을 확실히 느꼈습니다. 
현재 기획자들이 경험이 없어서.. 외부의 훌륭한 기획자가 오면 프로젝트가 훨씬 나아지지 않을까 하고 생각도 했습니다.


그런데..
다음 글을 읽으면서 제가 뭔가 근본적인 것부터 잘못 생각하고 있다는 것을 깨달았습니다. 

기획자가 인정하는 기획자 무용론 (http://fredism.com/?p=1129) 

대규모 기업에서는 기획자에게 모든 프로젝트를 총괄하는 Priority가 있다는 겁니다.
그러나 스타트업이나 소규모 기업에서는 기획자에게 이런 권한을 주지 못한다는 것이죠.

생각해 보니 기획자가 첫째로 막히는 부분은 개발자와의 의사소통에 있다고 봅니다. 
저희와 같은 작은 규모의 기업은 개발자가 나이나 경험 등의 측면에서 기획자보다는 상위에 있습니다.
그리고 개발자는 전통적으로 수동적인 입장을 취하는 경우가 많지요.

그러다 보니 기획자가 자신이 생각한 바를 설명하기보다는 개발자의 의견을 듣고 개발이 어렵다고 하면 기획을 수정하게 됩니다.

둘째로 위 글에서처럼 모두 같이 회의하기 때문에 기획자가 만드는 기획안이나 화면구성안이 없어도 프로젝트를 진행하는데 문제가 없고 
또 대표님이나 이사님과 같은 윗분들과의 대화로 이슈를 해결하면서 기획자는 그저 문서나 만드는 작업으로 전략해 버리지 않았나 싶습니다. 

이런 환경이라면 뛰어난 기획자가 온다해도 제 역할을 수행하지 못하고
내부에서는 뛰어난 기획자라면서 별로인데.. 라는 이야기만 듣게 될 확률이 높을 것 같습니다.

올해 성공적인 프로젝트를 위해 기획자의 위상부터 재정립 해봐야겠습니다.
기획, 디자인, 개발, 테스트, 운영, 마케팅에 이르는 전 부분이 어느 하나 중요하지 않은 부분이 없겠지만, 
맨 앞에 있는 기획 부분 부터 차근차근 만들어보려고 합니다.

 





Trackback 1 And Comment 2

FP(Function Point, 기능점수) 작성 방법에 대하여~

|



프로젝트를 수행할 때 규모산정은 꽤 중요한 비중을 차지하고 있습니다. 
프로젝트의 관리를 위한 초기 예측으로 활용되기도 하지만 보다 현실적으로는 프로젝트 비용을 결정하기 위해서 많이 사용이 됩니다. 

프로젝트의 규모 산정은 다음 그림과 같은 방식으로 할 수 있습니다. 

 
주로 소규모의 프로젝트에서는 간단하게 투입인력수 방식인 M/M로 계산을 많이 합니다.
그리고 예전에는 코드 라인수로 계산하는 LOC (Line Of Code) 기법도 종종 사용했지만..
최근에는 대부분 기능점수라 하는 Function Point를 주로 사용하고 있는 현실입니다.

가끔 주변에서 Function Point로 견적을 내달라는 요청을 받기도 합니다.
여기 저기 자료를 찾아봐도 너무 어려운 표현으로만 되어 있어 FP는 일단 어렵다는 느낌을 받는 것 같습니다.
그래서 보다 쉽게 FP(기능점수)의 작성방법에 대해서 설명해 보려고 합니다.

FP (Function Point, 기능점수)란? 
소프트웨어가 가지는 기능의 개수를 기준으로, 그 소프트웨어의 규모를 측정하는 수법이다. 소프트웨어의 개발비용 등을 산정하는 데에 이용된다. 1979년에 IBM사의 A.J.Albrecht이 고안한 방식이다.
FP법이 개발되기 전에는 소프트웨어의 소스코드의 행수(SLOC; Source Line of Code)나 파일크기 등이 소프트웨어 규모의 척도로서 이용되어 왔다. FP법의 등장하고 나서는 보다 객관적이고 정량적인 소프트웨어의 규모를 산출할 수 있게 되었다.
FP의 산출에는, 소프트웨어 내에서 어떠한 처리를 하고 있는지를 추출하고 입출력 등 기능마다 분류하여, 각각을 [펑션](기능)이라고 정의한다.
펑션 마다 레코드 종류의 개수, 데이터 항목의 개수로 부터 펑션의 [복잡함]을 정의하고, 개별 펑션의 평가치를 산출한다.
평가치의 어플리케이션 전체의 합계가 [미조정 펑션포인트]이며, 거기에 소프트웨어의 영향도(상하 35%)를 곱하면 [조정이 끝난 펑션포인트]가 산출된다.
FP법의 보급을 꾀하기 위해 1986년에 국제단체 IFPUG(International Function Point Users Group)이 발족되었다. ISO에서 FP법의 표준화 작업이 진행되고 있다.


FP (기능점수)를 작성해 보자!!


FP를 작성하기 위해서는 여러가지 사항을 고려해야 합니다. 
먼저 아래 정보통신산업진흥원에서 나온 그림을 보시죠~


FP를 위해서 고려해야하는 항목입니다.
여기에서 복잡도 가중치, 또 다음에 고려해야 할 보정계수에 대해서는 일단 고려하지 않으셔도 됩니다.

왜냐하면 FP를 요구하는 대부분의 업체에서 해당 포맷과 적용 데이터를 가지고 있기 때문입니다.
엑셀로 작성된 FP에 여러분들은 기능항목과, 위에 있는 기본적인 데이터를 넣으면 FP 값은 계산되어서 나오게 됩니다.

그러므로 제가 관심을 가지는 부분은 다음과 같습니다.

1) 기능레벨을 추출한다.

FP를 작성하기 위해서 가장 중요한 항목은 FP를 적용할 기능항목들을 추출하는 것입니다.
보통 3단계 레벨로 구성하고 각각의 기능설명을 상세하게 기록합니다. 

2) 내부논리파일(ILF)와 외부연계파일(EIF)를 구분한다. 

대부분의 프로젝트에서는 DB 또는 외부 연동을 진행하게 됩니다. 
그러므로 이러한 항목을 ILF나 EIF로 구분해서 판단해야 합니다. 

개발하고자 하는 시스템에 저장되는 DB나 파일의 경우에는 ILF로 계산하고, 
외부에서 연동을 통해 가져오거나 업데이트 해야하는 항목에 대해서는 EIF로 계산하면 됩니다. 

3) 외부입력(EI), 외부출력(EO), 외부조회(EQ)를 작성한다.

먼저 외부입력(EI)를 살펴보면 보통 이야기하는 CRUD에서 C(create), U(update), D(delete)를 생각하면 쉽습니다. 
즉, 각각의 기능에 대한 입력, 수정, 삭제가 일어나는 회수를 계산해서 적어주시면 됩니다. 

이어서 외부출력(EO)과 외부조회(EQ)를 잘 구분하셔야 합니다. 
외부출력(EO)이라 함은 데이터를 읽어와서 특정 프로세스를 거쳐서 출력되는 항목을 말합니다. 
즉, 내부에서 어떤 처리를 한번 한 다음에 화면에 출력되는 내용이라고 생각하면 됩니다. 

반면에 외부조회(EQ)는 단순히 내부논리파일이나 외부연계파일에서 데이터를 가져와서 그대로 출력하는 경우를 말합니다. 

이러한 숫자들을 모두 계산한 다음, 각각의 기능에 입력하면 대부분의 FP 계산 엑셀파일에서는 자동으로 FP를 계산해 주게 됩니다. 
그리고 보정 계수를 입력하면 되는데, 각각의 항목을 살펴보면 그리 어렵지 않게 입력할 수 있으니 
실제 현업에서 사용하고 있는 FP 엑셀파일을 확보해서 내용을 살펴보시기 바랍니다. 

정보통신산업진흥원에서 제공하는 FP에 대한 문서는 다음과 같이 첨부하니 활용하시기 바랍니다. 
기능점수(Function Point)산정 및 활용 방안.pdf


더 알아보기

CAGR(연평균 성장률)에 대한 정리

연평균 성장률을 계산하는 방법에 대해서 살펴보세요.

투자 수익률 분석 IRR과 NPV

프로젝트 예산 배정 및 수행 검토를 위한 IRR과 NPV에 대해 살펴보세요.


사업 계획의 효율적 관리 린 캔버스

1장의 사업계획서 린 캔버스로 효과적인 사업 계획을 해 보세요.

린 캔버스의 모델이 된 나인 블락스

비즈니스 모델 설계를 위한 nine blocks에 대해서 살펴보시면 좋을 듯 합니다.

기획안 작성 요령

기획안을 만들 때 참고할 수 있는 내용입니다.





Trackback 0 And Comment 2

PSA의 원칙과 실천단계

|




문제를 해결하는 방법이란 글에서 맥킨지 문제 해결의 기술에 대해서 대략적으로 이야기했습니다.
이 책을 기반으로 2009년 새해를 맞이하면서 생각해 볼 점들을 서술하도록 하겠습니다.

현대사회를 살아가면서 정말 필요한 것이 무엇일까요?
책에서는 가장 중요한 것이 논리적 사고 (logical thinking)이라고 합니다.
논리적 사고의 회로를 가지고 있다면, 어떤 상황 어떤 문제도 해처나갈 수 있는 지혜를 얻을 수 있을 것이고
모든 일에 자신감을 가지게 될 겁니다.
여기에 영어와 같은 어학과  IT 기술들을 활용할 수 있는 능력까지 있다면 최고의 인재가 될 수 있을 거라고 하네요.

그렇다면, 사회생활을 하면서 발생하는 수많은 문제점들을 논리적 사고를 이용해서 어떻게 해결할 수 있는지 정리해 보도록 하죠..

PSA(Problem Solving Approach)의 원칙


1. 모든 문제는 해결이 가능하다는 신념을 가진다. 


해결 할 수 없다고 생각하는 순간 몸과 마음은 거기에 따라가게 된다는 겁니다. 자신감이 없다면 어떤 문제도 결코 해결할 수 없는 것이죠..
실제 제가 함께 일한 개발자 중에 일은 잘 못하는 듯 한데 자신감 하나는 충만한 친구가 있었고, 반대로 능력은 괜찮은 듯 한데 부담감을 너무 많이 가지고 내가 할 수 있을까? 걱정부터 하는 친구가 있었습니다.
1~2년이 지난 후, 실제로 둘의 실력차이는 엄청나게 커졌습니다. ^^ (당연히 앞의 친구가 더 많은 능력을 보유하게 되었지요.)

2. 만약에 상황이 이렇게 된다면 어떻게 행동하거나 반응하면 좋은지 생각한다.


흔히 상황이 좋아지면 서로 공을 누가 세웠나를 논하고, 반대의 경우에는 누구에게 벌을 줄 것인지를 생각합니다. 그러나 PSA에 있어서는 상황의 좋고 나쁨에 따라 상벌을 논하기보다는 그 상황을 어떻게 해쳐나갈 수 있는지를 미리 고민해야 한다는 겁니다.

3. 원인과 현상을 혼동하지 말아야 한다.


원인과 현상을 구별하지 못하는 사람은 문제가 너무 많아서 해결하지 못한다는 이야기를 많이 한다고 합니다. 하지만 현상 하나에 일일이 대처한다면 그것이야말로 대책 없는 일이 될 수 있습니다.
즉, 원인을 포착하지 못하면 문제는 절대로 해결될 수 없겠지요..
실제 프로그래밍할 때 간단한 오류 하나 때문에 밤을 지샌적이 있을 겁니다. 이처럼 문제의 원인은 하나인데 여러가지 현상들을 모두 문제라고 생각함으로써 오히려 해법을 어렵게 가져가는 경우가 많이 있을 겁니다.

PSA(Problem Solving Approach)의 실천단계



1. 더해서 100이 되는 질문으로 문제의 원인을 찾는다.


앞에서 원인과 현상을 구별하는 것이 중요하다고 이야기했습니다. 원인을 찾기 위해서는 항상 더해서 100이 되는 질문을 치밀하게 만들어야 한다는 겁니다.

2. 문제의 본질을 찾았으면 가설을 세운다.


1번 질문을 통해 원인의 범위를 좁혀놨다면, 이제 그 원인에 대한 가설을 세워야 합니다. 아직 정말 원인인지 확실히 알지 못하므로 증명을 위해서 가설을 세워보는 겁니다.

3. 가설을 실증하는 데이터를 수집하고 증명한다.


앞에서 세운 가설을 증명하기 위해서 A=B, B=C이면 A=C라는 전이법칙을 사용합니다. 이를 위해 다양한 소스로부터 데이터를 수집하고 증명하는데 활용합니다.

PSA(Problem Solving Approach)의 4가지 프로그램


PSA는 프로세스(흐름)으로 수행하는 것이 바람직합니다.
즉, 첫째 필요한 정보를 구분하고, 둘째 수집된 정보의 의미를 이해하고, 셋째 핵심이 무엇인가를 파악하는 것이 중요합니다. 인터넷이 보편화된 현재에는 정보가 너무 많습니다. 이런 정보 중에서 정말 필요한 것이 무엇이고 그것이 내포하고 있는 핵심이 무엇인지를 파악하는 능력이 중요하다는 것이죠..

이를 위해서 PSA의 네가지 단계를 설명하고 있습니다.

1. 문제를 둘러싸고 있는 주변 환경을 이해


주변 환경을 볼 때는 항상 전체를 본 후 세부적인 내용으로 이해해야 한다고 합니다.
지나치게 세부적인 것 부터 볼 경우, 전체를 이해하지 못하는 경우가 종종 있다고 하네요..

그리고 항상 핵심이 무엇인지를 꼭 염두에 두고 작업을 해야만 성과물의 가치를 높일 수 있습니다.
이것저것 많이 한 것 같은데 핵심이 없다면 아무것도 안한 것과 다를바 없겠죠.

2. 효과적인 정보 수집 방법을 파악


기대의 매니지먼트라는 말이 있다고 합니다. 상대방의 기대 수준을 알면 그보다 높은 수준의 결과물을 만들 수 있게 된다는 것이죠.. 정보를 수집하는데 있어 자신이 여기에서 얻고자 하는 기대치가 무엇인지, 상사가 요구하는 기대치가 무엇인지를 알고 접근하면 좀 더 빠르고 정확하게 정보를 수집할 수 있다는 겁니다.

3. 데이터를 차트로 표현


어른들은 숫자를 좋아합니다. 즉, 숫자를 이용하면 설득력을 높일 수 있게 됩니다.
이런 숫자를 차트화 한다면 좀 더 이해력을 높일 수 있을 것입니다.

이런 차트를 작성할 때 알아 두어야 할 9가지 포인트를 정리합니다.
- 간단하고 알기 쉽고 보기 좋을 것
- 1차트에 1가지 메시지만
- 메시지와 차트가 일치하고 있을 것
- 항목은 5가지 이내로 압축하고 중요도가 낮은것은 '기타'에 넣을 것
- 항목의 순서를 고려하여 배열하고 중요한 것은 강조 처리할 것
- 사용하는 데이터의 기간을 일정한 간격으로 할 것
- 데이터의 연도와 단위를 명확히 할 것
- 보충 정보로 주의 사항이나 출처를 정확하게 기재할 것
- 마지막으로 완성품인지 아닌지를 확인할 것

4. 프레임워크를 통해 생각


문제 해결을 하는데 있어 안좋은 습관이 예단을 가지고 사물과 현상을 파악하고 예단을 가지고 정보를 취사 선택하며, 그리고 사물과 현상을 해석하는 것이라고 합니다.
이런 버릇을 없애고 사물과 현상을 객관적으로 이해하는 것을 도와주는 것이 프레임워크라는 겁니다.

프레임워크에 대해서는 다음에 다시 논의하도록 하겠습니다.

이상으로 PSA에 대해서 정리해봤습니다. ^^
나중에 문제가 발생했을 때, 어떻게 처리해야 할지 기억할 수 있도록 정리해 두는 거네요~

그럼. 제 블로그에 오시는 모든 분들 새해 복 많이 받으세요!!





Trackback 0 And Comment 0

위험관리(Risk Management) 프로세스 #2

|



지난번에 위험(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로 나누고 관리하는 형태를 취하면 된다고 하네요..

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




Trackback 0 And Comment 0

위험관리(Risk Management) 프로세스 #1

|



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

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

위험관리를 포함한 품질관리와 관련된 규격으로는 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, 위험 정량화에 대해서 추가로 정리하도록 하겠습니다.

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




Trackback 1 And Comment 0

Visibility에 대하여

|



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

웹에서의 visibility(가시성)의 척도는 바로 링크의 개수이다. 당신의 웹페이지로 들어오는 링크가 많으면 많을수록 그것은 가시적이다.
웹에서의 visibility는 매우 중요하죠.. 만약 내 페이지에 대한 링크가 전혀 없다면, 아무도 제 블로그를 찾아오지 않을 테니까요..

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

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

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

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

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

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

사용자 삽입 이미지


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

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




Trackback 0 And Comment 0

프로젝트 관리 어떻게 시작할까요?

|



프로젝트를 진행할 때, 현업에서 사용하는 방법론은 여러가지가 있습니다.
방법론!! 몇몇 사람들 특히 개발자들은 방법론은 쓸데없는 것이고 개발에 전혀 도움이 되지 않는다고 이야기 합니다.
저 역시도 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 책에 있길래 해봤는데.. 나름 괜찮은 것 같더라구요..  *^^*




Trackback 0 And Comment 0
prev | 1 | next