비즈니스 시스템에서는 프로젝트 가동일이 정말 중요하다. 이에 프로젝트 관리자는 일정 초과 대신 예산 초과를 선택하곤 한다. 그러나
그러나 사실 여기에는 금전적인 이유도 있다. 해당 분기의 매출과 이익이 보너스, 커미션, 주가를 결정하기 때문이다. 따라서 현재 분기 실적에 영향을 미칠 변화를 시도하기보다는 다음 분기에 가급적 빨리 이런 변화를 추구하게 된다.
특히 요즘이 이런 문제를 직면하는 시기다. 분기 말이 얼마 남지 않았다. 컷오버(Cutover, 새 시스템 가동) 시기에 대한 압력이 높아지기만 할 것이다. 그리고 프로젝트 팀의 집단 지성(Collective IQ)이 낮아지기만 한다. 7월 연휴를 앞두고, 모든 이들이 새 시스템 컷오버에 대해 압력을 가해올 것이다. 그래야만 2분기 보너스를 챙길 수 있기 때문이다.
Credit: Thinkstock
제도로 굳어진 합리화?
즉 새 비즈니스 시스템 론칭을 앞두고 온갖 제안을 들려올 것이다. 프로젝트에 박차를 가할 수 있다는 다음과 같은 제안들이다.
– 단위 테스트 대신 통합 테스트에 초점을 맞춘다.
– 통합 테스트와 사용자 수용 테스트를 동시에 진행한다.
– 설정 관리 오버헤드를 생략한다.
– 생산화 단계에서 직접 디버깅과 문제 해결을 시도한다.
– 통합을 중심으로 까다로운 테스트를 생략한다.
– 가장 중요한 3가지 유즈케이스를 대상으로 기능 테스트를 한다.
– 사용자 수용 테스트를 오프쇼어 팀에게 넘긴다.
– 시스템을 가동한 이후에 데이터 품질을 걱정한다.
– 별도 인력으로 타이거 팀(Tiger Team)을 구성한다.
– 컨설턴트를 2교대로 운용한다.
– 비즈니스 프로세스 검증과 코드 검토는 생략한다.
– 통합적인 부분의 완성은 나중으로 미루고, 야간 데이터 업데이트로 어느 정도 동기화한다.
– 영향을 적게 받는 사용자를 대상으로 새 시스템의 셰도우 복사본을 구현하고, 많이 사용하는 사용자는 기존 시스템을 계속 이용하게 한다. 이렇게 해도 새 시스템을 구현했다고 주장할 수 있다. 한편에서는 개발자들이 (사용자가 없는) 진짜 새 시스템을 계속 구축한다. (이는 ‘포템킨 빌리지(전시용 겉치례)’ 전략이라고 불린다.)
– 업무에 바탕을 둔 장기간의 효과적인 트레이닝은 지양한다. 대신 하루 일정의 트레이닝을 실시한다.
– 협력과 파워-유저 개발, 고우-라이브-위크(Go-live-week, 구현 후) 지원은 사치이니 생략한다. 이는 각자 해결해야 할 부분이다. 다음 프로젝트에 그 즉시 개발자를 투입할 예정이기 때문이다.
간단히 말해, 다른 분야의 ‘자칭’ 전문가들이 갖가지 설익은 아이디어를 내어 놓는다. 아마 구직자에게 이런 이야기를 들었다면 그 즉시 채용을 거절했을 것이다. 그러나 상사가 내어 놓은 아이디어라면 어떻게 할까? 아마 아래 입술을 깨물면서 입을 다물기 십상이다.
우리 모두에게 일어날 수 있는 일이다. 60년대부터 변함없이 그랬다(‘미스티컬 맨-몬스(Mythical Man Month)’와 ControlData OS 사례가 있다). 아마 애자일(Agile) 팀만이 원칙 및 절차 무시라는 유혹에 저항할 것이다.
지금도 전혀 나아지지 않았다. 특히 피해야 할 복잡성과 종속변수가 많은 프로젝트들에서 그렇다. 필자는 프로젝트 ‘전복’을 자초하는 이러한 관행에 정말이지 신물이 난다.
질문에 답이 있다
프로젝트 일정과 관련된 위기를 피하려면 어떻게 해야 할까? 프로젝트에 관련된 부분을 줄이면 된다. 소프트웨어에서 그렇게 하고 있다(비동기 웹 서비스). 프로젝트라고 안될 이유는 없다. 시도해 볼만한 방법들로는 다음과 같은 것들이 있다.
– IT 목표 달성과 보너스, 다른 인센티브를 연결시키지만, 고우-라이브(구현) 일자와는 연결시키지 않는다.
– 가능한 디버깅, 테스트, 조정, 복구 관련 활동을 개선하기 위해 (최소 몇 주 동안 로그를 유지하는 방식으로)모든 메시지를 로그로 기록하는 진짜 메시징 시스템에서 모든 통합을 처리한다.
– 통합에는 상상할 수 있는 수준보다 더 지저분한 데이터와 시멘틱스가 있을 것이라고 가정한다. 따라서 이전과 정상화(Normalization), 무결화(Cleansing) 일정에 25%를 추가한다. 정말로 그렇게 해야 한다.
– 지속적으로 통합을 해야 한다. 모든 코드를 대상으로 단위 테스트를 실시한다. 그리고 코드 개발과 함께 테스트를 하면서 시스템을 구현한다. 가능한 프로젝트 초기에 외부의 통합 요소와 실제 데이터를 통합한다.
– 사용자 중심의 설계를 한다. 프로젝트 일정에서 25%가 지나기 전에 사용자가 UI를 직접 테스트하고, 이에 따른 시정 결과를 평가하도록 만들어야 한다. 프로젝트 완료 때까지 이를 계속 수행한다.
– 조기에 스테이징(Staging)/샌드박스를 처리한다. 전 벤더의 사본을 대상으로 ‘풀 샌드박스’의 값을 지불하고, 사본을 스테이징 한다. 프로젝트의 중간쯤에 이를 적용한다. 정말로 그렇게 해야 한다. 샌드박스를 각각 연결해, 가능한 빨리 실제 개발 및 테스트 환경을 구현한다.
– 현실을 일깨운다. 임원진 가운데 후원자(후원자가 있을 것이다. 그렇지 않은가?)가 임원진을 대상으로 각 일정 종료 시점에 시스템을 시연한다. 이는 사용자 도입에 도움을 준다. 더 중요하게, 일정과 기능에 대해 지나친 기대를 갖지 않도록 만드는 효과가 있다.
– 우선순위를 정해 처리한다. 프로젝트 종료 시점에 문제에 직면하지 않는 방법 중 하나는 중간 결과물(Deliverables)을 줄이는 것이다. 정말 어려운 일이다. 그러나 필요 이상으로 예산과 일정을 초과하는 것을 막을 수 있다. 즉 부담을 줄여야 한다.
– 게임 이론을 적용한다. ‘백업 플랜(계획)’이라고 불린다. 최소한 고우-라이브 6주 전에 비즈니스의 ‘노우 고우(no-go)’ 결정을 처리하는 방법에 관한 토론을 한다.
– 정보를 공개한다. 중요한 중간 검토 때마다 팀원들이 부정적인 정보를 공개할 수 있게 허락을 한다. 말과 행동, 얼굴 표정으로 일정과 위험에 대한 현실을 깨닫게 만들 수 있다. 부정적인 정보를 공개한 사람에게 불이익을 주지 않는다.
– ‘빅뱅’ 같은 일을 하지 않는다. 단계 별로 도입을 한다. 앞선 단계를 안정화시킨 후, 이를 토대로 각 기능을 점진적으로 구현한다. 데이터를 점진적으로 도입한다(지난 해 데이터를 도입한 이후 2년 전 데이터를 추가). 그리고 우선순위가 낮은 데이터는 잠시 동안 ‘오프라인’ 상태를 유지한다.
바보 같은 아이디어로 들릴 아이디어가 있을지도 모르겠다. 그러나 50년 전과 같은 프로젝트 관행은 이제 변화시킬 때가 됐다. 뭔가 새로운 것을 시도할 시기다.
*David Taber는 ‘세일즈포스닷컴 성공의 비밀(Salesforce.com Secrets of Success)’의 저자며 세일즈포스닷컴의 공식 컨설팅 업체인 세일즈로직스 CEO다. dl-ciokorea@foundryco.com
