소프트웨어 개발의 위험을 관리하는 이유와 방법

이 기사에서는 소프트웨어 개발 프로세스에서 위험 관리에 대한 접근 방식에 대해 설명합니다. 우리는 또한 비즈니스 및 개발 관점에서 위험 관리의 중요성에 주목하고 위험 관리 계획의 예를 제공합니다.

2019년 11월 12일 디즈니는 오리지널 콘텐츠를 제공하는 넷플릭스와 같은 스트리밍 서비스인 디즈니 플러스를 출시했습니다. 수천 명의 사용자가 Pixar, Marvel, Star Wars 및 기타 여러 프랜차이즈의 콘텐츠를 즐기기 위해 월 7달러 이상을 지불할 준비가 되었습니다.

열망하는 시청자들은 비용을 지불한 콘텐츠 대신 며칠 동안 정전 화면을 보는 것에 실망했습니다. 불만은 로그인 문제부터 스트리밍 불가능, 앱 오류, 라이브러리에서 사라지는 쇼와 영화에 이르기까지 다양했습니다.

디즈니는 이러한 문제가 "높은 기대치"를 초과하는 수요 때문이라고 설명했습니다.

이것은 소프트웨어 개발에서 기술적인 위험 관리 가 제대로 이루어지지 않은 전형적인 예입니다.
디즈니가 이러한 정전을 피할 수 있었을까요? 예.
비슷한 문제를 피할 수 있습니까? 또한 그렇습니다.
이 기사에서는 소프트웨어 개발의 위험 관리 및 위험 완화에 대해 자세히 설명합니다.

리스크 관리의 중요성

모든 비즈니스는 고유하며 모든 위험을 완전히 예측할 수 있는 것은 아닙니다. 그러나 병목 현상을 식별하고, 위험이 발생할 가능성을 계산하고, 발생할 경우 부정적인 영향을 예측하는 데 도움이 되는 몇 가지 접근 방식이 있습니다.

위험 관리는 기업이 위험의 영향을 피하거나 개선하기 위해 수행할 수 있는 일련의 복잡한 활동입니다.

위험 관리의 목적은 무엇이 잘못될 수 있는지 , 왜 잘못될 수 있는지, 잘못될 경우 어떤 영향을 미치고 어떻게 수정해야 하는지를 아는 것입니다. 미리 경고합니다.

적절한 위험 관리의 장점은 위험이 현실화되어도 기업이 고통을 덜 받는 데 도움이 된다는 것입니다.

위험 관리는 다음과 같은 이점을 가져올 수 있습니다.

• 예측 가능하고 피할 수 있는 비상 사태에 대한 비용 절감을 통한 비용 절감
• 개발 팀이 예상치 못한 문제를 수정하는 것이 아니라 개발에 집중할 수 있도록 하여 더 빠르게 작업할 수 있는 능력
• 예상치 못한 문제를 해결하기 위해 추가 자금을 유치할 필요가 없어 더욱 스마트한 지출
• 비상시에도 모든 것을 통제할 수 있도록 고객을 보장함으로써 더 나은 평판

위험 유형

경험이 없는 기업가는 사업에 나쁜 일이 일어나지 않기를 바랍니다. 경험 많은 기업가는 나쁜 일이 일어날 것을 알고 미리 대비합니다.

그러면 무엇이 잘못될 수 있습니까? 기본적으로 아무거나. 다양한 위험 관리 접근 방식은 다양한 유형의 위험을 다룹니다. 기업에 대한 가장 일반적인 위험 범주는 다음과 같습니다.

• 인적 위험 — 팀원의 갑작스러운 질병, 임신, 체포, 사망 또는 경력 변경은 성과 지연에서 다른 팀원에게 기능 위임에 이르기까지 다양한 결과를 초래할 수 있습니다.

• 위치 또는 지리적 위험 — 모든 위치에는 워크플로에 영향을 줄 수 있는 기후, 정치적 상황, 시간대 및 작업 전통과 같은 특정 문제가 있습니다.

• 전략적 위험 — 문제 계획, 잘못된 전략 선택, 관리 부실 등은 처음부터 예측할 수 없지만 주요 위험 요소로 간주되어야 합니다.

• 운영 또는 관리 위험 — 이는 전략적 위험에 매우 가깝지만 실행에 관한 것입니다. 구현 문제, 잘못된 작업 종속성, 잘못된 관리, 느린 의사 결정, 잘못된 우선 순위 지정 및 기타 여러 운영 문제로 인해 비즈니스 개발이 지연되거나 막대한 비용이 발생할 수 있습니다. 극복하다.

• 법적 위험 — 최소한 특정 지역에서 사업을 할 수 있는지 알아보기 위해 특정 지역의 법률과 규정을 연구하는 것이 좋습니다. 또한 법률이 변경되는 경향이 있어 종종 세금 변경 및 공식화 문제로 이어질 수 있습니다. 법적 위험에는 Amazon, Apple App Store 및 Google Play와 같은 비즈니스 플랫폼의 규칙 및 규정 변경도 포함됩니다.

• 기술적 위험 — 선택한 기술은 문서에서는 완벽해 보이지만 실제로는 다르게 작동할 수 있습니다. 지속적인 업데이트, 운영 환경의 변경, 유지 관리 문제 및 기타 여러 기술적 측면은 비즈니스에 큰 영향을 미칠 수 있습니다.

사업의 종류에 따라 다른 많은 위험 요소가 나타날 수 있으며 위에 나열된 요소가 변경될 수 있습니다. 그러나 이러한 위험을 아는 것은 적절한 위험 관리 전략을 선택하는 데 도움이 됩니다.

위험 관리 전략

위험 관리에 대한 접근 방식은 다양한 요인에 따라 다르지만 가장 일반적인 위험 관리 전략은 다음과 같습니다.

위험 회피

이것은 기업이 위험을 감수하기를 거부하고 활동 수행을 거부하는 급진적인 전략입니다.

실수의 대가가 너무 높은 위험이 있습니다. 예를 들어, 솔루션의 기술적 능력의 한계를 알고 있다면 고부하 프로젝트로 솔루션에 과부하를 주지 않는 것이 현명합니다. 이 경우 실패 비용이 가능한 수익보다 높을 수 있습니다.

간단히 말해서 때로는 실패하지 않기 위해 일부 비즈니스 활동에 참여하지 않는 것이 좋습니다.

장점: 구현이 빠릅니다. 활동을 거부하거나 수락하기만 하면 됩니다.

단점: 테이블에 잠재적인 수익을 남겨둡니다.

좋은 대상: 여러 지점과 수입원이 있는 기업.

다음 경우에 사용: 가능한 위험으로 인한 피해가 활동으로 인한 가능한 이익보다 큽니다.

위험 완화

이것은 부정적인 결과를 완전히 피하는 것보다 덜 심각 하게 만드는 전략입니다.

앞마당에서 레모네이드를 파는 것보다 더 복잡한 사업을 운영할 때 피할 수 없는 문제에 직면할 수 있습니다. 이 경우 이러한 위험의 결과를 식별하고 완화하는 것이 좋습니다.

이것은 특히 소프트웨어 프로젝트에서 알려진 특정 위험에 대해 작동합니다. 다가오는 문제에 대해 고객에게 경고하거나 임시 솔루션을 제공하십시오. 클라이언트는 만족하지 않을 수 있지만 최소한 당신이 그들을 돌보는 것을 느낄 것 입니다. 예를 들어 맥도날드는 주문을 90초 이상 기다리면 무료 아이스크림 쿠폰을 준다.

장점: 위험을 제거하기 위해 리소스를 낭비하지 않습니다. 대신 그 결과를 다루면서 덜 심각하게 만들려고 노력하는데, 이는 종종 훨씬 더 쉽습니다.

단점: 귀하와 귀하의 고객은 여전히 ​​위험의 부정적인 결과를 처리해야 합니다.

좋은 대상: 충성도 높은 고객이 있는 기업, 타이밍에 민감한 기업, 서비스 제공업체.

다음 경우에 사용: 위험을 완전히 피할 수는 없지만 서비스는 여전히 정시에 제공되어야 합니다. 긴급 상황.

위험 이전

이 전략을 사용하면 부정적인 결과를 처리하기 위해 다른 사람에게 비용을 지불합니다.
비즈니스에서 특정 위험을 처리할 수 없는 경우 도움을 받으십시오. 이는 소프트웨어 개발의 위험 관리에 매우 비용이 많이 드는 접근 방식일 수 있지만 결과는 고객의 기대를 충족시키고 비즈니스를 계속 진행시킬 수 있습니다. 또한 승무원이 원하지 않는 더러운 작업에서 해방되어 집중력이 향상되고 결과적으로 품질이 향상된다는 맥락에서도 좋습니다.

장점: 간단하고 대부분 빠르게 수행할 수 있습니다.

단점: 많은 비용이 들 수 있으며 비즈니스의 일부에 대한 통제력이 떨어집니다.

좋은 대상: 일부 구성 요소에 대한 부하가 높은 기업 또는 전문 지식이 많지 않은 기능을 구현하는 기업.

다음 경우에 사용: 자신의 전문 지식을 얻거나 전문가를 교육할 시간 없이 활동을 빠르고 잘 수행해야 합니다.

위험 수용

이름에서 알 수 있듯이 이 전략을 사용하면 위험의 모든 부정적인 결과를 수용할 수 있습니다.

비즈니스 활동의 이익이 가능한 위험의 영향보다 훨씬 더 큰 경우가 있을 수 있습니다. 이 경우 기업이 위험을 감수하는 것은 괜찮습니다. 그러나 사용자는 위험 수용의 결과에 대해 경고해야 합니다.

Microsoft는 Windows XP와 같은 제품의 이전 버전 유지 관리를 중단할 때 이 전략을 사용합니다.

장점: 리소스가 거의 필요하지 않습니다.

단점: 모든 부정적인 결과를 얻습니다.

좋은 대상: 기존 기능을 지원하는 것보다 새로운 기능을 구현하는 것이 더 중요한 기존 비즈니스.

사용: 활동이 대다수 사용자에게 해를 끼치지 않거나 사용자에게 전달된 활동의 이익이 가능한 불편함보다 높을 때.

이러한 전략 중 어느 것도 만병통치약이 아니라는 점에 유의하십시오. 다른 종류의 위험은 기술적 위험과 함께 진행되어 작업 결과에 영향을 미칠 수 있습니다. 그리고 대부분의 경우 특정 프로젝트에 대한 위험 관리 전략은 비즈니스의 특별한 측면을 고려하여 위의 전략을 혼합한 것입니다 .

애자일 방법론을 사용하여 위험을 관리하는 방법(예시)

이것이 소프트웨어 개발 위험 관리 전략이 Mind Studios를 바라보는 방식입니다.

1단계. 위험 식별

시기: 프로젝트 평가 단계 중

이 단계에서 프로젝트 관리자는 브레인스토밍 세션을 위해 개발자와 디자이너 팀을 모아 모든 가능한 위험과 위험을 유발할 수 있는 요소를 찾습니다.

필요한 단계:

• 이전 프로젝트에서 겪었던 문제를 기억하십시오. 알려진 모든 미지의 것을 발견하려고 노력하십시오
• 이 특정 프로젝트에서 모든 종류의 위험이 발생할 가능성이 있는 영역을 정의합니다.
• 제품을 개발하는 동안 직면할 수 있는 모든 요소의 영향을 평가합니다.

2단계: 위험 분석 및 평가

시기: 프로젝트 평가 단계 직후

이 단계에서는 위험을 식별한 다음 분류합니다. 여기에서 프로젝트 관리자는 위험의 가능한 영향과 위험이 발생할 확률도 분석합니다. 이 단계에서는 프로젝트의 복잡성, 테스트 품질 및 개발 팀 간의 종속성을 고려하는 것이 좋습니다.

이 단계의 결과는 모든 종류의 위험에 대해 정의된 결과 목록입니다.

• 고객의 손실 가능성
• 비즈니스에 발생할 수 있는 문제
• 평판 손실
• 법적인 문제

3단계: 위험 관리 계획을 수립하고 클라이언트와 함께 승인

시기: 개발 시작 직전

이 단계에서 프로젝트 관리자는 위험 관리 활동 을 계획으로 공식화합니다 . 일반적으로 프로젝트의 위험 관리 계획은 다음 열이 있는 테이블입니다.

• 위험 정의

발생할 수 있는 문제를 정의하고 하나의 짧은 문장으로 설명합니다. 정의는 한 눈에 봐도 명확하게 이해되어야 하므로 '서버 전원 부족', '사용자 콘텐츠 업로드 불가', '플레이 스토어 출시 지연' 등 최대한 짧게 문제를 설명하는 경향이 있습니다. 명확하고 문제에 집중하십시오.

• 방아쇠

위험이 구체화되었는지 여부를 알 수 있는 방법을 설명합니다. 문제에 대해 정확히 무엇을 말하고 어떻게 보일 수 있습니까? 트리거가 다른 소스에서 올 수 있는 경우 모두 이름을 지정해야 합니다. 확률이나 값에 따라 트리거 소스 목록의 우선 순위를 지정해도 됩니다.

• 확률(점수)

우리는 위험이 발생할 가능성을 정의합니다. 가능한 위험의 수와 중요도에 따라 최대 및 최소 점수(예: 100 및 1)를 제안합니다. 위험 가능성이 높을수록 점수가 높아집니다.

• 임팩트(점수)

이 열에서는 각 위험 유형의 심각도를 점수화합니다.

• 가치(점수)

특정 위험이 프로젝트에 얼마나 중요한지 정의합니다. 숫자가 높을수록 우선 순위가 높습니다. Mind Studios에서는 일반적으로 영향과 확률 점수를 곱하여 위험의 가치를 정의합니다. 그러나 비즈니스의 요구 사항과 특성에 따라 이 값을 원하는 대로 정의할 수 있습니다.

• 주요 전략

위험을 관리하기 위해 사용할 기본 전략 또는 접근 방식의 이름을 지정합니다(예: 이전, 완화 또는 수락).

• 대체 전략(가능한 경우)

주 전략이 허용되지 않는 경우 보조 전략을 명명합니다. 예를 들어 현재 위험을 이전할 수 없는 경우 완화 프로세스를 시작할 수 있습니다. 모든 종류의 위험에 대해 가능한 한 많은 전략을 만드는 것이 좋습니다.

• 선택한 전략에 대한 실행 계획

이것은 전략의 가장 상세한 부분으로, 구현을 위한 단계별 가이드를 작성합니다. 결과적으로 우리는 모든 종류의 위험이 발생할 경우 우리가 할 일에 대한 명확한 계획을 세워야 합니다. 우리는 단계에 번호를 매기고 관련 담당자와 책임 있는 사람의 연락처를 포함하며 모든 단계를 가능한 한 명확하고 자세하게 기록합니다.

우리는 프로젝트에 대해 고려하는 모든 기본 및 대체 전략에 대한 실행 계획을 만듭니다.

다음 은 Mind Studios에서 사용 하는 기술적 위험 관리 계획의 예입니다 .

[구글 시트]

4단계: 위험 모니터링

언제: 첫날부터 배경에서; 모든 개발 스프린트 후 확인

해결된 위험이 다시 발생하지 않는다는 보장은 없습니다. 이것이 위험 모니터링이 소프트웨어 프로젝트의 활동 목록에 통합되어야 하는 이유입니다. 트리거는 사용자 피드백 및 QA 보고서에서도 식별할 수 있습니다. 모든 추가 개발 스프린트에 위험 모니터링 활동을 포함합니다.

모든 위험 관리 활동은 특히 소프트웨어 개발을 아웃소싱할 때 고객과 ​​합의해야 합니다. 모든 비용, 구체화 가능성 및 심각도는 가능한 한 명확해야 합니다. 고객은 비용을 지불하고 모든 유형의 위험을 담당하는 사람을 알아야 합니다. 클라이언트의 기대와 클라이언트의 예산 에서 수용 가능한 절충안을 찾으십시오.

비즈니스 위험

비즈니스 위험을 언급하지 않고 위험 관리에 대한 대화를 완료할 수 없습니다. 위에서 언급한 것과 같은 프로젝트 위험에 대처할 때 좋습니다. 그러나 개발 중이고 경쟁자가 유사한 제품을 더 빨리 출시하거나 킬러 기능을 갖춘 제품을 출시할 것이라는 사실을 알게 되었다고 상상해 보십시오. 이 상황에서 자신을 발견한다는 것은 프로젝트 위험을 잘 처리하지 못하더라도 비즈니스 위험을 관리하는 것을 잊었다는 것을 의미합니다.

비즈니스 위험은 비즈니스 의 목표나 대상을 위협하는 비즈니스 외부의 모든 것입니다. 경쟁사, 규제 기관, 경제 또는 기타 여러 가지에 의한 갑작스러운 변화일 수 있습니다.

비즈니스 위험 관리에는 다른 문서의 가치가 있는 다른 여러 단계와 단계가 수반됩니다. 그러나 다음은 몇 가지 일반적인 팁입니다.

1. 시장을 주시하라

기발한 사업 아이디어가 있다고 해서 다른 사람이 비슷한 아이디어를 가지고 있지 않다는 보장은 없습니다. 시장 현황을 파악하고 잠재적이고 활동적인 경쟁자를 주시하기 위해 정기적인 시장 조사 및 분석을 수행하십시오.

2. 제품 시장 적합성 작업

귀사의 제품이 강력한 시장 수요를 충족시킬 수 있는지 확인하십시오. 새로운 시장 상황이 비즈니스 성과에 영향을 미치는 경우 제품 시장 적합성을 재고해야 합니다. 제품 개발뿐만 아니라 비즈니스 개발에도 민첩하게 대처하십시오. 개선하고 혁신하고 주저하지 말고 선회하십시오.

소프트웨어 개발의 위험 완화: 결론

일반적으로 적절한 위험 관리는 제품 작업에 집중하는 데 도움이 됩니다. 적절한 위험 관리를 통해 위험 결과를 극복하는 대신 더 나은 기능과 고품질 제품을 만드는 데 더 많은 리소스가 집중됩니다.

위험 관리를 수행하는 개발자는 자신이 좋아하는 일에 더 많은 작업을 수행할 수 있으며 위험 관리를 수행하는 비즈니스 소유자는 더 행복한 고객, 더 나은 평판 및 창의성을 위한 더 많은 장소를 얻을 수 있습니다.

특정 비즈니스의 위험을 관리하는 방법이 여전히 궁금하십니까? 우리가 도울 수있어!

소프트웨어 프로젝트의 위험이 우려된다면 Mind Studios 프로젝트 관리자가 기꺼이 전문 지식을 공유할 것입니다! 연락하세요.

Tymur Solod와 Alexander Vasyliev가 작성했습니다.