팀이 실제로 어떻게 일을 마무리하는지를 중심으로 프로젝트 관리 시스템을 만드는 실전 가이드입니다. 왜 일반 프로젝트 도구는 결국 방치되는지, 우리의 진짜 단계와 인수인계를 어떻게 모델링하는지, 첫 버전에는 무엇이 필요한지, 그리고 상태 회의 없이 진행 중인 일을 어떻게 한눈에 보는지를 다룹니다.
기성 프로젝트 도구에 업무 흐름이 맞지 않는 에이전시, 크리에이티브 팀, 외주 사업자, 프로덕트 팀, 그리고 서비스업 사업자들.
- 우리의 진짜 업무 단계와 인수인계 위에 세운 프로젝트 모델
- 상태 회의를 대체하는 진행 중 업무 뷰
- 업무 방식이 바뀔 때마다 다시 손볼 수 있는 시스템
대부분의 팀은 프로젝트 관리 도구를 써 봤지만 결국 스프레드시트와 채팅으로 되돌아갑니다. 문제는 도구 자체가 아니라 맞지 않았다는 데 있습니다. 일반 프로젝트 도구는 하나의 틀, 즉 작업을 여러 열에 늘어놓는 형태를 강요하지만, 우리의 업무에는 우리만의 형태가 있습니다. 우리의 단계, 우리의 승인, 우리의 인수인계 말입니다. 도구가 실제 일하는 방식과 맞지 않으면 그것을 업데이트하는 일이 헛수고가 되고, 결국 조용히 방치됩니다. 이 가이드는 실제로 맞물리는 시스템을 만들어 오래 쓰게 하는 방법에 관한 것입니다.
일반적인 틀, 대개 작업이 여러 열을 옮겨 다니는 형태를 강요하기 때문입니다. 반면 우리의 업무에는 거기에 들어맞지 않는 고유한 단계와 승인, 인수인계가 있습니다. 그래서 사람들은 경영진을 위해 도구를 유지할 뿐이고, 진짜 조율은 채팅에서 이루어지며, 도구의 정보는 낡아 가고, 결국 보러 가는 곳이 아니라 따로 업데이트해야 하는 또 하나의 장소가 됩니다. 프로젝트 시스템은 그 단계가 곧 우리의 단계이고, 우리 자신의 표현으로 되어 있을 때만 자리를 잡습니다.
익숙한 신호가 하나 있습니다. 도구는 어떤 프로젝트를 "진행 중"이라고 표시하지만, 모두가 사실은 "클라이언트 자료 대기 중"이라는 걸 압니다. 도구에는 그 상태를 부를 이름이 없습니다. 빠진 상태 하나하나가 작은 거짓말이고, 작은 거짓말로 가득한 보드는 아무도 믿지 않으니 아무도 최신으로 유지하지 않습니다. 해법은 더 많은 규율이 아니라, 단계가 실제 단계와 일치하는 시스템입니다. 일이 정말로 멈추는 그 어색한 대기 상태까지 포함해서요.
그래서 우리의 업무 방식을 먼저 설명하고 그 주위에 시스템을 세우는 편이, 남의 템플릿을 설정하는 것보다 낫습니다. 단계와 승인 지점, 인수인계가 바로 결과물이며, 그것은 우리가 일하는 방식에 고유한 것이기 때문입니다.
어떤 보드를 만들기에 앞서, 최근 프로젝트 몇 건이 시작부터 완료까지 실제로 어떻게 흘러갔는지, 어디에서 멈췄는지까지 되짚어 보세요. 지금 우리는 업무의 형태를 뽑아내는 중입니다.
한 디자인 스튜디오는 "클라이언트에게 발송함"과 "클라이언트가 회신함" 사이의 틈에서 늘 프로젝트를 놓치고 있었습니다. 그 틈에서는 일이 담당자도, 눈에 보이는 시계도 없이 며칠씩 방치되었습니다. 솔직하게 모델링해 보니 그들의 흐름에는 여덟 단계가 있었고 그중 셋이 대기 상태였습니다. 그리고 결정적인 기능은 그저 대기 상태를 시계와 함께 눈에 보이게 만든 것뿐이었습니다. "클라이언트 피드백 대기 중"에서 일주일 멈춘 프로젝트가 일반적인 "진행 중" 열에 숨는 대신 빨갛게 떠오르게 된 것이죠. 다른 것은 아무것도 바꾸지 않았는데 정시 전달률이 껑충 뛰었습니다.
프로젝트 도구는 다른 어떤 종류보다도 빠르게 비대해집니다. 시간 기록, 청구, 리소스 계획, 클라이언트 포털, 의존 관계까지요. 첫 버전은 일을 눈에 보이게 하고 계속 움직이게 하는 가장 작은 것입니다.
반복되는 상태 회의가 존재하는 이유는 상태가 어디에서도 보이지 않기 때문입니다. 좋은 시스템이라면 보여 줬을 것을, 사람들은 입으로 말하려고 모이는 것이죠. 프로젝트 시스템의 목표는 그 회의를 불필요하게 만드는 것이지, 회의에서 이야기할 도구를 하나 더 늘리는 것이 아닙니다.
누구나 하나의 뷰를 열어 모든 프로젝트와 그 단계, 담당자, 그리고 얼마나 오래 멈춰 있었는지를 볼 수 있을 때, 바로 그 지점에 도달한 것입니다. 시계가 달린 대기 단계는 조용한 정체를 눈에 보이는 정체로 바꿉니다. "클라이언트 검토"에 여드레째 있는 프로젝트가 스스로 떠오르고, 대화는 발견이 아니라 결정이 됩니다. 보드가 신뢰받고 최신일 때, 회의는 정말로 논의가 필요한 몇 가지로 줄고, 흔히 아예 사라집니다.
시스템을 계속 신뢰받게 하는 일은, 직접 소유하는 데서 나오는 두 가지에 달려 있습니다. 보드가 현실과 일치하는 것은 거기 있는 단계가 진짜 단계이기 때문이고, 계속 일치하는 것은 업무 방식이 바뀔 때 단계를 직접 바꿀 수 있기 때문입니다. 우리의 워크플로를 중심으로 만들어지고, 개발 티켓 없이 다시 손볼 수 있는 프로젝트 시스템이야말로 팀이 계속 최신으로 유지하는 시스템입니다. 마침내 일에 관한 진실을 말해 주기 때문입니다.
도구가 일반적인 틀, 대개 작업을 여러 열에 늘어놓는 형태를 강요하는데, 그것이 우리의 진짜 업무 단계와 승인, 인수인계에 맞지 않기 때문입니다. 사람들은 경영진을 위해 그것을 유지하고 진짜 조율은 채팅에 남으니 정보가 낡아 갑니다. 시스템은 그 단계가 일이 정말로 멈추는 대기 상태까지 포함한, 우리의 실제 단계일 때 자리를 잡습니다.
최근 프로젝트 몇 건이 실제로 어떻게 흘러갔는지, 어디에서 멈췄는지까지 되짚고, 진짜 단계를 우리 자신의 표현으로 이름 붙이세요. 브리핑 완료, 디자인 중, 클라이언트 검토, 수정, 승인됨 같은 식으로요. 무엇보다 "클라이언트 피드백 대기 중" 같은 대기 상태를 포함하세요. 일반 도구에서는 바로 거기에 일이 숨기 때문입니다.
하나의 명확한 진짜 단계에 놓인 프로젝트, 모든 프로젝트와 단계의 담당자, 진행 중인 모든 업무를 단계별로 보는 하나의 뷰, 그리고 다음 담당자가 채팅 메시지 없이도 알 수 있게 하는 분명한 인수인계입니다. 시간 기록, 청구, 의존 관계는 모두 두 번째 버전까지 미뤄도 됩니다.
대체로 그렇습니다. 그 회의가 있는 이유는 상태가 어디에서도 보이지 않기 때문입니다. 신뢰받는 하나의 뷰가 모든 프로젝트와 그 단계, 담당자, 얼마나 오래 멈춰 있었는지를 대기 단계의 시계와 함께 보여 주면, 회의의 발견하는 부분은 사라지고 진짜 결정만 남습니다. 보드는 최신이고 진실해야 하며, 그것은 직접 소유하고 다듬는 데서 나옵니다.