소프트웨어 공학과 PM의 역량 - 기획자는 PM이 아니다.

하나의 시스템 개발은 많은 사람이 현업을 통해 만들어내는 공동 작품입니다.
조각 그림을 맞춰 나가듯 많은 공동 작업자들이 각 부분의 조각을 하나씩 완성해 나가고 그것을 통합하여 그림판에 옮겨 놓는 작업 입니다.

이런 작업에서는 우선 밑그림을 그리고, 각 조각을 만들고, 조각을 다시 그림판에 올려 놓는 일련의 활동을 하게 됩니다.

개발 방법론도 이런 일맥 상통한 작업이라고 할 수 있습니다.

하드웨어의 발전에 비해 소프트웨어 발전은 뒤처져 왔습니다. 그 원인이야 여러가지가 있겠지만,  소프트웨어 및 시스템은 반세기 동안 하드웨어/인프라 발전을 따라가지 못하고 있는 것이 현실 입니다.
 
소프트웨어가 발전이 느렸던 이유중 가장 큰 이유는

정형화 되어 있는 하드웨어 비해 소프트웨어는 정형화되어 있지 않기 때문입니다.
정형화되어 있지 않다는 것은 하드웨어 보다 소프트웨어쪽이 사람에게 가깝기 때문입니다.
(시스템중에 하드웨어 보다 소프트웨어가 사람의 생활패턴에 접근되어 있는 것이고, 기계와 인간간의 인터페이스 역활을 하고 있습니다. )

인간과 접근되어 있다 보니, 인간의 변화(혹은 변심)속에서 정형화라는 자체가 어려울 수 밖에 없습니다.

정형화를 위한 부분보다 어떻게 인간의 변화에 정확하게 대응하느냐에 대한 연구가 더 많이 발생할 수 밖에 없었을 것입니다.

개발 방법론은 이런 근본적인 원인으로 인한 많은 문제점을 효율적인 해결을 위한 방법으로 더욱 발전하게 되었습니다.

- 소프트웨어 공학 등장배경 -

● 하드웨어 개발 비용에 비해 소프트웨어 개발 비용의 증가
● 새로운 시스템 개발 요구 및 수요 급증
● 요구 및 수요 급증 대비 개발자 생산성 저하
● 개발 인력 부족
● 개발 기술 미비
● 기존 소프트웨어의 유지보수 어려움

소프웨어 공학은 소프트웨어의 개발에 필요한 모든 측면을 공학적인 접근 방법으로 다루는 학문으로

- 주어진 기간 내에 프로젝트을 효율적으로 관리하는 방법
- 프로젝트에 투입될 비용(Cost)를 예측하고 인력을 관리하는 방법
- 사용자 요구사항(Requirement)을 정확히 분석하고 요구사항에 적합한 소프트웨어를 개발하는 방법
- 개발 과정의 산출물을 체계적으로 문서화(Documentation)하는 방법

중심으로 연구를 합니다.


이런 의미에서 개발 방법론의 기본 개념은 소프트웨어 공학에서 나온 것입니다.

개발 방법론이란 제품을 생산하기 위한 일련의 활동(Activity)와 산출물(OutPut)를 체계적으로 관리하는 일련의 활동이라고 정의할 수 있으며, 이런 활동을 소프트웨어 공학에서는 소프트웨어 프로세스라고 정의하고 있습니다.

일반적인 프로세스 활동은 4단계로 이뤄집니다.

1. 명세(Specification) : 기능과 운영상의 제약조건 정의
2. 개발(Development) : 명세를 만족하는 소프트웨어 개발
3. 검증(Validation) : 사용자가 원하는 소프트웨어인지 확인
4. 진화(Evolution) : 사용자 요구사항의 변화에 부응하는 소프트웨어 변경

소프트웨어 공학이나, 개발 방법론이나 요구사항에 부합되는 제품, 서비스를 생산해내는 활동에 초점이 맞춰져 있고,  발생 예견된 많은 위험(RIsk) 최소화 하는 활동을 위한 관리기법(Management)이 필요한 것입니다.

PM(Project Manager)에 대한 잠시 짚어 보겠습니다.

- 프로젝트(Project) 란 프로젝트란 유일한 제품, 서비스 또는 결과를 창출하기 위해 일과성으로 투입하는 노력을 말한다.

- 프로젝트 관리(Project Management)란 프로젝트 요구사항을 충족시키는 데 필요한 지식, 기량, 도구 및 기법 등을 프로젝트 활동에 적용하는 것을 말한다.
프로젝트관리는 프로젝트 착수, 기획, 실행, 감시, 통제 및 종료 단계로 진행되는 프로젝트관리 프로세스의 적용과 통합을 통해 이루어진다.

- 프로젝트관리자(Project Manager)란 프로젝트 목표를 달성할 책임을 지고 있는 관리자를가리킨다.

- 출처 : PMBOK 3rd-

간혹 PM에 대해서 잘못 이해하고 있는 사람들이 많이 있습니다. 특히 웹에이전시의 PM는 그 역량에 대한 부분보다, 단지 클라이언트와의 접점을 위한 존재로만 인식하는 경우가 많이 있습니다.
그렇다보니, 기획자가 PM을 한다는 인식이 많이 가지고 있습니다.

PM은 관리자라고 해야 정확한 것입니다.
▶ 사용자(Client)의 요구사항과 프로젝트의 근본 방향을 정확하게 이해하고,
▶ 프로젝트 과업에 대한 일관성 있는 목표 달성의 책임을 가지고 있는 사람입니다.

프로젝트에 대한 전반적인 책임을 지기 위해서는 3가지의 중요한 역량이 있어야 합니다.

1. 일괄성
간혹 프로젝트를 하다 보면... 배가 산으로 간다는 말이 있습니다. 그 방향을 잃어 표류하는 배들은 난파될 확률이 높습니다. 초기반에 프로젝트의 배경을 이해하고 방향성을 갖추고 나면, 프로젝트 진행은 일괄성을 지녀야 합니다.
이 일괄성은 요구사항에 대한 부분이 가장 강합니다.

2. 단계성
일에는 순서가 있다고 말합니다. 각 단계에 대한 수행능력과 그 단계에 대한 조율을 적절하게 이뤄나가야 합니다.

3. 체계성
프로젝트를 진행하다 보면, 각 단계를 생략하는 경우가 많이 있습니다. 물론 상황에 따라 진행이 변화될 수 있겠으나, 모든 단계는 근거와 과정에 대한 이유가 존재하는 것입니다. 이런 단계를 거쳐 나갈때-변화가 되던 안되던- 체계적인 관리가 있어야 합니다. 특히 단계가 생략되는 경우에는 더욱 그렇습니다.


PM에 대한 이해가 낮을수록 프로젝트는 표류하여 난파될 가능성이 높습니다.

전쟁에서 많은 병사도 중요하지만, 병사들과 그들을 전쟁에 보낸 이들이, 중심에서 지휘하고 선장을 서는 장군이 어떤 존재인지를 이해해야지만, 일괄성을 단계성을 체계성을 보장 받을 수 있으며, 결국 전쟁에서 이길 수 있게 되는 것입니다.


기획자 = PM의 논리에서 벗어나야 합니다. PM은 누구나 될 수 있으나, 기본적인 지식을 습득되어야 합니다.

PM 는 개발/관리 방법론에 대한 지속적인 지식습득이 필요로 합니다.
집을 짓더라도, 토대가 제대로 잡히지 않는다면... 오래 가지 합니다.