[칼럼] 개발의 성공률를 높이기 위한 프로젝트 관리

이 글은 데브피아 칼럼 게시판에 있는 김수동님이 작성하신 칼럼입니다.

 

필요한 작업을 정리해 진척을 관리한다.

무엇인가를 개발하는 프로젝트는 공사의 프로젝트와는 근본적으로 다르다. 

공사라면 누군가가 실수를 하지 않는 한 순조롭게 작업이 진행된다. 그런데 개발에서는 예정대로 진행되지 않는 경우가 많다. 

기술적인 문제가 발생해 일부의 작업이 늦어지거나 후속 공정에서 설계의 결점이 발견되어 전 공정으로부터 다시 하거나, 예상외의 상황이 발생하기 쉽기 때문이다. 

도중에 여러가지 문제가 발생하면 최초의 일정대로는 진행되기 어렵다. 따라서, 프로젝트가 실패하지 않게 하기 위새서 여러가지 생각할 필요가 있다.

개발에 있어서의 프로젝트 관리는 기본적으로는 다음과 같은 생각으로 진행한다.

우선은 필요한 작업을 가능한 한 자세하게 밝혀낸다. 잘 사용되는 것은 3단의 계층에서 작업을 규정하는 방법이다.

예를 들어, 국면, 액티버티, 태스크라는 이름을 붙인다.  제1레벨의 국면은 프로젝트 전체를 시간 축으로 따라 분할한 것으로 작업의 큰 단락을 나타낸다.[조사 분석],[개요 설계],[기본 설계],[하부조직의 테스트],[종합 테스트],[시험 운용]등이 같은 것이다.

  어떻게 나눌까는 채용하는 개발 수법에 따라서 다르다. 공통되고 있는 것은 최초 쪽에 분석이나 개요 설계가 있어 마지막 편에 테스트나 실전 운용이 오는 점이다.

제2 레벨의 액티버티는 국면내에서 발생하는 작업의 그룹 나누기라고 생각해도 좋다. [종합 테스트]의 국면이면, [테스트 방법의 개략을 결정]이라고 [테스트 환경의 준비]과 같이  프로젝트의 리더가 관리하기 쉬운 단위로 구분 한다.

무엇보다 섬세한 단위가 제3 레벨의 태스크로 개개의 작업을 나타낸다. 액티버티 마다 태스크를 밝혀내므로 모든 태스크는 어떤 것인가의 액티버티에 속한다.

 

작업의 진척 상태는 태스크의 단위로 관리한다. 각 태스크 마다 소비한 시간을 보고시켜, 종료했는지도 기록한다. 액티버티에 포함되는 태스크가 모두 종료하면 액티버티도 종료하므로 액티버티 단위의 관리도 할 수 있다. 각각의 작업의 기일(종료 예정일)은 기본적으로 액티버티 마다 설정해 태스크에서는 극히 일부에만 설정한다. 매우 간단하게 설명이지만, 이러한 방법으로 관리한다. 수작업으로는 귀찮아서 프로젝트 관리용의 소프트를 이용하는 것이 일반적이다. 다만, 위기 경로를 요구하는 기능 등은 사용하지 않는다. 소프트웨어의 개발에서는 설계나 테스트를 결정할 수 있던 순서로 실시할 뿐 이므로, 각 국면으로 작업이 일정 대로 끝나도록 노력할 수 밖에 없기 때문이다.

그런데 정말로 중요한 것은 작업의 구분 방법은 아니다. 전술과 같은 관리 방법을 이용하면서 프로젝트가 성공하는 궁리를 더하는 것이야말로 프로젝트 관리의 중요한 목적이다. 이하에 대표적인 목적을 5개 소개한다.

 

목적 1： 리스크 회피를 위한 작업을 스케줄에 포함한다

프로젝트 관리의 최대의 목적은 일어날 것 같은 문제를 가능한 한 회피하는 것이다.

예를 들어 기술적으로 미해결의 부분이 있고 그것이 시스템의 성공 여부를 크게 좌우한다면 가능한 한 빨리 해결 방법을 찾아내지 않으면 안 된다. 이런 종류의 중요한 작업은 외보다 우선해 실행해야 한다. 프로젝트 관리의 액티버티로서보다 전의 국면에 삽입해 최적인 담당자를 할당한다.

 

또, 어떤 문제가 발생할까를 검토하는 협의도 프로젝트의 작업으로서 등록한다. 최초의 시점 뿐만이 아니다. 후의 단계에서도 검토할 수 있도록 프로젝트의 도중의 몇 개소인가에도 넣어 둔다.

여기에서도 적절한 사람을 담당자로 지명한다. 스케줄상에서 작업을 명시하면 해결 방법을 요구하거나 검토하는 것은 반드시 실시되고 적절한 시기(대부분은 빠른 시기)에 행해진다.

이와 같이 리스크를 회피하기 위한 작업을 스케줄에 포함하는 것은 프로젝트 관리의 중요한 목적의 하나이다.

 

목적 2： 각 작업 마다 담당자와 기일을 명확하게 나타내 보인다
밝혀낸 전부의 작업에 대해 누가 실시하는지를 할당한다. 담당이 명확하게 정해지면 그 사람이 책임을 가지고 실시할 가능성이 높기 때문이다.

더하고 가능한 한 빨리 일정을 공표하는 것도 중요하다. 참가 멤버 각자에는 복수의 태스크를 할당할 수 있도록  사전에 나타나는 것으로 보다 자유롭게 예정을 짤 수 있다. 액티버티 마다 기일을 결정해 거기에 늦지 않은 한 어떠한 순서로 작업해도 상관없다.

누군가와 관계하는 일만은 상대와 상담하면서 작업을 진행시킨다.

 

목적 3： 작성하는 성과물을 명시한다
설계에서도 테스트에서도 그 내용을 무언가에 기술하지 않으면 끝났다고는 말할 수 없다. 많은 태스크에서는 그 중에 무엇을 만드는지를 명시한다.

기획서나 설계서등의 문서, 프로그램, 테스트용 데이터 등 만들어야 할 성과물의 구체적인 이름을 지정한다. 각 태스크의 담당자는 그 태스크에 할당할 수 있었던 성과물을 작성하는 것이 제일의 목적이 된다.
대표적인 문서에 관해서는 기술 방법을 결정해 그것을 설명한 자료를 준비해야 하는 것이다. 또, 가능한 한 간단하게 만들 수 있는 궁리도 중요하다.

요점만을 기술하면 끝나는 서식으로 한다든가 서식의 템플릿을 준비해 필요한 부분만큼 기술시킨다든가 작성의 수고를 한계까지 줄인다. 서식이 정해져 있고 템플릿이 있으면 꽤 쓰기 쉬울 것이다. 외부에 제출할 필요가 없는 서류는 텍스트 중심의 간단한 것으로 끝마치면 효율적.

 

목적 4： 리뷰나 승인도 작업으로서 포함 시킨다
기획이나 설계의 내용이 적절할지 리뷰를 해 확인하는 것도 중요하다. 어느 부분을 누가 리뷰 하는지 또 누가 승인하는지 프로젝트의 작업으로서 스케줄에 포함하지 않으면 안 된다. 대부분의 케이스에서는 작성한 성과물이 리뷰의 대상이 된다.

또, 중요한 성과물에 관해서 만일 수 있는 리뷰 단계에서 큰 실수가 발견되어 너무 늦으므로 도중의 단계에서 실시하는 미니 리뷰를 넣어 둔다. 이러한 작업을 스케줄안에 짜넣어 명시하면 설계의 질을 높게 유지할 수 있고 설계자 전체(리뷰 하는 측)의 레벨도 향상할 수 있다.

 

목적 5： 개발의 지연이나 비용의 초과등을 발견한다
프로젝트에서는 작업이 예정대로 진행되고 있는지 정기적으로 확인해야 한다. 방법은 2개 있다. 우선 하나는 기일에 이른 액티버티가 실제로 종료하고 있을까를 조사하는 것이다.

늦었을 경우에는 원인을 조사하는 것과 동시에 대책도 실시해야 한다. 또 하나는 태스크 단위로 사용시간을 관찰하는 방법이다.

10시간에 끝날 예정의 태스크에 20시간 이상이나 걸려 종료하고 있지 않으면 중요한 문제가 발생하고 있을 가능성이 있다.

그 태스크를 중점적으로 조사하는 것으로 큰 문제를 빨리 발견할 수 있다. 액티버티의 지연으로 밝혀지는 것보다도 꽤 빨리 찾아낼 수 있는 메리트가 있다.

조금이라도 빨리 발견하면 대책을 강구하는 것은 용이하다. 비용에 관해서도 작업의 진척 상태와 합해 관찰하면 예산을 넘을지를 판단할 수 있다.

리더에게는 개발과 관리의 높은 능력이 필요
이상과 같은 목적을 모두 만족하기 위해서는 개발 전반에 정통하고 있을 필요가 있다. 어디에 문제가 발생할 것 같은가 추측할 수 없으면 우선적으로 실시해야 할 작업을 결정할 수 없다.

또, 전체에 어떤 작업이 있는지를 모르면 프로젝트의 섬세한 스케줄을 세울 수 없다. 게다가 누가 어떤 능력을 가지고 있는지 판단하는데도 기술력이 필요하다. 이것들을 종합 하면 프로젝트를 관리하는 리더에게는 어느 정도의 높은 기술력과 관리 능력의 양쪽 모두가 요구된다. 당연 제대로 한 개발의 경험은 필수다.

경험이 적은 사람에게 프로젝트의 관리를 맡기면 프로젝트를 포기하는 것만으로 볼수 밖에 없다. 프로젝트 리더를 결정할 때 이 점을 충분히 고려할 필요가 있다.

프로젝트 관리에 관해서 목적과 개요를 간단하게 말해 보았다. 관리자의 자기만족이나 기록을 남기기 위해라든지 멋지게 보이기 때문이라고 하는 이유로 프로젝트 관리를 실시하는 것은 아니다.

실패할 수 없는 프로젝트이기 때문에 더욱 어떻게든 개선하려고 시도하고 있는 것이다. 프로젝트 관리란 여러가지 생각를 포함시키면서 리스크의 회피와 설계 품질의 향상을 목표로 하는 도구이며 결과적으로 프로젝트를 성공할수 있는 확률 또한 올라간다. 어려운 개발에서는 이러한 관리 방법이 반드시 필요하다.

 

출처: 개발자 천국을 꿈꾸는 국내 최대의 IT 포탈 DEVPIA