프로젝트 관리의 기본 원칙

기본 원칙을 바탕으로 프로젝트가 무엇인지, 그리고 프로젝트를 효과적으로 관리하는 방법에 대한 포괄적인 이해를 제공합니다.

블루에서는 프로젝트 관리에 대해 많은 시간을 고민합니다. 이는 우리가 하는 일과 고객에게 제공하는 성공의 핵심입니다. 프로젝트 관리에 대한 확고한 이해 없이는 어떻게 프로젝트 관리 소프트웨어를 구축할 수 있을까요?

새로운 프로젝트를 시작할 때마다, 새로운 기능, 백엔드 엔지니어링 업그레이드, 마케팅 캠페인 또는 채용 활동 등 어떤 것이든, 우리는 프로젝트 자체와 그것이 어떻게 운영되고 있는지를 분석하는 것부터 시작합니다. 그래서 많은 경험과 통찰력을 바탕으로 프로젝트 관리의 몇 가지 기본 원칙을 정립하기로 결정했습니다.

비공식적이고 개인적인 직관으로 프로젝트를 탐색하는 것은 일반적이고 허용되지만, 이는 확장 가능한 접근 방식이 아니며 단점이 있습니다.

프로젝트란

프로젝트를 정의하는 것부터 시작해 보겠습니다.

프로젝트란 독특한 제품, 서비스 또는 결과를 생성하기 위해 정의된 시작과 종료가 있는 임시 작업입니다. 대부분의 사람들이 프로젝트를 생각하는 방식입니다. 그러나 고려해야 할 더 공식적인 프로젝트의 특성도 있습니다:

프로젝트는 한정된 자원(시간, 돈, 인력)을 가집니다;
프로젝트는 특정 목표를 달성하기 위해 수행됩니다;
프로젝트는 정의된 범위를 가집니다(즉, 하지 않을 일이 분명히 있습니다);
프로젝트는 불확실성과 위험에 노출됩니다.

이제 프로젝트가 무엇인지에 대한 이해가 더 깊어졌으니, 성공적인 프로젝트에 필요한 기본 원칙으로 넘어갈 수 있습니다. 여기에는 다음이 포함됩니다:

프로젝트 관리자;
목표;
완료해야 할 작업 목록 — 이는 종종 계획이라고 불립니다;
각 작업을 수행할 사람;
각 작업에 대한 일정;
정기적인 업데이트 및 회의의 커뮤니케이션 전략과 정보가 저장될 위치에 대한 계획.

우리는 이러한 요소들이 일반적으로 모든 프로젝트에 적용되며, 잘 수행되면 프로젝트 내의 모든 문제의 99%를 제거한다는 것을 발견했습니다.

프로젝트 관리자

프로젝트에 필요한 첫 번째 것은 성공적으로 프로젝트를 완료할 책임이 있는 사람입니다. 이는 명백한 진술처럼 보일 수 있지만, 강조할 가치가 있습니다.

이 사람은 프로젝트 관리자입니다. 그들은 프로젝트의 목표가 충족되고 프로젝트가 제시간에, 예산 내에서, 요구되는 품질 기준에 맞게 완료되도록 보장할 책임이 있습니다. 종종 우리 중 많은 사람들이 훈련된 프로젝트 관리자가 아니더라도 사실상 프로젝트 관리자가 됩니다. 만약 당신이 그렇다면, 운이 좋습니다. 우리는 이를 위한 가이드를 작성했습니다!

프로젝트 관리자가 해야 할 일과 하지 말아야 할 일을 고려하는 것이 중요합니다. 결국 그들은 많은 책임을 지고 있으며, 이 책임을 진지하게 받아들여야 합니다.

종종 프로젝트 관리에는 프로젝트 예산의 상당 부분이 소요될 수 있습니다 — 일반적으로 2%에서 10% 사이이며, 이는 프로젝트의 위험도에 따라 달라집니다. 위험이 클수록 프로젝트가 궤도를 유지하고 실패하지 않도록 보장하기 위해 더 많은 프로젝트 관리가 필요합니다.

그들이 관리자이기 때문에, 프로젝트 관리자는 다른 사람을 통해 목표를 달성하는 방법에 집중해야 합니다. 그들은 프로젝트 팀이 효과적이며 공동의 목표를 향해 조화롭게 작업하고 있는지 확인해야 합니다. 프로젝트 관리자는 모든 사람이 자신의 일을 잘 수행하고 있는지 확인해야 하는 사람입니다.

프로젝트 관리자는 또한 프로젝트의 이해관계자와 소통하고 그들에게 진행 상황을 업데이트하는 책임이 있습니다.

리더를 위한 우선순위 설정에서 논의한 것처럼, 프로젝트 관리자는 항상 제약의 지점에 집중해야 합니다. 이해관계자가 무언가를 승인하는 데 너무 많은 시간이 걸린다면, 그들은 그 약속을 얻기 위해 집중해야 합니다. 그들은 끊임없이 스스로에게 물어야 합니다. “무엇이 프로젝트 목표 완료를 방해하고 있으며, 이 문제를 가능한 한 빨리 해결하려면 어떻게 해야 할까?”

어떤 면에서 프로젝트 관리는 소통과 동의어입니다. 세부적인 아이디어를 문서화하는 것은 프로젝트 관리자가 갖춰야 할 귀중한 기술입니다. 이는 필요한 정보를 팀원이 스스로 찾을 수 있도록 하여 회의 수를 크게 줄입니다.

목표

프로젝트의 또 다른 핵심 요소는 프로젝트가 명확하고 측정 가능한 목표를 필요로 한다는 것입니다. 프로젝트가 완료되면 결과를 보고 프로젝트가 목표를 달성했는지 실패했는지 쉽게 알 수 있어야 합니다.

목표는 모든 팀원이 접근할 수 있도록 게시되어야 합니다. 이는 의사 결정이 분산되고 탈중앙화될 수 있음을 의미하므로 중요합니다. 각 팀원은 자신의 작은 작업 조각을 보고 이를 프로젝트의 전반적인 목표와 연결할 수 있습니다. 그런 다음, 불일치가 있을 경우 문제를 제기하거나 프로젝트의 작은 영역에서 접근 방식을 변경하여 더 큰 목표를 잘 수행할 수 있습니다.

프로젝트의 목표는 SMART해야 합니다:

구체적이어야 합니다. 프로젝트는 종종 사명 또는 비전 진술처럼 들리는 고수준의 목표를 가집니다. “고객 지원 개선”과 같은 나쁜 목표의 예가 있습니다. 이는 충분히 구체적이지 않습니다. “우리는 Q4가 끝날 때까지 30분 이내에 90%의 고객에게 이메일을 회신하는 것을 목표로 합니다.”와 같은 것이 훨씬 더 구체적입니다.
측정 가능해야 합니다. 구체적인 목표를 설정하면 목표가 달성되었는지 평가하기가 쉬워집니다.
달성 가능해야 합니다. 목표는 달성할 수 있어야 의미가 있습니다. 그러나 이는 쉬운 목표를 만드는 변명이 되어서는 안 됩니다. 좋은 목표는 도전적인 요소를 가져야 하며, 도달할 수 있을 만큼 도전적이어야 하지만 불가능하거나 매우 낮은 가능성은 없어야 합니다.
관련성이 있어야 합니다. 이는 매우 자명하게 들릴 수 있지만, 실제로 얼마나 자주 발생하는지 놀라울 것입니다. 프로젝트 목표는 프로젝트를 수행함으로써 달성할 수 있어야 합니다. 특정 작업을 수행하는 프로젝트 팀이 통제할 수 없는 목표를 설정할 수는 없습니다. 예를 들어, 기업의 제조 부서에서 일하는 팀은 고객의 매장 내 쇼핑 경험에 영향을 미칠 수 없습니다.
시간 제한이 있어야 합니다. 좋은 목표는 어떤 형태의 시간 제한이 있어야 합니다. 이는 특히 작업이 항상 명확하지 않은 현대 소프트웨어 프로젝트에서는 어려울 수 있으며, 일정 추정이 매우 어려울 수 있습니다. 때때로 여러 배수로 잘못될 수 있으며, 이는 누구의 특정 잘못도 아닙니다. 그럼에도 불구하고 일정을 설정하는 것은 프로젝트의 전체 범위가 특정 한계 내에 유지되도록 보장합니다. 문제를 해결하는 데 한 달이 필요한지, 1년이 필요한지에 따라 매우 다른 솔루션이 나올 것입니다.

목표는 모든 팀원에게 반복적으로 전달되어야 합니다: 그들은 (비유적으로) 프로젝트 관리자가 목표를 지속적으로 논의하는 것에 지겨워해야 합니다. 진행 상황을 추적하는 실시간(또는 가능한 한 실시간에 가까운) 대시보드도 모든 사람이 목표에 맞춰 정렬되고 프로젝트가 어떻게 진행되고 있는지 알 수 있도록 하는 데 매우 유용할 수 있습니다.

완료해야 할 작업 목록

우리는 계획을 “완료해야 할 작업 목록”이라고 부르는 것을 강력히 권장합니다. 이는 계획 프로세스를 신비롭게 만들지 않기 때문입니다.

계획은 종종 추측이지만 여전히 가치가 있습니다. 이는 계획 자체의 과정이 우리가 아는 것과 아직 모르는 것에 대한 통찰을 제공하기 때문입니다.

계획하지 않으면, 실패할 계획이다.

계획의 본질은 프로젝트의 시작부터 성공적인 완료까지의 모든 단계를 상세히 나열하는 것입니다. 일부 작업은 이전 단계가 완료되어야 하며, 따라서 종속성이라고 하는 일련의 연결된 작업이 생길 수 있습니다. 다른 작업은 병렬로 수행할 수 있으며 서로를 차단하지 않습니다.

프로젝트 관리자는 항상 다른 작업을 차단하는 가장 중요한 작업에 집중해야 합니다. 이는 프로젝트의 핵심 경로를 정의합니다. 즉, 모든 종속성이 끝에서 끝으로 정렬될 경우 프로젝트를 완료할 수 있는 최소 시간입니다.

프로젝트의 양쪽 끝에서 계획 작업을 수행하는 것은 효과적인 계획을 세우는 데 큰 도움이 될 수 있습니다. 이는 시작부터 끝까지 진행하되, 끝에서 시작하여 프로젝트를 완료하고 목표를 달성하는 데 필요한 것을 이해하는 방식으로 작업하는 것을 의미합니다.

계획 프로세스를 반대로 진행하는 마지막 부분은 일반적으로 놓친 작업을 드러냅니다.

그러나 각 작업에 대한 책임이 누구에게 있는지, 각 작업을 완료하는 데 얼마나 걸릴지를 이해할 때까지 계획 프로세스는 완료되지 않습니다.

이러한 사항은 매우 밀접하게 연결되어 있으므로 동시에 다루어져야 합니다. 작업에 대한 추정치를 생성하려면 해당 작업의 세부 사항을 아는 전문가를 포함해야 하며, 그럼에도 불구하고 자원에 대한 주의를 기울여야 합니다. 개인은 동시에 여러 작업을 효과적으로 수행하기가 드물므로, 프로젝트 계획이 병목 현상을 초래할 가능성이 있는지 이해해야 합니다. 이는 한 사람이 할당된 모든 작업을 완료할 수 없을 정도로 시간이 부족한 경우입니다.

각 작업을 수행할 사람

프로젝트의 각 작업에는 해당 작업을 완료할 책임이 있는 특정 개인이 있어야 합니다. 동일한 작업에 여러 개인이 필요하다고 판단되면, 작업을 구분할 만큼 세분화되지 않았을 가능성이 높습니다.

예를 들어, 많은 산업에서 설계 및 구축 단계가 있을 것입니다. 이는 제조, 건설 또는 소프트웨어에서도 마찬가지입니다. 이를 세분화하여 디자이너의 특정 작업과 빌더의 특정 작업을 할당할 수 있어야 합니다. 두 분야 간의 상호작용이 종종 발생하므로 이를 고려해야 합니다. 예를 들어 다음과 같은 형태일 수 있습니다:

디자이너의 설계 단계 1
빌더의 타당성 검사 1
디자이너의 설계 단계 2
빌더의 타당성 검사 2
고위 이해관계자의 검토
디자이너의 설계 최종화
빌더의 최종 검사
이해관계자의 승인

이는 설계 단계 완료를 위해 디자인 팀에만 할당된 “설계 단계”가 아닌, 관련된 다양한 당사자 간의 현실적인 상호작용을 보여줍니다.

각 작업에 대한 일정

이는 계획을 수립하는 데 가장 어려운 부분일 수 있습니다 — 각 작업이 얼마나 걸릴지를 어떻게 측정할까요? 앞서 논의한 바와 같이, 일정은 상향식이 아닌 하향식으로 작성되어야 합니다. 이는 각 항목이 작업을 수행할 사람(또는 최소한 지식이 있는 동료)에 의해 추정되고, 이러한 모든 추정이 추가되어 전체 일정으로 계산된다는 것을 의미합니다.

그렇긴 하지만, 세부 추정이 이루어지기 전에 전체적인 고수준 일정을 갖는 것이 유용합니다. 왜냐하면 무언가가 얼마나 걸릴지를 추정하고 작업을 해결하기 위한 특정 접근 방식을 결정하는 것은 본질적으로 동일하기 때문입니다.

따라서 프로젝트에 관대한 고수준 일정이 있다면, 개별 전문가들은 이를 자신의 추정에 반영하고, 일정을 맞추기 위해 모퉁이를 잘라내기보다는 장기적인 솔루션을 최적화하려고 할 수 있습니다. 프로젝트에 급한 일정이 있다면, 각 전문가는 타협을 해야 할 수도 있다는 것을 알고 있습니다.

프로젝트 계획을 수립하는 동안 종종 간과되는 한 가지는 이해관계자가 진행 상황을 검토하고 반영해야 할 결정을 확인해야 한다는 것입니다. 이를 가장 잘 수행하는 방법은 동일한 이해관계자 집합이 포함된 이전 프로젝트를 살펴보고 그들이 피드백을 제공하는 데 일반적으로 소요되는 시간을 이해하는 것입니다.

여기서 또 다른 위험은 주요 이해관계자와의 월간 운영 위원회 회의가 있는 경우, 프로젝트 결과물이 그 회의 중 하나에 제출될 수 없는 경우 어떻게 되는가입니다? 프로젝트가 다음 달 이해관계자 회의까지 일시 중지되나요, 아니면 이 문제를 해결하고 승인(또는 피드백과 함께 반송)해야 하나요?

커뮤니케이션 전략

이러한 문제가 발생하면 프로젝트 내 커뮤니케이션 접근 방식이 매우 중요하다는 것을 확인시켜 줍니다.

보통 문제는 나쁜 전략이 아니라 아예 전략이 없다는 것입니다. 그래서 비공식적이고 즉흥적인 방식으로 커뮤니케이션 채널이 열리며, “충분히 좋은” 것이 기준이 됩니다.

이 문제는 일이 항상 계획대로 진행되지 않는다는 것입니다. 사람들이 변하고, 지식이 잃어버려지며, 프로젝트가 커지고 더 많은 사람들이 참여함에 따라 커뮤니케이션 오버헤드는 빠르게 폭발할 수 있습니다.

따라서 도구 자체는 그리 중요하지 않습니다. 비트리비얼한 수의 사람들(예: 10명)을 초과하여 확장할 때 팀워크가 점점 더 어려워진다는 사실입니다.

팀 커뮤니케이션은 팀원 수에 비례하여 선형적으로 확장되지 않기 때문입니다.

예를 들어, 2명의 팀이 있다면, 하나의 커뮤니케이션 스레드(두 개인 간의 스레드)가 있습니다. 여기에 다른 사람을 추가하면 이제 세 개의 커뮤니케이션 스레드가 생깁니다. 따라서 팀 규모가 50% 증가했지만, 커뮤니케이션 스레드는 300% 증가했습니다.

이것이 어떻게 성장하는지 살펴보겠습니다:

2명의 팀원 = 1개의 커뮤니케이션 스레드
3명의 팀원 = 3개의 커뮤니케이션 스레드
5명의 팀원 = 10개의 커뮤니케이션 스레드
8명의 팀원 = 28개의 커뮤니케이션 스레드
10명의 팀원 = 45개의 커뮤니케이션 스레드
15명의 팀원 = 105개의 커뮤니케이션 스레드
20명의 팀원 = 190개의 커뮤니케이션 스레드
30명의 팀원 = 435개의 커뮤니케이션 스레드
50명의 팀원 = 1,225개의 커뮤니케이션 스레드
100명의 팀원 = 4,950개의 커뮤니케이션 스레드

이는 다음과 같은 방정식으로 표현될 수 있습니다:

n(n-1)/2

여기서 n은 프로젝트에 참여해야 하는 사람의 수입니다.

보시다시피, 이 숫자는 팀 규모가 증가함에 따라 기하급수적으로 증가합니다. 10명의 팀이 있다면, 45개의 잠재적 커뮤니케이션 스레드를 관리해야 합니다. 그러나 50명의 팀이 있다면, 1,225개의 잠재적 커뮤니케이션 스레드가 있습니다 — 이는 27배 더 많습니다! 그리고 100명의 팀이 있다면, 4,950개의 가능한 커뮤니케이션 스레드가 있습니다 — 이는 110배 더 많습니다!

이는 단순히 대규모 팀의 문제가 아니라, 개인이 같은 장소에 있지 않은 모든 팀의 문제라는 점에 유의해야 합니다. 이는 팀원 간의 물리적 근접성에 의해 가능한 커뮤니케이션 스레드 수가 제한되지 않기 때문입니다.

예를 들어, 10명의 팀이 있지만 모두 세계의 다른 지역에 위치해 있다고 가정해 보겠습니다. 이 경우, 여전히 45개의 잠재적 커뮤니케이션 스레드를 관리해야 합니다 — 팀원들이 물리적으로 서로 가까이 있지 않더라도 말입니다.

상황은 더 나빠질 수 있습니다. 위의 계산은 단 하나의 커뮤니케이션 방법만을 가정합니다. 다양한 커뮤니케이션 방법을 고려하려면 다음과 같이 방정식을 다시 작성해야 합니다:

n(n-1)/2

여기서 n은 커뮤니케이션 채널의 수입니다.

위의 커뮤니케이션 스레드 수를 다시 살펴보되, 이번에는 n이 다음으로 구성된다고 가정해 보겠습니다:

이메일
그룹 채팅
개인 채팅
프로젝트 관리 시스템의 댓글
전화
문서 내 메모/댓글

숫자를 대입하면 다음과 같은 결과가 나옵니다:

2명의 팀원 = 6개의 커뮤니케이션 스레드
3명의 팀원 = 18개의 커뮤니케이션 스레드
5명의 팀원 = 60개의 커뮤니케이션 스레드
8명의 팀원 = 168개의 커뮤니케이션 스레드
10명의 팀원 = 270개의 커뮤니케이션 스레드
15명의 팀원 = 630개의 커뮤니케이션 스레드
20명의 팀원 = 1,140개의 커뮤니케이션 스레드
30명의 팀원 = 2,610개의 커뮤니케이션 스레드
50명의 팀원 = 7,350개의 커뮤니케이션 스레드
100명의 팀원 = 29,700개의 커뮤니케이션 스레드

커뮤니케이션 스레드 수가 얼마나 빠르게 증가하는지 무섭습니다 — 그리고 원격 작업이 실제로는 실현 불가능한 대규모 회의를 더 쉽게 가능하게 한다면, 이는 양날의 검입니다.

따라서 요약하자면, 전략은 상대적으로 적은 수의 팀원으로도 발생할 수 있는 커뮤니케이션 폭발을 피하는 데 매우 중요합니다.

“커뮤니케이션 전략”이라는 개념이 복잡하고 웅장하게 들릴 수 있지만, 반드시 그럴 필요는 없습니다. 핵심은 몇 가지 원칙을 설정하고, 주요 커뮤니케이션 채널을 명시하며, 사람들이 무엇을 하지 말아야 하는지도 알려주는 것입니다.

고려해야 할 몇 가지 기본 원칙:

정보를 개방적으로 유지하십시오. 모든 것이 몇 개월 또는 몇 년 후에도 쉽게 찾을 수 있고 공유할 수 있어야 한다고 가정하십시오. 프로젝트 팀의 모든 사람이 필요한 모든 정보에 접근할 수 있도록 하고, 이를 염두에 두고 파일 및 문서의 이름을 지정하는 데 주의하십시오.
명확성을 우선시하십시오. 새로운 사람이 프로젝트 팀에 합류한다고 상상해 보십시오. 중요한 결정을 쉽게 이해할 수 있도록 정보를 명확하고 간결하게 문서화하십시오.
회의록을 작성하십시오. 모든 중요한 회의가 기록되고 쉽게 찾을 수 있도록 하십시오.

커뮤니케이션 채널 측면에서는 적을수록 좋습니다. 우리는 이를 다음과 같이 줄이는 것을 제안합니다:

프로젝트 관리 소프트웨어를 사용하여 작업별 논의를 진행합니다.
회의(대면 또는 원격)와 회의록 및 모든 프로젝트 회의록을 한 곳에서 찾을 수 있는 곳.
문서: 이는 Google Docs 내의 댓글 및 논의 또는 댓글을 허용하는 특정 도구(예: UX 디자인을 위한 Figma)일 수 있습니다.

이 목록에 그룹 채팅을 추가하는 것도 허용됩니다 — 그러나 이는 명확한 목표나 의제 없이 하루 종일(그리고 매일!) 회의가 될 수 있으므로 신중하게 관리해야 합니다.

프로젝트 관리자는 이러한 규칙을 명확하게 설정하고, 프로젝트 팀원이 올바르게 소통하도록 다시 밀어넣기 위해 때때로 막대기를 사용하는(은유적으로, 문자 그대로가 아님!) 본보기가 되어야 합니다.

최종 생각

전문가의 수준에 관계없이, 주제나 프로세스를 기초 수준에서 바라보는 것은 항상 가치가 있습니다. 따라서 프로젝트 관리 주제에 대해 깊이 파고들면서, 프로젝트를 성공적으로 실행하는 데 필요한 핵심 기본 원칙을 식별했습니다.

각 프로젝트에는 프로젝트 관리자가 있어야 합니다: 그들은 프로젝트가 명확한 목표를 가지고 있도록 보장하며, 이를 달성하기 위해 완료해야 할 작업으로 나누어야 합니다. 그런 다음 프로젝트 관리자는 각 작업에 팀원을 할당해야 합니다. 팀은 각 개별 작업과 전체 프로젝트에 대한 일정을 식별할 수 있습니다.

문제는 종종 고급 주제가 아니라 사소해 보이는 것들이 문제를 일으킬 수 있다는 것입니다. 이는 커뮤니케이션과 같은 주제입니다. 따라서 프로젝트 팀 내외부에서 잘 정의된 커뮤니케이션 전략이 있어야 합니다.

프로젝트 관리는 복잡한 주제이므로, 이는 결코 포괄적인 가이드가 아닙니다. 예산, 옵션 간의 갈등을 해결하는 방법, 프로젝트 내에서 위임을 얼마나 진행할 것인지와 같은 초기 개요에서 다루지 않은 몇 가지 요소가 여전히 있습니다.