Chapter 1. 전통적 프로젝트 경영에서 벗어나기

기존 프로젝트 관리의 문제점과 이슈를 제기하면서 이에 대한 해법을 애자일 관점에서 제시

1.1 업무 범위, 일정, 비용은 반드시 지켜야 하는가?

[문제 의식]

• 어떤 프로젝트가 초기에 설정한 업무 범위와 일정, 비용은 모두 준수했지만 시장에서 별로 가치가 없는 제품을 만들거나 조직에서 아무도 사용하지 않는 시스템을 만든다면 이 프로젝트를 성공했다고 할 수 있을까?
• 고객 만족도나 시장 반응은 좋았지만 초기에 설정한 일정이나 비용을 정확히 지키지 못했다면 이 프로젝트는 실패한 것인가?

[제언]

프로젝트에서 업무 범위, 일정, 비용을 관리하는 것은 매우 중요하지만 초기에 정한 목표를 무조건 준수하라는 의미는 아니다. 시장 및 고객에게 무엇이 가치가 있는지에 따라 신축성 있게 조정하는 것이 필요하다.

 

[이유]

• 프로젝트의 불확실성(uncertainty)과 복잡성(complexity)
• 아파트 건설과 같이 기성품을 만드는 프로젝트와 달리 새로운 제품이나 서비스를 만드는 IT 프로젝트는 초기 요구사항이 불확실하고 기술의 복잡성이 높을 수밖에 없다.

 

1.2 프로젝트 일정 및 예산에 대한 진실

[문제 의식]

• 예를 들어 일정 5개월, 예산 10억 원과 같은 단일 값 추정은 초기 요구사항을 기반으로 한 개략적인 추정치일 뿐이지 프로젝트의 실제 일정과 비용을 정확히 예측한 것은 아니다.
• 프로젝트의 일정과 비용에 대한 예측은 확률적으로 추정하는 것이 합리적이다. 예를 들어 일정은 최소 6~8개월, 비용은 20~25억 원 정도가 소요된다고 말이다.

※ 스티브 맥코넬(Steve McConnell)은 요구사항 정의를 확정한 이후에도 전체 일정이나 비용은 60~150%까지 변동될 수 있으며 상세 디자인을 완료한 후에야 90~110% 이내로 줄어든다고 이야기한다.

 

[문제 원인]

• 대부분의 경영진은 ROI와 손익분기점을 앞당길 수 있도록 프로젝트를 빨리 끝내면 좋다는 생각을 가지고 있다.
• 입찰 경쟁. 발주자는 불확실한 요구사항을 담보로 최소한의 일정과 비용으로 발주한다.

※ 스티브 맥코넬(Steve McConnell)은 합리적으로 설정한 일정에서 25% 이상은 줄이지 말라고 권고한다.

 

[문제 결과]

• 의사소통을 할 시간이 충분하지 않아서 원활한 협업을 방해한다.
• 여유가 없어 창의적으로 생각할 시간이 부족하다.
• 요구사항과 설계에 투자하는 시간이 적어 후반부에 재작업을 많이 하거나 품질이 떨어진다.
• 예상치 못한 리스크에 대처할 시간적 여유가 없어 일정이 지연되거나 품질에 문제가 생긴다.

 

1.3 업무 범위 내 요구사항은 모두 구현해야 하는가?

[문제 의식]

• 많은 기업들은 초기에 요구사항을 상세하게 제시하기가 어려워 요구사항을 포괄적으로 정해 놓고서 발주한다.
• 그리고 개발업체가 업무 범위 내의 상세 요구사항의 변경이나 추가를 모두 수용하기를 바란다.

[제언]

• 요구사항의 업무 범위와 깊이를 구분해서 생각해야 프로젝트 요구사항의 변화를 이해할 수 있다.
  • 업무 범위는 프로젝트에서 달성해야 하는 업무 영역이다.
  • 깊이는 범위에 따른 상세 요구사항이다.
• 프로젝트 일정과 비용은 범위와 깊이를 고려한 초기 요구사항을 기반으로 추정한다.
  • 이때 일정과 비용 베이스라인이 설정된다(초기에 설정하는 일정과 비용 기준이다).
  • 그러다 프로젝트가 진행되면서 상세 요구사항들이 변경되거나 추가되면 요구사항의 깊이를 더하는 요소로 작용한다.
  • 프로젝트 일정과 예산이 고정되어 있고 요구사항의 변경이 자주 발생하는 상황이라면 기존 요구사항과 변경사항의 우선순위를 관리하여 주어진 제약 조건을 충족시켜야 한다.

 

1.4 상습적인 야근이 프로젝트의 성과를 높일 수 있는가?

[문제 의식]

• 국내에서 수행되는 수많은 대규모 IT 프로젝트에서는 늘 뒤처진 구축 일정과 약속한 시스템 오픈 일정을 지키기 위해 야근과 주말출근을 강요한다.
• 그렇다고 개개인에게 별도의 보상도 하지 않는다.

[문제 원인]

• 애초부터 무리하게 잡힌 프로젝트 일정.
• 발주사나 경영자들이 프로젝트에서 야근을 하지 않으면 일을 열심히 하지 않는다고 인식하기 때문.
  • 제조업 중심으로 발전한 우리나라는 공장 가동 시간이 성과와 비례한다는 생각을 소프트웨어 개발과 같은 지식 서비스 산업에도 적용한다.

[문제 결과]

• 톰 디마르코(Tom DeMarco), 「피플웨어(Peopleware)」 : "사람의 내면에는 초과근무를 보상받으려는 심리가 있다. 단기간의 야근은 생산성 증대를 가져올 수 있지만 장기적인 야근을 주어진 일을 늘려서 할 뿐 초과근무로 인한 생산성 향상은 없다."
• 때로는 공포를 불러일으키는 관리가 성과를 일정 부분 올리는 것처럼 보이기도 하지만 실상은 눈에 보이지 않는 품질을 떨어뜨려 향후 일거리만 더욱 늘릴 뿐이다.
• 야근이 많은 프로젝트에 참여한 개발자 중 2/3 이상이 중간에 이직을 한다.

 

1.5 협력업체는 파트너인가, 소모품인가?

[문제 의식]

• 일부 독자적인 기술을 보유한 중소기업을 제외하고 대다수 협력업체는 대기업과 함께 성장하는 파트너가 아닌, 끊임없이 원가절감 압력을 받으면서 저임금 노동력을 제공하는 소모품처럼 보인다.

[문제 분석]

• 제조업과 소프트웨어는 다르기 때문에 일방적으로 원가절감을 강요한다면 품질만 떨어질 뿐이다.
  • 제조업은 특정 제품을 반복하여 개발하기 때문에 시간이 흐를수록 감가상각비가 낮아지지만, 소프트웨어 개발은 반복적인 특성이 별로 없고 기술 환경 변화에 따라 새로운 업무를 수행할 때가 많다. 
  • 원가 자체도 인건비가 대부분이기 때문에 시간이 갈수록 상승하므로 감가상각의 여지가 별로 없다.
• 소프트웨어는 모든 산업의 부가가치를 높이는 촉매제 역할을 수행 중이다, 이런 역할을 성공적으로 수행하려면 소프트웨어 개발의 창의성과 혁신 역량이 수반되어야 한다.
  • 창의성과 혁신은 개발에 참여하는 구성원에게서 드러나는데 현재 프로젝트 구성원의 상당수는 협력업체 인력이다.
  • 혁신적인 제품은 제품 개발에 참여하는 사람들이 열정적으로 참여하고 소통할 때 만들어지기 쉽다.

[제언]

• 협력업체는 언제든지 바꿀 수 있는 부품이 아니라 혁신적인 제품을 만들 수 있는 창의력의 원천이다.

 

1.6 비즈니스 환경은 어떻게 변화하는가?

1. 과거보다 요구사항이 불확실해지면서 개발 일정이 점점 짧아진다.

• 과거에는 개발 초기에 요구사항을 최대한 도출하고 개발하는 동안 요구사항 변경을 최소화하는 방향으로 진행했다.
• IT 산업에서는 시장 환경이 불확실하여 요구사항이 심하게 변경되며, 초기 요구사항 중 상당수는 가치가 없어져 새로운 요구사항으로 대체하기도 한다.
• 그렇다고 시장 출시를 늦출 수는 없다. 결국 출시 시기에 맞춰 개발 과정 중에 발생하는 요구사항의 변경을 모두 수행해야만 한다.

2. 고객에게 매력적인 가치를 제공해야 시장에서 살아남는다.

• 과거에는 기업이 단순히 특정 기능이나 품질만 개선해도 시장에서 어느 정도 위치를 확보할 수 있었지만 지금은 고객에게 매력적인 가치를 제공하지 않으면 살아남기 어렵다.
• 소니와 노키아 모두 거액의 자금을 R&D와 제품 개발에 투입했음에도 결국은 시장에서 팔리지 않는 제품을 내놓았다.
• 이제 프로젝트는 단순히 초기에 주어진 요구사항을 개발하는 것으로 그쳐서는 안 된다.

 

1.7 전통적 프로젝트 수행 방식에는 어떤 한계가 있는가?

1. 프로젝트 초기에 구체적인 요구사항을 도출하기 어렵다.

• 분석, 설계, 구현, 테스트를 순차적으로 진행하는 폭포수 개발 방식은 분석 단계에서 요구사항을 충분히 도출하지 않으면 이후 단계로 진행하기 어렵고, 전체 일정도 예측이 불가능하다.

2. 프로젝트 중간에 발생하는 요구사항의 변경을 반영하기 어렵다.

• 많은 엔지니어가 분석 단계에서 다양한 기법(비즈니스 모델링, 스토리보드, 프로토타입 등)을 활용하여 고객의 요구사항을 정확히 파악하려고 노력한다.
  • 하지만 이것만으로는 고객이 원하는 최종 시스템의 모습을 이해하기에 한계가 있다.
  • 고객 또한 어느 정도 완성된 시스템을 보고서야 구체적인 요구사항과 피드백이 나오기 마련이다.

3. 프로젝트 과정 중 중간 산출물을 많이 요구한다.

• 관리 절차와 개발 산출물은 개별적으로 타당성 척도가 있고, 이를 필요한 부분이나 현실에 적용할 때는 프로젝트의 특성에 따라 세심한 테일러링(tailoring)이 요구된다.
• 하지만 이런 테일러링 작업은 전문가의 부재 및 조직의 경직성으로 잘 이루어지지 못해 결과적으로 개발팀의 업무로드가 되는 경우가 많다.
• 어떤 프로젝트는 실제 제품을 만드는 코딩과 테스트를 수행하는 시간보다 문서 산출물을 만드는 시간이 더 오래 걸리기도 한다.

※ 프로세스 테일러링: 조직의 표준(standard) 프로세스를 프로젝트 상황에 맞게 조정하여 실질적으로 사용할 수 있는 프로세스와 템플릿으로 만드는 행위를 의미한다.

4. 프로젝트 관리자 중심의 명령과 통제 방식 때문에 구성원은 수동적으로 바뀌고, 커뮤니케이션은 매우 부족하다.

• 대부분의 프로젝트에서 관리자는 업무를 계획하고 통제하며 팀원에게 업무를 분배하는 역할을 수행하고, 팀원은 그저 리더에게서 할당받은 업무를 수행한다.
• 이런 상황에서 팀원은 수동적으로 일하게 되고, 프로젝트에서 발생하는 문제를 적극적으로 해결하려는 의지 또한 낮아진다.
• 커뮤니케이션 또한 관리자와 팀원 간에 주로 일어나고 팀원 간에는 잘 일어나지 않는다(개인적인 잡담은 해도 업무적인 이야기는 잘 안 한다).
• 결국 팀원 간에 이야기하면 간단히 풀릴 문제도 관리자 레벨로 올라가 업무를 처리하는 속도가 느려진다.