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

  1. 2008.09.29 프로젝트 팀원 역할 어떻게 설정해야 할까요?
  2. 2008.09.15 프로젝트의 성공 요인 분석 #2
  3. 2008.09.15 프로젝트의 성공 요인 분석 #1
  4. 2008.09.04 위험관리(Risk Management) 프로세스 #1
  5. 2008.04.02 Visibility에 대하여
  6. 2007.09.27 프로젝트 관리 어떻게 시작할까요?
  7. 2007.07.12 데드라인 (The Deadline) - 소설로 읽는 프로젝트 관리

프로젝트 팀원 역할 어떻게 설정해야 할까요?

|




프로젝트 관리자가 관리해야 할 항목은 보편적으로 다음의 9가지를 이야기 합니다.
- 품질관리          - 범위관리         - 위기관리          - 통합관리
- 일정관리          - 원가관리         - 인력관리          - 의사결정          - 구매관리

모두 중요합니다만, 프로젝트를 진행하면서 느끼는 점은 결국 사람이 만든 문제는 사람이 해결해야 한다는 점입니다. 즉 인력관리가 가장 복잡하면서도 어렵지 않나 생각합니다.

프로젝트 관리자가 되면, 프로젝트 수행을 위한 팀원을 적든 많든 배정받게 됩니다.
물론 슈퍼맨을 배정받으면 좋겠지만, 대부분은 일반적인 개발자를 만나게 될 겁니다.

이런 경우, 진정한 리더는 팀원들 자체에 신경쓰기 보다는 그 팀원들의 가능성을 식별해야 한다고 합니다.

가능성....

Project Management - A systems approach to Planning, Scheduling, and Controlling이란 책에 보면 프로젝트 관리자가 마주치게 되는 팀원들의 역할을 설명하고 있습니다.

즉, 협력적인 역할을 하는 사람도 있고 반면에 부정적인 역할을 하는 사람도 있다는 것이죠..

부정적인 팀원들의 역할을 방해하고 협력적인 팀원들의 역할을 극대화 시키는 것이 바로 프로젝트 관리자의 중요한 역할이라는 겁니다.

먼저 부정적인 가능성을 가진 팀원들의 성향을 살펴보죠..

 침략자  팀원들을 비판하고 아이디어에 이의를 제기하며 자존심을 꺽는다.
 지배자  조정하고 (업무를) 인수받으려고 시도한다.
 악의 옹호자  모든 사물에서 결점을 찾아내고 모든 아이디어에 이의를 제기한다.
 문제에 대해 갈팡질팡 하는 팀원  아이디어 사이를 왔다 갔다 하며 초점을 맞출 수 없도록 불균형을 조장한다.
 인정을 받아내려는 팀원  항상 지위에 대해 논쟁하고 성공의 공로를 차지하려고 시도한다.
 탈퇴자  참여하지 않고 정보를 공개하지 않는다.
 방해자  계획이 진행되지 않는 것에 대해 여러 가지 이유를 댄다.

이어서 협력적인 가능성을 가진 팀원들을 살펴보면 다음과 같습니다.

 선창자  새로운 아이디어를 찾고 "한번 해보자"란 말을 사용한다.
 정보 탐색자  보다 정보로 무장하려고 노력하고 자원과 지원 데이터를 찾는다. 팀의 이익을 위한 연구를 한다.
 정보 제공자  자신이 알고 있는 것을 공유하여 팀의 지식을 증대시킨다.
 촉진자  다른 사람들의 아이디어에 대해 눈에 보이는 지원을 보여준다.
 분류자  모든 사람이 이슈나 의사결정 사항을 확실히 이해하도록 도와준다.
 조화자  팀 사이의 단결된 감정을 형성한다.
 문지기  모든 정보가 적절하고 팀이 당면하고 있는 이슈에 대해 집중하도록 보증한다.

정리하면서 보니 역시 사람에게는 양면성이라는 것이 존재하는 듯 합니다.
저 역시 문제에 대해 갈팡질팡 하면서 동시에 정보 제공자로서의 역할을 하는 듯 합니다.

결국은 팀원들의 협력적인 가능성을 극대화시키고 부정적인 가능성을 최소화 시킬 수 있는 능력이 필요하다는 것이겠죠..

여러분은 어디에 속하는 팀원이라고 생각하나요?




Trackback 0 And Comment 0

프로젝트의 성공 요인 분석 #2

|



지난 글에서 프로젝트 성공 요인 중 변경관리, 희의관리, 이해관계자, 변화관리에 대해서 살펴봤습니다.
이번에는 이슈화, 리스크관리, 인적자원, 현실과 지표의 괴리에 대해서 알아보겠습니다.

다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다.

5. 사소해 보이는 문제도 '이슈화' 하자

프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다.

이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다.

이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행 모니터링 -> 이슈 종결 내용 공지

이슈가 문제가 되면 리스크(위험)이 됩니다.
그럼에도 불구하고 이슈가 발생할 것 같으면 쉬쉬하고 내부적으로 해결해 보려는 노력을 많이 합니다.
프로젝트에서는 이슈가 언제든지 발생할 수 있습니다. 이런 문제를 내부에서만 조용히 해결하려다 더 큰 문제가 많이 발생할 수 있습니다.
사소한 이슈라도 제대로 파악하고 챙기는 프로젝트 관리자가 되어 보시기 바랍니다.
6. 프로젝트의 조기 경보기 "리스크 관리"

리스크를 프로젝트나 프로젝트 내의 일부분이 정해진 기간 내에 주어진 예산으로 완료되지 못할 위기에 빠질 수 있는 정도나 기대한 성과가 달성되지 못할 가능성이라고 정의하고 있습니다.

프로젝트 특성상 발생할 수 있는 리스크에 대해서 비슷한 프로젝트를 진행한 경험에서 축적된 지식으로 예측할 수 있으며, 이렇게 예측된 리스크를 관리 우선 순위별로 분류해 리스크 관리 체크 항목을 가지고 리스크를 관리해 나갈 수 있다고 합니다.

그래서 미리 막을 수 있는 대응책과 실제 발생했을 때 처리 방법이 있어야 한다고 이야기 합니다.
또한, 지표를 통해 리스크를 지속적으로 모니터링 할 수 있어야 함은 기본사항이구요..

앞에서 리스크/위험 관리에 대해서는 #1, #2로 정리한 내용이 있습니다.
리스크 완화, 회피, 모니터링, 관리에 대해서 이야기 했었습니다.
이런 위험 관리는 모든 프로젝트에서 중요한 요소라고 다시 한번 강조하고 싶네요..

7. 인적 자원의 파악, 가볍게 여기면 큰 코 다친다.

의욕이 앞서 보유한 자원의 총량을 초과해 프로젝트를 수행하다 보면 프로젝트가 제대로 진행되기 어렵습니다.
특히 인적자원은 사람의 수 뿐만 아니라 그 사람이 보유한 역량의 수준까지도 파악해야 한다고 합니다.

또한 아웃소싱에 의존하는 비율도 미리 정한 것을 초과하지 않도록 해야 하는데, 이유는 추후 유지보수나 관리에 문제가 발생할 소지가 있기 때문입니다. 프로젝트의 핵심 업무는 내부 인력으로 처리하는게 바람직하다고 하네요..

프로젝트 뿐만 아니라 모든 일은 결국 사람이 해결할 수 밖에 없다고 봅니다. 프로젝트에 있어서 갑자기 인력이 교체되거나 역량이 부족한 인력으로 수행하게 되면 댱연히 문제가 발생할 수밖에 없을 겁니다.
아웃소싱에 의존하는 업체도 아웃소싱 인력의 능력에 따라 프로젝트의 성패를 맡겨야 하니 불안할 수밖에 없을 거구요..
8. 현실과 지표 사이의 괴리를 메우자

프로젝트를 진행하면서 나오는 몇 % 진행되었다는 숫자에 대한 문제점을 지적하고 있습니다.
산출물 기준으로 진척도를 계산하게 되면 외형은 확인할 수 있지만, 품질은 확인이 곤란하다는 겁니다.
그리고 개발자의 감으로 진척도를 이야기 하면 테스트에 대한 부분이 포함되어 있지 않으며 객관적이지 않은 진행 상황일 수밖에 없다고 합니다.

그래서 전체 진척도와 단계별 진척도를 별도로 관리하고 테스트와 검토 단계의 비중을 높여서 계산해야 한다고 합니다.

어디서 보니까 어른들은 숫자를 참 좋아한다고 합니다. 모든 데이터를 정량화 하는 것은 프로젝트 관리에서도 중요한 작업임에 틀림없습니다.
그러나 그 정량화에는 반드시 현실이 제대로 반영되어 있어야 합니다. 그러기 위해서는 기준이 중요하고, 프로젝트에서도 개발 속도 뿐만 아니라 품질까지도 포함해야 한다는 것이죠..

이상으로 프로젝트의 성공 요인에 대해 정리해봤습니다. 일반적으로 생각하는 부분과 큰 차이가 없어서 정리해봤습니다.

여러분은 어떻게 생각하는지요? 이 외에도 중요한 요소가 있다면 댓글 부탁드립니다.




Trackback 0 And Comment 0

프로젝트의 성공 요인 분석 #1

|



2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다.
4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다.

1. 업무 변경 관리로 프로젝트 성공률을 높이자.

첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다.

방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요
변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요.
단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미리 일정을 반영해서 변경관리를 해야 한다고 합니다.
마지막에 일시에 수행하는 것은 프로젝트가 긴 경우, 업무 변경의 양도 많고 시간도 오래 걸리므로 주의해야 한다고 하네요..

어쨌든 추가 비용이 들더라도 업무 변경 관리는 어떤 형식으로든지 해야 합니다.
보통 프로젝트 수행시에 보면, 마지막에 설계 문서를 한꺼번에 다시 고치는 경우가 가장 많은 것 같습니다.
즉, 프로젝트가 끝난 후에 개발 결과물에 맞추어서 설계문서를 다시 만드는 것인데요..
실질적인 변경관리라고 볼 수는 없다고 봅니다.

정말 성공하는 프로젝트를 만들고 싶다면, 설계를 변경하는 것에 대한 위험성을 고객이나 프로젝트 수행자 모두 인식하고 초기 설계부터 신중을 기해야 할 것입니다.
2. 회의도 관리가 필요한 시대다.

회의로 인해 낭비되는 시간의 가치에 대해서 이야기 하고 있습니다.
회의를 줄이기 위해 단순한 정보 공유는 이메일이나 인트라넷 게시판을 활용하고, 화상회의 같은 것을 충분히 활용하자는 겁니다.

만약 회의를 진행한다면, 미리 회의 목적과 내용을 회의 참석자에게 알리고, 회의의 시작과 끝나는 시간을 정해서 준수하고, 회의 끝 부분에 안건과 결론을 정리하고, 결론이 난 부분을 해당 부서나 팀에 효과적으로 전달해야 한다고 하네요..

회의가 많은 기업은 그리 성공하지 못한다는 이야기를 들은 적이 있습니다.
물론 회의라는 것이 매우 중요한 것이지만 그만큼 잘못 사용하면 탁상공론에 실행이 뒷받침되지 않는 조직이 될 가능성도 높겠죠..
3. 이해관계자를 '내 편'으로 만들어라

이해관계자라 하면 고객과 같은 '프로젝트 스폰서', 프로젝트를 수행하는 '프로젝트 실행자', 프로젝트에는 직접 관여하지는 않지만 영향을 주거나 받을 수 있는 '외부 이해관계자'를 이야기 합니다.

이런 이해관계자를 명확하게 파악하고, 각자의 입장에서 프로젝트 수행에 대한 득실과 주장의 정보를 파악하고, 프로젝트에 대한 영향을 분석하고, 대응전략과 구체적인 실행방안을 세우고, 모니터링 및 피드백을 해야 한다는 겁니다.

여기에서는 주로 외부 이해관계자에 대한 이야기를 하고 있는데요..
저는 일반적으로 IT 프로젝트에 있어서 고객에 초점을 맞추고 싶습니다. 고객이라 하면 외부고객과 내부고객으로 나눠 볼 수 있을 겁니다.
내부에 같이 프로젝트를 진행하는 사람들도 하나의 고객이라고 생각하고 내편으로 만들어 업무를 진행한다면 프로젝트 진행이 좀 더 수월해지지 않을 까 합니다.
4. 프로젝트 연착륙 뒤엔 변화관리가 있다.

여기에서 변화관리는 위의 변경관리와 다른 이야기 입니다. 변경관리가 프로젝트 진행 중에 발생하는 변경 요소를 관리하는 것이라면, 변화관리는 프로젝트 완료 후 새롭게 적용되는 변화에 대한 관리를 말합니다.

프로젝트를 완료하더라도 적용해야 하는 직원들의 새로운 환경이나 제도에 대한 저항을 받을 수 있다고 합니다. 그래서 실행 과정에서 직,간접적으로 영향을 받게 되는 조직원과 고객으로부터 불편을 사게 되면 기대한 만큼의 성과를 내기도 어렵고, 조직원과 이해관계자들한테 성공했다는 평가를 받기 힘들다고 합니다.

변화를 적극 수용하고 변화에 대한 저항을 극복하며, 변화 계획을 세우고 그 계획을 차질 없이 성취해 나가기 위한 변화 관리가 필요하다고 이야기 하고 있습니다.

실제로 어렵게 프로젝트를 통해 결과물을 만들어도 제대로 활용하지 않으면 무용지물일 겁니다.
결국 만드는 것만이 최종 마무리가 아니라 제대로 필요한 곳에 적용하는 것이 성공적인 프로젝트의 마무리가 아닐까 합니다.
이어서 나머지 이슈화, 리스크관리, 인적자원, 현실과지표에 대해서 정리해 보도록 할께요~
프로젝트 관리 알면 알수록 배울게 많은 것 같습니다.




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

데드라인 (The Deadline) - 소설로 읽는 프로젝트 관리

|



데드라인
톰 디마르코 지음, 김덕규, 류미경 옮김/인사이트

"프로젝트 관리" 관련 포스트에서 가끔 인용했던 톰 디마르코(Tom DeMarco)의 '데드라인'을 소개합니다. 


일단, 딱딱한 "프로젝트 관리"를 소설 형식으로 쉽게 이야기하고 있습니다. 

그래서 읽기가 편하고, 내용이 어렵지 않고, 설명도 잘 되어 있습니다.  


물론, "프로젝트 관리"에 초점을 맞추다보니, 소설 내용이 작위적이면서 개연성이 없기는 합니다. 

어차피 재미있는 소설책을 원한게 아니었으므로 큰 문제는 없다고 봅니다. 


각 장(章)의 마지막에 "프로젝트 관리"에서 중요한 내용을 요약한 부분이 있는데, 참고 자료로 활용 가치가 있습니다. 

요약 내용 중 일부를 발췌해서 올립니다. 


모든 일에 변화가 필요합니다. 하지만, 사람들은 변화를 쉽게 받아들이지 않습니다.

그러므로 변화를 수용하기 위해, 고려해야 할 사항을 다음과 같이 설명하고 있습니다.


- 사람들은 안전하다고 느끼지 않는 한 변화를 수용하지 않는다.
- 변화는 프로젝트를 성공시키기 위해서 (그리고 그많한 가치가 있는 대부분의 노력을 위해서도) 필수적이다.
- 안전성이 부족하면 사람들은 위험을 감수하려고 하지 않는다.
- 위험을 피하는 것은 치명적이다. 위험과 연관되어 있는 이점도 놓치기 때문이다.
- 사람들은 직접적으로 위협을 받거나 자신들에게 악용될지도 모르는 권력을 인지할 때 불안함을 느낄 수 있다.


관리자가 반드시 가져야 할 감각―

많이 아는 것보다 직감, 후각, 정신과 같은 감각이 중요하다고 합니다. 

- 관리에는 마음과 본능과 정신 그리고 후각이 필요하다.
- 그러므로
   마음으로 이끌고,
   본능을 믿고(직감을 믿어라),
   조직에 정신을 심어주고,
   거짓말을 식별할 수 있는 후각을 키워라.


"프로젝트 관리"는 프로젝트의 위험을 관리하는 것. 절대 공감…

- 프로젝트의 위험을 관리하는 것으로 프로젝트를 관리한다.
- 각 프로젝트의 위험을 조사하고 관리한다.
- 궁극적으로 바람직하지 않은 결과를 추적하는 것이 아니라 원인이 되는 위험을 추적한다.
- 각 위험에 대한 발생 확률과 예상되는 소요 비용을 평가한다.
- 각 위험에 대해 위험이 구체화되는 것을 나타내는 초기 증상을 예방한다.
- 무엇이든지 '할 수 있다'는 자세를 갖고 일하지 않아도 되는 사람을 위험 담당자로 임명한다.
- 나쁜 소식이 조직의 계층구조 상위로 전달되는 데 용이한 (필요하다면 익명으로) 채널을 수립한다.

가끔 프로세스에 집중하다가 중요한 것을 놓치는 경우가 있습니다. 둘 사이의 균형이 중요하죠..
"눈 앞의 사소한 이익을 추구하다 큰 일을 그르치다."
- 좋은 프로세스와 지속적으로 향상되는 프로세스는 모두 훌륭한 목표가 된다.
- 이들은 또한 매우 당연한 목표이기도 하다. 훌륭한 개발자들은 그렇게 하라고 말을 하든 안 하든 간에 여기에 초점을 맞춘다.
- 공식적인 프로세스 향상 추진 계획은 시간과 돈이 든다. 그러한 프로세스 향상 작업은 프로젝트 작업을 뒤쳐지게 할 것이다. 생산성 향상이 실현된다 하더라도 그 계획을 실행한 프로젝트가 프로세스 향상에 들인 시간을 상쇄하지는 못한다.
- 프로젝트에서 향상 방법을 하나만이라도 제대로 선정한다면 본전(그러한 변화에 투자한 시간과 비용)을 뽑을 수 있을 것이라고 생각한다.
- 프로젝트가 그 기간 동안 하나 이상의 향상 방법을 수용하기를 바라는 것은 무리다. 여러 가지 기술을 한번에 향상시키려는 계획(Multi-skill improvement programs)은 그 계획을 실행하지 않았을 때보다 프로젝트를 더 지연시킨다.
- 표준 프로세스는 사람들이 중요한 지름길로 갈 기회를 놓치게 할 위험성이 있다.
- 특히 인원이 과다하게 투입된 프로젝트의 경우 모든 사람들에게 돌아갈 만큼 일이 충분하지 않다면 문제가 발생하게 된다.

"관리자가 화를 낸다."… 
직원이 무능하기 보다 관리자가 무능한 것이다. 느낌이 확 옵니다. .
- 관리에서 화와 모욕은 전염된다. 상급 관리자가 직원들을 학대하면 그 밑에 있는 관리자들도 그와 같은 행동을 따라한다.(학대받은 아이들이 학대하는 부모가 되는 것과 비슷하다.)
- 관리차원에서 모욕을 주는 일은 사람들이 자신의 능력에 좀더 투자하도록 만드는 자극제 역할을 해야 한다. 그것은 당근과 채찍 두 가지 관리법 중 가장 자주 사용되는 '채찍'인 것이다. 하지만 모욕이 능력을 더 발휘하도록 만든다는 증거가 어디에 있는가?
- 관리자가 직원들을 자극하기 위해 모욕을 주는 것은 직원이 무능하다기보다는 관리자가 무능하다는 표시다.

좋은 프로젝트 관리자, 아니 훌륭한 프로젝트 관리자…

끊임없이 연구하고 공부하는 자세가 필요하지 않을까요.







Trackback 0 And Comment 0
prev | 1 | next