가능한 한 빨리 유저를 끌어들여라

프로젝트 매니저가 알아야 할 97가지 - 첫 번째 이야기

by - Barbee Davis
PMI의 Community Post에 매월 두 번 칼럼을 쓰고 있다. 이 칼럼은 전 세계 400,000명 이상의 프로젝트 매니저들에게 전달된다. PMI 연수 조직인 Registered Education Program(R.E.P.)의 허가, 갱신 담당 리뷰어로도 활동하고 있다. 데스크톱 기술 애플리케이션 교육과 인증을 실시하는 컴퓨터 소프트웨어 연수 회사를 경영하고 있다. Microsoft Project의 Black Belt를 보유자이다. "How To Learn MicrosoftProject in 24 Hours"의 공동 집필자이다. 미국 내 다양한 프로젝트를 직접 관리하며 수백 명의 프로젝트 매니저를 훈련시켰다. 대학 강단에도 서고 있고 다양한 세미나의 초청 강연자로서도 유명하다. 어쩌면 당신도 미국이나 캐나다의 No Fluff Just Stuff에 참여했다면 접수처에서 그를 마주쳤을지도 모른다.

지금껏 소프트웨어 개발은 고객의 요구를 확인하고 장막 뒤에 숨어 코딩과 테스트를 진행하는 것이 일반적이었습니다. 어차피 사용자는 우리가 뒤에서 어떤 일을 하고 있는지 알지 못합니다. 프로젝트가 끝나갈 무렵 가려진 장막을 슬쩍 치우고 만들어진 걸 보여주면 "와~", "오오~"와 같은 감탄사를 쏟아낼 것입니다. 하지만 안타깝게도 좋게만 흘러가진 않습니다.

"오오~ 여러분이 열심히 한 건 잘 알겠어요. 하지만 저희가 원했던 건..."이라는 말이 돌아옵니다.

프로젝트 성공 비결은 프로젝트 진행 중에 보여줄 수 있는 부분이 생기면 바로 사용자를 끌어들여서 보여주고 피드백을 받는 것입니다. 프로젝트 완료 후에 문제가 발견되는 것보다 개발 초기에 문제가 발견되는 것이 훨씬 좋습니다.

프로젝트가 진행되면 될수록 수정에 드는 비용도 점점 커집니다. 프로그램을 고치고 다시 테스트하는 시간, 수정한 부분 주변에 있는 코드와의 통합을 테스트하는 시간은 개발 초기 단계와 완료 단계에서 비교해보면 아주 크게 차이가 나게 됩니다. 수정 범위가 너무 커서 변경 관리 위원회(Change Control Board)의 승인 프로세스가 필요해진다면 프로젝트는 시간적으로나 비용적으로도 모두 위기에 노출됩니다.

이러한 문제들이 사양을 변경하면 간단히 해결된다고 해서 절대로 마음대로 변경해선 안됩니다. 아무리 사소한 문제여도, 개발자와 매니저가 괜찮다고 판단했다 하더라도 사용자와 상의 없이 함부로 변경 해선 안됩니다. 그 판단이 옳은지는 소프트웨어를 실제로 이용하는 현장 사용자만 알 수 있기 때문입니다.

저는 발주한 소프트웨어의 재설계에만 5,000,000 달러를 들인 거대한 연구 회사를 알고 있습니다. 종전의 시스템은 아이템 번호가 각 제품에 대응되어 특정한 규칙으로 번호가 매겨집니다. 예를 들면 4125는 "학생용 안내서", 4225는 "학생용 강의 개요", 4325는 "강사용 안내서", 4425는 "강사용 강의 개요"와 같이 정리되고, "4x25"라는 일련번호의 아이템은 모두 동일 화면에서 주문할 수 있게 되어 있었습니다.

세계 140개 거점에서 하루에 몇 번이고 같은 아이템을 발주하는 상황이라 담당자들은 그 아이템 번호를 외워서 처리하고 있었습니다. 학생용 안내서의 번호를 외워서 따로 검색하지 않고 바로 다른 관련의 아이템의 번호를 입력하여 주문하는 방식입니다. 그러한 특별한 규칙 덕분에 그들은 필요할 때마다 재빨리 주문할 수 있었습니다.

이 소프트웨어를 재설계하면서 담당한 프로젝트팀은 실제 현장에서 사용되고 있던 발주 프로세스에 대해 전혀 고려하지 못했습니다. 새로운 설계에서는 아이템 간의 논리적인 관계와 규칙들을 고려하지 않고 예전에 사용하던 4125 학생용 안내서를 6358로 변경해버렸습니다. 그리고 "학생용 강의 개요"는 8872로, "강사용 강의 개요"는 3392로 변경했습니다.

그 결과 담당자들은 새로운 아이템 번호를 일일이 알아보고 주문해야 했고 지금까지 해왔던 번호를 기억 속에서 지워야만 했습니다. 게다가 관련된 아이템들은 서로 다른 페이지에서 주문하도록 변경되어버렸습니다.

당연히 현장에는 대혼란이 발생했고 담당자들은 크게 화를 냈습니다. 발주 업무에 큰 차질이 빚어졌기 때문입니다. 결국 그 프로젝트는 처음부터 다시 시작해서 설계되었고 정해진 기간과 비용을 크게 초과해 버렸습니다.

당신은 프로젝트 매니저로서 가능한 한 빨리 사용자와 개발자가 활발히 커뮤니케이션할 수 있도록 도와야 합니다.