# 프로젝트의 정의
📝 프로젝트란?
제한된 시간 안에 한정된 자원으로 달성하고자 하는 목표를 완수하는 작업을 프로젝트라 한다.
▶ 김 대리가 다음 달 10일까지 완성해야 하는 일정관리 프로그램도 프로젝트라고 할 수 있다.
김 대리가 혼자 작업해야 하는 것은 투입할 수 있는 자원이 사람 한 명이라는 얘기다.
다음달 10일이 제한된 시간이고, 일정관리 프로그램 개발이 목표하는 범위라 할 수 있다.
이제 좀 더 전문적인 용어를 사용해 프로젝트를 알아보자.
첫 번째 - 유일성
프로젝트 결과물은 이전 다른 프로젝트와 똑같은 결과물이 나올 수 없는 유일한 것이다. 김대리가 만들고자 하는 일정관리 프로그램 또는 이전에 똑같은 목표를 가지고 똑같은 결과물을 만들어낸 사례가 없다. 만일 있었다면 복사나 구매해서 사용하지 프로젝트와 같은 복잡한 과정을 거쳐 새로 만들 필요가 없다.
두 번째 - 일시성
프로젝트는 시작과 끝이 분명한 특성이 있다. 일정관리 프로그램 또한 오늘부터 다음 달 10일 까지라는 정해진 기한을 가지고 있으며 이를 지키지 못할 때 불이익을 받는다.
세 번째 - 목적성
프로젝트는 반드시 달성하고자 하는 목적이 있다. 김 대리가 만드는 일정관리 프로그램 또한 직원의 일정관리를 편하게 돕고 전사적으로 통합 관리한다는 목적이 있다.
네 번째 - 점진적 상세화
프로젝트는 처음에는 추상적이었다가 시간이 지나면서 점차 구체화되는 특징을 가지고 있다. 일정관리 프로그램 또한 처음에는 머릿속에 대충 이런 기능이 있으면 좋겠구나 하는 생각만 가지고 있다가 기획과 설계 단계를 거치면서 하나씩 구체화 된다.
⁉️ 소프트웨어 개발 프로젝트 관리가 어려운 이유
소프트웨어 개발 프로젝트는 실체가 없고 무형의 생각을 실무로 구현해야 한다는 점과 실물이 없어서 요구사항이 자주 변경된다는 점에서 어려운 프로젝트라 할 수 있다.
이와 같은 이유로 소프트웨어 프로젝트 관리 기법은 정교하게 발달해 왔지만, 아직도 소프트웨어 프로젝트 효율적으로 관리하기는 쉬운 일이 아니다.
# 프로젝트 생명주기
프로젝트는 발주사에서 '프로젝트 기획서'라는 기업 내부 문서를 작성하면서 시작한다. 이 문서의 목적은 '왜' 프로젝트를 해야 하는지 경영진을 설득하는 것이다.
그다음 제안 요청서를 작성해서 해당 분야의 전문업체들에 발주사가 원하는 바가 무엇이며 얼마의 금액을 지급할지 알려준다. 제안사는 제안 요청서를 보고 자신이 프로젝트를 어떻게 수행할지 알려주는 제안서를 발주사에 제출한다. 발주사는 자신들의 목적에 맞게 합리적인 가격으로 시스템을 구축할 수 있는 업체를 선정하고 계약을 진행한다.
용 어 | 내 용 |
발주사 | 시스템을 구축하기 위한 프로젝트를 만들어 업체를 선정하고 비용을 지불하는 회사로써 시스템의 실질적 주인이 된다. |
제안사 | 프로젝트를 수주하고자 제안서를 발주사에 제출해서 평가받는 업체 |
수주사 | 제안서를 제출한 제안사 중에서 최종적으로 프로젝트를 수주한 업체 |
프로젝트에 대한 계약이 완료되면 프로젝트 관리를 위한 준비를 하게 된다. 수주사는 이에대한 계획을 '프로젝트 관리 계획서'라는 문서에 담아 발주사에 제출한다. 프로젝트 관리 계획서에는 비용을 어떻게 쓰고 인력관리를 어떻게 할 것이며, 시간을 어떻게 나누어서 관리할지에 대한 상세한 계획이 들어가게 된다.
수주사에서 프로젝트를 본격적으로 진행할 때 가장 먼저 하는 것이 '요구사항 분석'이다. 고객( 발주사 )이 무엇을 원하는지를 제안 요청서, 제안서, 그리고 업무에서 사용하는 문서를 분석하고 고객( 발주사 )과의 인터뷰를 통해 알아낸다.
이제 '프로젝트 설계' 단계로 넘어가는데, 요구사항에 기초해 프로그램을 개발하기 위한 필수적인 프로세스, 인터페이스, 데이터 설계서를 만든다.
프로젝트 개발은 설계서를 기반으로 프로그래머가 프로그램을 코딩하는 단계다. 개발자가 코딩하고 설계짜가 검토하는 과정에서 설계서의 오류가 하나씩 수정되면서 설계써의 품질이 높아지고 프로그램이 하나씩 완성된다.
개발이 완료됐다면 고개( 발주사 )과 함께 프로젝트의 목적에 알맞은 프로그램이 개발되었는지 테스트를 통해 검증한다. 이 단계가 완료되면 프로젝트가 종료되고 수주사에는 비용이 지급된다. 이때 실질적으로 프로젝트는 마무리된다.
다음 단계부터는 엄밀히 말해 프로젝트보다는 시스템 운영이라고 하는 것이 정확하다. 하지만, IT 관련 업무를 위해 프로젝트라는 틀을 사용해서 설명하겠다. 운영 단계에서는 시스템의 안정적인 운영을 위해 기존에 있는 운영 체계( 모니터링, 백업 )와 연결한다. 프로그램은 지속해서 개선되고 추가된다.
최초 개발 후 일정 기간( 5년 정도 )이 지나면 시스템은 점차 노후화되기 시작한다. IT 환경도 변화되고 비즈니스 환경도 바뀌게 된다. 이때 담당자는 시스템을 개선해서 계속 사용할지 아니면 폐기하고 재개발 할지 결정하게 된다.
# 프로젝트에 대해 알아야 하는 이유
▪ 다른 사람 이해하기
프로젝트는 단계별로 다양한 사람들이 참여하고 있다. 이들은 각각의 R&R( Role and Responsibility )을 가지고 있다.
📣 R & R ( Role and Responsibility ) 이란?
공동 업무에서 본인의 책임과 역할을 뜻한다.
R&R 속에 각자의 목표, 위험( Risk ), 책임과 같은 이해관계가 얽혀있다. 프로젝트를 이해한다는 것은 R&R을 이해한다는 것이다.
다른 사람이 어떤 생각을 하고 있고 어느 부분에서 제일 스트레스를 받으며,
상대방이 무엇을 원하는지 알면 진정으로 다른 사람을 이해할 수 있게 된다.
여기에서 다른 사람은 나의 고객이다. 물건을 파는 사람만 고객이 있는 것이 아니라 컴퓨터만 보고 일하는 프로그래머에게도 고객이 있다. 나에게 개발을 의뢰하고 내가 만든 프로그램을 사용하는 사람이 바로 고객이다.
고객은 나를 평가하고, 고객의 평가가 회사에서 나의 위치와 연봉을 결정하게 된다.
▪ 커뮤니케이션 능력 향상
프로젝트 수행과정에서 상대방과 원활한 대화를 하기 위해서는 다양하고 깊이 있는 지식이 필요하다. 먼저 상대방이 무엇을 해야 하고 무엇을 원하는지 알아야 한다. 상대방이 사용하는 용어를 모른다면 계쏙 질문을 해야 하고 그러다 보면 자신이 평가 절하되는 것을 느낄 수 있을 것이다.
도메인 지식은 제안서와 제안 요청서 그리고 인터뷰를 통해 얻을 수 있고, 전문 기술은 보인이 맡은 일을 열심히 하게 되면 자연스레 익을 수 있다. 하지만 R&R과 프로세스, 용어에 대한 이해는 프로젝트와 관련된 오랜 경험 속에서만 얻을 수 있는 것이다.
▪ 넓은 시야 확보
내가 좀 더 가치있는 사람이 되려면 어떻게 해야 할 까? 앞으로 나에게 어떤 업무가 떨어질지, 앞으로 어떤 기술이 필요할지 그리고 상개방이 얘기는 안 하지만 진정으로 원하는 것이 무엇인지, 상대방이 중요한 부분을 놓치고 있는 것은 없는지 이런 것들을 알 수 있어야 한다. 이런 능력이 발현되려면 넓은 시야를 가져야 한다. 넓은 시야를 갖기 위해서는 기업 IT 분야에 어떤 업무가 있고 어떤 일을 하는 지 이해하는 것이 무엇보다 중요하다.
'Planning' 카테고리의 다른 글
[Planning] Data 설계 (2) | 2024.09.08 |
---|