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)

  1. 식별 (Risk identification)

    : 프로젝트, 제품 및 비즈니스 위협 등 risk 종류 식별

  2. 분석 (Risk analysis)

    : 식별된 위험의 가능성과 결과 평가

  3. 계획 (Risk planning)

    : 위험의 영향을 피하거나 최소화하기 위한 계획 수립

  4. 모니터링 (Risk monitoring)

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


  1. 위험 식별 (Risk identification)
  • 팀 활동일 수도 있고 개별 프로젝트 관리자의 경험을 기반으로 할 수도 있다.

    • 경험 多 → 위기 예측 더 Good
  • 일반적인 위험의 체크리스트는 프로젝트의 위험을 식별하는 데 사용할 수 있다.

    • 기술 (Technology risks)
    • 조직 (Organizational risks)
    • 사람 (People risks)
    • 요구사항 (Requirements risks)
    • 예측과 다름 (Estimation risks)

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

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

  1. 위기 모니터링 (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)
    • 그룹의 구성원

      : 소프트웨어 개발에는 클라이언트와의 협상, 프로그래밍, 테스트 및 문서화와 같은 다양한 활동이 포함되므로 프로젝트 그룹에 여러 사람이 필요

    • 조직 방식

      : 개인이 자신의 능력을 최대한 발휘하고 일을 예상대로 끝내도록 그룹을 구성

    • 기술적 관점에서의 소통

      : 그룹 구성원 간, 소프트웨어 엔지니어링 팀과 기타 프로젝트 이해 관계자 간의 원활한 의사 소통이 필수




5) 프로젝트 팀 구성 (Organization of Project Team)

직능별 조직 (Organization by Functional Team)

  • 일 별로 부서를 다 나눔
  • 다른 부서는 동일한 프로젝트에서 다른 역할을 수행한다.3
  • 팀 구성원이 부서에 포함된다.
  • 부서간 협업이 이루어진다.

프로젝트 별 조직 (Organization by Projects)

  • 기능 구성원(개발자)이 다른 프로젝트에 있다.
  • 의사소통 경로가 짧기 때문에 인적 자원 및 진행 관리가 효율적이다.

매트릭스 조직 (Matrix Organization)

  • 기능 그룹의 관리자가 책임을 진다.
  • 개발자는 기능 팀에 포함된다.
  • 구성원은 다른 프로젝트 팀에 중복될 수 있다.

에자일 조직 (Agile Organization)

  • 5~9명으로 구성된 팀이 서로 긴밀하게 협력
  • 결과 및 문제의 소유권 공유

0개의 댓글