개시 #
프로젝트의 시작을 시작 단계라고 합니다. 이 단계에서는 프로젝트의 아이디어를 탐색하고 개발합니다. 이 단계의 목표는 프로젝트가 실제로 완료될 수 있는지 확인하는 것입니다. 누가 노력을 주도할 것인지, 어떤 조직이 참여할 것인지, 비즈니스가 관련자들로부터 충분한 지원을 받을 것인지에 대한 선택이 이루어집니다.
이 단계에서는 기존 또는 미래의 프로젝트 리더가 위에서 언급한 사항을 요약한 제안서를 준비해야 합니다. 사업 계획 및 보조금 신청서는 이러한 종류의 프로젝트 제안의 예입니다. 프로젝트의 잠재적 후원자는 신청서를 평가하고 승인되면 필요한 자금을 제공합니다. 프로젝트는 승인 시 공식적으로 시작됩니다. 시작 단계에서 다음 질문을 해결해야 합니다.
- 왜 이 프로젝트를?
- 물리적으로 가능한가요?
- 원하는 결과는 무엇입니까?
- 프로젝트의 한계는 무엇입니까(프로젝트 범위에 포함되는 것)?
‘아니오’라고 말할 수 있는 능력은 프로젝트 리더의 중요한 특성입니다. 개인이 프로젝트에 열중하면 범위가 커지는 경향이 있습니다. ‘우리가 그것에 있는 동안, 우리는 또한…’가 기본 아이디어입니다. 추가 목표가 추가된 프로젝트 및 계속 성장하는 프로젝트는 거의 지연되고 초기 목표를 달성할 가능성이 거의 없습니다.
첫 번째 단계는 프로젝트의 모든 이해 관계자 간의 연결을 설정하는 것입니다. 범위를 잘 이해하면 프로젝트 결과에 대한 비현실적인 기대를 피할 수 있습니다. 시작하려면 관련된 다양한 사람들 사이의 연결을 설정하십시오. 그 범위를 확실히 파악하는 것이 중요합니다.
특정 종류의 프로젝트에 대해 선택한 방법은 결과에 상당한 영향을 미칩니다. 예를 들어, 연구 개발 노력은 응용 프로그램의 기술적 실행 가능성을 평가하는 보고서를 제공할 수 있습니다. 프로토타입을 개발하는 프로젝트에는 애플리케이션의 모든 기능이 포함됩니다. 그러나 특정 환경(예: 수백 명의 사용자)에서 사용하기에 적합할 필요는 없습니다. 작동하는 제품을 생산하는 프로젝트는 유지 관리, 문서화 및 애플리케이션 관리 문제도 해결해야 합니다.
관련된 사람들로 인해 수많은 오해와 분쟁이 발생합니다. 프로젝트 관리 이러한 점에서 불분명하다. 고객은 기능적인 제품을 예상할 수 있지만 프로젝트 팀 구성원은 프로토타입을 만들고 있다고 생각합니다. 후원자는 프로젝트가 유용한 소프트웨어를 만들 것이라고 생각할 수 있지만 팀 구성원은 먼저 개념이 기술적으로 실행 가능한지 여부를 결정해야 합니다.
정의 #
승인된 착수 프로젝트 계획 이후, 프로젝트는 두 번째 단계인 정의 단계를 시작했습니다. 이 단계에서는 프로젝트 결과와 관련된 요구 사항을 가능한 한 정확하게 지정합니다. 이 단계에서는 프로젝트 개발에 관련된 모든 당사자의 기대치를 결정해야 합니다. 아카이빙에 필요한 파일은 몇 개입니까? 메타데이터는 DDO(Data Documentation Initiative) 형식이어야 합니까, 아니면 Dublin Core(DC)로 충분합니까? 파일은 원래 형식으로 허용됩니까, 아니면 ‘선호 표준’을 준수하는 형식으로만 허용됩니까? 아카이브에서 데이터 세트가 적절하게 처리되도록 보장하는 것이 기탁자의 의무입니까, 아니면 아카이브 책임자의 책임입니까? 프로젝트 결과에 대해 어떤 보증이 제공됩니까? 문의 목록은 무기한 계속될 수 있습니다.
프로세스에서 가능한 한 빨리 요구 사항을 설정하는 것이 중요합니다.
Wijnen(2004)은 기억 보조 수단으로 다음과 같은 유형의 프로젝트 요구 사항을 설정합니다.
- 전제 조건
- 기능 요구 사항
- 기능 요구 사항
- 설계 제약
전제 조건은 프로젝트가 발생해야 하는 프레임워크를 제공합니다.
법률, 근로 조건을 규율하는 규칙, 승인 절차가 모두 그 예입니다. 이러한 기준은 프로젝트 내에서 변경할 수 없습니다.
요구 사항 사양은 최종 결과물의 품질과 관련이 있으며 프로젝트 결과가 사용되는 방식과 관련된 기술 사양이라는 점을 기억하는 것이 중요합니다. 예를 들어, 소프트웨어 프로젝트가 완료된 후 오류 수를 90%까지 줄여야 합니다. 반면에 설계 제한은 프로젝트별 요구 사항입니다. 예를 들어 유해 화학 물질 및 노동 기준이 의심스러운 외국 파트너는 프로젝트에 포함될 수 없습니다.
주요 조직의 컨소시엄을 위한 웹 응용 프로그램 구축을 포함하는 프로젝트의 정의 단계에서는 프로그램이 지원할 브라우저에 대한 결정이 내려지지 않았습니다. 컨소시엄은 ‘모든 사람의 브라우저’이기 때문에 Microsoft Explorer가 될 것이라고 생각했습니다.
개발자들은 이미 브라우저에 익숙하고 개발 전반에 걸쳐 특히 유용한 몇 가지 기능을 가지고 있었기 때문에 Firefox에서 애플리케이션을 구축했습니다. Firefox용으로 설계된 대부분의 웹 사이트는 Explorer에서도 훌륭하게 표시되기 때문에 변경 사항은 처음에는 감지할 수 없었습니다. 그러나 프로젝트가 끝날 무렵 클라이언트는 웹 사이트가 ‘멋져 보이지 않는다’고 항의하기 시작했습니다. Firefox를 통해 사이트에 액세스하던 프로그래머는 불만 사항에 당황했습니다.
두 브라우저가 호환되지 않는다는 것이 명백해지자 프로그래머들은 방어적으로 ‘파이어폭스를 설치할 수 없나요? 결국, 그것은 무료입니다’. 다른 한편, 조직은 어떤 이유에서든 익스플로러와 함께 파이어폭스를 설치하는 것을 거부한 정부 시스템 관리자에게 의무를 부과했습니다.
설치를 원하더라도 절차가 오래 걸리고 시스템 관리자가 작업에 소요하는 시간과 관련된 추가 비용이 발생했을 것입니다. 마지막으로 응용 프로그램이 Explorer에 맞게 조정되어야 한다고 결정했습니다. 이것은 훨씬 더 많은 노력을 필요로 했고, 그 결과 프로젝트가 이미 예정된 것보다 훨씬 더 늦어져 추가 비용을 협상해야 했습니다. 나중에 조사한 결과 다양한 조직에서 서로 다른 버전의 Microsoft Explorer를 사용하고 있는 것으로 나타났습니다.
프로젝트에 참여하는 모든 이해 관계자, 특히 프로젝트의 결과를 활용할 최종 사용자가 정의 단계 전반에 걸쳐 참여하는 것이 중요합니다. 최종 고객은 종종 프로젝트를 주문하는 사람이 아니기 때문에 종종 무시됩니다. 정의 단계에서 프로젝트 비용을 지불하는 고객은 요구 사항에 기여해야 합니다. 그럼에도 불구하고 이니셔티브는 미래의 사용자를 초대함으로써 이익을 얻습니다. 시작점으로 프로젝트 정의 단계 전반에 걸쳐 모든 이해 관계자와 소집 회의를 개최하는 것이 좋습니다.
나중에 사용자(젊은이)가 교육용 비디오 게임 개발에 참여했습니다. 게임이 거의 준비되었을 때 젊은이들과 함께 테스트하기로 결정했습니다. 그들의 첫 평가는 온건하고 우호적이었던 것 같습니다. 그러나 밀렸을 때 그들은 게임이 ‘매우 지루함’을 느꼈고 ‘자체적으로 플레이하지 않을 것’이라고 인정했습니다. 이 젊은 사람들이 프로젝트 초기에 참여했다면 게임은 의심할 여지 없이 성공했을 것입니다. 현재 이 게임은 인터넷 웹사이트에 거의 게재되지 않았습니다.
정의 단계에서는 프로젝트에 참여하는 모든 이해 관계자의 요구 사항 목록을 생성합니다. 물론 각 조건에는 역함수가 있습니다.
작업이 복잡할수록 더 많은 시간과 돈이 필요합니다. 또한 일부 기준은 서로 충돌할 수 있습니다. 보다 환경 친화적 인 새로운 복사기; 또한 화재 안전 표준을 충족해야 합니다. 화재 안전을 관리하는 규정은 환경 친화적이지 않은 난연성 재료의 사용을 의무화하고 있습니다. 이 이미지와 같이 해결해야 합니다.
마지막으로 명확한 기준 목록이 생성되어 승인을 위해 프로젝트 의사 결정자에게 제출됩니다. 목록이 승인된 후 설계 프로세스가 시작될 수 있습니다. 정의 단계가 끝날 때까지 클라이언트와 프로젝트 팀 간의 대부분의 합의가 이루어집니다.
요구 사항 목록은 프로젝트가 작동해야 하는 매개변수를 설정합니다.
이 목록은 프로젝트 팀을 평가하는 데 사용됩니다. 결과적으로 클라이언트는 정의 단계 후에 추가 요구 사항을 추가할 수 없습니다.
프로젝트의 일부로 만들어진 컴퓨터 설치에는 박물관의 새로운 전시가 포함됩니다. 프로젝트에 정의 단계가 없기 때문에 박물관과 설치 공사를 책임지는 사람들 사이에 구체적인 협상이 이루어지지 않았습니다. 설치의 컴퓨터가 중간에 고장났을 때, 박물관은 프로젝트의 보증이 그것을 커버할 것이라고 믿었습니다. 프로젝트 팀은 반대 입장을 취했습니다. 합의에 도달하려면 이사들 간의 협상이 필요했습니다.
설계 #
정의 단계의 요구 사항 집합을 사용하여 설계 결정을 내릴 수 있습니다. 디자인 단계에서 프로젝트의 목표를 달성하는 것처럼 보이는 하나 이상의 디자인이 생성됩니다. 디자인 단계에서는 프로젝트 주제에 따라 디오라마, 도면, 순서도, 사이트 트리, HTML 화면 디자인, 프로토타입, 그림 인상 및 UML 스키마를 생성할 수 있습니다. 프로젝트 리더는 이 도면을 사용하여 프로젝트의 최종 설계를 선택합니다. 그 다음은 개발 단계입니다. 디자인이 선택되면 정의 문구와 같이 프로젝트의 후속 단계에서 변경할 수 없습니다.
이 경우에는 ‘디자인 부서’라는 문구가 적절하지 않았습니다. 오히려 협업한 디자이너 그룹을 지칭했습니다. 게다가 부서장을 포함해 모두가 너무 바빴다.
한 프로젝트에서는 프로젝트의 성공에 중요한 다양한 디자인을 생성해야 했습니다. 프로젝트 팀의 젊은 디자이너가 개발한 디자인. 디자인 팀장은 궁극적으로 디자인에 대한 책임이 있지만 디자인을 검토하는 프로젝트 팀 회의에는 참석하지 않았습니다. 프로젝트 상사는 지속적으로 그를 초대하고 그의 젊은 동료가 그린 그림을 이메일로 보냈지만 이메일은 무시되었습니다. 프로젝트 리더와 젊은 디자이너는 부서장이 디자인을 수락했다고 잘못 믿었습니다. 구현 단계가 시작되었습니다. 프로젝트가 거의 완료되었을 때, 그 결과를 부서장에게 전달했고, 부서장은 화를 내며 모든 것을 다시 할 수 있다고 명령했습니다.
