2015.06.30

일정 최우선 대충 관행은 그만!··· 프로젝트 관리의 '더러운 비밀' 넘어서기

David Taber | CIO

비즈니스 시스템에서는 프로젝트 가동일이 정말 중요하다. 이에 프로젝트 관리자는 일정 초과 대신 예산 초과를 선택하곤 한다.

그러나 사실 여기에는 금전적인 이유도 있다. 해당 분기의 매출과 이익이 보너스, 커미션, 주가를 결정하기 때문이다. 따라서 현재 분기 실적에 영향을 미칠 변화를 시도하기보다는 다음 분기에 가급적 빨리 이런 변화를 추구하게 된다.

특히 요즘이 이런 문제를 직면하는 시기다. 분기 말이 얼마 남지 않았다. 컷오버(Cutover, 새 시스템 가동) 시기에 대한 압력이 높아지기만 할 것이다. 그리고 프로젝트 팀의 집단 지성(Collective IQ)이 낮아지기만 한다. 7월 연휴를 앞두고, 모든 이들이 새 시스템 컷오버에 대해 압력을 가해올 것이다. 그래야만 2분기 보너스를 챙길 수 있기 때문이다.


Credit: Thinkstock

제도로 굳어진 합리화?
즉 새 비즈니스 시스템 론칭을 앞두고 온갖 제안을 들려올 것이다. 프로젝트에 박차를 가할 수 있다는 다음과 같은 제안들이다.

- 단위 테스트 대신 통합 테스트에 초점을 맞춘다.

- 통합 테스트와 사용자 수용 테스트를 동시에 진행한다.

- 설정 관리 오버헤드를 생략한다.

- 생산화 단계에서 직접 디버깅과 문제 해결을 시도한다.

- 통합을 중심으로 까다로운 테스트를 생략한다.

- 가장 중요한 3가지 유즈케이스를 대상으로 기능 테스트를 한다.

- 사용자 수용 테스트를 오프쇼어 팀에게 넘긴다.

- 시스템을 가동한 이후에 데이터 품질을 걱정한다.

- 별도 인력으로 타이거 팀(Tiger Team)을 구성한다.

- 컨설턴트를 2교대로 운용한다.

- 비즈니스 프로세스 검증과 코드 검토는 생략한다.

- 통합적인 부분의 완성은 나중으로 미루고, 야간 데이터 업데이트로 어느 정도 동기화한다.

- 영향을 적게 받는 사용자를 대상으로 새 시스템의 셰도우 복사본을 구현하고, 많이 사용하는 사용자는 기존 시스템을 계속 이용하게 한다. 이렇게 해도 새 시스템을 구현했다고 주장할 수 있다. 한편에서는 개발자들이 (사용자가 없는) 진짜 새 시스템을 계속 구축한다. (이는 '포템킨 빌리지(전시용 겉치례)' 전략이라고 불린다.)

- 업무에 바탕을 둔 장기간의 효과적인 트레이닝은 지양한다. 대신 하루 일정의 트레이닝을 실시한다.

- 협력과 파워-유저 개발, 고우-라이브-위크(Go-live-week, 구현 후) 지원은 사치이니 생략한다. 이는 각자 해결해야 할 부분이다. 다음 프로젝트에 그 즉시 개발자를 투입할 예정이기 때문이다.

간단히 말해, 다른 분야의 '자칭' 전문가들이 갖가지 설익은 아이디어를 내어 놓는다. 아마 구직자에게 이런 이야기를 들었다면 그 즉시 채용을 거절했을 것이다. 그러나 상사가 내어 놓은 아이디어라면 어떻게 할까? 아마 아래 입술을 깨물면서 입을 다물기 십상이다.

우리 모두에게 일어날 수 있는 일이다. 60년대부터 변함없이 그랬다('미스티컬 맨-몬스(Mythical Man Month)'와 ControlData OS 사례가 있다). 아마 애자일(Agile) 팀만이 원칙 및 절차 무시라는 유혹에 저항할 것이다.

지금도 전혀 나아지지 않았다. 특히 피해야 할 복잡성과 종속변수가 많은 프로젝트들에서 그렇다. 필자는 프로젝트 '전복'을 자초하는 이러한 관행에 정말이지 신물이 난다.

질문에 답이 있다
프로젝트 일정과 관련된 위기를 피하려면 어떻게 해야 할까? 프로젝트에 관련된 부분을 줄이면 된다. 소프트웨어에서 그렇게 하고 있다(비동기 웹 서비스). 프로젝트라고 안될 이유는 없다. 시도해 볼만한 방법들로는 다음과 같은 것들이 있다.




2015.06.30

일정 최우선 대충 관행은 그만!··· 프로젝트 관리의 '더러운 비밀' 넘어서기

David Taber | CIO

비즈니스 시스템에서는 프로젝트 가동일이 정말 중요하다. 이에 프로젝트 관리자는 일정 초과 대신 예산 초과를 선택하곤 한다.

그러나 사실 여기에는 금전적인 이유도 있다. 해당 분기의 매출과 이익이 보너스, 커미션, 주가를 결정하기 때문이다. 따라서 현재 분기 실적에 영향을 미칠 변화를 시도하기보다는 다음 분기에 가급적 빨리 이런 변화를 추구하게 된다.

특히 요즘이 이런 문제를 직면하는 시기다. 분기 말이 얼마 남지 않았다. 컷오버(Cutover, 새 시스템 가동) 시기에 대한 압력이 높아지기만 할 것이다. 그리고 프로젝트 팀의 집단 지성(Collective IQ)이 낮아지기만 한다. 7월 연휴를 앞두고, 모든 이들이 새 시스템 컷오버에 대해 압력을 가해올 것이다. 그래야만 2분기 보너스를 챙길 수 있기 때문이다.


Credit: Thinkstock

제도로 굳어진 합리화?
즉 새 비즈니스 시스템 론칭을 앞두고 온갖 제안을 들려올 것이다. 프로젝트에 박차를 가할 수 있다는 다음과 같은 제안들이다.

- 단위 테스트 대신 통합 테스트에 초점을 맞춘다.

- 통합 테스트와 사용자 수용 테스트를 동시에 진행한다.

- 설정 관리 오버헤드를 생략한다.

- 생산화 단계에서 직접 디버깅과 문제 해결을 시도한다.

- 통합을 중심으로 까다로운 테스트를 생략한다.

- 가장 중요한 3가지 유즈케이스를 대상으로 기능 테스트를 한다.

- 사용자 수용 테스트를 오프쇼어 팀에게 넘긴다.

- 시스템을 가동한 이후에 데이터 품질을 걱정한다.

- 별도 인력으로 타이거 팀(Tiger Team)을 구성한다.

- 컨설턴트를 2교대로 운용한다.

- 비즈니스 프로세스 검증과 코드 검토는 생략한다.

- 통합적인 부분의 완성은 나중으로 미루고, 야간 데이터 업데이트로 어느 정도 동기화한다.

- 영향을 적게 받는 사용자를 대상으로 새 시스템의 셰도우 복사본을 구현하고, 많이 사용하는 사용자는 기존 시스템을 계속 이용하게 한다. 이렇게 해도 새 시스템을 구현했다고 주장할 수 있다. 한편에서는 개발자들이 (사용자가 없는) 진짜 새 시스템을 계속 구축한다. (이는 '포템킨 빌리지(전시용 겉치례)' 전략이라고 불린다.)

- 업무에 바탕을 둔 장기간의 효과적인 트레이닝은 지양한다. 대신 하루 일정의 트레이닝을 실시한다.

- 협력과 파워-유저 개발, 고우-라이브-위크(Go-live-week, 구현 후) 지원은 사치이니 생략한다. 이는 각자 해결해야 할 부분이다. 다음 프로젝트에 그 즉시 개발자를 투입할 예정이기 때문이다.

간단히 말해, 다른 분야의 '자칭' 전문가들이 갖가지 설익은 아이디어를 내어 놓는다. 아마 구직자에게 이런 이야기를 들었다면 그 즉시 채용을 거절했을 것이다. 그러나 상사가 내어 놓은 아이디어라면 어떻게 할까? 아마 아래 입술을 깨물면서 입을 다물기 십상이다.

우리 모두에게 일어날 수 있는 일이다. 60년대부터 변함없이 그랬다('미스티컬 맨-몬스(Mythical Man Month)'와 ControlData OS 사례가 있다). 아마 애자일(Agile) 팀만이 원칙 및 절차 무시라는 유혹에 저항할 것이다.

지금도 전혀 나아지지 않았다. 특히 피해야 할 복잡성과 종속변수가 많은 프로젝트들에서 그렇다. 필자는 프로젝트 '전복'을 자초하는 이러한 관행에 정말이지 신물이 난다.

질문에 답이 있다
프로젝트 일정과 관련된 위기를 피하려면 어떻게 해야 할까? 프로젝트에 관련된 부분을 줄이면 된다. 소프트웨어에서 그렇게 하고 있다(비동기 웹 서비스). 프로젝트라고 안될 이유는 없다. 시도해 볼만한 방법들로는 다음과 같은 것들이 있다.


X