프로젝트 관리에는 정답이 없다.

프로젝트 관리에 답은 없다고 생각한다. 프로그램가 원하는 목표를 달성하면 된다.

그럼 어떻게 관리할 것인가? 원칙의 문제일 것이다. 사실 사람이 핵심인데, 이 이야기는 다음에 언급하고,
일단 프로젝트 관리의 원칙적인 얘기들을 하려고 한다. 

- 일정관리, 범위 관리, 원가 관리, 품질 관리, 인력 관리, 의사소통 관리, 위험 관리

이러한 것들을 관리해야 한다.

일정 관리는 기본이다. 언제까지 일을 마쳐서 납품을 해야 한다는 것이다. 일정은 어떻게 알 수 있을까? 해보지 않은 일을 얼마가 걸지 사실 예측이 어려운 것이다. 프로그램을 개발하는 일정에는 함정이 있다. 보통 개발 일정을 잡으라고 하면 코딩 시간으로 착각을 한다.

개발자들은 대개 그렇다. 매니저는 그렇게 생각하면 안된다. 그리고 스튜던트 효과가 있다. 먼저 왜 개발기간이 코딩 기간과 다른지 이야기다. 코딩은 해당 기능을 구현하는 시간이다. 하지만 대개 이 시간에 기획, 분석, 설계, 테스트가 빠져 있다. 물론 약간의 테스트, 개발자들이 할 수 있는 기능에 대한 최소한의 테스트를 생각한다. 하지만 통합 테스트, 성능까지 고려된 테스트까지 고려하지 않는다. 하지만 개발 완성도를 보는 입장에서 또는 운영을 하려는 상황에서는 완벽해야 한다. 그런데, 자신의 능력을 과신한 탓인지, 아니면 과욕인지, 길게 이야기 하는 것이 눈치보여서인지 어떤 경우는 굉장히 짧은 시간을 말을 한다. 자신이 짧은 시간에 개발할 수 있다는 것을 어필하고 싶을 수도 있을 것이다. 하지만 그리고 나서 개발을 부랴부랴 하고 테스트 하고, 오픈을 하고 나면 버그가 발생되고, 오류가 발생하고 장애가 나고 그렇게 몇번 아프다 보면 아차 싶다. 그 뒤로는 일주일 걸릴 것을 2주일 걸린다고 하고, 막연히 길게 얘기를 한다. 그것 또한 정답은 아니다.

개발자가 누락한 것은 기획,분석,설계,테스트 시간이다. 그래서 코딩 시간은 전체 개발기간의 20%라는 이야기를 한다. 이 이야기만 들으면 오바라고 할 것이다. 그리고 그럴 시간 없다고 할 것이다. 하지만 어떤 기능을 추가하기 위해서 그 기능이 무엇인지 어떻게 들어가야 하는지 등에 대한 기획, 분석은 반드시 필요하고, 개발자들은 잘 못한다. 기획자가 있어야 하거나 일반 유저들의 소리를 들어야 한다. 그리고 테스트를 해서 기존 기능에 영향이 없는지 확인해야 한다. 개발자들은 대게 자신이 개발하고 있는 것에 집중한다.

그리고 한가지 유의 할 것은 스튜던트 효과이다. 일명 시험전날 벼락치기 우리는 그렇게 자라왔다. 미리 미리 하진 않는다. 그렇다 보니 프로젝트 막판에 몰아서 하게 된다. 이것이 사람의 습성인 것을 어떻게 하느냐 싶지만, 기능을 조금더 세분화해서 목표를 짧게 가져가는 것이 좋다. 그래야 성취욕도 생기고, 전체 일정 막판에 하게 되는 리스크도 줄일 수가 있다. 일정 관리에는 도사리는 리스크들이 많다. 중간에 문제가 발생되거나 생각지 못했던 문제들이 발생되기도 한다. 그래서 프로젝트 일정에도 소위 말하는 버퍼가 필요하다. 위험 요소라는 것은 예측할 수 없는 것이기도 하고, 시간을 필요로 하는 것도 있어서 일정은 그렇게 잡는 것이 중요하다. 물론 일정을 넉넉하게 주는 프로젝트는 없기에 일정에는 합리적인 일정 확보를 필요로 한다. 쉽게 말하면 일정을 잡을 때 버퍼 이런식으로 일정 잡는 것은 불가능하다. 일정에는 항시 기획, 상세 기획안 작성, 분석, 설계, 테스트, 테스트도 기능 테스트, 통합 테스트, 성능 테스트 등으로 세분화 해서 일정을 잡아야 한다. 여유 있게 잡으라는 의미가 공백을 두라는 것이 아니라 최대한 세부적으로 일정을 잡되 그 일정에 최대한 맞추면서 위험을 줄이라는 의미이다. 

책처럼 전체를 보기를 원하시면 아래 링크를 클릭하시고 북마크 하셔서 보시면 편리합니다. 

https://wikidocs.net/22339