프로젝트 매니저(PM, Project Manager) : 불안감, 매니지먼트를 불가능하게 하는 것들

'불안하다. 프로젝트의 데드라인은 정해져 있는데 소프트웨어가 일정에 맞게 잘 개발되어가고 있는 건지 모르겠다'

프로젝트가 관리되지 않고, 운에 떠 맡긴 채 진행되어 간다는 느낌이 들어 불안함 가운데 일하게 될 때가 있다. 무엇 때문일까?

데드라인과 요구사항

보통 대규모 국가 기관의 SI 사업을 하면 모든 개발 일정이 고객에 의해 이미 정해져 있다. 개발자는 대게 개발 일정에 선택권을 가지지 못한다. 이와 같은 경우 데드라인 안에 개발을 무사히 마치는 최선의 방법은 완료일정 안에 구현해야하는 전체 요구사항들을 역산하여 일정 계획을 세우는 것이다. 그렇게 해서 시간이 부족하면 사람을 더 투입하거나 개인이 하루 8시간 보다 더 많은 일을, 더 많은 에너지를 투자하여 일 해야한다는 계획을 세우게 된다.

개발자가 개발 기간을 정해서 프로젝트 일정이 정해지는것이 아니라 정해진 데드라인에 개발 기간을 역산한다니... 위 이야기가 약간 슬프게 들리지 않는가? 그러나 사실 이 정도면 훌륭한 팀에서 일하는 것이다. 왜냐하면 무엇을 구현해야하는지, 각 기능이 언제까지 구현되어야 하는지, 그리고 인력이 부족한지까지 관리되고 있기 때문이다.

다음 경우의 팀을 한 번 보자. 이 팀은 프로젝트 시작과 함께 프로젝트의 전체 요구사항을 정리해 두지 않았다. 정해진 데드라인은 똑같은데 구현해야 할 전체 요구사항이 정리되어 있지 않으니 시간 역산이 불가능하다. 초긍정 매니저는 다 잘될거야, 불필요한 문서작업이야, 다 아는 건데 뭘... 쉽게 무작정 긍정적으로 생각하며 프로젝트를 진행해 나간다. 초긍적 매니저 말대로 될 수도 있겠지만 너무나 불안한 배팅을 하는 것과 같다. 대게는 프로젝트 중후반부터 어떤 기능이 생각보다 복잡해서 개발에 시간이 많이 필요하다거나, 구현되지 않은 놓친 요구사항을 깨닫고 야근, 야근, 야근을 하게 될 것이다.

일정계획과 설계

다음은 전체 요구사항이 잘 정리되어 있고 개발일정 까지 잘 역산되어 있는 앞의 팀의 사례에서 한 걸음 더 나아가 보자.

그들은 설계를 거의 하지 않고 코드를 작성하기를 시작했다. 초긍적 매니저는 요새 누가 자세히 설계하고 코드 짜냐며, 애자일 아니냐며, 코드를 작성하기 시작한다. 이 말은 사실 데드라인이 무자비하게(?) 정해져 있는 대규모 SI 사업에는 쉽게 적용되기 힘든 말이다. 개발사에서 주도적으로 서비스를 만드는 작은 규모의 자사 서비스 프로젝트에는 어느정도 어울릴지 모르겠다.

왜냐하면, 요구사항 각각을 구현하기 위해 역산된 일정이 얼마나 지켜질 수 있도록 정확한가는 설계가 얼마나 적절히 잘 되어있냐에 달려있기 때문이다. 요구사항을 어떻게 구현할지 개념 정의부터, 실행 흐름, 실행에 필요한 모듈들, 모듈간의 구조적 관계 등이 잘 식별되어 정의 되어 있으면 요구사항을 구현하는데 진짜 얼마나 시간이 소요될지 꽤 정확하게 예측이 가능하다. 그러나 설계가 전혀 되어 있지 않다면 그 일정은 대게 코딩을 하면서 점차 알게될 것이다. 각각의 기능 개발 일정은 개발 도중에 실시간으로 들락날락 하게될 것이고 거의 관리가 불가능한 수준이 될 것이다.

아마도 이때 부터 글의 처음에 썻던 불안감이 맴돌아 압박 가운데 야근, 야근, 야근이 시작될 것이다.

살인적인 일정

그렇다면 왜 전체 요구사항이 정리되지 않고, 설계도 제대로 되지 않은 채 프로젝트가 진행되어 불안 불안하게 프로젝트를 진행하게 되는 것일까? 대표적인 원인 두 가지를 살펴보도록 하자. (사실 더 다양한 원인이 있을 것이다)

첫 째는 실제 개발에 필요한 시간과 무관하게 고객의 사정에 의해 정해진 무자비한 프로젝트 일정 때문일 것이다. 예를 들면 고객은 개발과 전혀 상관 없이 이 정도 기간이면 좋겠다고 프로젝트 일정을 정하고, 그리고 그 일정에 맞추어 하드웨어를 구매하고 납품되도록 하며, 마지막으로 소프트웨어 개발팀에게 하드웨어가 저 때 들어오니 어쩔 수 없다, 이 일정에 맞추어야 한다고 통보하는 식이 될 수 있다.

둘 째는 앞에 자주 등장한 초긍적 매니저 덕분일 수도 있다. 전체 요구사항을 정의한 문서도 설계도 필요 없고, 적당히 나중에 하면 된다는 마인드, 곧 매니지먼트의 부재는 대형 SI 프로젝트에서는 재앙을 가져올 확률이 높다.

놓치지 말아야 할 것

대형 SI 프로젝트에서 전체 요구사항을 정리해서 관리해 나가는 것, 그리고 전체적인 설계를 적절히 수행하여 각 기능의 구현 예상 일정을 수립할 수 있도록 관리하는 일은 매우 중요한 일이다. (설계를 얼마나 자세히 해야하느냐는 또다른 주제가 될 것 같다) 프로젝트 매니저도, 개발자 스스로도 이 두 가지를 놓쳐서는 안된다.

행복했던 개발의 경험

개발자 3년차 쯤이었던 것 같다. 그때 방산회사에서 .Net 기반 업무 자동화 프로그램 개발을 했는데 요구사항 분석과 화면 설계, 내부 모듈들의 설계를 위한 시간이 생각보다 넉넉히 주어졌다. 요구사항 분석은 액셀 문서에 정리했고, 화면 설계는 PPT로 해서 고객 피드백을 받았고, 내부 모듈 설계는 UML 툴을 사용해 고객과 함께 보며 검토했다. 설계까지 마치고 전체 요구사항들에 대한 개발 예상 일정을 전체 데드라인에서 역산하여 고객에게 공유했다. 그리고 정말 그 일정대로 개발을 마친적이 있다. 무척 놀라운 경험이었는데 하루하루 예상했던 기능을 구현하고 단위 테스트를 끝내며 너무너무너무 행복하게 개발했던 기억이 난다. 그 뒤로 사실 그런 프로젝트를 몇 번 만나지 못했지만 늘 그 때를 떠올리면 행복한 꿈을 꾸는 것 같다.