Offcanvas

���������

비즈니스 가치를 향한 과감한 변화··· ‘제품 기반 IT’

전통적인 프로젝트 기반 IT 서비스에서 벗어나 제품 개발 모델을 취하는 IT 리더들이 늘고 있다.    프로젝트 기반 딜리버리 모델로는 디지털 트랜스포메이션 목표를 제대로 달성하기 어렵다고 판단하는 IT 리더들이 증가하고 있다. 이로 인해 ‘제품 중심 IT’(product-centric IT)로의 전환과 변화에 가속도가 붙는 양상이다. 전통적인 프로젝트 관리에서는 사업 단위(BU)가 세심히 준비한 일정에 따라 과업들을 파악하고, 예산을 추적해서 소프트웨어를 구축한다. 가트너 애널리스트들에 따르면, 프로젝트 기반 IT 딜리버리 모델은 일반적으로 조직 전체의 전략과 로드맵을 고려하지 않는다. 또 폭포수 방식의 개발 방법이 선호되며, 이 과정에서 비즈니스 가치 측정에 도움을 주는 KPI 등의 매트릭스가 축적되게 된다.  반면 제품 주도 모델은 개발자와 제품 관리자, 비즈니스 애널리스트로 구성된 같은 장소에서 일을 하는 CFT(크로스 펑션 팀)로 구성된다. 이들은 서로 협력해 비즈니스 역량을 만든다. 이 팀은 애자일과 디봅스 기법을 활용, 검색이나 주문 이행 비즈니스 프로세스의 특정 제품 기능을 지속적으로 반복해 구현한 후 전달한다. 이들은 누구나 접근해 이용할 수 있는 KPI로 의미 있는 결과를 도출하는 데 필요한 ‘상호 작용’들인 가치 흐름을 측정 및 평가한다. 프로젝트 관리는 딜리버리 일정이 더 지연되고 의심스러운 결과가 초래될 수 있는 반면, 제품 중심 IT 모델은 더 빨리 비즈니스 결과를 내고, 고객 경험을 향상시키고, 조직의 ‘마찰’을 줄여 신뢰를 높이는 경향을 가진다. 비즈니스가 동일한 목표를 추구하기 때문이다. 이런 제품 기반 IT로의 지속적인 변화는 전통적인 기업들이 페이스북, 우버, 기타 디지털 네이티브 기업들의 발자취를 어떻게 따라가고 있는지 시사한다. ‘디지털 홈 리모델링’을 가속화하고 있는 제품 기반 모델 파워 홈 리모델링(Power Home Remodeling)은 소프트웨어 개발자, 스크럼 마스터, 현...

제품 기반 IT 제품 중심 IT 워터폴 폭포수 데브옵스 애자일 프로젝트 기반 IT 딜리버리 모델

2021.01.18

전통적인 프로젝트 기반 IT 서비스에서 벗어나 제품 개발 모델을 취하는 IT 리더들이 늘고 있다.    프로젝트 기반 딜리버리 모델로는 디지털 트랜스포메이션 목표를 제대로 달성하기 어렵다고 판단하는 IT 리더들이 증가하고 있다. 이로 인해 ‘제품 중심 IT’(product-centric IT)로의 전환과 변화에 가속도가 붙는 양상이다. 전통적인 프로젝트 관리에서는 사업 단위(BU)가 세심히 준비한 일정에 따라 과업들을 파악하고, 예산을 추적해서 소프트웨어를 구축한다. 가트너 애널리스트들에 따르면, 프로젝트 기반 IT 딜리버리 모델은 일반적으로 조직 전체의 전략과 로드맵을 고려하지 않는다. 또 폭포수 방식의 개발 방법이 선호되며, 이 과정에서 비즈니스 가치 측정에 도움을 주는 KPI 등의 매트릭스가 축적되게 된다.  반면 제품 주도 모델은 개발자와 제품 관리자, 비즈니스 애널리스트로 구성된 같은 장소에서 일을 하는 CFT(크로스 펑션 팀)로 구성된다. 이들은 서로 협력해 비즈니스 역량을 만든다. 이 팀은 애자일과 디봅스 기법을 활용, 검색이나 주문 이행 비즈니스 프로세스의 특정 제품 기능을 지속적으로 반복해 구현한 후 전달한다. 이들은 누구나 접근해 이용할 수 있는 KPI로 의미 있는 결과를 도출하는 데 필요한 ‘상호 작용’들인 가치 흐름을 측정 및 평가한다. 프로젝트 관리는 딜리버리 일정이 더 지연되고 의심스러운 결과가 초래될 수 있는 반면, 제품 중심 IT 모델은 더 빨리 비즈니스 결과를 내고, 고객 경험을 향상시키고, 조직의 ‘마찰’을 줄여 신뢰를 높이는 경향을 가진다. 비즈니스가 동일한 목표를 추구하기 때문이다. 이런 제품 기반 IT로의 지속적인 변화는 전통적인 기업들이 페이스북, 우버, 기타 디지털 네이티브 기업들의 발자취를 어떻게 따라가고 있는지 시사한다. ‘디지털 홈 리모델링’을 가속화하고 있는 제품 기반 모델 파워 홈 리모델링(Power Home Remodeling)은 소프트웨어 개발자, 스크럼 마스터, 현...

2021.01.18

기고 | 프로젝트 관리 방법론 선택시 유의 사항

어떤 프로젝트 방법론을 채택하느냐가 성공을 좌우한다. 그러나 프로젝트의 복잡성을 관리하는 수많은, 때에 따라 중복되는, 접근법들 가운데 어떤 프로젝트 관리 방법론이 가장 적절한지 어떻게 파악하는 일은 쉽지 않다. 프로젝트 매니저(PM, project managers)는 위험을 줄이면서 가장 효과적이고 효율적으로 프로젝트를 이행하는 방법을 개선하며 조직에 기여할 수 있다. 그러나 이는 단순히 조직의 우선순위를 인식하는 것만으로는 충분하지 않다. 각 프로젝트 관리 방법론이 최고의 긍정적 효과를 어떻게 거둘 수 있는지, 그리고 이들이 프로젝트의 성공 확률을 어떻게 훼손할 수 있는지에 대한 보다 깊은 이해가 필요하다. 여기서는, 오늘날 실무에서 가장 널리 쓰이는 프로젝트 관리 방법론(Project Management Methodologies, PMMs)을 소개하고 프로젝트와 조직에 가장 잘 맞는 방법론을 어떻게 규명할지를 설명한다. 우선 적절한 프로젝트 관리 방법론을 평가하고 선택하는 프로세스가 개발되면 이는 문서로 만들어져 반복될 수 있고, 따라서 프로젝트를 조직하고 관리하는 방법을 고민하면서 허비하는 시간을 줄일 수 있으며, 프로젝트 목표와 결과물을 달성하는데 더 많은 시간을 할애할 수 있다. 가장 보편적인 프로젝트 관리 방법론 폭포수: 폭포수(Waterfall)는 여러 해 동안 주류 프로젝트 관리 방법론이었다. 이는 본질상 순차적이고, 여러 산업에 걸쳐 통용되지만, 소프트웨어 개발 시 가장 보편적으로 활용된다. 이는 특정한 순서로 실행되는 정적 단계들(Static Phases)로 구성된다. 즉 요건 분석, 설계, 테스팅, 구현 및 유지관리이다. 폭포수는 각 단계에 걸쳐 제어의 증가가 가능하지만, 프로젝트가 이미 진행 중인 상황에서 프로젝트 범위가 변경될 때 유연성이 극히 떨어진다. 이는 정형적인 계획 단계를 제공하여 모든 프로젝트 요건들을 미리 포착할 확률을 높일 수 있어, 초기 단계들에서 핵심 정보와 요건을 놓치는 일을 줄여준다. ...

애자일 크리티컬 패스 분석법 린 개발 스크럼 CCPM CPM 식스 시그마 프로젝트 관리자 폭포수 프로젝트 매니저 프로젝트 관리 PM CIO 크리티컬 체인 프로젝트 관리

2018.07.26

어떤 프로젝트 방법론을 채택하느냐가 성공을 좌우한다. 그러나 프로젝트의 복잡성을 관리하는 수많은, 때에 따라 중복되는, 접근법들 가운데 어떤 프로젝트 관리 방법론이 가장 적절한지 어떻게 파악하는 일은 쉽지 않다. 프로젝트 매니저(PM, project managers)는 위험을 줄이면서 가장 효과적이고 효율적으로 프로젝트를 이행하는 방법을 개선하며 조직에 기여할 수 있다. 그러나 이는 단순히 조직의 우선순위를 인식하는 것만으로는 충분하지 않다. 각 프로젝트 관리 방법론이 최고의 긍정적 효과를 어떻게 거둘 수 있는지, 그리고 이들이 프로젝트의 성공 확률을 어떻게 훼손할 수 있는지에 대한 보다 깊은 이해가 필요하다. 여기서는, 오늘날 실무에서 가장 널리 쓰이는 프로젝트 관리 방법론(Project Management Methodologies, PMMs)을 소개하고 프로젝트와 조직에 가장 잘 맞는 방법론을 어떻게 규명할지를 설명한다. 우선 적절한 프로젝트 관리 방법론을 평가하고 선택하는 프로세스가 개발되면 이는 문서로 만들어져 반복될 수 있고, 따라서 프로젝트를 조직하고 관리하는 방법을 고민하면서 허비하는 시간을 줄일 수 있으며, 프로젝트 목표와 결과물을 달성하는데 더 많은 시간을 할애할 수 있다. 가장 보편적인 프로젝트 관리 방법론 폭포수: 폭포수(Waterfall)는 여러 해 동안 주류 프로젝트 관리 방법론이었다. 이는 본질상 순차적이고, 여러 산업에 걸쳐 통용되지만, 소프트웨어 개발 시 가장 보편적으로 활용된다. 이는 특정한 순서로 실행되는 정적 단계들(Static Phases)로 구성된다. 즉 요건 분석, 설계, 테스팅, 구현 및 유지관리이다. 폭포수는 각 단계에 걸쳐 제어의 증가가 가능하지만, 프로젝트가 이미 진행 중인 상황에서 프로젝트 범위가 변경될 때 유연성이 극히 떨어진다. 이는 정형적인 계획 단계를 제공하여 모든 프로젝트 요건들을 미리 포착할 확률을 높일 수 있어, 초기 단계들에서 핵심 정보와 요건을 놓치는 일을 줄여준다. ...

2018.07.26

기고 | 애자일과 워터폴을 공존시키는 4가지 방법

이론적으로 이들 두 기법은 서로 섞일만한 것들이 아니다. 하지만 현실적으로는 대개 공존해야만 한다. 여기 애자일과 워터폴이라는 상반되는 기법이 함께 존재할 수 있도록 하는 4가지 방법을 정리한다. Image Credit : Getty Images Bank IT 부서는 애자일(Agile) 프로젝트의 민첩성과 생산성을 으레 선호한다. 하지만 경영진과 재무 조직에 프로젝트를 소개할 때는 워터폴(Waterfall) 개념을 거의 항상 필수요건으로 소개하게 된다. 사실 따져보면 애자일과 워터폴은 반대에 가까운 개념들이며, 특히 많은 소프트웨어 프로젝트에서 두 기법을 두고 꽤나 불편한 상황이 연출되기도 한다. 폴라 압둘의 노래와는 달리 상반되는 성격이 그리 매력적으로 다가오지 않는 것이다. 그렇다면 이 둘을 어떻게 함께 활용할 수 있을까? 대응 전략 #1: 적극적 계정 관리 워터폴에는 고정된 사양뿐만이 아니라 고정된 예산과 일정이 수반된다. 따라서 유연하거나 모호하게 정의된 스프린트(Sprint) 성과물과 조합하려면 꽤나 고민을 해야 한다. 하지만 워터폴의 ‘사양’이 불분명하거나 (고객은 무엇이 필요한지 정확하게 모르기 때문) 신축성이 있는 경우 (임원이 우선적으로 결정하기 때문) 의외로 효과가 있을 수 있다 하지만 이 전략은 조심스럽게 적용될 필요가 있다는 점에 주의해야 한다. 프로젝트 범위 확대 및 우선순위 충돌 문제로 비화되서는 안 된다. 베스트 프랙티스: 매 스프린트 시작과 끝에 서면으로 기대치를 명시적으로 관리한다. 또한 스프린트 중 제공되는 각 기능에 대해 고객의 승인을 받는다. 워스트 프랙티스: 문제 자체가 알아서 해결되기를 바라면서 현실을 외면하는 태도. 대응 전략 #2: 주문 변경 공식화 워터폴 프로젝트에서 고객은 걸핏하면 주문을 변경한다 (계약서가 그렇게 조장하는 측면도 있다). 그렇다면 이런 메커니즘을 조기에 자주 활용하자. 예전에 참여한 70만달러짜리 프로젝트에서 50건의 주문 변경이 ...

애자일 소프트웨어 폭포수 개발 프로젝트 데브옵스 워터폴

2016.07.12

이론적으로 이들 두 기법은 서로 섞일만한 것들이 아니다. 하지만 현실적으로는 대개 공존해야만 한다. 여기 애자일과 워터폴이라는 상반되는 기법이 함께 존재할 수 있도록 하는 4가지 방법을 정리한다. Image Credit : Getty Images Bank IT 부서는 애자일(Agile) 프로젝트의 민첩성과 생산성을 으레 선호한다. 하지만 경영진과 재무 조직에 프로젝트를 소개할 때는 워터폴(Waterfall) 개념을 거의 항상 필수요건으로 소개하게 된다. 사실 따져보면 애자일과 워터폴은 반대에 가까운 개념들이며, 특히 많은 소프트웨어 프로젝트에서 두 기법을 두고 꽤나 불편한 상황이 연출되기도 한다. 폴라 압둘의 노래와는 달리 상반되는 성격이 그리 매력적으로 다가오지 않는 것이다. 그렇다면 이 둘을 어떻게 함께 활용할 수 있을까? 대응 전략 #1: 적극적 계정 관리 워터폴에는 고정된 사양뿐만이 아니라 고정된 예산과 일정이 수반된다. 따라서 유연하거나 모호하게 정의된 스프린트(Sprint) 성과물과 조합하려면 꽤나 고민을 해야 한다. 하지만 워터폴의 ‘사양’이 불분명하거나 (고객은 무엇이 필요한지 정확하게 모르기 때문) 신축성이 있는 경우 (임원이 우선적으로 결정하기 때문) 의외로 효과가 있을 수 있다 하지만 이 전략은 조심스럽게 적용될 필요가 있다는 점에 주의해야 한다. 프로젝트 범위 확대 및 우선순위 충돌 문제로 비화되서는 안 된다. 베스트 프랙티스: 매 스프린트 시작과 끝에 서면으로 기대치를 명시적으로 관리한다. 또한 스프린트 중 제공되는 각 기능에 대해 고객의 승인을 받는다. 워스트 프랙티스: 문제 자체가 알아서 해결되기를 바라면서 현실을 외면하는 태도. 대응 전략 #2: 주문 변경 공식화 워터폴 프로젝트에서 고객은 걸핏하면 주문을 변경한다 (계약서가 그렇게 조장하는 측면도 있다). 그렇다면 이런 메커니즘을 조기에 자주 활용하자. 예전에 참여한 70만달러짜리 프로젝트에서 50건의 주문 변경이 ...

2016.07.12

2015년 연봉 높고 인기 많은 IT기술력 9선

기업들이 목표 달성을 위해 점점 더 많이 기술에 의존하게 되면서 이 분야의 기술력이 비즈니스의 미래에 중요한 역할을 담당하게 됐다. 이러한 수요에는 더 높은 연봉과 취업 기회가 따라오게 된다. 그렇다면, 어떤 기술력이 시간과 자원 투자 대비 가장 가치가 높을까? 데브옵스, 빅데이터, 사이버보안, 기타 IT기술들이 있지만, 이들이 실제 업계에서 어떻게 평가 받고 있을까? <CIO닷컴>은 다이스닷컴(Dice.com)과 함께 IT구직 시장 전반에 대해 살펴보고 그 답을 찾아보았다. 2015년 1분기의 기술 업계 구직 동향을 조사해 어떤 기술력이 가장 수요가 높은지를 파악했다. 이 슬라이드쇼에서는 ‘구인 공고’ 측면에서 가장 많이 늘어난 기술력들을 정리했다. (모든 이미지 출처 : Shutterstock) ciokr@idg.co.kr

CIO 폭포수 기술력 사이버보안 구인 구직 세일즈포스닷컴 빅데이터 채용 파이썬

2015.04.28

기업들이 목표 달성을 위해 점점 더 많이 기술에 의존하게 되면서 이 분야의 기술력이 비즈니스의 미래에 중요한 역할을 담당하게 됐다. 이러한 수요에는 더 높은 연봉과 취업 기회가 따라오게 된다. 그렇다면, 어떤 기술력이 시간과 자원 투자 대비 가장 가치가 높을까? 데브옵스, 빅데이터, 사이버보안, 기타 IT기술들이 있지만, 이들이 실제 업계에서 어떻게 평가 받고 있을까? <CIO닷컴>은 다이스닷컴(Dice.com)과 함께 IT구직 시장 전반에 대해 살펴보고 그 답을 찾아보았다. 2015년 1분기의 기술 업계 구직 동향을 조사해 어떤 기술력이 가장 수요가 높은지를 파악했다. 이 슬라이드쇼에서는 ‘구인 공고’ 측면에서 가장 많이 늘어난 기술력들을 정리했다. (모든 이미지 출처 : Shutterstock) ciokr@idg.co.kr

2015.04.28

기고 | 정부 SW 프로젝트로부터 얻는 3 가지 아이디어

필자는 애자일 기법을 지지한다. 그러나 정부 프로젝트에서는 애자일 프랙티스를 거의 찾아볼 수 없다.. 간트 차트(Gantt Chart) 와 PERT 다이어그램을 대중화하는 이들이 현대 소프트웨어 프로젝트에 도움이 될 수 있을까? 그리고 Healthcare.gov의 거대한 실패와 관련 있었던 사람들을 잊어서는 안 된다. 그러나 한 현자는 "지혜란 자신보다 어리석은 사람으로부터 배울 수 있는 능력이다"고 말했다. 오늘은 우리가 정부로부터 배울 수 있는 3 가지 소프트웨어 개발법에 관해 알아보도록 하자. 일몰법(Sunset Laws)을 이용하자 똑똑한 정부 관료들은 법률의 자동 파기, 즉 일몰 규정을 지지하곤 한다. 시간이 지나면서 기준이 바뀌는 민사 및 규제 문제에 대해서는 더욱 그렇다. 일몰 규정이 없다면 적절하지 못한 법률은 의회의 의안 또는 대법원의 결정에 의해서 삭제해야 한다. 이 때문에 지역, 주, 연방 법전에는 무용지물일 뿐 아니라 어리석은 조항이 넘쳐난다. IT 부문에서도 변하지 않는 규칙과 요건으로 인해 같은 일이 발생한다. 뛰어난 비즈니스 분석가라면 시스템 개선 중 거의 발생하지 않는 상황을 처리하도록 수립된 형편 없고 과장된 비즈니스 프로세스를 다수 발견할 수 있을 것이다. 이런 포 시그마(Four Sigma) 이벤트는 직접 처리하는 것이 더 나으며, 자동화는 더 많은 문제를 야기할 가능성이 있다. 메인프레임(Mainframe) 융합 프로젝트를 분석하는 스탠디시 그룹(Standish Group)의 연구에서 이런 현상을 탐구했다. 결과는? 기존 코드의 기능 중 90% 가 더 이상 필요 없었다. 교훈 : 중요한 소프트웨어 요건을 위해 사용자들이 (또는 기타 실행자들이) 처음부터 시작해 필요를 다시 파악하도록 하는 자동 만료일을 실시한다. 이것이 중요한 이유는 가짜 요건의 이행을 막을 수 있기 때문이다. 시험할 수 없다면 요건이 아니다 이 교훈은 야생 거...

프로젝트 애자일 정부 소프트웨어 개발 폭포수

2014.08.08

필자는 애자일 기법을 지지한다. 그러나 정부 프로젝트에서는 애자일 프랙티스를 거의 찾아볼 수 없다.. 간트 차트(Gantt Chart) 와 PERT 다이어그램을 대중화하는 이들이 현대 소프트웨어 프로젝트에 도움이 될 수 있을까? 그리고 Healthcare.gov의 거대한 실패와 관련 있었던 사람들을 잊어서는 안 된다. 그러나 한 현자는 "지혜란 자신보다 어리석은 사람으로부터 배울 수 있는 능력이다"고 말했다. 오늘은 우리가 정부로부터 배울 수 있는 3 가지 소프트웨어 개발법에 관해 알아보도록 하자. 일몰법(Sunset Laws)을 이용하자 똑똑한 정부 관료들은 법률의 자동 파기, 즉 일몰 규정을 지지하곤 한다. 시간이 지나면서 기준이 바뀌는 민사 및 규제 문제에 대해서는 더욱 그렇다. 일몰 규정이 없다면 적절하지 못한 법률은 의회의 의안 또는 대법원의 결정에 의해서 삭제해야 한다. 이 때문에 지역, 주, 연방 법전에는 무용지물일 뿐 아니라 어리석은 조항이 넘쳐난다. IT 부문에서도 변하지 않는 규칙과 요건으로 인해 같은 일이 발생한다. 뛰어난 비즈니스 분석가라면 시스템 개선 중 거의 발생하지 않는 상황을 처리하도록 수립된 형편 없고 과장된 비즈니스 프로세스를 다수 발견할 수 있을 것이다. 이런 포 시그마(Four Sigma) 이벤트는 직접 처리하는 것이 더 나으며, 자동화는 더 많은 문제를 야기할 가능성이 있다. 메인프레임(Mainframe) 융합 프로젝트를 분석하는 스탠디시 그룹(Standish Group)의 연구에서 이런 현상을 탐구했다. 결과는? 기존 코드의 기능 중 90% 가 더 이상 필요 없었다. 교훈 : 중요한 소프트웨어 요건을 위해 사용자들이 (또는 기타 실행자들이) 처음부터 시작해 필요를 다시 파악하도록 하는 자동 만료일을 실시한다. 이것이 중요한 이유는 가짜 요건의 이행을 막을 수 있기 때문이다. 시험할 수 없다면 요건이 아니다 이 교훈은 야생 거...

2014.08.08

폭포수 프로젝트 관리에도 민첩성이 필요하다

영화에는 절대 죽지 않는 등장인물들이 꼭 등장한다. 하지만, 절대로 떨쳐버리지 못한 불길한 생각이 클라우드 프로젝트를 정말로 망칠 수 있다. 안타깝게도 경영진들은 고전적이고 비생산적인 폭포수(Waterfall) 프로젝트 관리를 좋아하며 클라우드를 도입한다 해도 전통적인 구축 방식으로 이원화해서 시스템을 운영하고 싶어하는 경향이 있다. 하드웨어와 물리적인 아 키텍처를 다룰 때는 활동의 결과가 무엇이며, 프로젝트의 어느 단계에 도달해 있고, 어디에서 변화가 생길지 등이 상대적으로 분명하다 할 수 있다. 결과적으로 PERT(Program Evaluation and Review Technique) 단계를 통해 사전에 결정된 일정은 갑과 을, 모두에 이득이 된다. 물론 만일의 사태가 발생할 수 있지만 프로젝트 진행 일정을 수 개월 또는 수 분기 앞서 결정할 수 있다. 일반적으로 일정과 예산의 초과는 20% 미만으로 떨어지게 되고 단순한 동기부여와 처벌을 통해 처리할 수 있다. 또한 폭포수 프로젝트 관리는 결정론적인 결과를 지원하는 설계 자동화와 시뮬레이션 도구 덕분에 컴퓨터 및 네트워크 하드웨어 설계 프로젝트에서 효과를 발휘하고 있다. 하지만 클라우드 소프트웨어 등 분산형 비동기 시스템에서는 그렇지 않다. 프로젝트의 규모가 커질수록 초과의 범위도 확대되며 때로는 100%를 상회하기도 한다. 바인베르크(Weinberg)의 제 2법칙에서처럼 프로그래머가 소프트웨어를 개발하듯이 건축가들이 건물을 짓는다면, 첫 번째 딱따구리가 문명을 파괴하게 될 것이다. 폭포수 프로젝트 관리의 주요 당면과제 모든 사용자들이 한 번에 새로운 시스템으로 교체하는 것을 빅뱅(Big Bang)이라고 하며 빅뱅 방식을 선택하는 데는 크게 두 가지 이유가 있다. 첫 번째 이유는 경영진이 수 개월 전에 승인된 값비싼 프로젝트를 포기하는 것을 선호하기 때문이다. 이럴 때는 아래의 논쟁을 통해 이런 나쁜 습관을 고쳐놔야 한다. -예산 삭감이 진정으로 최고의...

애자일 PM 프로젝트 관리 폭포수 민첩 Waterfall

2012.05.15

영화에는 절대 죽지 않는 등장인물들이 꼭 등장한다. 하지만, 절대로 떨쳐버리지 못한 불길한 생각이 클라우드 프로젝트를 정말로 망칠 수 있다. 안타깝게도 경영진들은 고전적이고 비생산적인 폭포수(Waterfall) 프로젝트 관리를 좋아하며 클라우드를 도입한다 해도 전통적인 구축 방식으로 이원화해서 시스템을 운영하고 싶어하는 경향이 있다. 하드웨어와 물리적인 아 키텍처를 다룰 때는 활동의 결과가 무엇이며, 프로젝트의 어느 단계에 도달해 있고, 어디에서 변화가 생길지 등이 상대적으로 분명하다 할 수 있다. 결과적으로 PERT(Program Evaluation and Review Technique) 단계를 통해 사전에 결정된 일정은 갑과 을, 모두에 이득이 된다. 물론 만일의 사태가 발생할 수 있지만 프로젝트 진행 일정을 수 개월 또는 수 분기 앞서 결정할 수 있다. 일반적으로 일정과 예산의 초과는 20% 미만으로 떨어지게 되고 단순한 동기부여와 처벌을 통해 처리할 수 있다. 또한 폭포수 프로젝트 관리는 결정론적인 결과를 지원하는 설계 자동화와 시뮬레이션 도구 덕분에 컴퓨터 및 네트워크 하드웨어 설계 프로젝트에서 효과를 발휘하고 있다. 하지만 클라우드 소프트웨어 등 분산형 비동기 시스템에서는 그렇지 않다. 프로젝트의 규모가 커질수록 초과의 범위도 확대되며 때로는 100%를 상회하기도 한다. 바인베르크(Weinberg)의 제 2법칙에서처럼 프로그래머가 소프트웨어를 개발하듯이 건축가들이 건물을 짓는다면, 첫 번째 딱따구리가 문명을 파괴하게 될 것이다. 폭포수 프로젝트 관리의 주요 당면과제 모든 사용자들이 한 번에 새로운 시스템으로 교체하는 것을 빅뱅(Big Bang)이라고 하며 빅뱅 방식을 선택하는 데는 크게 두 가지 이유가 있다. 첫 번째 이유는 경영진이 수 개월 전에 승인된 값비싼 프로젝트를 포기하는 것을 선호하기 때문이다. 이럴 때는 아래의 논쟁을 통해 이런 나쁜 습관을 고쳐놔야 한다. -예산 삭감이 진정으로 최고의...

2012.05.15

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.6