모든 가이드에서는 대규모 프로젝트를 워크스트림으로 나누라고 조언합니다. 하지만 그 사이사이의 스페이스를 어떻게 처리해야 하는지에 대해서는 거의 언급하지 않습니다. 그러나 바로 그 스페이스가 프로젝트의 성공과 실패를 좌우합니다.
프로젝트 관리에서 업무 흐름을 단순한 분할 문제로 생각하기 쉽습니다. 업무를 여러 트랙으로 나누고, 각 트랙에 소유자를 배정하고, 진행되도록 내버려 두면 됩니다. 하지만 업무를 나누는 것은 첫 단계에 불과합니다. 한 트랙이 완벽하게 진행되더라도, 다음 팀으로의 인계 과정을 아무도 주시하지 않으면 문제가 발생할 수 있습니다.
이 가이드는 각 워크스트림 간에 발생하는 사항, 즉 인계, 의존성, 공유 마감일 등을 관리하는 데 중점을 둡니다. 예시로는 인계, 의존성, 공유 마감일 등이 있습니다.
요약: 워크스트림은 복잡한 프로젝트를 각각 단일 소유자가 있는 병렬 트랙으로 분할합니다. 이 부분은 간단하며, 거의 모든 사람이 제대로 이해하고 있습니다. 프로젝트를 좌초시키는 것은 바로 이러한 트랙들을 연결하는 업무 인계, 의존성, 그리고 공유된 일정입니다. 안타깝게도 이러한 연결 고리를 관리할 담당자가 지정되지 않는 경우가 너무 많습니다.
성과를 내는 팀은 단순히 업무 흐름을 더 원활하게 운영할 뿐 아니라, 모든 연결 지점을 매일 주의 깊게 살핍니다. 이들은 명확한 소유자, 간단한 ‘예/아니오’ 방식의 점검 포인트, 그리고 문제를 상급자에게 보고해야 할 시점에 대한 명확한 규칙을 활용합니다. 단 한 가지만 기억하신다면, 단순히 업무 흐름뿐만 아니라 연결 지점도 관리하십시오.
프로젝트 관리에서 ‘워크스트림’이란 무엇인가요?
워크스트림은 관련 작업들로 구성된 별개의 독립적인 트랙입니다. 이는 동일한 주요 프로젝트 목표를 달성하기 위해 다른 트랙들과 병행하여 진행됩니다. 각 트랙은 고유한 프로젝트 결과물, 타임라인, 그리고 단일 소유자인 워크스트림 리더를 갖습니다.
여기서 핵심은 ‘구조’입니다. 체계가 잡히지 않은 작업 그룹은 경계가 모호하고 명확한 소유자도 없습니다. 반면, 워크스트림은 정의된 범위, 명확한 인계 지점, 그리고 진행 상황을 책임지는 한 명의 담당자가 있습니다. 이러한 구조를 통해 병행되는 작업 간의 충돌을 방지할 수 있습니다.
워크스트림은 복잡한 프로젝트를 명확하게 파악할 수 있게 해주는 요소입니다. 전체 구조를 일일이 뜯어보지 않아도 각 트랙의 상태 정보를 확인할 수 있습니다. 워크스트림이 없다면 대규모 프로젝트는 무너집니다. 모든 것이 똑같이 시급해 보이고, 팀들은 의존성을 놓치게 되며, 단 한 번의 지연만으로도 전체 타임라인이 무너져 버립니다.
워크스트림을 ‘트랙(tracks)’, ‘프로젝트 스트림(project streams)’, 또는 ‘딜리버리 스트림(delivery streams)’이라고 부르기도 합니다. 이는 라벨만 다를 뿐 동일한 구조적 단위를 의미합니다.
워크스트림과 워크플로우: 둘의 차이점은 무엇일까요?
워크스트림은 광범위한 업무 영역을 의미합니다. 워크플로우는 해당 영역 내에서 작업을 진행시키는 구체적인 프로세스를 말합니다. 사람들은 종종 이 두 용어를 혼동하곤 합니다. 그러나 이를 혼동하면 소유권이 불분명해집니다.
워크스트림은 프로젝트 내에서 관련 작업, 팀, 결과물로 구성된 전체 영역을 의미합니다. 워크플로우는 단일 작업이 시작부터 완료까지 따르는 정확한 단계의 순서를 말합니다. 예시: 초안 작성, 검토, 승인, 게시.
다음은 주요 차이점을 나란히 비교한 것입니다:
| 범위 | 관련 일의 광범위한 영역 | 단일 반복 가능한 프로세스 |
| 소유권 | 워크스트림 리더가 팀을 관리합니다 | 프로세스 소유자가 단계를 정의합니다 |
| 기간 | 프로젝트가 진행되는 동안 지속됩니다 | 작업이 시작될 때마다 반복됩니다 |
| 프로젝트 역할 | 주요 병행 트랙 | 트랙 내에서 실행되는 프로세스 |
| 예시 | 제품 출시를 위한 마케팅 | 해당 출시 과정 내 콘텐츠 승인 |
핵심 원칙: 이 관계는 ‘포함’ 관계입니다. 모든 업무 흐름은 여러 워크플로우를 포함합니다.
핵심 원칙: 이 관계는 ‘포함’ 관계입니다. 각 업무 흐름은 여러 워크플로우를 포함합니다.
워크스트림을 ‘용기’로, 워크플로우를 그 안의 ‘반복 가능한 메커니즘’으로 생각해 보십시오. 예를 들어, 제품 출시를 위한 마케팅 워크스트림에서는 콘텐츠 생성 워크플로우, 광고 승인 워크플로우, 출시일 체크리스트 워크플로우 등 세 가지 별개의 워크플로우가 실행될 수 있습니다.
워크스트림의 이점은 무엇인가요?
워크스트림은 다음과 같은 여섯 가지 구체적인 이점을 제공합니다: 지연 최소화, 명확한 소유권, 가시적인 작업량, 위험 격리, 간편한 보고, 신속한 온보딩. 워크스트림은 단순히 프로젝트를 체계화하는 데 그치지 않고, 압박 상황에서도 프로젝트가 대응하는 방식을 변화시킵니다. 다음과 같은 이점을 누릴 수 있습니다.
- 지연 영향 제한. 한 워크스트림에서 발생한 지연이 다른 워크스트림으로 확산되는 것을 막아줍니다. 평면적인 작업 목록에서는 어느 한 곳에서 지연이 발생해도 전체 일정이 뒤처지게 됩니다. 워크스트림을 활용하면, 인프라 분야에서 2주간의 지연이 발생하더라도 UX 디자인과 직접적인 연관성이 없는 한 해당 분야에는 영향을 미치지 않습니다. 이로 인해 피해 범위가 ‘전체 프로젝트’에서 ‘단일 워크스트림’으로 축소됩니다. 또한, 하위 마감일을 놓친 경우와 출시 일정을 놓친 경우를 쉽게 구분할 수 있습니다.
- 명확한 소유권. 각 업무 흐름에는 지정된 책임자가 한 명씩 있습니다. 문제가 발생하면 ‘이건 누구의 업무였지?’라고 묻느라 시간을 낭비하는 일이 없습니다. 책임자는 문제를 직접 해결하거나 상급자에게 보고합니다. 책임을 서로 공유하면 문제는 해결되지 않은 채 방치되기 마련입니다. 모두가 다른 누군가가 처리하고 있을 것이라고 생각하기 때문입니다.
- 가시화된 업무량. 번아웃이 발생하기 전에 미리 파악할 수 있습니다. 인력과 도구는 하나의 거대한 백로그가 아닌 특정 워크스트림에 배정됩니다. 이를 통해 한 엔지니어가 동시에 피크를 맞이하는 세 개의 트랙에 배정되어 있는지 확인할 수 있습니다. 이러한 중복 현상은 단순한 목록에서는 보이지 않지만, 워크스트림 보기에서는 명확하게 드러납니다.
- 위험의 격리. 데이터 마이그레이션 트랙에서 공급업체가 마감일을 지키지 못하더라도, 변경 관리 트랙에서는 교육 자료 제작이 계속 진행됩니다. 기술 설정 트랙도 마찬가지로 진행됩니다. 한 가지 장애가 발생해도 다섯 개의 트랙이 모두 중단되는 것이 아니라, 하나의 트랙만 일시 중단됩니다. 프로젝트 일주일을 잃는 대신, 해당 워크스트림의 일주일만 지연됩니다.
- 보고가 더 쉬워집니다. 리더는 프로젝트 전체를 훑어보지 않고도 단일 스트림만 확인하면 됩니다. 규정 준수에 대해서만 관심이 있는 이해관계자는 해당 트랙을 확인하여 필요한 정보를 얻을 수 있습니다. 상태를 파악하기 위해 200개의 작업을 일일이 스크롤할 필요가 없습니다.
- 더 빠른 온보딩. 신규 팀원은 며칠 만에 생산성에 적응할 수 있습니다. 프로젝트 도중에 합류하는 엔지니어는 기여하기 위해 전체 프로젝트를 익힐 필요가 없습니다. 자신의 워크스트림 범위만 파악하고 바로 업무를 시작하면 됩니다. 워크스트림은 관리하기 쉬운 작은 범위를 형성합니다.
프로젝트는 워크스트림 내부에서 실패하는 것이 아닙니다. 워크스트림 간의 이음매에서 실패합니다. 그 이유는 다음과 같습니다:
프로젝트를 워크스트림으로 나누는 것은 쉬운 일입니다. 누구나 Box를 그릴 수 있습니다. 프로젝트를 좌초시키는 것은 바로 그 Box들 사이에서 일어나는 일들입니다. 바로 업무 인계, 의존성, 그리고 한 워크스트림이 마감 기한을 지키지 못해 다른 워크스트림이 차질을 빚게 되는 순간들입니다.
결정 사항, 상태 변경, 마감일 변경 등이 전달 과정에서 누락되기 일쑤입니다. 워크스트림을 많이 만들수록 관리해야 할 인계 과정이 늘어납니다.
이는 『신화적인 맨-먼스』 에 나오는 수학적 원리를 사람 대신 구조에 적용한 것에 불과합니다. 저자는 다음과 같은 수식에 따라 의사소통 경로가 2차적으로 증가한다는 사실을 보여주었습니다:
n(n-1)/2: 인원이 늘어날수록 조정 비용은 2차 함수적으로 증가하는 반면, 산출량은 선형적으로만 증가합니다.
‘사람’을 ‘워크스트림’으로 바꿔 생각해도 이 교훈은 여전히 유효합니다. 워크스트림이 3개면 관리해야 할 인터페이스도 3개입니다. 6개면 15개가 됩니다. 워크스트림을 하나 추가할 때마다 단순히 일만 늘어나는 것이 아닙니다. 일이 누락될 수 있는 지점의 수가 기하급수적으로 늘어나는 것입니다.
이는 업무 전반에 대한 관점을 완전히 바꿔줍니다. 리더의 역할은 단순히 자신의 업무 영역을 운영하는 데 그치지 않습니다. 그 영역의 경계를 지키는 것이기도 합니다. 리더는 다른 업무 흐름에 대해 어떤 책임을 지고 있는지, 그리고 다른 업무 흐름이 자신에게 어떤 책임을 지고 있는지 정확히 파악해야 합니다.
마찬가지로, 프로젝트 관리자의 업무는 단순히 작업을 관리하는 데 그치지 않습니다. 이는 각 워크스트림 간의 연계 관계를 관리하는 일입니다. 프로젝트 관리자는 업무 인계 과정을 모니터링하고, 의존성을 주시하며, 워크스트림 간 위험 요소를 조기에 파악해야 합니다.
여기에도 함정이 있습니다. ‘콘웨이의 법칙 ’이라는 유명한 원칙은 조직이 자연스럽게 자체 내부 의사소통 경로를 모방한 시스템을 구축하게 된다고 경고합니다. 다시 말해, 의도치 않게 기존 조직도를 기준으로 업무 흐름을 그룹화하게 될 가능성이 높습니다.
그러면 두 개의 서로 다른 팀에 걸쳐 있는 작업들이 오히려 지연되는 것을 보고 놀라게 될 것입니다. 이미 한 자리에 모여 있는 사람들에 따라 워크스트림을 나누지 말고, 업무 유형에 따라 워크스트림을 줄이세요. 이 가이드의 나머지 부분은 단순히 Box를 그리는 것에 관한 것이 아닙니다. Box들 사이의 연결 고리를 설계하는 방법에 관한 것입니다.
프로젝트 관리의 업무 흐름 유형
워크스트림에는 크게 네 가지 유형이 있습니다: 기능별(부서별), 크로스-기능별(결과별), 지역별(지역 단위), 기술/시스템별(기술 계층별)입니다. 경계를 어디에 그느냐에 따라 프로젝트 기간 동안 어떤 업무 인계 과정을 관리해야 할지가 결정됩니다.
| 기능 | 누구나 쉽게 이해할 수 있는 명확한 경계 | 팀 간 작업이 소홀히 처리되는 경우가 있습니다 | 업무가 대체로 독립적으로 진행되는 팀 |
| 크로스-기능적 | 워크스트림 내에 자연스럽게 통합되어 진행 상황을 쉽게 파악할 수 있습니다. | 인력 배정이 어렵고, 인력이 여러 워크스트림에 분산되어 있습니다. | 밀접한 협력이 필요한 성과 |
| 지리적 | 실제 지역별 차이를 반영합니다 | 지역 간 중복된 노력 | 진정한 현지화 범위를 반영한 글로벌 출시 |
| 기술/시스템 | 시ーム은 실제 시스템 인터페이스와 지도됩니다 | 모든 통합 위험은 최종 단계에서 발생합니다 | 명확한 계층 구조를 갖춘 소프트웨어 및 IT |
기능별 업무 흐름
기능별 업무 흐름은 엔지니어링, 마케팅, 법무와 같은 부서나 전문 분야별로 운영됩니다. 조직도상 이미 이러한 경계가 존재하기 때문에, 일부 팀에서는 이를 기본값으로 선택합니다. 한 업무 흐름이 어디서 끝나고 다음 업무 흐름이 어디서 시작되는지에 대해 이견이 없습니다.
장점:
- 모두가 이해하는 명확한 경계: 누가 무엇을 담당하는지에 대한 논란의 여지가 없으며, 이는 사람들이 이미 일상적인 역할에 대해 가지고 있는 인식과 일치합니다.
- 일이 독립적으로 진행될 때 원활한 업무 인계: 엔지니어링 팀이 대부분의 경우 법무팀을 기다리지 않고 개발을 진행할 수 있다면, 업무 간 연계 지점을 쉽게 관리할 수 있습니다.
- 간결한 소유권 체계: 각 부서장이 명백한 책임자로서, 첫날부터 책임 소재가 명확해집니다.
한도:
- 부서 간 작업은 소속이 없습니다: 한 번에 세 팀이 필요한 작업은 누구의 업무도 아닌 상태가 됩니다(해당 작업이 어느 하나의 워크스트림에도 명확하게 속하지 않기 때문입니다).
- 워크스트림은 해당 영역 내에서만 최적화됩니다: 각 팀은 자체 트랙을 완벽하게 관리하며, 업무 인계는 다른 누군가가 담당한다고 가정합니다.
다음과 같은 경우에는 건너뛰세요: 가장 중요한 목표를 달성하기 위해 지속적으로 세 개 이상의 부서가 완벽하게 조화를 이루어야 하는 경우. 이 경우 업무 흐름보다 부서 간 연계 지점이 훨씬 더 많아질 것입니다.
가장 적합한 경우: 각 팀의 일이 비교적 독립적이며, 명확하고 잘 정의된 인계 지점이 몇 군데 있는 프로젝트.
크로스-기능적 업무 흐름
크로스-기능적 업무 흐름은 특정 산출물이나 결과를 중심으로 구성됩니다. 이를 통해 여러 부서의 인력을 하나의 흐름으로 통합합니다. 예시로는 ‘사용자 온보딩’ 트랙이 있습니다. 이 트랙에는 디자이너, 엔지니어, 지원 담당자가 포함될 수 있습니다. 이를 통해 각 부서의 경계를 허물고, 리더가 매일 확인할 수 있는 하나의 흐름으로 통합합니다.
장점:
- 가장 까다로운 업무 인계 과정의 가시성도 높아집니다: 디자인과 엔지니어링 간의 마찰은 하나의 워크스트림 내에서, 매일 열리는 회의 한 번을 통해 해결됩니다. 멀리 떨어진 조직 경계를 넘어 문제가 악화되는 일은 없습니다.
- 다양한 전문 분야를 아우르는 긴밀한 팀워크: 서로 다른 영역을 지키려는 사람들보다, 같은 목표를 향해 나아가는 사람들이 더 빠르게 협력합니다.
- 명확한 결과물 소유권: 리더는 완성된 결과물에 대한 소유권을 가집니다. 성공은 단순한 활동량이 아닌, 실제로 출시된 결과물로 측정됩니다.
한도:
- 인력 배치는 끊임없는 싸움입니다: 본래 소속 팀에서 인력을 빼내야 하는데, 해당 직원의 팀 매니저들은 여전히 그들을 팀에 남겨두고 싶어 합니다. 이로 인해 직원들의 충성심이 분산됩니다.
- 병목 현상이 구성원의 달력으로 옮겨갑니다: 세 개의 서로 다른 크로스-기능 스트림에 배정된 구성원은, 비록 개별 스트림 중 어느 하나도 과부하 상태가 아니더라도 새로운 병목 현상이 됩니다.
다음과 같은 경우에는 건너뛰세요: 부서장들로부터 인력을 전담으로 배정하겠다는 확실한 약속을 이끌어낼 수 없는 경우. 인력이 절반밖에 채워지지 않은 크로스-기능적 워크스트림은 기능별 워크스트림보다 더 나쁩니다.
가장 적합한 경우: 다양한 전문 분야 간의 긴밀한 협력이 필요한 결과물의 경우, 팀 경계를 넘어 발생하는 마찰보다는 팀 내에서 직접 관리하는 편이 더 낫습니다.
지리적 업무 흐름
지리적 업무 흐름은 지역이나 위치별로 운영되며, 예를 들어 ‘북미 출시’와 ‘EMEA 출시’가 있습니다. 이러한 구조는 현지 법률, 언어 또는 시장 조건에 따라 서로 다른 작업이 발생하는 글로벌 출시에서 흔히 볼 수 있습니다.
효과적인 점:
- 실제 지역별 차이를 반영: 현지 법률이나 시장 조건이 서로 다를 경우, 지역별 워크스트림을 통해 각 팀이 자체적인 속도에 맞춰 진행할 수 있습니다.
- 지역 소유권과 실행: 시장을 잘 아는 지역 책임자는 멀리서 추측만 하는 중앙 프로젝트 관리자보다 더 나은 결정을 내립니다.
- 지역별 리스크 통제: 유럽에서 규정 준수 절차가 지연되더라도 북미 지역의 출시 일정은 차질 없이 진행됩니다.
한도:
- 중복 노력은 실패의 기본값입니다: 현지 일과 공유 일 간의 경계가 명확하지 않아 두 지역이 동일한 문제를 두 번 해결하게 됩니다.
- 공통 기반이 소홀히 다뤄집니다: 브랜드 가이드라인, 데이터 모델, 가격 구조는 모든 지역에서 일관성을 유지해야 합니다. 이러한 항목에는 중앙 소유자가 필요하지만, 각 지역 팀은 모두 다른 누군가가 이를 처리하고 있을 것이라고 가정합니다.
다음과 같은 경우에는 건너뛰세요: 지역 간 차이가 시간대뿐인 경우. 실제로 존재하지 않는 차이로 인해 불필요한 조정 비용을 발생시키고 있는 경우. 이 경우 기능별 설정 구조를 사용하는 편이 더 나을 것입니다.
가장 적합한 경우: 현지 조건에 따라 완전히 다른 작업이 발생하지만, 그 밑바탕에는 책임 소재가 명확한 공유 핵심 요소가 뒷받침되는 글로벌 출시 프로젝트.
기술/시스템 업무 흐름
기술/시스템 업무 흐름은 프론트엔드, 백엔드, 데이터베이스, 인프라와 같은 기술 계층별로 일을 그룹화합니다. 이러한 설정은 소프트웨어 및 IT 분야에서 흔히 볼 수 있습니다. 각 계층마다 소유자와 위험 프로필이 다릅니다. 여기서 ‘이음새’는 시스템 인터페이스를 의미하므로, 이는 ‘프로젝트는 이음새에서 실패한다’는 말을 가장 직관적으로 보여주는 사례입니다.
효과적인 점:
- 시ーム은 실제 코드 계약과 일치합니다: 인계 과정은 코드 연결 및 API입니다. 이를 구체적으로 정의하고, 버전을 관리하며, 테스트할 수 있습니다. 이는 모호한 팀 간 인계보다 훨씬 더 구체적입니다.
- 전문적인 소유권 체계: 각 계층의 책임자는 해당 계층의 위험 요소에 대한 심도 있는 전문 지식을 갖추고 있습니다. 즉, 문제를 잘 이해하는 담당자가 문제를 조기에 포착할 수 있습니다.
- 병행 진행: 프론트엔드 및 백엔드 팀은 합의된 계약에 따라 동시에 개발을 진행할 수 있습니다.
한도:
- 통합 위험은 마지막 단계에서 누적됩니다: 각 계층이 어떻게 연결될지에 대한 결정이 지연될 때마다, 그 결과는 통합 단계에서 한꺼번에 터져 나옵니다. 이것이 바로 마지막 단계에서 문제가 빈번하게 발생하는 이유입니다.
- 계약 변경은 은밀하게 이루어집니다: 한 계층이 다른 계층에 알리지 않고 인터페이스를 변경하면, 마지막 단계에서 모든 것이 무너집니다.
다음과 같은 경우에는 건너뛰세요: 프로젝트 규모가 작아 단일 팀이 전체 기술 스택을 담당하는 경우. 계층 기반 워크스트림은 불필요한 추가 인터페이스를 생성합니다.
가장 적합한 대상: 각 시스템 계층마다 별도의 소유자가 있고, 고유한 위험 프로필을 가지며, 계층 간에 명확한 코드 인터페이스가 존재하는 소프트웨어 및 IT 프로젝트.
대부분의 대규모 프로젝트는 하이브리드 방식을 사용합니다.
이러한 방식을 혼합하는 것은 대개 올바른 접근 방식이지만, 동시에 조직도에서 가장 큰 함정이 도사리는 부분이기도 합니다. 글로벌 출시의 경우 최상위 수준에서 지역별 스트림을 운영하며, 각 지역 내부에는 마케팅, 물류, 규정 준수 등 기능별 하위 스트림이 중첩되어 구성될 수 있습니다.
앞서 설명한 수학적 원리를 기억하세요. 중첩 수준이 높아질수록 연결 지점이 기하급수적으로 늘어납니다. 업무 인계 과정을 명확히 파악할 수 있는 범위 내에서만 트랙을 중첩하세요.
모든 업무 흐름에 필요한 요소
모든 워크스트림에는 다음 10가지 요소가 필요합니다: 명확히 지정된 단일 소유자, 명확한 범위, 문서화된 투입물과 산출물, 인계 마일스톤, 독립적인 상태 추적, 에스컬레이션 규칙, 전용 채널, 표준화된 업데이트 형식, 단계 간 여유 시간, 그리고 단일 정보 출처. 프로젝트를 어떻게 분할하든, 이러한 요소가 갖춰져야만 워크스트림이 제대로 유지될 수 있습니다.
- 단 한 명의 명시된 소유자. 해당 워크스트림의 진행 상황과 인계에 책임을 지는 리더가 한 명 필요합니다. 이는 위원회나 팀 전체가 될 수 없습니다. 소유자의 이름을 한 단어로 지칭할 수 없다면, 그 워크스트림은 아직 존재하지 않는 것입니다.
- 명확한 범위와 산출물. 이 워크스트림에서 무엇을 산출하고, 무엇을 산출하지 않는지 간결하게 명시하십시오. 범위가 모호하면 두 개의 워크스트림이 생겨, 서로 같은 작업을 수행하거나 상대방이 처리할 것이라고 가정하는 상황이 발생할 수 있습니다.
- 입력 및 출력 목록. 해당 워크스트림이 시작하기 위해 다른 트랙에서 무엇을 필요로 하는지, 그리고 완료 시 다른 트랙에 무엇을 제공해야 하는지 정의하십시오. 이것이 바로 문서화된 연계점입니다. 이를 문서화하지 않으면 계획 수립 목적상 존재하지 않는 것과 같습니다.
- 명확한 업무 인계 마일스톤. 이 워크스트림에서 다른 워크스트림으로 업무를 인계하는 지점에 간단한 ‘예/아니오’ 체크포인트를 설정하세요. 프로젝트 마일스톤은 ‘완료됨’ 또는 ‘미완료’ 중 하나여야 합니다. 인계 상태를 ‘80% 완료’라고 라벨링해서는 안 됩니다.
- 독립적인 상태 추적. 각 워크스트림은 진행 중인지, 위험에 처해 있는지, 아니면 블록이 발생했는지 여부를 표시해야 합니다. 이를 통해 경영진은 해당 워크스트림에 포함된 모든 작업을 일일이 확인하지 않고도 단일 워크스트림의 현황을 파악할 수 있습니다.
- 명확한 에스컬레이션 규칙. 작업 진행을 방해하는 블록이 언제 해당 워크스트림에서 제외되어 주 프로젝트 관리자에게 전달될지 사전에 합의하십시오. 예시: ‘2일 이상 지속되는 모든 블록 또는 위험에 처한 의존성’과 같이 정할 수 있습니다. 규칙이 없으면 모든 문제가 에스컬레이션되거나, 반대로 아무것도 에스컬레이션되지 않는 상황이 발생할 수 있습니다.
- 전용 채팅 채널. 이 워크스트림의 최신 소식, 결정 사항 및 파일을 공유할 수 있는 별도의 공간을 마련하세요. 주요 프로젝트 채팅과 분리하여 중요한 세부 사항이 누락되지 않도록 하세요.
- 표준화된 업데이트 형식. 담당자가 상태를 보고하는 빈도와 사용할 템플릿을 설정하세요. 프로젝트 관리자가 쉽게 비교할 수 있도록 모든 워크스트림에서 이 형식을 일관되게 유지하세요.
- 작업 이관 시점에 여유 시간을 확보하십시오. 특히 일 이관 지점을 중심으로 일정에 여유 일수를 추가하십시오. 일이 다른 사람에게 넘어갈 때 지연은 기하급수적으로 늘어납니다.
- 단일 정보 소스. 모든 구성원이 신뢰할 수 있는 워크스트림 플랜 및 상태의 마스터 버전을 하나만 유지하세요. 세부 정보를 여러 앱에 분산시키면, 워크스트림이 해결하고자 하는 혼란을 다시 초래하게 됩니다.
프로젝트에 대한 워크스트림을 만드는 방법
워크스트림을 생성하는 데는 총 5단계가 필요합니다. 범위를 정의하고, 프로젝트를 결과물로 세분화하며, 각 트랙에 소유자 한 명을 지정하고, 의존성과 마일스톤을 매핑한 다음, 커뮤니케이션 및 추적 체계를 구축하는 것입니다.
스프레드시트, PM 플랫폼, 화이트보드 등 어떤 방식으로 플랜을 세우든, 중요한 것은 일이 경계를 넘나들기 시작해도 견고하게 유지될 수 있는 경계를 설정하는 것입니다.
1단계: 프로젝트 범위 및 목표 정의
단 하나의 워크스트림을 그리기 전에, 프로젝트에서 무엇을 산출하고 무엇을 산출하지 않는지 먼저 기록해 두십시오. 워크스트림의 경계는 범위에서 비롯되어야 하며, 그 반대가 되어서는 안 됩니다. 업무를 충분히 파악하지 않은 상태에서 워크스트림을 설정하면 중요한 작업을 놓치거나 중복된 업무를 생성하게 될 것입니다.
다음 단계로 넘어가기 전에 다음 세 가지를 문서화하십시오:
- 최종 상태: 출시된 제품이나 마이그레이션된 시스템과 같은 완성된 결과물
- 엄격한 제약 조건: 예산, 마감일, 그리고 모든 규정 준수 사항
- 성공 기준: 이해관계자의 승인 등, 일이 완료되었음을 확인하는 방법
간결하게 작성하십시오. 이 단계를 통해 간단한 1페이지 분량의 범위 문서를 작성해야 합니다.
전문가 팁: 프로젝트의 목표를 한 문장으로 요약해 보세요. 그 문장에 ‘그리고’라는 단어가 두 번 이상 등장한다면, 그 안에는 여러 업무 흐름이 숨어 있을 가능성이 높습니다.
2단계: 프로젝트를 결과물로 세분화하기
프로젝트에서 반드시 산출해야 할 주요 자산을 파악하십시오. 관련 항목을 각각 고유한 산출물을 갖는 트랙으로 그룹화하십시오.
이 단계에서는 과도한 설계는 피하십시오. 스트림을 하나씩 추가할 때마다 연결 지점이 늘어납니다. 프로젝트를 10개의 트랙으로 분할하면 실제 일보다 회의에 더 많은 시간을 낭비하게 될 수 있습니다.
그룹에 독립성 테스트를 적용해 보세요:
- 두 세트의 작업이 서로를 기다리지 않고도 진행될 수 있다면 각각 분리하십시오.
- 밀접하게 연결되어 있고 매일 같은 인력이 공유하는 작업이라면 이를 한데 묶어 관리하세요.
- 해당 그룹의 작업 수가 5개 미만이거나 담당자가 1명뿐인 경우, 해당 그룹을 상위 그룹으로 통합하십시오
3단계: 업무 흐름 소유자 및 역할 지정
각 워크스트림마다 정확히 한 명의 책임자를 지정하십시오. 이 책임자는 타임라인, 산출물 및 업무 인계에 대한 책임을 집니다. 위원회나 팀 전체에 소유권을 부여하지 마십시오. 한 명의 책임자에게 집중하십시오.
해당 단일 소유자를 중심으로 역할을 다음과 같이 정리하십시오:
- 리드: 해당 워크스트림을 총괄하는 책임자
- 기여자: 실제로 일을 수행하는 사람들
- 승인자: 완료된 산출물에 최종 승인을 내리는 사람
- 이해관계자: 작업에 직접 일하지는 않지만 진행 상황을 파악해야 하는 사람들
전문가 팁: 팀 리더에게 실질적인 일상적 권한을 부여하세요. 팀 리더가 주 프로젝트 매니저에게 먼저 허락을 구하지 않고는 자신의 팀에서 발생하는 문제를 해결할 수 없다면, 그 구조는 허울뿐입니다.
4단계: 의존성 파악 및 마일스톤 설정
명확하고 가시적인 연결 관계를 통해 각 워크스트림이 서로 어떻게 의존하는지 문서화하십시오. 추측에만 의존하지 마십시오. 의존성이 누군가의 머릿속에만 존재한다면, 타임라인이 지연될 때 경고를 트리거할 수 없습니다.
각 트랙이 교차하는 정확한 지점을 파악하세요:
- 의존성: 각 워크스트림에 대해, 해당 워크스트림으로 유입되는 장애 요인과 유출되는 산출물을 목록으로 작성하십시오.
- 인계 마일스톤: 각 교차점에 배치된 간단한 ‘예/아니오’ 확인 지점
- 공유 마감일: 두 트랙이 동일한 마감일을 공유하는 경우, 두 책임자 모두 해당 날짜에 대해 합의해야 합니다.
전문가 팁: 스프레드시트에서는 ‘의존성’ 열을 활용하세요. 프로젝트 관리 도구에서는 시각적인 타임라인 보기를 사용하여 모든 워크스트림에 걸친 중요 경로를 한눈에 확인하세요. 더 좋은 방법은 ClickUp 의존성 매핑 템플릿과 같은 구조화된 레이아웃을 활용하면, 머릿속으로만 의존성을 추적할 필요 없이 한곳에 체계적으로 정리할 수 있습니다.
5단계: 커뮤니케이션 및 추적 체계 구축
각 워크스트림에 업데이트, 의사 결정 및 파일을 위한 전용 스페이스를 마련하십시오. 이를 메인 프로젝트 채팅과 분리하여 관리하십시오. 이렇게 하면 한 워크스트림의 일상적인 채팅이 다른 워크스트림의 긴급 알림을 가려버리는 것을 방지할 수 있습니다.
각 워크스트림별로 간결한 커뮤니케이션 플랜을 수립하기 위해 다음 세 가지 항목을 확정하십시오:
- 단일 신뢰할 수 있는 정보원: 모두가 신뢰하는 하나의 마스터 플랜 버전
- 표준 업데이트 일정: 프로젝트 관리자가 상태 정보를 쉽게 비교할 수 있도록, 담당자가 일치하는 템플릿을 사용하여 얼마나 자주 상태를 보고하는지
- 에스컬레이션 규칙: 문제가 프로젝트 관리자에게 전달되어야 하는 시점에 대해 합의된 규칙
전문가 팁: 프로젝트 착수 전 상태 템플릿을 표준화하세요. 각 팀장이 각자 다른 형식을 사용하면, 프로젝트 관리자는 프로젝트 리스크를 관리하는 대신 업데이트 내용을 해석하는 데 시간을 낭비하게 됩니다.
워크스트림 관리를 위한 최고의 실행 방식
워크스트림을 효과적으로 관리하는 데는 여섯 가지 습관이 핵심입니다: 매주 연결 지점을 점검하고, 실무 세션을 진행하며, 워크스트림 간 인력을 추적하고, 워크스트림 간 위험 등록부를 유지하며, 마일스톤마다 경계를 검토하고, 완료된 워크스트림을 종료하는 것입니다. 이를 설정하는 것은 한 장의 스냅샷과 같고, 실행하는 것은 한 편의 영화와 같습니다.
킥오프 단계에서 설계한 구조는 일이 시작되는 날부터 변화하기 시작합니다. 팀 리더가 떠나거나, 의존성이 바뀌거나, 사소한 업무 흐름이 갑자기 팀의 절반을 집어삼키기도 합니다. 이것이 바로 많은 설정이 2주 차에 무너지게 되는 이유입니다.
다음 여섯 가지 실천 방법을 통해 현실이 변하더라도 업무 흐름을 원활하게 유지할 수 있습니다:
- 연결 지점을 점검하십시오. 상태 점검은 대개 단일 워크스트림 내부만 살펴 진행이 순조로운지 확인합니다. 하지만 실제로 문제가 발생하는 것은 워크스트림 간의 연결 부분이며, 실제로도 그런 일이 발생합니다. 한 팀장이 다른 워크스트림이 의존하는 결과물의 일정을 몰래 변경할 수도 있습니다. 일주일에 한 번씩, 각 팀장이 서로에게 어떤 책임을 지고 있는지, 그리고 그 시기가 언제인지 재확인하도록 하십시오.
- 작업 세션을 진행하세요. 팀 리더들은 문제가 고착화되기 전에 장애 요인을 공유하고 갈등을 해결하기 위해 정기적인 회의가 필요합니다. 이는 이해관계자를 위한 형식적인 진행 보고가 아닙니다. 각 팀 리더는 어떤 장애 요인이 있는지, 어떤 마일스톤이 다가오고 있는지, 그리고 타임라인에 어떤 변화가 있었는지 직접 설명합니다. 프로젝트 관리자는 회의를 주도하되, 지나치게 개입하지 않고 진행을 이끌어갑니다. 장기 프로젝트의 경우 매주, 단기 프로젝트의 경우 매일 회의를 진행하세요.
- 담당자를 추적하세요. 워크스트림 자체는 아무 문제가 없어 보일 수 있지만, 세 개의 서로 다른 워크스트림에 배정된 한 사람이 병목 현상을 일으킬 수 있습니다. 워크스트림을 개별적으로만 살펴보면 이러한 중복 현상은 눈에 띄지 않습니다. 모든 워크스트림의 업무량이 같은 주에 정점에 달하는 엔지니어나 디자이너가 있는지 주의 깊게 살펴보세요. 이러한 충돌을 조기에 파악하면 팀의 소진을 방지할 수 있습니다.
- 팀 간 위험 등록부를 관리하십시오. 단일 워크스트림 내의 위험은 해당 워크스트림 소유자의 업무입니다. 공급업체의 납기 지연과 같이 여러 워크스트림에 걸쳐 발생하는 위험은 프로젝트를 망칠 수 있습니다. 각 위험이 어떤 워크스트림에 영향을 미치는지 표시하는 간단한 로그를 작성하십시오. 모든 팀 간 위험에 단일 소유자를 지정하고, 각 워크스트림 소유자 간 동기화 회의 때마다 이를 검토하십시오.
- 주요 마일스톤에서 경계를 재검토하십시오. 프로젝트 시작 시점에 완벽했던 경계가 3개월 후에는 부적절해질 수 있습니다. 주요 마일스톤에 공식적인 검토 시점을 마련하십시오. 팀 리더들이 워크스트림, 연결된 관계, 인력 배치가 여전히 적합한지 확인하도록 하십시오. 매주 경계를 변경하면 팀들이 집중력을 잃게 되므로, 데이터에 근거가 있을 때만 변경하십시오.
- 완료된 워크스트림은 종료하십시오. 모든 워크스트림은 회의와 업무 인계로 인해 시간과 노력이 소요됩니다. 일부 워크스트림은 원래 목적이 달성된 후에도 계속 유지되기도 합니다. 워크스트림에 남은 작업이 몇 개로 줄어들면, 인접한 워크스트림에 통합하십시오. 워크스트림을 유지하기 위해 불필요한 조정 비용을 지출하지 마십시오. 완료된 워크스트림을 종료하면 프로젝트를 효율적으로 관리할 수 있습니다. 또한, 워크스트림 수가 적을수록 업무가 누락될 가능성이 줄어듭니다.
다양한 산업 분야의 3가지 업무 예시
워크스트림은 마케팅 캠페인, 소프트웨어 빌드, 건설 프로젝트 등 다양한 프로젝트에 걸쳐 나타나며, 매번 동일한 구조를 가지지만 의존성의 엄격도 수준은 프로젝트마다 다릅니다. 다음은 세 가지 일반적인 프로젝트에서 워크스트림이 실제로 어떻게 적용되는지 보여주는 예시입니다.
1. 마케팅 캠페인 업무 흐름
어떤 회사가 여러 채널을 통해 제품을 출시한다고 가정해 봅시다. 캠페인 매니저가 이를 총괄합니다. 네 가지 업무 흐름이 병행되어 진행되며, 모두 하나의 출시일을 목표로 합니다. 각 업무 흐름은 다음과 같이 구성됩니다:
- 콘텐츠 제작: 블로그 게시물, 사례 연구, 랜딩 페이지. 담당자: 콘텐츠 마케팅 매니저
- 유료 미디어: 광고 크리에이티브, 목표 및 예산. 담당자: 수요 창출 매니저
- 이벤트: 웨비나 설정, 발표자 조정, 프로모션. 담당자: 이벤트 전문가
- 영업 지원: 프레젠테이션 자료, 배틀 카드, 데모 스크립트. 담당자: 제품 마케터
핵심 연계 지점: 유료 미디어 팀은 콘텐츠 팀이 승인된 메시지와 브랜드 자산을 전달하기 전까지는 광고 크리에이티브를 최종 확정할 수 없습니다.
이 방식의 차별점: 의존성이 유연합니다. 대부분의 업무 흐름은 일정 기간 동안 독자적으로 진행될 수 있습니다. 따라서 위험 요소는 경직된 연결 고리가 아니라, 하류 모든 것을 막아버리는 한두 번의 메시지 전달 과정에 있습니다. 달력이 아니라 업무의 이음새를 주의 깊게 살펴보세요.
핵심 연계 지점: 유료 미디어 팀은 콘텐츠 팀이 승인된 메시지와 브랜드 자산을 전달하기 전까지는 광고 크리에이티브를 최종 확정할 수 없습니다.
이 방식의 차별점: 의존성이 유연합니다. 대부분의 업무 흐름은 일정 기간 동안 독자적으로 진행될 수 있습니다. 따라서 위험 요소는 경직된 연결 고리가 아니라, 하류 모든 것을 막아버리는 한두 번의 메시지 전달 과정에 있습니다. 달력이 아니라 업무의 이음새를 주의 깊게 살펴보세요.
2. 소프트웨어 개발 업무 흐름
이제 새로운 고객용 앱을 개발하는 팀을 상상해 보세요. 엔지니어링 리더가 여러 스쿼드를 총괄하며, 각 스쿼드는 특정 계층을 담당합니다. 의존성 체인은 모든 스트림을 가로지르기 때문에 어느 한 곳에서라도 지연이 발생하면 출시일이 밀리게 됩니다. 일은 다음과 같이 분할됩니다:
- UX 연구: 와이어프레임과 검증된 사용자 흐름을 제공합니다.
- 프론트엔드: 디자인에 따라 컴포넌트를 구축합니다
- 백엔드/API: 합의된 계약에 따라 서비스를 동시에 구축합니다.
- QA 및 테스트: 승인 기준에 따른 테스트
- DevOps/설정: 스테이징 및 라이브 사이트에 배포합니다.
핵심 연결 고리: QA 팀은 테스트 주기를 계획하기 위해 프론트엔드와 백엔드 진행 상황에 대한 가시성을 확보해야 합니다.
이 방식의 차별점: 애자일 환경에서는 이러한 워크스트림이 스쿼드에 대응합니다. 각 스쿼드는 자체 스프린트 계획 일정을 운영하며, 기능 확정(feature freeze)과 같은 공유된 마일스톤에서만 동기화합니다. 이로 인해 통합 관련 리스크가 마지막 단계에 집중됩니다. 따라서 주의 깊게 살펴봐야 할 부분은 계층 간 코드 계약입니다.
3. 건설 프로젝트 업무 흐름
마지막으로 상업용 건물 프로젝트를 예로 들어 보겠습니다. 종합 건설사가 프로젝트를 총괄하며, 순서를 재조정할 수 없는 각 전문 공종 간의 협업을 조정합니다. 이는 모든 산업 분야 중에서도 가장 경직된 의존성 구조입니다. 이로 인해 작업 인계 과정이 조금의 실수도 용납되지 않습니다. 각 작업 흐름은 정해진 순서대로 마일스톤을 달성해야 합니다:
- 현장 준비: 정지, 평탄화, 기초 공사 준비
- 구조 공학: 골조 및 하중 지지 구조물 시공
- 전기 및 배관: 구조 공사가 마일스톤을 달성해야만 시작할 수 있는 배관 및 전기 배선 기초 공사
- 내부 마감: 승인된 기초 공사 검사를 거친 후 진행됩니다.
- 허가/규정 준수: 병행하여 진행되지만, 실제 시공의 시작을 지연시킵니다.
핵심 연계 지점: 전기 및 배관 기초 공사를 시작하기 전에 구조 공사가 정의된 점검 지점을 반드시 통과해야 합니다.
이 도구의 차별점: 일 순서를 재조정할 수 없습니다. 다른 두 도구에 있는 ‘단순히 병렬로 이동’하는 식의 탈출구가 없습니다. 따라서 의존성 매핑은 여기서 ‘있으면 좋은 기능’이 아닙니다. 이는 첫날부터 반드시 수행해야 할 핵심 업무입니다. 인계 과정이 누락되면 사이트 운영이 중단됩니다.
ClickUp에서 워크스트림을 설정하는 방법
ClickUp은 작업을 ‘스페이스(Spaces)’, ‘폴더(Folders)’, ‘리스트(Lists)’로 구성합니다. 각 업무 흐름에는 고유한 상태, 작업, 문서가 포함된 별도의 리스트가 할당됩니다. 모든 보기에서 동일한 데이터가 공유됩니다. 한 곳에서 작업을 이동하거나 날짜를 변경하면 모든 곳에 자동으로 반영됩니다.
워크스트림에 특히 효과적인 방법:
- 계층 구조는 워크스트림 경계와 일치합니다. 프로젝트를 위한 ‘스페이스’나 ‘폴더’를 생성한 다음, 워크스트림별로 ‘리스트’를 만드세요. 각 리스트에는 고유한 상태 단계가 적용됩니다(예: 엔지니어링은 ‘할 일’ → ‘진행 중’ → ‘코드 검토’ → ‘완료됨’ 순서를 따르는 반면, 마케팅은 ‘초안’ → ‘검토’ → ‘승인’ → ‘실행’ 순서를 따릅니다). 워크스트림 경계가 바로 리스트 경계이므로, 별도의 설정 없이도 작업 범위가 명확하게 유지됩니다.
- 의존 관계가 워크스트림 전반에 연쇄적으로 반영됩니다. 간트 보기에서 의존성 선을 그려 서로 다른 목록에 속한 작업들을 연결하세요. ‘종속성 재조정’ 기능을 활성화하세요. 그러면 한 워크스트림에서 작업 인계가 지연될 경우, 다음 워크스트림의 모든 하류 작업이 자동으로 조정됩니다. 워크스트림 간의 연결 고리는 끊어지지 않고 계속 표시됩니다.
- 대시보드를 통해 여러 워크스트림을 한눈에 파악하세요: 리스트별로 필터링된 ClickUp 대시보드를 구축하여 모든 워크스트림의 상태, 장애 요인, 마일스톤 진행 상황을 한 화면에서 확인하세요. 프로젝트 관리자는 5명의 담당자에게 업데이트를 확인하러 다니는 대신, 위험 관리를 집중적으로 수행할 수 있게 됩니다.
- AI가 여러 업무 흐름을 종합하여 요약합니다: ClickUp Brain은 여러 리스트의 상태를 한 번에 가져와 업무 흐름 간 의존성을 파악해 줍니다. 초안은 업무 흐름 책임자에게 자동으로 업데이트됩니다. 기본적으로 전체 맥락을 파악하고 있으므로, 병행되는 여러 트랙 간의 조정 부담이 줄어듭니다.
- 이음새를 지켜주는 슈퍼 에이전트. 프로젝트에 ClickUp 슈퍼 에이전트를 지정하면, 이 에이전트가 연결 지점을 대신 모니터링해 줍니다. 인계 마일스톤이 지연되면 경고하고, 상류 의존성이 변경되면 수신 스트림의 책임자에게 알림을 보내며, 단일 스트림 상태 확인으로는 놓치기 쉬운 크로스 스트림 리스크를 표면화합니다. 이는 주간 연결 지점 점검의 항상 실시간 버전으로, 대시보드가 모두 녹색으로 표시된다고 해서 실패한 인계가 은폐되는 일은 없습니다.
한도:
- 적응 기간이 필요합니다. Trello나 공유 스프레드시트를 사용하던 팀은 사전에 계층 구조(스페이스 → 폴더 → 리스트)를 계획해야 합니다. 구조를 생략하고 모든 것을 하나의 리스트에 무작위로 넣으면 업무 흐름 간의 구분이 완전히 사라집니다. 대부분의 팀은 자신에게 맞는 설정에 적응하는 데 1~2주 정도가 걸립니다.
- 단순한 프로젝트에는 이보다 더 많은 tools가 필요하지 않습니다. 소규모 팀 하나로 3개 미만의 트랙을 동시에 진행 중이라면, ‘의존성’ 열이 포함된 스프레드시트를 사용하는 것이 더 빠르게 작업을 진행하는 데 도움이 됩니다.
다음과 같은 경우에는 건너뛰세요: 프로젝트가 단일 팀으로 구성되고, 업무 인계가 거의 없으며, 트랙 간에 실질적인 의존성이 없는 경우.
적합한 대상: 병렬로 진행되는 업무 흐름 간에 실질적인 의존성이 존재하며, 한 트랙에서 지연이 발생하면 다른 트랙에도 그 영향이 가시적으로 연쇄적으로 반영되어야 하는 다팀 프로젝트.
예상치 못한 네 가지 이음매 결함
이미 명백한 실수들을 파악할 수 있습니다. 여기에는 소유자가 지정되지 않은 경우, 조직도 주변에 트랙을 그리는 경우, 또는 한 사람이 세 개의 트랙에 걸쳐 업무를 담당하는 경우가 포함됩니다.
하지만 어떤 오류들은 발생 당시에는 실수처럼 보이지 않습니다. 모든 것이 순조롭게 진행되는 것처럼 보이기 때문입니다. 다음은 눈에 띄지 않게 숨어 있는 네 가지 문제입니다:
겉보기엔 온통 초록색이지만, 속으로는 위기에 처한 프로젝트. 모든 팀 리더는 자신의 워크스트림을 ‘일정대로 진행 중’으로 표시합니다. 대시보드는 온통 초록색으로 가득 차 있지만, 출시일은 어김없이 늦어집니다. 이는 각 워크스트림 내부의 상태만 측정할 뿐, 업무 인계 과정 자체에는 별도의 상태 정보가 없기 때문입니다.
해결책: 각 업무 인계에 고유한 상태를 부여하세요. ‘정상 진행 중’, ‘위험’, ‘블록’ 중 하나로 표시한 다음, 해당 상태를 인수하는 팀이 책임지도록 하세요.
아무도 문서화하지 않은 암묵적인 합의. 누군가가 말합니다. “마케팅 팀은 항상 제때 파일을 보내주니까, 공식적인 규칙은 필요 없어요.” 바로 그 점이 문제입니다. 사람들이 문서화하는 것을 생략하는 연결 고리들은 오히려 쉽고 신뢰할 수 있는 것들입니다. 문서화되지 않았기 때문에, 문제가 발생해도 자동 알림이 울리지 않습니다.
해결책: 먼저 처리하기 쉬운 업무 인계 사항을 기록하세요. 아무도 이를 걱정하지 않기 때문에 정확히 이 작업을 수행해야 합니다. 계획 수립에 있어서는 ‘좋은 의도’만으로 유지되는 연결고리는 존재하지 않습니다.
회의 과다. 업무 인계를 철저히 관리하려는 나머지, 모든 연결 지점마다 정기 회의를 설정하게 됩니다. 그 결과, 팀 리더들은 실제 일을 수행하는 것보다 일에 대해 논의하는 데 더 많은 시간을 소비하게 됩니다. 이는 다른 실수들만큼이나 많은 시간을 낭비하게 만듭니다.
해결책: 회의 일정을 위험도에 맞춰 조정하십시오. 한 번의 지연만으로도 모든 것이 중단되는 ‘긴밀한 연결’의 경우 매일 동기화해야 합니다. 반면, 일정 기간 동안 지연이 허용되는 ‘유연한 연결’의 경우 주요 마일스톤 시점에 맞춰 동기화하면 됩니다.
가상의 병렬 일. 프로젝트 차트에는 두 개의 트랙이 나란히 배치되어 있습니다. 겉보기에는 서로 독립적인 것처럼 보입니다. 하지만 두 트랙 모두 같은 사람이 결정을 내리기를 기다리고 있거나, 같은 상사가 예산을 승인하기를 기다리고 있습니다. 서류상으로는 일이 동시에 진행되는 것처럼 보이지만, 실제로는 두 트랙이 차례로 진행됩니다.
해결책: 리소스를 확인하여 이러한 문제를 조기에 파악할 수 있습니다. 단순히 작업뿐만 아니라, 공유된 인력과 승인 담당자도 살펴보세요. 한 명을 다른 업무에서 빼내면 두 트랙의 진행이 지연된다면, 그 트랙들은 애초에 진정한 의미에서 병렬로 진행되고 있었던 것이 아닙니다.
규모가 확대되어도 중단되지 않는 업무 흐름을 설정하세요
성공적으로 성과를 내는 프로젝트와 진도가 더딘 프로젝트를 구분하는 핵심은, 누군가가 이러한 업무 흐름 간의 연결 관계를 체계적으로 설계했는지, 아니면 그저 저절로 해결될 것이라고 가정했는지에 달려 있습니다.
이런 패턴은 흔히 볼 수 있습니다. 첫 주는 모든 것이 순조로워 보입니다. 작업 흐름이 깔끔하고, 소유자가 명확하며, 모두가 빠르게 진행합니다. 하지만 4주 차가 되면, 한 작업 흐름에서 내려진 결정이 다른 작업 흐름의 일을 망쳐버립니다. 팀들이 서로 접하는 지점의 간극을 아무도 주시하지 않았기 때문에, 아무도 이 문제를 지적하지 못했던 것입니다.
제시간에 결과를 내놓는 팀은 플랜이 더 뛰어나기 때문이 아닙니다. 각 트랙이 다른 트랙에 대해 어떤 책임을 지고 있는지 더 명확히 파악하고 있기 때문입니다. 프로젝트 매니저가 지속적으로 관리해야만 이러한 구조가 유지되므로, 그들은 이러한 가시성을 매일 실천하는 습관으로 삼습니다.
여러 팀이 동일한 마감일을 향해 협업하는 프로젝트가 자주 있다면, ClickUp을 통해 각 트랙을 별도의 목록으로 관리할 수 있습니다. 목록 간에 의존성을 연결하고 단일 대시보드에서 모든 사항을 모니터링할 수 있습니다. 심지어 AI를 활용하여 담당자를 일일이 찾아다니지 않고도 트랙 간 상태 정보를 확인할 수도 있습니다. 이 모든 작업이 하나의 플랫폼에서 이루어지므로, 여러 도구를 따로 연결할 필요가 없습니다.
프로젝트 관리의 워크스트림에 관한 자주 묻는 질문
워크스트림과 프로젝트 단계의 차이점은 무엇입니까?
‘단계(phase)’는 순차적인 반면, ‘워크스트림(workstream)’은 병렬적으로 진행됩니다. 단계는 계획, 실행, 종료와 같이 프로젝트가 순서대로 거치는 단계입니다. 반면, 워크스트림은 프로젝트 수명 주기 전반에 걸쳐 병렬로 진행됩니다. 엔지니어링과 같은 단일 워크스트림은 모든 단계에서 지속적으로 활성화됩니다. 단계는 작업이 언제 수행되는지를 알려주는 것으로 생각하십시오. 반면 워크스트림은 타임라인 전반에 걸쳐 누가 어떤 트랙을 담당하는지를 알려줍니다.
워크스트림은 프로젝트 및 프로그램과 어떻게 다른가요?
차이점은 크기 및 프로젝트 간의 조화 방식에 있습니다. 프로그램은 관련 프로젝트들의 집합입니다. 프로젝트는 명확한 마감 기한이 있는 단일 이니셔티브입니다. 워크스트림은 해당 프로젝트 내의 하나의 병행 트랙입니다. 워크스트림은 결코 독립적으로 존재하지 않습니다. 더 큰 프로젝트 목표의 일부로서만 존재합니다. 워크스트림은 부모 프로젝트와 종료 날짜 및 주요 목표를 공유합니다. 반면, 별도의 프로젝트는 자체적인 독립적인 헌장을 가지고 있습니다.
PMBOK이나 PRINCE2와 같은 공식 표준에서 ‘워크스트림’을 정의하고 있습니까?
‘워크스트림’을 공식적으로 정의한 주요 프로젝트 관리 표준은 없습니다. PMI의 PMBOK 가이드, APM 지식 체계(Body of Knowledge), PRINCE2 매뉴얼 어디에도 이 용어가 멘션되어 있지 않습니다. 이는 실제 프로젝트 수행 과정에서 자연스럽게 생겨난 실무 용어입니다. 이를 표준화하는 관리 기관이 없기 때문에 기업마다 사용 방식이 다릅니다.
워크스트림과 워크 패키지의 차이점은 무엇입니까?
워크 패키지는 훨씬 더 작은 단위로, 작업 세분화 구조(WBS) 내에 포함됩니다. 엄밀히 말해, 워크 패키지는 추정하고 할당할 수 있는 가장 하위 수준의 작업입니다. 워크스트림은 훨씬 더 광범위합니다. 이는 많은 워크 패키지와 여러 워크플로우를 포함할 수 있는 지속적인 흐름입니다. 간단히 말해, 워크 패키지는 산출물의 단위입니다. 워크스트림은 이러한 산출물들을 묶어 소유권으로 관리하는 단위입니다.
한 사람이 두 개 이상의 업무 흐름을 이끌 수 있습니까?
가능은 하지만, 이는 숨겨진 병목 현상을 유발하는 가장 빠른 방법입니다. 단일 책임자를 지정하는 핵심 목적은 한 트랙의 업무 인계에 대한 명확한 책임을 부여하는 데 있습니다. 한 사람을 세 개의 스트림에 동시에 배정하면 병목 현상이 그 사람의 달력으로 옮겨갑니다. 그러면 모든 트랙이 끊임없이 작업을 전환하는 한 사람을 기다리게 됩니다. 부득이하게 한 사람에게 여러 작업을 맡겨야 한다면, 규모가 작고 위험이 낮은 트랙에만 한정하십시오. 또한, 같은 주에 타임라인이 집중되는지 주의 깊게 살펴보세요.
훌륭한 워크스트림 리더의 조건은 무엇일까요?
훌륭한 워크스트림 리더는 모든 결정을 주 프로젝트 관리자에게 일일이 상의하지 않고도 자신의 팀이 원활하게 업무를 진행할 수 있도록 충분한 권한을 가지고 있습니다. 이 역할은 해당 워크스트림의 타임라인, 산출물 및 인계 절차를 책임집니다. 최고의 리더는 자신의 업무 경계를 확실히 지킵니다. 인계 과정을 면밀히 모니터링하고, 의존성이 지연될 경우 조기에 문제를 보고합니다. 일상적인 결정에도 허가를 받아야 하는 리더는 이름만 리더일 뿐입니다.