컨설턴트의 프로젝트 관리 방법론
애자일 vs 폭포수 방법론
컨설턴트의 업무는 프로젝트 매니저의 역할과 많은 부분이 겹칩니다. 특히 저는 디지털과 IT 컨설팅을 위주로 하다 보니, 클라이언트의 프로젝트들을 계획하고 관리하는 PM의 업무를 중시하는 프로젝트를 주로 다뤘습니다.
제가 현재 진행하고 있는 디지털 마케팅 전략 프로젝트는 전통적인 폭포수 방법론(Waterfall Method)을 활용하고 있습니다.
이번 프로젝트에 폭포수 방법론이 더 적합했던 이유는 아래와 같습니다.
클라이언트는 컨설팅펌에게 프로젝트를 전적으로 맡긴 후, 그 과정에 최소한의 개입을 한 후 최종 결과물만 확인하기를 희망했습니다. 폭포수 방법론은 '과정'보다는 '결과'에 집중하는 편입니다.
프로젝트 론칭 날짜가 명확히 주어진 상황이었기에, 프로젝트 일정이 유연하게 변형될 여지가 없었습니다. 또한 클라이언트는 예산을 미리 정해놓은 후 프로젝트를 시작하길 원했으며, 최소한의 예산 변경을 추구했습니다. 폭포수 방법론은 정해진 일정과 정해진 예산을 갖고 프로젝트를 시작합니다.
그 반대로, 제가 전에 진행했던 IT 프로젝트들은 애자일 방법론을 이용했습니다. 두 개의 대기업이 합병하기로 결정한 후, 저희는 ERP와 CRM 플랫폼을 합치고 정리해야 하는 목표와 함께 프로젝트를 시작했습니다.
이와 같이 대규모의 빅데이터가 존재하고, 수십 명의 관계자들이 프로젝트에 참여해야 했던 경우에서는 애자일 방법론이 적합했습니다. 그 이유는 아래와 같습니다.
컨설턴트로써 클라이언트에게 일방적으로 서비스를 제공한다기보다는, 양 쪽 기업의 파트너십을 기반으로 결과물을 같이 만들어간다는 느낌을 선호했습니다. 애자일 방법론은 외부인 클라이언트와, 그리고 내부인 팀원들과의 꾸준한 교류와 대화들을 실현시킵니다.
프로젝트 진행 중에도 사용되고 있던 live dataset과 live process를 갖고 작업을 해야 했기 때문에, 문제점이 발생하였을 경우 문제 해결을 신속하게 처리해야 한다는 의무감이 존재했습니다. 만약 문제가 될 수 있는 부분을 발견했다면, 애자일 방법론의 데일리 스크럼 미팅을 통해 누구나 부담 없이 escalation을 할 수 있었으며, 단순한 '결과'보다는 함께 토론하며 해결 내가는 '과정'에 집중할 수 있습니다.
프로젝트와 클라이언트의 니즈와 주어진 상황에 따라, 적합한 프로젝트 방법론을 택할 수 있는 능력이 필요합니다. 따라서 폭포수와 애자일 방법론에 대해 정리해봤습니다.
폭포수 방법론
폭포수 방법론을 이용해 관리되는 프로젝트는 순차적으로 밟으며 차례대로 진행됩니다. 기획, 디자인, 개발, 테스트, 론칭과 같은 과정을 순서대로 거치며, 반드시 한 단계의 진행이 끝나야 그다음 단계를 진행할 수 있는 특성이 있습니다. 이는 모든 단계에서 아무 문제없이 진행이 된다면, 가장 이상적이고 효율적인 방법입니다. 하지만, 이미 진행 완료된 완성품에 바꾸고 싶은 부분이 생긴다면은 시간적, 그리고 경제적으로 비실용적일 수 있는 절차를 거쳐야 합니다.
애자일 방법론
Agile = Iterative애자일 방법론을 이용한 프로젝트는 반복적인 iteration을 통해 프로토타입에 '살'을 붙여가며 마지막 결과물이 탄생하기까지 개발해나갑니다. 초기에 계획과 설계의 절차를 마친 후 개발을 시작하기보단, 연속적으로 반복 작업을 수행합니다. 따라서 여러 명의 stakeholder들과 여러 개의 요구사항 변경이 있더라고, 모든 조건을 프로젝트에 수월하게 반영시킬 수 있습니다.
제가 실제로 IT 컨설팅 프로젝트에서 썼던 애자일 프로세스 흐름을 요약해봤습니다.
Scrum Team
애자일 방법론을 활용한 프로젝트를 진행하려면 우선 스크럼 팀이 구성되어야 합니다. 프러덕트 오너(PO)는 제품 책임자로서, product backlog에 포함될 제품에 대한 비즈니스 관점에서 바라본 requirements를 작성합니다. 스크럼 마스터(SM)는 애자일 프로젝트의 메인 관리자로써, 스크럼이 순조롭게 수행될 수 있도록 도와주는 중요한 역할을 맡고 있습니다. 마지막으로 개발자 리드(developer lead)는 여러 명의 개발자들과 스크럼 팀의 연결고리로 활동합니다. 제가 맡은 프로젝트에서 저는 개발자 리드로써, 인도에 위치한 개발자 10명과 함께 협업하며 다양한 technical challenge들의 솔루션을 함께 디자인하는 역할을 수행했습니다.
Product Backlog
애자일의 첫 번째 업무는 클라이언트와 협업하여 요구사항을 수집하는 것(requirement gathering)입니다. 그에 따라 제품을 사용할 다양한 유저 스토리를 디자인하고, 스토리 포인트/점수를 매기며 업무의 prioritization 또는 우선순위를 결정합니다.
Sprint Planning
하나의 스프린트가 시작하기 전, 스프린트의 기간과 제품 백로그에 나열돼있는 업무를 계획하는 스프린트 플래닝 미팅을 수행합니다. 팀원들의 capacity 또한 고려하며 팀원들은 자신이 이번 스프린트에서 실행할 업무를 정합니다.
Scrum Calls
매일 하루의 시작은 스크럼 미팅과 함께 출발합니다. 팀원 모두가 스탠드업에 참여하며, 한 명씩 어제 한일, 오늘 할 일, 그리고 자신의 업무를 진행 함으로써의 현실적인 걱정거리에 대해 솔직하게 공유합니다.
Sprint Review
스프린트가 종료할 때쯤, 팀원들은 각자가 한 일을 각자 성찰한 후 다른 팀원에게 짧게 발표를 합니다. 자신이 만든 결과물을 꾸밈없이 설명하며, 팀원들에게 솔직한 피드백을 받은 후, 같이 개선해나갈 방법들에 대해 토론합니다.
Sprint Retrospective
스프린트 리뷰는 실제로 만들어 낸 성과물에 대한 토론이라고 하면, 스프린트 회고는 팀워크에 대한 토론입니다. 한 스크럼 팀으로써 잘한 점과 앞으로 개선할 수 있는 점들을 도출해 내는 과정을 거칩니다.
2001년 17명의 개발자들이 agilemanifesto.org에 애자일 정의론을 정리했습니다.
그중 몇 가지의 중요 요소를 아래 요약해봤습니다.
애자일 소프트웨어 개발 선언
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를 가치 있게 여깁니다.
애자일 선언 이면의 원칙 (요약 버전)
가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시킵니다.
비록 개발의 후반부일지라도 요구사항 변경을 환영합니다.
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 합니다. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화입니다.
단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적입니다.
팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정합니다.
점점 빠르게 변하고 있는 디지털 세상에서 더욱더 효율적인 업무 진행을 위해 많은 기업들이 애자일 방법론을 통해 프로젝트를 진행하려는 시도를 하고 있습니다.
실제로 제가 현재 진행하고 있는 디지털 마케팅 전략 프로젝트 또한 최근에 '애자일 포드(Agile Pod)'라는 베타 시스템을 만들었습니다. 지금까지 몇 년 동안 폭포수 방법론으로 관리해왔던 프로젝트를 조금 더 효율적으로 변환시키기 위한 새로운 시도입니다. 저희 팀은 저를 이 파일롯 프로그램에 투입시켰고, 저는 전통적으로 진행해왔던 업무 방식을 완전히 바꿀 애자일 방법론의 긍정적인 잠재력을 기대해봅니다.
(P.S. 저는 제 인생의 가치관에서 또한 애자일 방식론을 적용하려고 노력 중입니다. 에자일의 가장 큰 장점은 행동력이라고 생각합니다. 새로운 일에 도전할 때 '계획'이라는 단계에 너무 긴 시간을 투자하며 철저하게 '완벽한 준비'를 하다 보니, 좋은 기회의 타이밍을 놓친 경험이 있었습니다. 그 후로, 저는 'just do it'이라는 인생 모토와 함께 새로운 일을 실행하고, 피드백을 받은 후, 개선하는 과정을 추구해오고 있습니다. 도전을 할지 말지 주저하다가 고민만 하다 보면, 시작조차 하지 못하기 마련입니다!)
