[ 기타 ] IT 프로젝트에 관하여

19-12-24

프로젝트 관리

• 수주업의 개념
  1. 사업기획 및 발주 - 제안 - 계약 및 협상 - 프로젝트 수행
• fresales
• IT 이익률?? 보통 5%이내?! 보통기업은 최소 20%는맞춰야 한다.

< IT프로젝트 >

1. 컨설팅 프로젝트

• 기업의 중장기 IT 전략 수립 => 3~5년 중장기 IT 투자계획

  1. Masterplan

  2. SP(Strategy Planning)

• 컨설팅 회사에 의뢰?! why?

  => 내부적으로 말고 외부적으로 전체적으로 검토하기 위해

  ​ (경쟁사 등등)

  => 객관적인 시각

• 수주.. 인력감소... 현대차노조... 스마트팩토리못하게막아...

2. SI사업

1. SI
   • 대부분 신규 시스템,기술
   • 기술을 연계하고 통합(난이도 上)
   • 업무강도 上
   • 성장을 하고. 도전적. 배움의 즐거움. => Career path !!!
2. SM
   • 기 구축 시스템을 안정적으로 운영하고 유지/보수
   • routin한 업무. 워라밸 가능.
   • 이직 어렵다. 뻥칠게 없다.

• 시스템 개발, 구축 및 검토
• 기반 인프라 구축 및 고도화

3. 운영 및 유지보수

• 구축된 시스템의 안정적인 운영

프로젝트

1. 소형 , 중형, 대형

=> 프로젝트규모가 작을수록 성공확률은 높아지며,

=> 프로젝트규모가 커질수록 성공확률이 현저하게 낮아짐

• IT프로젝트의 성공 확률은 30% 미만 (feat. the standish group)

< IT프로젝트의 특징 >

1. 프로젝트 진행상황을 가시적으로 정확히 판단하기 어려움

2. 개발자 의존도가 높은 속성

   (IT 기술등급이 존재)

3. 초기 사용자 요구사항을 명확히 정의하기 어러움

   (데이터측면? 화면측면? 절차측면? 사용자측면?)

   • 분석 - 설계 - 개발 - 테스트 - 안정화

4. 대부분 일괄계약 - 초기정확한 규모 산정이 어려움

< 주요 실패요인 >

1. 고객의 잦은 요구 변경 ( 21% )

2. 기술 , 경험 부족 ( 20% )

3. 부정확한 기간, 비용 예측 (20% )

4. 고객, 현업의 참여 부족 ( 12% )

5. 영업의 과욕....

   (실적의 과욕)

• Crunch Mode
• 서양의 문화는 사업 목표라는 객체 중심으로 프로젝트를 인식하여, 계약을 체결하고 프로젝트 수행중 발생하는 제약 범위 밖의 요구사항은 쉽게 거절할 수 있기 때문에 수행 및 관리가 비교적 용이함.
• 동양은 프로젝트 목표도 중요하지만 고객과의 관계유지가 중요.
• 프로젝트 과업범위를 명확하게 제시하고 관리.
• 팀원간의 협업, 이해관계자관의 효과적인 의사소통
• 과제 성격의 소규모 프로젝트에서는 범위,일정,품질에 초점을 맞추어야 한다
• 개발 방법론 / 관리 방법론 / Agile 방법론

< Waterfall 모델 >

대부분 현장에서... 단점이 많아 애자일을 많이쓴다.

< Agile 방법론 > - 사용자 지향적 개발방법 -

• waterfall 모델과 달리 뒤 단계를 미리 예측하며 개발하지 않고, 일정한 반복주기를 가지고 끊임없이 프로토타입을 만들어 내며 필요할 때마다 요구사항을 더하고 수정하여 커다란 소프트웨어를 개발해 나가는 방식.

• 이 과정에서 각각에 이해관계자를 참여시켜 요구사항 수집과 결과 검증을 모두 거쳐갈 수 있는 장점.

• 일정 지연이 잘 발생하지 않음.

• Sprint1 - S2 - S3 - S4 - .....Sn

  (이전 스프린트와 다음 스프린트를 고객에게 우선순위를 설정.)

  (떨어진 우선순위에 대해 회의한다. 안할건지? 다른 프로젝트에 반영할지?)

• 많은 장점에도 불구하고 왜 적용이 힘든것일까?? WHY???

  1. 고객이 선호 X - 고객이 원하는 만큼 그만큼 나머지가 빠지기 때문. 머리아팡~

  2. 사용자들이 선호 X - 이해관계자들이 끊임없이 검증하고 참여해야 하기 때문에

  3. 업무방식 - 매 스프린트가 하나의 프로젝트같다

     => 근무 빡세게 하고 정시 퇴근

  4. 한국의 복잡한 보고체계

     팀원 - PL - PM - 고객 ( 원래 Waterfall 방식 보고체계 )

     팀원 <--> 고객 ( 애자일 지향 )

• 그럼 우리나라는 어떤 프로젝트를 애자일로 하는가?

  1. 내부 R&D / 솔루션 개발 - 고객이 없으니까

< 프로젝트 착수단계 >

• project leader를 선임하고 팀원별 명확한 역할과 책임을 정립.

• 팀 내 협의 하에 프로젝트 Ground Rule(기본규칙)을 정립

  (하루에 한번정도는 최소한 해야 한다.)

  (어떤일을 했고, 어떤 이슈사항과 협조사항(논의할점)을 얘기할 지 리더에게 메일보내기)

  (아침에 그 내용들을 모아 다음날 아침에 회의하기 - 다시 팀원들에게 모두 회람 - 자연스럽게 결과보고서)

< 프로젝트 계획단계 >

• 요구사항(SPEC)을 분석하여 최대한 명확화하도록 노력 - 정확하게 구체화시키자.

  => 시행착오 줄이기

• WBS 기반으로 체계적인 공정계획을 수립

  => 꼭 해보자!!!

  • WBS란? (Work Brakdwon Structure)

    프로젝트 일정을 관리하기 위해 단계별 활동내역을 정의한 후 활동간의 선후행관계, 수행기간을 정의하여 일정계획을 수립하고 활동별 담당자를 배정하여 만든 공정계획 문서를 의미함.

  • 프로젝트 일정 계획 수립 시 주의사항?!

    1. 개발 내역에 대한 기술적인 난이도를 사전에 평가해야 하고...

    2. 업무를 담당하는 팀원 각각의 능력을 고려하되...

       (공평이란 ? => 잘하는애는 어려운거 소수 배정, 못하는애 는 쉬은거 다수 배정)

    3. 개발과정에서 예상치 못한 이슈가 발생하는 경우가 많기 때문에...

       => 초안을 만든 다음에 마지막 1주일을 비워주자. (앞쪽을 압축)

       => 도전적인 열정 , 일정지연을 막을 수 있다.

       => " Critical Chain Method "

< 프로젝트 실행단계 >

• 개발 전 목표시스템에 대한 체계적인 설계를 수행해라.

  1. 기능, 데이터, UI, 아키텍쳐 요구사항등을 고려한 체계적인 설계를 통해..
  2. 불필요한 코드를 줄이고 테스트와 재작업이 쉬운 코드를 만들어내며..
  3. 개발과정에서 무한 수정/변경 등의 삽질을 방지할 수 있을 뿐만 아니라..
  4. 향후 수정 및 유지보수가 용이하며 운영 생산성이 향상될 수있음.

• 체계적인 변경통제와 형상관리가 필수

  • 형상관리 툴 꼭 사용하자(ex. GITHUB)

  • 형상관리를 하게 되면어떤 점이 좋아지는가?

    • 비전관리 / 배포관리 / 릴리즈관리 / 이슈관리 / 빌드관리

    • 소스통합 가능, Rollback 가능, 자동테스트 가능, 생산성 UP!