Project Management

mong·2022년 11월 26일

PM Project Management sw 소프트웨어 프로젝트 관리 위기 관리 조직 관리

Software Engineering

목록 보기

2/2

01. SW Project Management

1) SW Project Management

소프트웨어 프로젝트 관리

소프트웨어 프로젝트 관리란?
- 많은 시간과 노력을 필요로 하는 일
- 많은 일들과 연관이 있음
  - 소프트웨어는 일정과 시간에 맞춰서 전달된다.
  - 조직의 요구사항에 따라 소프트웨어를 개발하고 조달한다.
- 프로젝트 관리의 필요성
  - WHY? : 소프트웨어 개발은 항상 소프트웨어를 개발하는 조직에서 설정한 예산 및 일정 제약 조건이 적용되기 때문
성공적인 프로젝트란?
- 고객과 동의한 시간 내에 납품
- 예산 초과 X
- 고객의 기대에 맞게 개발
- 일관성 있는 개발팀을 유지
소프트웨어 관리 구별? distinctions
- product is intangible ( 만질 수 없는)
  - SW는 보거나 만질 수 없다. : SW는 형체가 X → 관리하기 쉽지 X
  - 구현 여부(과정)를 가시적으로 명확하게 볼 수 없다 .
- 많은 소프트웨어 프로젝트들은 일회성 프로젝트이다.
  - 큰 소프트웨어 프로젝트는 주로 이전 프로젝트들과 몇 부분에서 다르다.
  - 매니저가 경험이 많아도 문제를 예상하기 어려울 수 있다. : 경험과 무관하게 새로운 문제에 당면할 수 있기 때문
- 소프트웨어 프로세스는 다양하고 조직에 따라 다르다.
  - 특정 소프트웨어 프로세스가 개발 문제를 일으킬 가능성이 있는 시점을 아직 확실하게 예측할 수 없다.
  - 조직적인 특징 O → 특장점이 있음
프로젝트 관리에 영향을 주는 요소들
- 회사 규모
- SW 고객
- SW 크기
- SW 종류
- 조직 문화
- SW 개발 프로세스
  
  ⇒ 이러한 요소는 다른 조직의 프로젝트 관리자가 매우 다른 방식으로 작업할 수 있음을 의미한다.
  
  : 조직에 따라서 다른 방법으로 관리

관리 활동

보편적인 관리 활동 (feat. PM의 역할) (Universal Management Activities)
1. 계획 수립 (Project planning)
  - 프로젝트 관리자(Project Manager)들은 계획에 책임이 있다.
  - 예측, 스케줄링, 역할 분담 등은 PM이 보통 책임을 가짐
2. 위기 관리 (Risk management)
  - 프로젝트 관리자는 프로젝트에 영향을 미칠 수 있는 위험을 평가하고, 이러한 위험을 모니터링하며 문제가 발생할때 조치를 취한다.
  - 프로젝트 中 발생 가능한 위협 예측 및 행동 방안 수립
3. 사람 관리 (People management)
  - 프로젝트 관리자는 팀을 위한 사람을 선택하고 효과적인 팀 성과로 이어지는 작업 방식을 수립해야 한다.
  - 사람을 어떻게 부릴 지 등 관리
4. (고객사에게) 보고 (Reporting)
  - 프로젝트 관리자는 일반적으로 고객과 소프트웨어를 개발하는 관리자에게 프로젝트 진행을 보고할 의무가 있다.
5. 문서 작성 (Proposal Writing)
  - 소프트웨어 프로젝트의 첫 번째 단계에는 작업 항목을 수행하기 위한 계약을 따내기 위한 제안서 작성이 포함될 수 있다.
  - 제안서는 프로젝트의 목적과 수행 방법을 설명

2) 위기 관리 (Risk Management)

위기 관리란 무엇인가?

위기 관리란?
- SW가 개발되는 데에 있어서 위험 사항을 분석하고 어떻게 반응할지 예측하여 문서를 작성함
  - 비용이나 스케줄이 초과되지 않도록
- 위험 관리는 위험을 식별하고 프로젝트에 미치는 영향을 최소화하기 위한 계획을 세우는 것과 관련이 있다.
소프트웨어 위험 관리의 중요성
- 소프트웨어 개발에 내재된 불확실성 때문
- 이러한 불확실성은 아래 사항들로부터 발생한다.
  - 느슨하게 정의된 요구사항
  - 고객의 필요에 따라 요구사항 변경 & 요구사항 반영이 잘 안 됨
  - 시간과 자원 예측에 어려움이 있어 스케줄을 잘못 짰을 때
  - 개개인의 스킬 차이
위험을 예상하기 위해
- 프로젝트, 제품 및 비즈니스에 대한 이러한 위험의 영향을 이해한다.
- 위험을 피하기 위한 조치를 취한다.
- 문제의 수준 정의 및 handling

위기 분류 (Risk Classification)

위기 분류에는 2가지 차원(?)(dimension)이 있음
- 위기의 종류(type) (기술적, 조직적 …)
- 무엇이 위기에 영향을 받는가
Risk 종류
- 프로젝트 위기 (Project)
  
  : 스케줄 or 자원에 영향을 미침
- 제품 위기 (Product)
  
  : 개발되는 소프트웨어의 품질 or 성능에 영향
- 사업? 위기 (Business)
  
  : 조직적인 개발 방법 or SW 조달
  
  → 명확히 구분되지는 X
  
  ⇒ 하나의 risk가 여러개 영향 O

위기 관리 과정 (Risk management process)

식별 (Risk identification)

: 프로젝트, 제품 및 비즈니스 위협 등 risk 종류 식별
분석 (Risk analysis)

: 식별된 위험의 가능성과 결과 평가
계획 (Risk planning)

: 위험의 영향을 피하거나 최소화하기 위한 계획 수립
모니터링 (Risk monitoring)

: 프로젝트 전반에 걸쳐 위험 모니터링

위험 식별 (Risk identification)

팀 활동일 수도 있고 개별 프로젝트 관리자의 경험을 기반으로 할 수도 있다.
- 경험 多 → 위기 예측 더 Good
일반적인 위험의 체크리스트는 프로젝트의 위험을 식별하는 데 사용할 수 있다.
- 기술 (Technology risks)
- 조직 (Organizational risks)
- 사람 (People risks)
- 요구사항 (Requirements risks)
- 예측과 다름 (Estimation risks)

위험 분석 (Risk Analysis)

각 위험의 확률 및 심각도 평가
발생 빈도(probability)는 매우 낮음, 낮음, 중간, 높음, 매우 높음으로 나뉜다.
→ 우선 순위 부여
위험 결과는 치명적이거나 심각하거나 견딜 수 있거나 중요하지 않을 수 있다.
→ 발생 결과의 영향 level

위험 계획 (Risk planning)

각 위험을 고려하고 해당 위험을 관리하기 위한 전략 개발
- 어떻게 피할지 (Avoidance strategies) : 위험 발생 확률이 감소
- 피해 최소화 (Minimization strategies) : 프로젝트 or 제품에 위험의 임팩트 감소
- 비상 대책 (Contingency plans) : 위험 발생시, 비상 대책으로 그 위험을 처리
‘ What if ‘ questions : ‘만약 ~ 한다면?’ 질문으로 예측하기
- 질문 예시
  - 만약 여러 엔지니어들이 동시에 아프면?
  - 만약 경제 침체로 인해 프로젝트 예산이 감소된다면?
  - 만약 오픈소스 소프트웨어가 성능이 기대 이하라면?
  - 만약 소프트웨어를 지원해주던 기업이 지원을 안 해준다면?
  - 만약 요구사항 전달 일정을 지키지 못한다면?

위기 모니터링 (Risk monitoring)
- 식별된 각 위험을 정기적으로 평가하여 가능성이 낮아지거나 높아지는지 여부를 결정한다.
- 위험의 영향 변경 여부 평가
- 각 주요 위험은 관리 진행 회의에서 논의
  ⇒ Risk 감시 & 우선순위 (재앙수준) 변경 및 추가

3) 사람 관리 (Managing People)

사람 관리 (People Management)

사람 관리?
- 사람은 조직의 가장 중요한 자산이다.
- 관리자의 작업은 기본적으로 사람 중심이다.
  - 사람에 대한 이해가 없으면 관리는 실패한다.
- 열악한 인력 관리는 프로젝트 실패의 중요한 원인이다.

사람 관리 요소
- 일관성 (Consistency) : 팀원 모두가 선호나 차별받지 않고 동등한 대우를 받아야 한다.
- 존중 (Respect) : 팀 구성원마다 기술이 다르며 이러한 차이점을 존중해야 한다.
- 포함 (Inclusion) : 모든 팀원을 빠지지 않고 참여시키고 사람들의 의견을 고려해야 한다.
- 정직함 (Honesty) : 프로젝트에서 잘되고 있는 것과 잘 되지 않는 것에 대해 항상 정직해야 한다. : 프로젝트 진행 척도 및 자기가 맡은 파트에 대해 정직하게!

사람들에게 동기부여 (Motivating people)
- 관리자의 중요한 역할은 프로젝트에 참여하는 사람들에게 동기를 부여하는 것
- 동기 부여는 사람들이 효과적으로 일하도록 격려하기 위해 작업과 작업 환경을 조직하는 것을 의미한다.
- WHAT IF : 동기 X?
  - 자신이 하는 일에 관심 X
  - 천천히 일하고 실수 할 가능성이 UP
  - 팀이나 조직의 더 넓은 목표에 기여 X
  - 동기 부여 유형
    - 기본적 요구 : 음식, 잠 등
    - 개인 요구 : 존중, 자존감 등
    - 사회적 요구 : 그룹의 일원으로서 인정받는 것 등

사람들의 요구사항 계층 (Human needs hierarchy)

요구 만족도
- 소프트웨어 개발 그룹에서 기본적인 생리학적 및 안전 요구 사항은 문제 X
  - 사회적 (Social) : 공동시설 제공 : 소셜 네트워킹을 통해 *비공식 커뮤니케이션 허용
  - 존중 (Esteem) : 성취 식별 : 적절한 보상
  - 자아 실현 (Self-realization) : Train - 더 배우고 싶어하는 사람들 : 책임감

*비공식 커뮤니케이션(informal communication): 감정 공유, 일상적인 토론, 가십 등

성격 유형 (Personality types)

성격 유형
- 욕구 계층 구조는 실제로 동기 부여를 지나치게 단순화한 것이다.
- 동기 부여는 다양한 성격 유형도 고려해야 한다.
  - 작업 지향적인 사람 (Task-oriented people) : 일 중심 → 일에 동기 부여를 받음
  - 상호작용 지향적인 사람 (Interaction-oriented people) : 사람들과 소통 → 동료의 존재와 행동으로 동기 부여
  - 자기 중심적인 사람 (Self-oriented people) : 자아실현 → 주로 개인적인 성공과 인정에 의해 동기 부여

1. 작업 지향적 (Task-oriented)
    - 일을 하는 동기: 일 그 자체
2. 상호작용 지향적 (Interaction-oriented)
    - 주요 동기: 동료의 존재 & 행동
    - 사람들은 일하기를 좋아하기 때문에 일하러 간다…? WOW
3. 자기 지향적 (Self-oriented)
    - 일은 개인의 목표를 성취하는 목적을 위한 수단
    - 예시: 부자가 되기 위해, 여행을 가기 위해 등

동기 부여 균형 (Motivation Balance)

동기 부여 균형
- 개별 동기는 각 클래스의 요소로 구성
- 개인 및 외부 사정에 따라 균형 변동 가능
- 사람들은 개인적인 요인뿐만 아니라 그룹과 문화의 일부가 되어 동기 부여
  
  : 개인 성향도 있지만 그룹 문화에도 영향을 받음
- 사람들은 함께 일하는 사람들에 의해 동기가 생겨서 일하러 간다.

4) 팀워크 (Teamwork)

Teamwork

팀워크란?
- 대부분의 소프트웨어 엔지니어링은 그룹 활동이다.
  - 대부분의 사소하지 않은 소프트웨어 프로젝트의 개발 일정은 혼자서는 작업을 완료할 수 없는 수준이다.
- 좋은 그룹은 단결력(cohesive)이 있고 팀 정신(team spirit)이 있습니다.
  - Good 그룹 → Good 화합
  - 관련된 사람들은 자신의 개인적인 목표뿐만 아니라 그룹의 성공에 동기 부여
- 그룹 상호 작용은 그룹 성과의 핵심 결정 요소
- 그룹 구성의 유연성이 제한됨
  - 관리자는 가능한 사람들과 함께 할 수 있는 최선을 다해야 한다.
  - 사람도 중요하지만 사람들끼리의 조직 및 그룹 관리도 중요

그룹의 단결력 (Group cohesiveness)
- 단결력 좋은 단체
  - 멤버들이 개인보다는 그룹을 위해 노력
  - 장점
    1. 퀄리티의 기준 UP
    2. 팀원끼리 서로 배울게 多
      
      : 무시로 인한 억제가 감소
    3. 지식 공유
      
      : 그룹 구성원이 떠나도 지식 유지 가능
    4. 지속적인 개발과 리팩토링이 장려됨
      
      : 그룹 구성원은 원래 디자인이나 프로그램을 만든 개인에 관계없이 공동으로 작업하여 고품질 결과를 제공하고 문제를 해결한다.
팀의 효율 (Effectiveness of a team)
- 그룹의 구성원
  
  : 소프트웨어 개발에는 클라이언트와의 협상, 프로그래밍, 테스트 및 문서화와 같은 다양한 활동이 포함되므로 프로젝트 그룹에 여러 사람이 필요
- 조직 방식
  
  : 개인이 자신의 능력을 최대한 발휘하고 일을 예상대로 끝내도록 그룹을 구성
- 기술적 관점에서의 소통
  
  : 그룹 구성원 간, 소프트웨어 엔지니어링 팀과 기타 프로젝트 이해 관계자 간의 원활한 의사 소통이 필수