프로젝트관리 지식체계 지침서 | 모델, 방법, 가공품

 

* 모델(Model): 모델은 프로세스, 프레임워크 또는 현상을 설명하는 사고 전략이다.

* 방법(Method): 방법은 성과, 산출물, 결과 또는 프로젝트 인도물을 달성하기 위한 수단이다.

* 가공품(Artifact): 결과물은 템플릿, 문서, 산출물 또는 프로젝트 인도물이 될 수 있다.

 

[프로젝트 관리 원칙(12)] => (행동 안내) || 모델, 방법 -> [프로젝트 성과 영역(8)] -> 가공품(인도물, 결과물) || (조정)

 

 

출처: PMP Certification ECO 문제집, ATP 주식회사 PCCA, (주)도서출판 성안당

프로젝트관리 지식체계 지침서 | 조정(Tailoring)

 

1. 개요: 조정이란 프로젝트 관리 접근 방식, 거버넌스 및 프로세스를 주어진 환경과 당면 과제에 더욱 적합하게 만드는 의도적인 적용을 말한다.

2. 단계 별 적용

 1) 초기 개발 방식 선택: 작업에 가장 적합한 개발 방식 선택

 2) 조직에 맞게 조정: 조직의 변경 사항에 따라 수정

 3) 프로젝트에 맞게 조정: 규모, 중요성 및 기타 요인에 따라 조정

 4) 지속적인 개선 구현: 검사 및 조정

3. 성과 영역별 조정의 예

 - 이해관계자: 이해관계자와 공급업체를 위한 협업적인 환경이 조성되어 있는가?

 - 프로젝트 팀: 프로젝트 팀원의 물리적 위치는 어디인가? 프로젝트 팀이 동일장소에 배치되어 있는가?

 - 개발 방식 및 생애주기: 어떠한 개발 방식이 제품, 서비스 또는 결과물에 적합한가? 적응형 방식일 경우, 반복형과 점증형 중 어느 방식으로 프로젝트를 개발할 것인가?

 - 기획: 내부 및 외부 환경 요인이 프로젝트와 그 인도물에 어떤 영향을 미치는가?

 - 프로젝트 작업: 프로젝트 전반에 거쳐 그리고 프로젝트 종료 시 어떤 정보를 수집해야 하는가?

 - 인도: 조직에 검증 및 통제와 관련된 기존의 공식 또는 비공식 정책, 절차 및 지침이 있는가?

 - 불확실성: 현재의 노력에 대한 리스크 선호도 및 리스크 허용한도는 어떠한가?

 - 측정: 가치는 어떻게 측정되는가?

 

 

출처: PMP Certification ECO 문제집, ATP 주식회사 PCCA, (주)도서출판 성안당

프로젝트관리 지식체계 지침서 | 구성, 프로젝트 성과 영역 (8)

 

* 프로젝트관리 지식체계 지침서 구성

1. 프로젝트 성과 도메인: 프로젝트 및 의도된 결과의 성공적인 전달을 가능하게 하는 통합 시스템을 형성하는 8개의 프로젝트 성과 영역을 식별하고 설명한다.

2. 조정(테일러링): 조정(테일러링) 기법을 설명하고 테일러링 대상과 개발 프로젝트 조정 방법에 대한 개요를 제공한다.

3. 모델, 방법 및 가공품(아티팩트): 일반적으로 적용되는 모델, 방법 및 가공품(아티팩트)에 대한 간략한 설명을 제공한다. 이러한 모델, 방법 및 가공품은 프로젝트 팀이 결과물을 생성하고, 작업을 구성하고, 의사소통 및 협업을 활성화하는 데 사용할 수 있는 선ㅌ낵의 범위를 기술한다.

 

* 프로젝트 성과 영역

1. 이해관계자(Stakeholder)

 1) 개요: 이해관계자 성과 영역은 이해관계자와 관련된 활동 및 기능을 다룬다.

 2) 성과

  (1) 프로젝트 전반에 걸쳐 이해관계자와의 생산적인 업무 관계

  (2) 프로젝트 목표에 대해 이해관계자와의 합의

  (3) 프로젝트 수혜자인 이해관계자가 지지하고 만족하며, 프로젝트나 그 인도를 반대할 수 있는 이해관계자는 프로젝트 성과에 부정적인 영향을 미치지 않는다.

 

2. 팀(Team)

 1) 개요: 팀 성과 영역은 비즈니스 성과를 실현하는 프로젝트 인도물 생산 담당자와 관련 있는 활동 및 기능을 다룬다.

 2) 성과

  (1) 공유된 오너십

  (2) 높은 성과를 올리는 팀

  (3) 모든 구성원이 보여주는 적절한 리더십과 기타 대인관계 기술

 

3. 개발 방식 및 생애주기(Development Approach and Life Cycle)

 1) 개요: 개발 방식 및 생애주기 성과 영역은 프로젝트의 개발 방식 케이던스 및 생애주기 단계와 관련된 활동 및 기능을 다룬다.

 2) 성과

  (1) 프로젝트 인도물과 일치하는 개발 방식

  (2) 프로젝트 생애주기는 프로젝트 시작부터 마지막까지 비즈니스 인도 및 이해관계자 가치를 연결하는 단계로 구성된다.

  (3) 프로젝트 생애주기는 프로젝트 인도물을 생산하는 데 필요한 인도 케이던스 및 개발 방식을 원활하게 하는 단계로 구성된다.

 

4. 기획(Planning)

 1) 개요: 기획 성과 영역은 프로젝트 인도물과 성과 인도에 필요한 초기, 진행 및 진화하는 조직 및 협동과 관련된 활동과 기능을 다룬다.

 2) 성과

  (1) 프로젝트가 조직적이고, 통합적이며, 의도적인 방식으로 진행된다.

  (2) 총체적인 접근 방식으로 프로젝트 성과를 제공한다.

  (3) 진화하는 정보가 프로젝트 착수의 인도물과 성과를 산출할 수 있도록 정교하게 구성된다.

  (4) 계획에 소요된 시간이 상황에 적절하다.

  (5) 기획 정보가 이해관계자 기대치를 관리하기에 충분하다.

  (6) 새롭게 부상하고 변화하는 요구나 조건을 근거로 프로젝트 전반에서 계획을 조정하는 프로세스가 있다.

 

5. 프로젝트 작업(Project Work)

 1) 개요: 프로젝트 작업 성과 영역은 프로젝트 프로세스 확립, 물적 자원 관리, 학습 환경 조성 등과 관련된 활동과 기능을 다룬다.

 2) 성과

  (1) 효율적이고 효과적인 프로젝트 성과

  (2) 프로젝트와 환경에 적합한 프로젝트 프로세스

  (3) 이해관계자와의 적절한 커뮤니케이션

  (4) 물적 자원의 효율적 관리

  (5) 조달의 효과적 관리

  (6) 지속적인 학습과 프로세스 개선으로 팀 역량 개선

 

6. 인도(Delivery)

 1) 개요: 인도 성과 영역은 프로젝트에 부여된 범위 및 품질 이행의 제공과 관련된 활동 및 기능을 다룬다.

 2) 성과

  (1) 프로젝트가 비즈니스 목표 및 전략 발전에 기여

  (2) 프로젝트가 인도에 착수한 성과를 실현

  (3) 프로젝트 편익이 계획된 기간에 실현

  (4) 프로젝트 팀이 요구사항을 명확하게 이해

  (5) 이해관계자가 프로젝트 인도물을 수락하고 만족

 

7. 측정(Measurement)

 1) 개요: 성과 측정 영역은 프로젝트 성과 측정 및 수용 가능한 성과 유지를 위한 적절한 조치 이행과 관련된 활동 및 기능을 다룬다.

 2) 성과

  (1) 프로젝트 상태에 대한 신뢰할 수 있는 이해

  (2) 의사결정을 촉진하는 실행 가능한 데이터

  (3) 프로젝트 성과를 추적하기 위한 적절한 조치의 적시 실행

  (4) 신뢰할 수 있는 예측 및 평가를 기반으로 적시에 정보에 입각한 의사결정을 내림으로써 목표를 달성하고 비즈니스 가치를 창출

 

8. 불확실성(Uncertainty)

 1) 개요: 불확실성 성과 영역은 리스크 및 불확실성과 관련된 활동과 기능을 다룬다.

 2) 성과

  (1) 기술, 사회, 정치, 시장 및 경제 환경을 포함하여(이에 국한되지 않음) 프로젝트가 발생하는 환경을 인식

  (2) 불확실성에 대한 사전 예방적 탐구 및 대응

  (3) 프로젝트에서 여러 변수의 상호의존성 인식

  (4) 위협과 기회를 예측하고 문제의 결과를 이해하는 능력

  (5) 예상치 못한 이벤트나 조건으로 인한 부정적인 영향이 거의 없거나 전혀 없는 프로젝트 인도

  (6) 프로젝트 성과 및 결과를 개선할 수 있는 기회 실현

  (7) 프로젝트 목표에 맞춰 여분의 비용 및 일정을 효과적으로 활용

 

 

출처: PMP Certification ECO 문제집, ATP 주식회사 PCCA, (주)도서출판 성안당

프로젝트 관리 표준서 | 프로젝트 관리 원칙 (12)

 

1. 스튜어드십(Stewardship): 성실하고 존중하며 배려하는 관리자가 되어야 한다.

 1) 개요: 관리자는 내부 및 외부 지침을 준수하면서 청렴성, 관심 및 신뢰성을 가지고 활동을 수행하기위해 책임감 있게 행동한다. 관리자는 자신이 지원하는 프로젝트의 재무적, 사회적, 환경적 영향에 대한 광범위한 헌신을 보여준다.

 2) 구성

  (1) 스튜어드십은 조직 내부 및 외부에 대한 책임을 포괄한다.

  (2) 스튜어드십에는 다음이 포함된다.

   - 청렴성

   - 관심

   - 신뢰성

   - 규정 준수

  (3) 스튜어드십의 전체적인 관점에서는 재무적, 사회적, 기술적 및 지속 가능한 환경 인식을 고려한다.

 

2. 팀(Team): 협업하는 프로젝트 팀 환경을 조성한다.

 1) 개요: 프로젝트 팀은 다양한 기술, 지식 및 경험을 갖춘 개인으로 구성되어 있다. 협력적으로 작업하는 프로젝트 팀은 독자적으로 작업하는 개인보다 공유 목표를 더 효과적이고 효율적으로 달성할 수 있다.

 2) 구성

  (1) 프로젝트는 프로젝트 팀에서 인도한다.

  (2) 프로젝트 팀은 조직적, 전문적 문화와 지침 내에서 업무를 수행하며, 종종 자체적인 "현지" 문화를 구축한다.

  (3) 협력적 프로젝트 팀 환경은 아래와 같은 것을 촉진한다.

   - 다른 조직 문화 및 지침과 연계

   - 개인 및 팀의 학습 및 개발

   - 원하는 성과를 인도하기 위한 최적의 기여

 

3. 이해관계자(Stakeholder): 이해관계자와 효과적으로 소통한다.

 1) 개요: 프로젝트 성공 및 고객 만족도에 기여하는 데 필요한 수준으로 선제적으로 이해관계자를 참여시킨다.

 2) 구성

  (1) 이해관계자는 프로젝트, 성과 및 결과에 영향을 미친다.

  (2) 프로젝트 팀은 참여를 통해 다른 이해관계자에게 서비스를 제공한다.

  (3) 이해관계자 참여는 가치 인도를 선제적으로 발전시킨다.

 

4. 가치(Value): 가치에 중점을 둔다.

 1) 개요: 비즈니스 목표 및 의도한 편익과 가치에 맞게 프로젝트 연계를 지속적으로 평가 및 조정한다.

 2) 구성

  (1) 가치는 프로젝트 성공의 궁극적인 지표이다.

  (2) 가치는 프로젝트 전반에 걸쳐 프로젝트 종료 시 또는 프로젝트 완료 후에 실현될 수 있다.

  (3) 가치와 가치에 기여하는 편익은 정량적 및/또는 정성적 용어로 정의될 수 있다.

  (4) 성과에 집중하면 프로젝트 팀이 가치 창출로 이어지는 의도한 편익을 지원할 수 있다.

  (5) 프로젝트 팀은 진행 상황을 평가하고 예상 가치를 극대화하도록 조정한다.

 

5. 시스템 사고(System Thinking): 시스템 상호 작용을 인식하고 평가 및 대응한다.

 1) 개요: 프로젝트 성과에 긍정적인 영향을 미치기 위해 총체적인 방법으로 프로젝트 내부 및 주변의 동적 상황을 인식하고 평가하고 대응한다.

 2) 구성

  (1) 프로젝트는 상호 의존적이고 상호 작용하는 활동 영역의 시스템이다.

  (2) 시스템 사고는 프로젝트 각 부분이 서로 간에, 그리고 외부 시스템과 어떻게 상호 작용하는지에 대한 전체적인 관점을 수반한다.

  (3) 시스템은 계속해서 변하므로 내부 및 외부 조건에 지속적으로 주의를 기울여야 한다.

  (4) 시스템 상호 작용에 반응함으로써 프로젝트 팀은 긍정적인 성과를 활용할 수 있다.

 

6. 리더십(Leadership): 리더십 행동을 보여준다.

 1) 개요: 개인 및 팀의 요구를 지원하기 위해 리더십 행동을 보여주고 조정한다.

 2) 구성

  (1) 효과적인 리더십은 프로젝트 성공을 촉진하고 긍정적인 프로젝트 성과에 기여한다.

  (2) 어떤 프로젝트 팀 구성원이라도 리더십 행동을 보여줄 수 있다.

  (3) 리더십은 권위와 다르다.

  (4) 효과적인 리더는 상황에 맞게 자신의 스타일을 조정한다.

  (5) 효과적인 리더는 프로젝트 팀원 간의 동기부여의 차이를 인식한다.

  (6) 리더들은 정직성, 청렴성 및 윤리적 행동 영역에서 바람직한 행동을 보인다.

 

7. 조정(Tailoring): 상황에 맞게 조정한다.

 1) 개요: 가치를 극대화하고, 비용을 관리하고 속도를 개선하는 동시에 추구하는 성과를 달성하기에 "충분한" 프로세스를 사용하여 프로젝트, 목표, 이해관계자, 거버넌스 및 환경의 맥락에 기반하여 프로젝트 개발 방식을 설계한다.

 2) 구성

  (1) 각 프로젝트는 고유하다.

  (2) 프로젝트의 성공은 프로젝트의 고유한 맥락에 적응하며, 원하는 성과를 내기에 가장 적절한 방법을 결정하는 데 달려있다.

  (3) 접근 방식 조정은 반복적이므로 프로젝트 전반에 걸쳐 지속되는 프로세스이다.

 

8. 품질(Quality): 프로세스 및 결과물에 품질을 확보한다.

 1) 개요: 프로젝트 목표를 충족하고 관련 이해관계자가 제시하는 니즈, 사용 및 인수 요구사항에 부합하는 인도물을 생산하는 품질에 계속해서 초점을 맞춘다.

 2) 구성

  (1) 프로젝트 품질에는 이해관계의 기대를 충족하고 프로젝트 및 제품 요구사항을 충족하는 것이 수반된다.

  (2) 품질은 인도물의 인수 기준을 충족하는 데 중점을 둔다.

  (3) 프로젝트 품질에는 프로젝트 프로세스가 적절하고 최대한 효과적인지 확인하는 작업이 수반된다.

 

9. 복잡성(Complexity): 복잡성을 살핀다.

 1) 개요: 접근 방식 및 계획에 따라 프로젝트 팀이 프로젝트 생애주기를 성공적으로 탐색할 수 있도록 프로젝트 복잡성을 지속적으로 평가하고 탐색한다.

 2) 구성

  (1) 복잡성은 인간의 행동, 시스템 상호작용, 불확실성 및 모호성으로 인해 발생한다.

  (2) 복잡성은 프로젝트 진행 중 어떤 지점에서든 발생할 수 있다.

  (3) 복잡성은 가치, 범위, 의사소통, 이해관계자, 리스크 및 기술 혁신에 영향을 미치는 이벤트 또는 조건에 의해 발생할 수 있다.

  (4) 프로젝트 팀은 복잡성의 요소를 파악하는 데 주의를 기울이고, 복잡성의 규모나 영향을 줄이기 위해 다양한 방법을 사용할 수 있다.

 

10. 리스크(Risk): 위험 대응을 최적화한다.

 1) 개요: 프로젝트와 그 성과에 대한 긍정적인 영향을 극대화하고 부정적인 영향을 최소화하기 위해 리스크에 대한 노출, 즉 기회 및 위협을 지속적으로 평가한다.

 2) 구성

  (1) 개별적인 리스크와 전반적인 리스크가 프로젝트에 영향을 줄 수 있다.

  (2) 리스크는 긍정적(기회) 또는 부정적(위협)일 수 있다.

  (3) 리스크는 프로젝트 전반에 걸쳐 지속적으로 처리된다.

  (4) 리스크를 대하는 조직의 태도, 리스크 선호도 및 한계선은 리스크 처리 방식에 영향을 미친다.

  (5) 리스크 대응은 다음과 같아야 한다.

   - 리스크 심각성에 적합해야 한다.

   - 비용 대비 효과적이어야 한다.

   - 프로젝트 맥락 내에서 현실적이어야 한다.

   - 관련 이해관계자가 동의해야 한다.

   - 담당자가 결정되어야 한다.

 

11. 적응성과 복원력(Adaptability and Resiliency): 적응력과 유연성을 받아들인다.

 1) 개요: 조직 및 프로젝트 팀의 접근 방식에 적응성과 복원력을 구축하여 프로젝트가 변경을 수용하고, 좌절에서 회복하며, 프로젝트 작업을 발전시킬 수 있도록 지원할 수 있다.

 2) 구성

  (1) 적응성은 변화하는 조건에 대응할 수 있는 능력이다.

  (2) 복원력은 충격을 흡수하고 좌절 또는 실패로부터 신속하게 회복하는 능력이다.

  (3) 산출물보다는 성과에 중점을 두면 적응성을 촉진할 수 있다.

 

12. 변화(Change): 계획한 앞날을 달성할 수 있도록 변화할 수 있다.

 1) 개요: 현재 상태에서 프로젝트 성과에 의해 생성되는 의도된 미래 상태로 전환하는 데 필요한 새롭고 다른 행동과 프로세스의 채택 및 지속에 대비해 영향을 받는 사람들을 준비시킨다.

 2) 구성

  (1) 변화에 대한 구조적인 접근 방식은 개인, 그룹 및 조직이 현재 상태에서 미래지향적 상태로 전환하는 데 도움이 된다.

  (2) 변화는 내부 영향 또는 외부 요인에서 비롯될 수 있다.

  (3) 모든 이해관계자가 변화를 수용하는 것은 아니므로 변화를 가능하게 하는 것은 어려울 수 있다.

  (4) 짧은 시간 내에 너무 많은 변화를 시도하면 변화에 대한 피로감 및/또는 저항으로 이어질 수 있다.

  (5) 이해관계자 참여와 동기부여식 접근 방식은 변화를 채택하는 데 도움이 된다.

 

 

출처: PMP Certification ECO 문제집, ATP 주식회사 PCCA, (주)도서출판 성안

프로젝트 관리 표준서 | 가치 인도 시스템

 

* 개념 : 프로젝트 < 프로그램 < 포트폴리오

* 주요 용어

 - 인도물(Deliverable): 프로세스, 단계 또는 프로젝트를 완료하기 위해 산출해야 하는 고유하고 검증 가능한 제품, 결과.

 - 결과물(Artifact): 템플릿, 문서, 산출물 또는 프로젝트 인도물.

 - 산출물(Output): 측정 가능한 유/무형의 결과.

 - 성과(Outcome): 프로세스나 프로젝트의 최종 결과물. 성과에는 산출물과 결과물이 포함될 수 있지만 프로젝트를 통해 인도하려는 편익과 가치에 초점을 맞추면 의미가 더 넓어질 수 있다.

 - 편익(Benefit): 편익이란 재화나 서비스를 소비함으로써 얻을 수 있는 주관적 만족감을 객관적 척도인 화폐가치로 표현한 것.

 - 가치(Value): 어떤 것의 가치, 중요성 또는 유용성. 이해관계자마다 가치를 인식하는 방식이 다르다. 고객은 제품의 특정 기능 및 특징을 사용할 수 있는 능력으로 가치를 정의할 수 있다. 조직은 재무 지표(어떤 편익을 얻는 데 드는 비용보다 그 편익이 적음)에 따라 결정된 비즈니스 가치에 중점을 둘 수 있다. 사회적 가치에는 사람, 지역사회 또는 환경 그룹에 대한 기여도가 포함될 수 있다.

 

1. 가치 창출

 - 조직과 이해관계자를 위한 가치를 창출하기 위해 시스템 내에서 프로젝트가 어떻게 작동하는지 설명한다.

 - Portfolios, programs, projects, products 등 다양한 요소를 통해 가치를 창출할 수 있다.

 - 가치 전달 시스템은 정보와 피즈백이 모든 구성 요소 간에 일관되게 공유될 때 가장 효과적으로 작동한다.

2. 조직 거버넌스 시스템

 - 거버넌스가 가치 전달 시스템을 지원하는 방법을 설명한다.

 - 거버넌스 시스템은 가치 전달 시스템과 함께 작동하여 원활한 워크플로를 지원하고 문제를 관리하며 의사 결정을 지원한다.

3. 프로젝트 관련 기능

 - 프로젝트를 지원하는 기능을 식별한다.

 - 프로젝트와 관련된 기능은 한 사람 혹은 여러 사람이 수행하거나 정의한 역할로 결합한다.

4. 프로젝트 환경

 - 프로젝트와 가치 전달에 영향을 미치는 내부 및 외부 요인을 식별한다.

 - 프로젝트는 가치 전달에 다양한 영향을 주는 내부 및 외부 환경에서 수행한다.

 - 내부 및 외부 환경은 계획 및 기타 프로젝트 활동에 영향을 줄 수 있으며, 이러한 영향은 프로젝트 특성, 이해관계자 또는 프로젝트 팀에 유리하거나 불리하거나 중립적인 영향을 미친다.

5. 제품 관리 고려 사항

 - 포트폴리오, 프로그램, 프로젝트 및 제품이 관련되는 방식을 식별한다.

 

 

 

출처: PMP Certification ECO 문제집, ATP 주식회사 PCCA, (주)도서출판 성안당

프로젝트 - 정해진 기간 안에서 정교한 작업을 통해 결과와 서비스를 만들어 내는 일련의 과정
* 프로젝트 정의(TPO)
1. Temporary(일시적인)
 - 일정 상 시작과 끝이 반드시 존재한다는 의미
2. Progressivley elaborated(점진적 정교화)
 - 지속적으로 수정, 향상, 갱신, 추가되는 요소를 점진적으로 정교화하는 작업에 대한 의미
 ex) Rolling wave planning(high-level), prototype(working model, mock-up)
3. Output(산출물)
 - 서비스를 운영(Operation)하는 소프트웨어 제품(Product)을 의미

 

Tech PM - 비지니스 가치가 있는 소프트웨어를 발의하고 기획/설계/일정관리/오픈/운영까지 A-Z를 관리

소프트웨어를 통해 서비스를 제공하는 프로젝트를 발의하고 시스템을 기획/설계하는 Tech PM은 아래와 같은 일을 해야 합니다.

1. 개발자가 이해할 수 있는 수준의 요구사항 정의
2. 비지니스 상황에 맞춘 구축 우선순위 선정 판단
3. 간결하지만 명료한 문서작성 기술

비지니스 측면 가치에 대한 기획을 통해 구축된 시스템이 Product(제품)로서 안정적인 서비스를 제공하고, 고정적인 수익을 창출할 수 있는 도구가 될 수 있도록 설계해야 합니다.

 

Tech PM은 소프트웨어 기반의 회사에서 개발자와 현업이 서로 원하는 바를 얻게끔 만들어주는 역할을
책임을 가지고 헌신적으로 실천할 수 있어야 합니다.

 

PM은 이 모든 고민을 문서로 남겨 관리할 수 있어야 합니다.

* Why?

 - 상시 보고할 수 있는 준비

 - 혼재된 요구사항과 모호한 협의안, 방향을 정하는 의사결정 점검

* 문서 히스토리
* 메뉴구조도
* 요구사항 정의서 2부 (현업, 개발사)
* 플로우차트(task, user, I.A)
* 와이어프레임
* 화면정의서
* 기능명세서
* ERD(다이어그램)
개발사 입장에서 작성하는 요구사항 정의서는 마찬가지로 현업과의 약속이자 프로젝트 발의 당시 검토했던
기능 구현방안과 일정, 리스크 등을 서술해놓은 문서입니다.

 

개발사의 관점에서 제작한 요구사항 정의서는 현업에게 전달받은 요구사항을 기능 구현 관점에서 세부적으로 분해한 내용이 있어야 합니다.

현업이 비교적 비지니스 이익에 직접적인 영향을 미치는 요인을 고민한다면, 개발사는 구현 가능여부, 일정, 리스크(side-effect), 확장성 등을 고민해야 합니다.

 

개발사는 현업이 요청한 요구사항을 원하는 일정에 맞춰 리스크가 적고 확장성을 가질 수 있도록 구현할 수 있도록 고민해야 합니다.

사내 개발인력 관리 및 필요 시 외부인력 투입 검토, 시스템이 올라가는 인프라에 대한 검토 및 자체 일정관리에 비용을 투자해야 합니다.

 

개발사는 현업에 막연히 최대치 이상의 인력과 일정에 대한 버퍼가 고려된 공수를 요구한다면 파트너간 신뢰를 잃을 수 있습니다.

하지만, 필요한 자원에 대한 요구는 견적에 반드시 기입되어야 하기 때문에, 납득이 가능한 수준의 요구를 합리적이고 누구나 납득이 가능하도록 현업에게 설명할 수 있도록 많은 준비가 필요합니다.

 

현업이 개발사로부터 산출되기 원하는 요구사항 정의서는 아래 내용을 담고 있어야 합니다.

  1. 현업이 전달한 요구사항을 세부적인 기능 단위로 나열 -> 가능여부 | 일정 | 리스크 | 사유 | 비고
  2. 실제 로직을 구현하는 입장에서 검토할 수 있는 기능의 확장성에 대해 현업에서 참고할만한 의견
  3. 신기술 및 인프라 고도화에 대한 기술 의견
* 요구사항 정의서 페이지 구성요소
----------------------------현업문서 참고----------------------------
1) IDX
2) 환경
 - 어플리케이션 아키텍처 종류 (WEB or APP)
3) 구분
 - 기능이 작동하는 모듈 별 묶음 단위
 ex) 상품, 재고, 회원 등
4) 구분 IDX
5) 요구사항 명
 - 기능 구현이 필요한 요구사항에 대한 명칭
----------------------------개발사 의견 작성----------------------------
6) 요구사항 상세
 - 기능 구현이 필요한 요구사항에 대한 위치(화면주소)와 동작원리에 대한 상세한 내용
7) 기능 별 구현 가능여부
 - 불가능 시 대안책 제시
8) 기능 별 구현 일정
9) 비고
 - 기능에 대한 의견을 기록
현업 입장에서 요구사항 정의서는 개발사와의 약속이자 프로젝트 발의 당시 원했던 시스템을 통한 비지니스 성장 방향을 서술해놓은 중요한 문서입니다.

 

현업의 관점에서 제작한 요구사항 정의서는 비교적 비지니스 이익에 직접적인 영향을 미치는 요인에 대해 요구사항 별로 작성합니다.

 

현업은 사내의 인적/물적 자원을 통해 더 높은 수익을 창출해낼 수 있는 시스템을 구축하기 위해 비용을 투자합니다.

신규 수익을 창출해내거나, 기존에 나갔던 비용을 절감하여 이익율을 높일 수 있는 시스템이 필요합니다.

 

막대한 비용을 투자한 시스템은 단순히 담당자가 일을 편하게 할 수 있도록 도와주거나, 복잡한 단순 계산 업무를 대신해주기 위해 존재하지 않습니다.

 

현업이 원하는 시스템은 아래와 같습니다.

  1. 반복적인 업무를 관리형 시스템으로 대체함으로서 생길 수 있는 공수의 확연한 절감
  2. 직무 별로 흩어져 있는 데이터를 유기적으로 순환시켜주는 연동형 시스템
  3. AI/ML 등 복잡한 계산식의 정답을 고도화된 알고리즘을 통해 산출해내는 생산형 시스템
* 요구사항 정의서 페이지 구성요소
1) IDX
2) 환경
 - 어플리케이션 아키텍처 종류 (WEB or APP)
3) 구분
 - 기능이 작동하는 모듈 별 묶음 단위
 ex) 상품, 재고, 회원 등
4) 구분 IDX
5) 요구사항 명
 - 기능 구현이 필요한 요구사항에 대한 명칭
6) 요구사항 상세
 - 기능 구현이 필요한 요구사항에 대한 위치(화면주소)와 동작원리에 대한 상세한 내용
7) 요청자(요청부서)
8) 정량, 정성적 수익
 - 해당 요구사항이 비지니스에 미치는 수익(매출성장) 관점 영향도 분석 내용
9) 비고
 - 히스토리, 예외 사유 등을 기록

* 출처: https://brunch.co.kr/@toqha7822/15

메뉴 구조도는 시스템에 구축되어 있는 (1)메뉴와 화면이 서로 연결되어 있는 구조(2)화면의 종류
한 눈에 볼 수 있도록 시각화해놓은 표를 의미합니다.

Depth1 -> 메뉴 종류
Depth2 -> 메뉴 內 화면 종류
Depth3 -> 화면 內 섹션 별 구성요소의 역할

 

출처 : https://kun-hee.tistory.com/52

 

문서 히스토리를 남기는 것은 프로젝트가 착수되는 시점부터 문서가 사용되는 최신 시점까지 상황에 따라 의도와 방향이 달라진 점과 날짜, 작성자를 기록하는 작업입니다.

 

 

주로 문서 앞 일부를 차지하는 문서 히스토리 페이지는 업무에 대한 디테일한 내용이 아니라 중요하지 않게 여겨집니다.

하지만, 프로젝트를 통해 시스템을 만들고 운영하는 관리자는 시스템을 구축/운영할 때 산출되는 문서가 본인의 자산이며 실력을 반증하는 도구가 됩니다.

 

  • 과거 현업 또는 개발사에게 들었던 내용과 본인이 말했던 내용 중 아무리 중요한 내용이라 할지라도,
    사람이라면 시간이 지남에 따라 기억이 왜곡되거나 없어질 수 있습니다.
  • 불과 1주일 전 자신의 입장과 의도가 지금과 동일하다는 보장은 아무도 할 수 없습니다.

 

히스토리가 빠짐없이 작성된 문서는 시행착오를 줄여주며 당시의 상황과 의도를 파악하는데 중요한 역할을 하게 됩니다.

대체로 큰 규모의 프로젝트일수록 문서 히스토리 기록의 중요도가 높아집니다.

 

히스토리가 기록되지 않은 문서는 현 시점에 참고해도 이슈가 없을지, 어떤 이유로 현재 상황에 도달하게 되었는지 확인할 길이 없으며, 과거의 상황을 모르고 의도를 오해하는 일을 만들게 됩니다.

 

 

* 문서 히스토리 페이지 구성요소
1) 버전
 - 정수 : 실제 운영이 가능한 버전 (현업 제공o)
 - 소수점 : 실제 운영과 유사한 환경에서 테스트를 위해 배포한 버전 (현업 제공x)
2) 개정일자
3) 변경내용
 - 문서가 변경된 이유에 대한 요약 설명
 - 현업과 개발사 간 의사결정이 완료되어 문서화된 내용이 반영되었다면 기록
4) 작성자 (부서+이름+직무)
5) 승인자

 

+ Recent posts