다음을 통해 공유

초기 프로젝트

  • 아티클

프로젝트 개시라는 초기 단계에서는 프로젝트의 기본 리소스를 준비합니다.

항목 내용

  • 계획 회의

  • 반복 개발

  • 프로젝트가 범위 기반인지 날짜 기반인지 확인

  • 프로젝트 리소스 계획

  • 역할 및 책임 정의

  • 의사 소통 계획 정의

  • 관련자 파악

  • 프로젝트 계획 개요 작성

  • 프로젝트 계획 검토

  • 프로젝트 지원 약속 받기

계획 회의

프로젝트의 초기 단계에서는 일부 관련자와 실무 전문가를 소집하여 프로젝트에 대해 논의하고 제품 계획을 세워야 합니다. 프로젝트의 특성 및 복잡성과 제품 결과물을 기준으로 관련자를 선택해야 합니다.

회의에 소요되는 기간은 프로젝트의 규모와 복잡성에 따라 며칠 또는 몇 주가 될 수 있습니다.

반복 개발

위험 관리에서 중요한 기술은 프로젝트를 반복되는 단위로 계획하는 것이며, 단위는 대개 4-6주입니다. 반복 계획은 프로젝트 팀이 개발하고 테스트할 기능의 목록입니다. 각 기능은 사용자가 해당 제품을 사용하여 수행할 수 있는 작업 또는 그러한 작업의 향상된 변형을 명시합니다. 각 반복이 종료되면 계획된 기능을 시연합니다. 일부 반복이 종료되었을 때는 제한된 소수의 사용자가 시험해 볼 수 있도록 부분적으로 완료된 제품을 릴리스합니다.

시연 및 시험을 통해 얻은 피드백은 계획을 검토하는 데 사용됩니다.

기본적인 사용자 시나리오와 시스템의 주요 구성 요소를 초기 단계에서 간단하게라도 시험하도록 제품 계획을 세웁니다.

대부분의 프로젝트에서 가장 큰 위험 중 하나는 요구 사항을 잘못 이해하는 것입니다. 개발 팀뿐 아니라 최종 사용자와 관련자도 요구 사항을 잘못 이해할 수 있습니다. 새 시스템을 설치하는 경우 비즈니스 활동에 미칠 영향을 예측하기는 어렵습니다.

또한 프로젝트가 진행되는 동안 비즈니스 상황이 변화함으로써 제품 요구 사항이 변경되는 수도 있습니다.

반복적인 프로세스를 사용하면 제품 시연을 통해 요구 사항이 조정되는 경우 많은 양의 재작업을 수행하느라 비용을 낭비하지 않고도 프로젝트가 종료되기 전에 조정된 요구 사항을 구현할 수 있습니다.

또 다른 중요한 위험은 개발 비용을 잘못 예상하는 것입니다. 새로운 분야나 새로운 플랫폼에서 작업하는 개발자는 프로젝트가 시작되기 전에 개발 비용을 정확히 예측하기가 어렵습니다. 특정 구현 전략이 충분한 효과를 발휘할지 여부를 판단하기가 어려운 경우도 있습니다. 그러나 각 반복이 끝날 때마다 계획을 검토하면 팀이 이전 반복에서 얻은 경험을 고려할 수 있습니다. 올바른 제품 계획에서 초기 단계에 모든 주요 구성 요소에 대한 작업 일정을 세우는 이유에는 이러한 이유도 포함됩니다.

프로젝트가 범위 기반인지 날짜 기반인지 확인

일부 프로젝트는 전달되기 전에 모든 요구 사항이 구현되어야 합니다. 소프트웨어 분야에서는 이러한 유형의 프로젝트가 일반적이지 않습니다. 실례로 다리를 건설하는 경우 절반만 완성된 부분은 쓸모가 없습니다. 반면 소프트웨어 프로젝트는 절반만 완료되었더라도 올바르게 계획된 경우에는 배포가 가능하고 제한된 사용자가 사용할 수 있습니다. 그런 다음 몇 번의 업그레이드 과정을 거쳐 증분 방식으로 프로젝트를 완료할 수 있습니다.

먼저 프로젝트가 실제로 범위 기반인지 여부를 확인하십시오. 프로젝트가 범위 기반이면 구체적인 예측과 세부 계획이 준비될 때까지 기다린 후에 종료 날짜를 결정해야 합니다. 이렇게 하려면 비용이 발생합니다. 계획과 관련된 비용이 늘어날 뿐 아니라, 예측이 빗나갈 경우에 대비하여 일정에 여유를 두면 전달 날짜가 연기되므로 비용이 증가합니다. 따라서 범위 기반 프로젝트인지를 판단하려면 아주 신중해야 합니다. 순수한 소프트웨어 제품 또는 서비스 상황보다는 복잡한 시스템 엔지니어링 환경인 경우에 범위 기반 프로젝트일 가능성이 더 높습니다.

대부분의 소프트웨어 프로젝트는 증분식으로 전달할 수 있으므로 날짜 기반입니다. 예를 들어 미국의 연말연시 시즌에 맞춰 컴퓨터 게임을 릴리스하려는 경우 10월까지는 제품이 준비되어야 합니다. 10월에 제품을 전달하지 못하면 할로윈부터 크리스마스까지의 판매에 심각한 영향이 있으며, 일정이 두 달이나 연기되면 기회의 창(Window of Opportunity)도 잃을 수 있습니다.

프로젝트 리소스 계획

프로젝트를 원하는 날짜에 전달할 수 있도록 프로젝트 리소스를 계획해야 합니다. 이전 프로젝트에서 얻은 데이터를 사용하여 어느 정도의 리소스이면 충분한지 검토해야 합니다.

필요한 리소스를 파악한 후에는 프로젝트 팀 구조, 리소스 사용 수준 및 지리적 분포(해당되는 경우)를 명확하게 나타내는 프로젝트 조직도를 만듭니다. 모든 리소스 사용 정보는 프로젝트 포털에 저장합니다.

역할 및 책임 정의

각 프로젝트 역할과 해당 역할의 책임을 기술하고 이를 프로젝트 계획에 공개합니다. 각 프로젝트 참가자는 프로젝트에서 자신이 맡은 역할과 책임을 파악해야 합니다.

의사 소통 계획 정의

프로젝트의 의사 소통 계획을 정의하는 것은 중요합니다. 의사 소통 경로는 프로젝트의 조정 비용을 관리하는 데 도움이 됩니다. 회의에 참석해야 하는 사람, 회의 소집 빈도, 의사 소통 경로, 그리고 한 번의 회의에서 일반적인 참석자가 해결할 수 없는 문제를 상위 단계로 올리는 방법을 정의해야 합니다.

올바른 의사 소통 계획의 목표는 프로젝트에서의 조정 활동이 가능한 한 원활하게 이루어지도록 하고 의사 소통의 문제로 불필요한 낭비가 발생하지 않도록 하는 것입니다.

의사 소통 계획은 프로젝트 포털에 게시하고 필요할 때 적절히 관리해야 합니다. 의사 소통 계획은 새 멤버를 비롯하여 모든 참가자에게 유용한 도구입니다. 의사 소통 계획을 통해 팀의 작업 방식뿐 아니라 다양한 목적에 따라 다양한 팀 멤버와 다양한 방식으로 적절하게 의사 소통함으로써 작업을 완료하는 방법을 쉽게 파악할 수 있습니다.

관련자 파악

관계가 있는 모든 프로젝트 관련자를 파악해야 합니다. 핵심 팀 멤버뿐 아니라, 프로젝트의 성공적인 구현이나 제품 출시 후의 파급 효과에 이해 관계를 같이 하는 비즈니스 및 기술 관련자도 목록에 포함해야 합니다. 이러한 관련자는 소프트웨어 엔지니어링 활동의 상위 부분이나 하위 부분에 관계가 있을 수 있습니다.

프로젝트 계획 개요 작성

첫 번째 프로젝트 계획의 초안을 만들어야 합니다. 이 초안은 개발이 시작될 때 수정할 수 있습니다. 이 초안 계획은 프로젝트 스폰서와 리소스 및 기간에 대해 논의하는 데 유용합니다. 초안 계획에는 주요 기능 및 예상 전달 날짜를 요약해야 합니다. 자세한 내용은 프로젝트 계획(CMMI)을 참조하십시오.

프로젝트 계획 검토

프로젝트 계획의 개요를 프로젝트 포털에 게시합니다. 계획을 짜는 데 많은 노력이 소요되었지만, 아직은 여러 세부 일정이 결정되지 않은 개략적인 수준의 계획일 뿐입니다. 이는 의도적인 것입니다. 계획이 지나치게 자세하면 나중에 시간이나 노력이 낭비될 수 있습니다.

요구 사항이 확실하지 않은 경우에는 개요 수준으로만 계획을 세우고 보다 많은 정보를 얻을 때까지 세부적인 계획은 미뤄야 합니다. 또한 이러한 정보를 구할 계획을 세워야 합니다.

모든 관련자와의 검토 회의 일정을 세웁니다. 이러한 유형의 활동에는 항상 대면 회의가 가장 적합합니다. 전체적인 내용을 검토하고 반대 의견을 들을 수 있도록 충분한 시간을 검토 회의에 할애해야 합니다.

프로젝트 지원 약속 받기

프로젝트 계획에 대한 프로젝트 관련자와의 합의에 이르면 각 관련자로부터 프로젝트 계획에 동의한다는 약속을 받습니다.

약속 사항을 모아 그 세부 내용을 프로젝트 포털에 보관합니다.

추가 리소스

자세한 내용은 다음 웹 리소스를 참조하십시오.