개발 #
개발 단계에서 프로젝트를 구현하는 데 필요한 모든 구성 요소가 조립됩니다. 잠재적인 공급업체 또는 하청업체에 연락하고, 일정을 만들고, 공급품과 도구를 주문하고, 직원들에게 지시하는 등의 작업을 수행합니다. 구현 단계를 시작할 준비가 되면 개발 단계가 완료됩니다. 모든 문제는 실행을 책임지는 사람들을 위해 명확히 해야 합니다.
특정 프로젝트, 특히 소규모 프로젝트에는 공식적인 개발 단계가 필요하지 않을 수 있습니다. 중요한 것은 구현 단계에서 누가, 언제 무엇을 달성해야 하는지가 분명하다는 것입니다.
구현 #
구현 단계에서 프로젝트는 형태를 얻습니다. 이 단계는 프로젝트 결과의 실제 구축을 수반합니다. 프로그래머는 인코딩하고, 디자이너는 시각적 콘텐츠를 만들고, 계약자는 구성하고, 실제 재구성이 발생합니다. 이것은 프로젝트가 막 시작되었다고 생각할 수도 있는 외부인에게 프로젝트가 명확해지는 기간입니다. NS
구현은 ‘실행’ 단계이며 이 기간 동안 추진력을 유지하는 데 중요합니다.
한 경우, 프로젝트 팀은 필수 팀 구성원 중 한 명이 부모가 되어 약 한 달 동안 완전히 사용할 수 없게 될 것이라는 사실을 알지 못했습니다. 그를 교체할 때가 되자 외부 전문가가 호출되어 팀이 중단되는 것을 방지했습니다. 팀은 유지할 수 있었지만 외부 전문 지식이 예산을 상당 부분 차지했습니다.
구현 단계가 끝나면 결과는 정의 단계에서 설정된 요구 사항 목록과 비교됩니다. 또한 디자인과 관련하여 평가됩니다. 예를 들어, 온라인 응용 프로그램이 Internet Explorer 5 및 Firefox 1.0 이상을 지원하는지 확인하기 위해 테스트를 수행할 수 있습니다. 건물의 트림이 합의에 따라 시공되었는지, 사용된 자재가 실제로 정의 단계에서 지정된 것인지 여부를 확인할 수 있습니다. 이 단계는 모든 기준이 충족되고 결과 제품이 설계와 일치하면 완료됩니다.
프로젝트에 참여하는 사람들은 정의 단계에서 언급된 모든 기준을 정확히 충족하는 제품을 얻는 것이 매우 드물다는 점을 명심해야 합니다. 프로젝트 실행 과정에서 예상치 못한 상황이 발생하거나 이해가 진전되면 프로젝트 팀이 초기 요구 사항 또는 기타 설계 문서에서 벗어나게 될 수 있습니다.
이것은 특히 외부 클라이언트가 프로젝트 결과를 주문한 경우 경합의 원인이 될 수 있습니다. 특정 경우에 고객은 정의 프로세스 중에 도달한 계약을 호출할 수 있습니다.
일반적으로 정의 프로세스가 완료되면 요구 사항을 수정할 수 없습니다. 이것은 디자인에도 적용됩니다. 디자인 프로세스가 완료되면 디자인을 변경할 수 없습니다. 이것이 필요한 경우(때때로 발생) 프로젝트 리더는 수정 사항이 가능한 한 빨리 모든 이해 관계자(특히 의사 결정자 또는 소비자)에게 전달되도록 해야 합니다. 또한 향후 오해를 피하기 위해 수정 사항을 적절하게 기록하는 것이 중요합니다. 프로젝트 문서에 대한 추가 정보는 이 가이드북 뒷부분에 포함되어 있습니다.
종료 및 후속 조치 #
중요하지만 후속 단계는 종종 간과됩니다. 이 단계에서 프로젝트의 성공을 보장하기 위해 모든 필수 준비가 이루어집니다. 후속 단계에는 매뉴얼 작성, 사용자 교육 및 교육, 헬프 데스크 구축, 결과 유지 관리, 프로젝트 자체 평가, 프로젝트 보고서 작성, 파티 주최 등이 포함될 수 있습니다. 결과 달성을 축하하기 위해 프로젝트 팀을 이사로 이전하고 프로젝트 팀을 해체합니다.
후속 단계의 핵심 문제는 프로젝트가 언제 어디서 종료될 것인가입니다. 프로젝트 관리자는 종종 프로젝트의 처음 90%는 빠르게 진행되고 마지막 10%는 몇 년이 걸릴 수 있다고 농담합니다.
프로젝트가 이러한 한계에 도달하면 후속 단계에서 프로젝트를 종료하려면 프로젝트 시작부터 프로젝트의 경계를 평가해야 합니다.
프로젝트의 최종 결과가 프로토타입이 될 것인지 아니면 기능하는 제품이 될 것인지 관련된 개인에게 때때로 불분명합니다. 이것은 불확실한 결과를 가진 창의적인 이니셔티브에서 특히 만연합니다. 고객은 제품을 받을 것으로 예상할 수 있지만 프로젝트 팀은 프로토타입을 개발 중이라고 생각할 수 있습니다. 이러한 상황은 추적 기간 동안 가장 잘 나타납니다. 참신한 아이디어를 검증하기 위해 설계된 소프트웨어 개발 노력의 예를 생각해 보십시오. 연구 결과를 전혀 얻을 수 없는지에 대한 상당한 우려가 있었습니다.
결국 프로젝트는 긍정적인 결과를 낳았습니다. 팀은 최소한 테스트 환경의 범위 내에서 제대로 작동하는 소프트웨어를 생산했습니다. 정보 기술에 익숙하지 않은 클라이언트는 기능적인 제품을 얻었다고 믿었습니다. 결국, 그것은 그의 사무실에 있는 컴퓨터에서 작동했습니다. 프로그램은 잘 작동했지만 작업자 50명의 PC에 설치했을 때 프로토타입에 문제가 발생하고 일부에서는 불안정해졌습니다.
프로그래머는 소프트웨어를 수리할 수 있지만 다음 프로젝트에 참여하기 때문에 시간이 촉박했습니다. 게다가 실험용 아이템이라고 생각하는 것을 수리하는 데에는 별로 관심이 없었다. 몇 달 후 Microsoft가 Windows 서비스 팩 2를 도입했을 때 프로그램이 완전히 작동하지 않았습니다. 클라이언트는 ‘제품’이 단종된 것에 대해 분노했습니다.
