리스크란? 프로젝트 리스크 관리

 

리스크(Risk)이란 무엇인가?

"Tomorrow problems are today's risk."

따라서 "리스크"의 명확한 정의는 일부 손실(loss)을 초래하거나 프로젝트 진행을 위협(threaten)할 수 있지만 아직 발생하지 않은 문제입니다(has not happened yet).  이러한 잠재적인 문제는 프로젝트의 비용(cost), 일정(schedule) 또는 기술적 성공과 소프트웨어 장치(device)의 품질(quality ) 또는 프로젝트 팀 사기(morale)에 해를 끼칠 수 있습니다.

리스크 관리는 이러한 문제가 프로젝트를 손상시키기 전에 이러한 문제를 식별하고 제거하는 시스템입니다.
프로젝트의 현재 문제와 잠재적인 문제인 리스크를 구분해야 합니다.

이 두 가지 문제를 해결하려면 다른 방법이 필요합니다.

예를 들어, 적절한 기술을 가진 사람을 뽑지 못해서 직원을 비축하는 것이 현재 문제이지만, 경쟁 회사에 의해 우리 기술 인력이 채용될 리스크가 있습니다.

위험(risk)와 이슈(issue)에 대해

 

 

리스크 관리 (Risk Management) 구분

소프트웨어 프로젝트는 매우 다양한 리스크와 관련될 수 있습니다. 소프트웨어 프로젝트에 영향을 미칠 수 있는 중대한 리스크를 체계적으로 식별하는 데 능숙하기 위해서는 리스크를 여러 등급으로 분류하는 것이 필수적입니다. 그런 다음 프로젝트 관리자는 각 클래스의 어떤 리스크가 프로젝트와 관련이 있는지 확인할 수 있습니다.

소프트웨어 프로젝트에 영향을 줄 수 있는 리스크에는 세 가지 주요 분류가 있습니다.

1. 프로젝트 리스크
   프로젝트 리스크: 프로젝트 리스크에 대한 우려는 예산, 일정, 인력, 자원 및 고객 관련 문제의 다양한 형태입니다. 중요한 프로젝트 리스크는 일정 슬리피지입니다. 소프트웨어는 무형이기 때문에 소프트웨어 프로젝트를 모니터링하고 제어하기가 매우 어렵습니다. 식별할 수 없는 것을 제어하는 ​​것은 매우 어렵습니다. 자동차 제조와 같은 모든 제조 프로그램의 경우 계획 집행자는 제품이 모양을 갖추는 것을 인식할 수 있습니다.
   
   
2. 기술적 리스크
   기술적 리스크는 잠재적인 방법, 구현, 인터페이스, 테스트 및 유지 관리 문제와 관련됩니다. 또한 모호한 사양, 불완전한 사양, 사양 변경, 기술적 불확실성 및 기술적 진부화로 구성됩니다. 대부분의 기술적 리스크는 프로젝트에 대한 개발 팀의 지식 부족으로 인해 나타납니다.
   
   
3. 비즈니스 리스크
   이러한 유형의 리스크에는 아무도 필요로 하지 않는 우수한 제품을 구축하거나, 예산 또는 인력 투입을 상실하는 등의 리스크가 포함됩니다.

기타 리스크 범주

1. 알려진(Known) 리스크: 프로젝트 프로그램, 계획이 개발되는 비즈니스 및 기술 환경, 보다 신뢰할 수 있는 데이터 소스(예: 비현실적인 납기일)에 대한 신중한 평가 후 발견할 수 있는 리스크
2. 예측 가능한(Predictable) 리스크: 이전 프로젝트 경험에서 가정된 리스크(예: 과거 회전율)
3. 예측할 수 없는(Unpredictable) 리스크: 발생할 수 있고 실제로 발생하지만 사전에 식별하기가 극히 어려운 리스크.

 

 

리스크 관리 원칙 (Principle of Risk Management)

• Global Perspective (글로벌 관점)
  여기서는 더 큰 시스템 설명, 설계 및 구현을 검토합니다. 우리는 기회와 리스크가 미칠 영향을 봅니다.
• Take a forward-looking view (미래 지향적 관점)
  미래에 나타날 수 있는 위협을 고려하고 다음 이벤트를 지시하기 위한 미래 계획을 작성하십시오.
• Open Communication (열린 의사소통)
  클라이언트와 팀원 간의 자유로운 의사소통을 허용하여 리스크에 대한 확신을 가질 수 있도록 합니다.
• Integrated management (통합 관리)
  이 방법에서 리스크 관리는 프로젝트 관리의 필수적인 부분이 됩니다.
• Continuous process (지속적인 프로세스)
  이 단계에서는 리스크 관리 패러다임 전반에 걸쳐 리스크를 지속적으로 추적합니다.

 

 

리스크 관리 활동 (Risk Management Activities)

리스크 관리는 그림과 같이 세 가지 주요 활동으로 구성됩니다.

JavaTpoint

 

 

리스크 관리 활동

리스크 평가 (Risk Assessment)

리스크 평가의 목적은 리스크를 손실 조건으로 분할하여 잠재성을 유발하는 것입니다. 리스크  평가를 위해서는 먼저 모든 리스크를 두 가지 방법으로 평가해야 합니다.

• 리스크가 현실화될 가능성(r로 표시).
• 문제의 결과는 해당 리스크(s로 표시)와 관련됩니다.

이 두 가지 방법을 기반으로 각 리스크의 우선순위를 추정할 수 있습니다.

 p = r * s

p는 리스크를 통제해야 하는 우선순위, 
r은 리스크가 사실이 될 확률, 
s는 리스크가 사실이 되어 발생하는 손실의 심각도입니다. 
식별된 모든 리스크가 설정되면 가장 가능성이 높고 피해가 큰 리스크를 먼저 제어할 수 있으며 이러한 리스크에 대해 보다 포괄적인 리스크 완화 방법을 설계할 수 있습니다.

 

1. 리스크 식별(Risk Identification)

프로젝트 관리자는 효과적인 리스크 관리 계획을 세워 리스크의 영향을 줄일 수 있도록 가능한 한 빨리 프로젝트의 리스크를 예측해야 합니다.
프로젝트는 매우 다양한 리스크가 존재합니다. 중대한 리스크를 식별하기 위해서는 프로젝트에 영향을 미칠 수 있습니다. 리스크의 클래스를 다양한 리스크로 분류할 필요가 있습니다.
소프트웨어 프로젝트에 영향을 줄 수 있는 다양한 유형의 리스크가 있습니다.

• 기술(Technology) 리스크: 시스템 개발에 사용되는 소프트웨어 또는 하드웨어 기술에서 발생하는 리스크.
• 사람(People) 리스크: 개발 팀의 사람과 연결된 리스크입니다.
• 조직적(Organizational) 리스크: 소프트웨어가 개발되고 있는 조직적 환경에서 발생하는 리스크.
• 도구(Tools) 리스크: 시스템을 만드는 데 사용되는 소프트웨어 도구 및 기타 지원 소프트웨어에서 발생하는 리스크.
• 요구사항(Requirement) 리스크: 고객 요구 사항의 변경 및 요구 사항 변경 관리 프로세스에서 발생하는 리스크.
• 추정(Estimation) 리스크: 시스템을 구축하는 데 필요한 자원의 관리 추정에서 가정하는 리스크

 

2. 리스크 분석(Risk Analysis)

리스크 분석 프로세스 중에 식별된 모든 리스크를 고려하고 해당 리스크의 가능성과 심각성을 인식해야 합니다.
이 작업을 수행하는 간단한 방법은 없습니다. 이전 프로젝트에 대한 인식과 경험, 그리고 그 과정에서 발생하는 문제에 의존해야 합니다.

각 리스크의 확률과 심각성을 수치적으로 정확하게 추정하는 것은 불가능합니다. 대신 다음과 같은 여러 대역 중 하나에 리스크를 승인해야 합니다.

• 리스크 확률은 매우 낮음(0-10%), 낮음(10-25%), 보통(25-50%), 높음(50-75%) 또는 매우 높음(+75%)으로 결정될 수 있습니다.
• 리스크의 영향은 치명적(계획의 존속을 위협), 심각(상당한 지연을 일으킬 수 있음), 허용 가능(지연은 허용된 우발 상황 이내) 또는 미미한 것으로 결정될 수 있습니다.

 

리스크 통제 (Risk Control)

원하는 결과를 얻기 위해 리스크를 관리하는 프로세스입니다. 결국 계획의 식별된 리스크가 결정됩니다. 프로젝트는 가장 해롭고 가장 가능성이 높은 리스크를 포함하도록 만들어져야 합니다. 다른 리스크에는 다른 억제 방법이 필요합니다. 사실, 대부분의 리스크는 리스크를 처리하는 프로젝트 관리자의 독창성이 필요합니다.

리스크 관리 계획에는 세 가지 주요 방법이 있습니다.

• 리스크 회피
  작업 범위를 줄이기 위해 요구 사항을 변경하기 위해 클라이언트와 논의하고, 인적 자원 이직의 리스크를 피하기 위해 엔지니어에게 인센티브를 제공하는 등 여러 가지 방법이 필요할 수 있습니다.
• 리스크 이전
  이 방법에는 제3자가 개발한 리스크 요소를 가져오고, 보험에 가입하는 등이 포함됩니다.
• 리스크 감소
  리스크로 인한 손실을 포함하는 계획 방법을 의미합니다. 예를 들어, 일부 핵심 인력이 떠날 리스크가 있는 경우 새로운 채용을 계획할 수 있습니다.

 

리스크 레버리지: 리스크를 처리하는 다양한 방법 중에서 선택하려면 프로젝트 계획에서 리스크를 통제하는 정도와 그에 따른 리스크 감소를 고려해야 합니다. 이를 위해 다양한 리스크의 리스크 레버리지를 추정할 수 있습니다.

리스크 레버리지는 리스크 노출의 변동을 리스크 감소량으로 나눈 값입니다.

Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of reduction)

risk exposure before reduction : 감소 전 리스크 노출
risk exposure after reduction : 감소 후 리스크 노출
cost of reduction : 감소 비용

1. 리스크 계획 (Risk planning)
   리스크 계획 방법은 식별된 각 주요 리스크를 고려하고 이러한 리스크를 유지하기 위한 방법을 개발합니다. 각 리스크에 대해 리스크에서 식별된 문제가 발생할 경우 계획의 중단을 최소화하기 위해 취할 수 있는 행동을 생각해야 합니다.
   또한 문제를 예상할 수 있도록 계획을 모니터링하는 동안 수집해야 할 수 있는 데이터에 대해서도 생각해야 합니다.
   다시 말하지만, 비상 계획을 위해 따를 수 있는 쉬운 프로세스는 없습니다. 그것은 프로젝트 관리자의 판단과 경험에 의존합니다.
   
   
2. 리스크 모니터링 (Risk Monitoring)
   리스크 모니터링은 제품, 프로세스 및 비즈니스 리스크에 대한 가정이 변하지 않았다는 방법의 왕입니다.

 

---

 

 

프로젝트 일정 (Project Scheduling)

프로젝트 작업 스케줄링은 중요한 프로젝트 계획 활동입니다. 이는 언제 어떤 기능을 사용할 것인지 결정하는 것으로 구성됩니다. 프로젝트 계획을 예약하기 위해 소프트웨어 프로젝트 관리자는 다음을 수행하려고 합니다.

1. 프로젝트를 완료하는 데 필요한 모든 기능을 식별합니다.
2. 큰 기능을 작은 활동으로 나눕니다.
3. 다양한 활동 간의 종속성을 결정합니다.
4. 활동을 완료하는 데 필요한 시간 동안 가장 가능성 있는 크기를 설정합니다.
5. 활동에 자원을 할당합니다.
6. 다양한 활동의 ​​시작 날짜와 종료 날짜를 계획합니다.
7. 임계 경로를 결정합니다. 중요한 방법은 프로젝트 기간을 결정하는 활동 그룹입니다.

소프트웨어 계획을 계획하는 첫 번째 방법은 프로젝트를 완료하는 데 필요한 모든 기능을 식별하는 것입니다. 프로젝트와 개발 프로세스의 복잡성에 대한 올바른 판단은 감독자가 프로젝트의 중요한 역할을 효과적으로 식별하는 데 도움이 됩니다.

다음으로, 큰 기능은 다양한 엔지니어에게 할당될 유효한 작은 활동 세트로 나뉩니다. 작업분류체계 형식주의는 프로젝트 관리자가 목적을 분류하고 작업분류체계를 구축한 후 관리자가 기능을 체계적으로 분해할 수 있도록 지원한다. 그는 활동 사이의 종속성을 찾아야 합니다. 다양한 활동 간의 종속성은 다양한 이벤트가 수행되는 순서를 결정합니다.
활동 A가 다른 활동 B의 결과를 필요로 하는 경우 활동 A는 활동 B 이후에 예약되어야 합니다. 일반적으로 기능 종속성은 기능 간의 부분 순서를 설명합니다. 즉, 각 서비스가 다른 기능의 하위 집합보다 선행할 수 있지만 일부 기능은 그들 사이에 우선 순위가 설명되지 않을 수 있습니다(동시 함수라고 함). 활동 간의 종속성은 활동 네트워크의 패턴으로 정의됩니다.

활동 네트워크 표현이 처리되면 모든 활동에 리소스가 할당됩니다. 리소스 할당은 일반적으로 Gantt 차트를 사용하여 수행됩니다. 자원 할당이 완료된 후 PERT 차트 표현이 개발됩니다. PERT 차트 표현은 프로그램 모니터링 및 제어에 유용합니다. 작업 스케줄링을 위해 프로젝트 계획은 프로젝트 기능을 일련의 활동으로 분해해야 합니다. 모든 활동이 수행되어야 하는 시간 프레임이 결정됩니다. 모든 작업의 ​​끝을 이정표라고 합니다. 프로젝트 관리자는 이정표의 적시 완료를 감사하여 프로젝트의 기능을 추적합니다. 그가 이정표가 지연되기 시작하는 것을 조사한다면, 그는 완전한 마감일을 여전히 충족할 수 있도록 활동을 신중하게 처리해야 합니다.

 

 

인사 계획 (Personnel Planning)

인사 계획은 직원 채용을 다룹니다. 직원 배치는 조직 구조에 의해 식별되는 직책에 대해 임명된 직원을 처리합니다.
여기에는 다음이 포함됩니다.

• 인력에 대한 요구 사항 정의
• 모집(후보자 식별, 인터뷰 및 채용)
• 보상 (Compensating)
• 에이전트 개발 및 촉진

인사 계획 및 일정 수립을 위해 시스템의 하위 시스템 및 필요한 구성 요소에 대한 노력과 일정 크기를 갖는 것이 도움이 됩니다. 계획 시간에 시스템 방법이 완료되지 않은 경우 계획자는 시스템의 대형 하위 시스템과 이러한 하위 시스템의 주요 모듈에 대해서만 알 수 있다고 생각할 수 있습니다.

프로젝트 계획이 예상되고 다양한 단계와 기능의 노력과 일정이 알려지면 직원 요구 사항을 달성할 수 있습니다.
프로젝트의 비용과 전체 기간에서 프로젝트의 평균 직원 규모는 총 노력(인-월)을 전체 프로젝트 기간(월)으로 나누어 결정할 수 있습니다.

일반적으로 프로젝트에 필요한 인력은 요구 사항 및 설계 중에 적으며 구현 및 테스트 중에 최대이며 통합 및 테스트의 마지막 단계에서 다시 감소합니다.
COCOMO 모델을 사용하여 각 방법에 대한 노력과 일정을 알고 있으므로 다양한 단계에 대한 평균 인력 요구 사항을 계산할 수 있습니다.

모든 작업에 대한 일정과 평균 직원 수준을 알면 프로젝트에 대한 전체 인력 할당을 계획할 수 있습니다.
이 계획은 프로젝트 기간 동안 다른 시간에 다른 활동에 얼마나 많은 사람들이 필요한지를 나타냅니다.
이 계획에서 월별 총 노력과 각 단계의 총 노력을 쉽게 계산할 수 있습니다.

소프트웨어 추정 모델, 코코모 (COCOMO Model)

 

팀 구조 (Team Structure)

팀 구조는 개별 프로젝트 팀의 배열 문제를 다룹니다. 다른 프로젝트 팀을 구성할 수 있는 몇 가지 가능한 방법이 있습니다. 주로 세 가지 공식 팀 구조가 있습니다. 수석 프로그래머, 자아가 없거나 민주적이며 혼합 팀 조직은 이러한 구조에 대한 몇 가지 다른 변형도 가능합니다. 다양한 복잡성과 규모의 문제는 종종 주요 솔루션에 대해 서로 다른 팀 구조를 필요로 합니다.

자아가 없는 팀 또는 민주적인 팀 (Ego-Less or Democratic Teams)

Ego-Less 팀은 적은 수의 프로그래머로 구성된 팀으로 구성됩니다. 그룹의 목표는 합의에 의해 설정되고 각 구성원의 의견은 중요한 결정에 적용됩니다. 그룹 리더십은 그룹 구성원들 사이에서 이루어집니다. 그 특성상 자아가 없는 팀은 지속적으로 민주적인 팀으로 알려져 있습니다.

구조는 모든 대표자의 의견을 허용하므로 다양한 문제에서 더 나은 결정을 내릴 수 있습니다. 이는 이 방법이 시간적 제약이 없는 장기 연구형 프로젝트에 적합함을 시사한다.

 

수석 프로그래머 팀 (Chief Programmer Team)

자아가 없는 팀과 달리 수석 프로그래머 팀에는 계층 구조가 있습니다. 백업 프로그래머가 있는 수석 프로그래머, 프로그램 사서 및 일부 프로그래머로 구성됩니다.
수석 프로그래머는 프로젝트의 모든 주요 기술 결정에 필수적입니다.
그는 대부분의 디자인을 수행하고 디자인의 다른 부분에 대한 코딩을 프로그래머에게 할당합니다.

백업 프로그래머는 수석 프로그래머를 사용하여 기술적인 결정을 내리고 수석 프로그래머가 병이 나거나 떠나는 경우 수석 프로그래머를 대신합니다.
프로그램 사서는 문서 및 기타 커뮤니케이션 관련 작업을 유지 관리하는 데 중요합니다.
이 구조는 대인 커뮤니케이션을 상당히 감소시킵니다.

 

통제된 분산 팀 (Controlled Decentralized Team)

계층적 팀 구조 - Hierarchical Team Structure

통제된 분산 팀으로 알려진 세 번째 팀 구조는 민주주의 팀과 수석 프로그래머 팀의 강점을 결합하려고 합니다.
그것은 그 아래에 수석 프로그래머 클래스가 있는 프로젝트 리더로 구성되며, 모든 시니어 프로그래머 아래에는 주니어 프로그래머 그룹이 있습니다.
선배 프로그래머 그룹과 후배 프로그래머 그룹은 에고 없는 팀처럼 행동하지만 다른 그룹 간의 의사 소통은 그룹의 수석 프로그래머를 통해서만 발생합니다.

선임 프로그래머는 또한 프로젝트 리더와 의사 소통합니다.
이러한 팀은 민주적 팀보다 의사소통 경로가 적지만 수석 프로그래머 팀에 비해 경로는 더 많습니다.
이 구조는 합리적으로 간단한 대규모 프로젝트에 가장 적합합니다. 단순한 프로젝트나 연구형 프로젝트에는 적합하지 않습니다.