태스크란? WBS와 Scrum으로 업무를 효율적으로 완수하는 법

업무라는 단어가 허드렛일이나 꺼려지는 행동과 관련된 절망감을 불러일으킬 수 있지만, 이는 업무 자체보다는 시간 관리 방식과 더 관련이 있습니다.

이 글에서는 업무에 대해 자세히 알아보고, 더 큰 프로젝트를 업무로 세분화하는 가장 좋은 방법을 보여드리며, 업무를 관리하고 분배하는 효율적인 접근 방식을 다룰 것입니다.

프로젝트에서 업무란 무엇일까요?

프로젝트 관리에서 업무는 더 큰 목표와 관련된 특정 목적을 가진 작업 항목 또는 활동입니다. 프로젝트 완료로 가는 데 필요한 단계입니다.

예를 들어, 모바일 앱 버그 수정과 같이 복잡한 작업일 수도 있습니다.

아니면 최신 브로셔를 복사하여 배포하는 것과 같이 간단한 작업일 수도 있습니다.

개별 업무는 일반적으로 한 명의 개인 또는 팀에 할당되는 반면, 더 큰 프로젝트는 회사 전체의 노력이 될 수 있습니다.

업무에는 시작 및 종료 날짜 또는 일련의 하위 업무가 포함될 수도 있고 그렇지 않을 수도 있는데, 이는 관련된 프로젝트의 복잡성에 따라 달라지며, 업계와 관련될 수 있습니다.

프로젝트를 더 작은 업무로 어떻게 세분화할 수 있을까요?

평균 11.6주 동안 지속되는 장기적인 Scrum 프로젝트조차도 업무 관리를 활용하여 효율적이고 효과적으로 업무를 완료합니다.

업무 관리의 일부에는 관리 가능한 워크로드 생성, 업무 종속성 고려, 물론 중복 작업이나 장애물을 피하기 위한 팀 간의 소통이 포함됩니다.

이러한 문제를 방지하려면 상위 수준의 프로젝트 결과물과 목표를 실질적인 업무로 세분화하는 방법이 필요합니다.

다음 섹션에서는 가장 인기 있는 두 가지 방법론인 Waterfall과 Scrum을 보여드리겠습니다.

작업 분해 구조

작업 분해 구조(WBS)는 PMI 가이드북에서 프로젝트를 세분화하는 공식적인 방법입니다.

전체 프로젝트를 업무로 세분화하는 방법을 파악하려면 먼저 최종 제품 또는 결과를 클라이언트에게 전달하는 데 필요한 실제 결과물로 나누어야 합니다.

예를 들어, 산악 자전거를 만들 계획이라면 프레임, 핸들바, 페달, 바퀴, 체인 등으로 나눌 수 있습니다.

(이미지 출처)

또한 프로젝트의 종속성(즉, 완료를 위해 다른 종속성이 필요한 결과물)을 파악해야 합니다.

WBS를 단순화하면 자전거 프레임 제조에 대한 섹션이 다음과 같이 표시될 수 있습니다.

물론 각 항목에는 벤더 소싱, 디자인 검토, 재료 선택 등과 같은 여러 업무가 포함됩니다.

하지만 이러한 업무를 모든 업무를 완료하는 데 필요한 기술을 갖춘 팀에 할당하면 상위 수준 계획이 다음과 같이 보일 수 있습니다.

Scrum

Agile 프레임워크(Scrum 등)를 사용하는 경우, 초기에 전체 프로젝트를 세부적인 업무로 세분화하는 데 신경 쓰지 않을 것입니다. 이러한 대규모 예측 연습을 피하는 것이 Agile의 주요 원칙 중 하나입니다.

대신, Scrum 스프린트에서 제품의 결과물 증가분을 계획하는 데 집중할 것입니다. 이는 최종 결과물의 작동하는 제품 버전을 제공하는 데 전념하는 2~4주 기간의 집중된 작업입니다.

이러한 반복을 계획하는 기반은 기능 또는 사용자 스토리(사용자 관점의 기능)의 백로그입니다. 장기적인 제품 방향을 설명하는 제품 로드맵이 있을 수도 있습니다.

제품 백로그는 스프린트 전, 중, 후에 지속적으로 정리되고 최적화됩니다. 소프트웨어 프로젝트를 계획하지 않더라도 증분으로 제공할 수 있는 요소를 종종 식별할 수 있습니다.

각 스프린트 전에 팀 및 이해 관계자(관련 당사자)와 만나 가장 중요한 사용자 스토리에 대해 논의합니다. 몇 가지 항목을 선택하고 전용 스프린트 백로그를 만듭니다.

그런 다음 각 사용자 스토리를 추가로 업무로 나누고 팀 구성원은 처리할 수 있는 특정 업무의 소유권을 갖습니다.

모든 조직이나 프로젝트에 이상적인 것은 아니지만 복잡한 프로젝트에서 과도한 관리에 대한 해독제입니다.

프로젝트 업무의 크기는 어느 정도여야 할까요?

그렇다면 얼마나 세분화해야 할까요? 프로젝트에서 업무의 범위와 길이는 어느 정도여야 할까요?

프로젝트의 규모와 PM 프레임워크에 따라 다르지만, 몇 가지 경험 법칙이 있습니다.

WBS의 8/80 규칙 

전통적인 프로젝트 관리에서 경험 법칙은 WBS에서 업무가 8시간 미만 또는 80시간 이상이 되어서는 안 된다는 것입니다.

따라서 PMI는 WBS에서 업무를 20~80시간 사이로 유지할 것을 권장합니다.

그런 다음 개별 팀은 자체 할 일 목록을 관리하고 2주 업무를 일일 하위 업무로 세분화하기 위해 더 세분화된 업무 보드를 가질 수 있습니다.

Scrum의 업무 길이

사용자 스토리는 일반적으로 지정된 길이가 없지만, 일반적으로 관리 가능한 청크(보통 하루 또는 그 미만)로 나뉩니다. 공식 Scrum 가이드에서는 업무라는 단어를 사용하지 않고 대신 작업 단위를 사용합니다.

“개발 팀이 스프린트의 첫날에 계획한 작업은 이 회의가 끝날 때까지 분해되며, 종종 하루 또는 그 미만의 단위로 분해됩니다.” 

Scrum 보드에서는 story point(먼데이닷컴에서는 1 SP를 하루로 간주)를 사용하여 업무의 길이를 추정할 수 있습니다.

업무는 둘 이상의 리소스를 필요로 해서는 안 됩니다. 결과물을 개별 업무로 세분화할 때 시간만 고려하는 것은 아닙니다. 가장 좋은 방법은 업무가 할당된 사람이 처음부터 끝까지 완료할 수 있는지 확인하는 것입니다.

예를 들어, 그래픽 디자이너는 앱의 와이어프레임을 만들 수 있지만 작동하는 프로토타입을 만들 수는 없습니다.

따라서 작동하는 기능 프로토타입의 더 큰 결과물을 와이어프레임/디자인 및 개발(최소한)로 나누어야 합니다.

대기업의 경우 리소스는 디자이너, 개발자 및 소프트웨어 테스터를 포함하는 전체 팀일 수 있습니다. 이 경우 계획 및 업무 할당 시 세분화할 필요가 없습니다.

작업 소요 시간을 정확하게 추정하기

업무 기간을 정확하게 추정하는 가장 좋은 방법은 업무를 처리할 실제 리소스를 계획 프로세스에 참여시키는 것입니다.

Agile 또는 Scrum으로 전환할 필요는 없습니다. 관리뿐만 아니라 실제 프로젝트 구현자를 계획 프로세스에 참여시키기만 하면 됩니다.

업무 기간을 돕는 것뿐만 아니라 종속성 및 잠재적 병목 현상을 예상하는 데에도 도움이 될 수 있습니다.

프로젝트 업무를 구성하는 가장 좋은 방법은 무엇일까요?

프로젝트를 관리하고 업무로 세분화하는 데는 수백 가지의 다양한 프레임워크와 방법이 있습니다.

효율성과 채택 용이성으로 인해 몇 가지가 눈에 띄며 그 결과 인기를 얻었습니다.

(이미지 출처)

이러한 업계 최고의 옵션을 자세히 살펴보겠습니다.

Waterfall

Waterfall은 전통적인 “예측적” 프로젝트 관리 접근 방식을 의미합니다. 시작하기도 전에 프로젝트의 모든 단계를 처음부터 끝까지 계획하기 때문에 예측적이라고 합니다.

Waterfall이라고 하는 이유는 프로젝트가 순차적인 순서를 따르도록 계획되기 때문입니다.

먼저, 프로젝트의 요구 사항을 파악하는 것으로 시작합니다. 완성된 제품을 제공하려면 어떤 결과물이 필요할까요?

그런 다음, 설계 및 제작(구현)으로 넘어갑니다. 마지막으로, 제품이 의도한 대로 작동하는지 확인하고 출시합니다. 마지막 단계에는 제품의 장기적인 유지 관리가 포함됩니다.

Waterfall을 비난하는 것은 젊은 관리 전문가들 사이에서 인기 있는 취미이지만, 나름의 자리가 있습니다.

실제 생산 시간과 관련된 많은 종속성 및 높은 비용이 있는 물리적 제품의 경우, 전체 프로젝트를 자세히 매핑하는 것이 가장 좋은 방법일 수 있습니다.

Agile

Agile은 특정 방법론이 아니라 프로젝트에 적용할 핵심 가치 및 원칙 집합을 개략적으로 설명합니다. 결과적으로 Agile은 여러 가지 방법론과 프레임워크를 포괄하는 포괄적인 용어입니다.

가장 유명한 원칙은 프로젝트의 작동하는 반복을 자주 제공하는 것입니다. 이는 Waterfall과 같이 처음부터 끝까지 전체 제품을 계획하는 것과는 대조적입니다.

Lean

Lean은 Agile과 마찬가지로 프로젝트 관리 접근 방식을 자세히 설명하는 특정 프레임워크가 아닙니다. 대신, 핵심 원칙 집합을 가진 관리 철학을 의미합니다.

Lean의 초점은 생산의 각 단계에서 프로세스의 낭비를 제거하는 것입니다. 결국, 실행이 결과를 제어합니다.

부서 간의 병목 현상을 해결하여 최종 조립 속도를 높이는 것이 좋은 예입니다.

Scrum

Scrum은 Agile과 혼동해서는 안 됩니다. Agile은 상위 수준의 개념과 원칙에 더 가깝고, Scrum은 프로젝트 관리를 위한 실제 프레임워크입니다.

가치뿐만 아니라 명확한 규칙, 회의(의식) 및 결과물(아티팩트)을 개략적으로 설명합니다.

(이미지 출처)

예를 들어, Scrum 팀은 최대 9명의 정규 팀원만 포함해야 합니다. 매일 Scrum 회의는 15분만 진행되어야 합니다.

스프린트를 설계하고 완료하는 전체 프로세스가 자세히 설명되어 있습니다. Scrum 프레임워크가 Agile 원칙을 실제로 구현하려는 팀에 매우 유용한 이유입니다.

효과적인 업무 관리를 위해 프로젝트 관리 플랫폼을 사용하는 방법

비효율적인 프로세스로 관리자와 팀의 속도를 늦추는 대신 최신 업무 관리 소프트웨어를 활용하세요.

먼데이닷컴은 프로젝트 관리자가 원하는 모든 기능을 갖춘 디지털 작업 공간으로, 배우고 사용하기가 실제로 쉽습니다. 함께 작업할 프레임워크 또는 방법론을 선택하세요.

원하는 프레임워크 또는 방법론을 선택하세요

완전히 새로운 수준의 생산성에 도달하려면 기본적인 업무 관리로는 부족합니다. 일상적인 업무를 넘어선 프로젝트 관리 프레임워크를 도입해야 합니다.

다행히 먼데이닷컴을 사용하면 쉽게 전환할 수 있습니다. WBS에서 Scrum까지 모든 것을 위한 전용 템플릿을 제공합니다.

상위 수준의 프로젝트 로드맵을 개발하세요

일관된 결과를 얻으려면 상위 수준의 프로젝트 로드맵을 개발해야 합니다. 프로젝트가 진행됨에 따라 모든 결정과 우선 순위를 안내하는 데 도움이 됩니다.

WBS 및 기타 업무 보드를 사용하여 더 세분화하세요

여기에서 더 큰 목표를 더 작은 결과물로 나누고 관련된 각 팀 또는 부서의 워크로드를 설정하기 시작합니다.

전체 프로세스를 개략적으로 설명해야 하지만 프로젝트 규모에 따라 모든 활동 또는 업무를 지정하지 않을 수 있습니다.

하지만 관련된 팀 또는 부서 내에서 개별 업무를 계획하는 데 가장 적합하지 않습니다.

먼데이닷컴은 이러한 팀이 일상적인 업무를 관리하는 데 사용할 수 있는 보다 기본적인 업무 보드도 제공하는 이유입니다.

더 큰 항목을 더 작은 하위 업무로 쉽게 나누고 할당할 수도 있습니다.

통합 및 자동화를 사용하여 사소한 업무를 자동화하세요

워크플로우를 완벽하게 만들려면 몇 가지 새로운 업무 보드를 만드는 것만으로는 충분하지 않습니다. 반복적인 사소한 업무도 제거해야 합니다.

예를 들어, 스마트 통합을 사용하면 이메일이나 메시지를 받으면 자동으로 카드를 업데이트하거나 새 업무를 만들 수 있습니다.

이는 광범위한 팀과 사용 사례에 유용한 기능입니다. 예를 들어, 소프트웨어 팀은 모든 버그 보고서와 함께 새로운 업무를 얻을 수 있습니다.

사소한 업무를 자동화하면 관리자와 팀이 중요한 상위 수준의 결정에 집중할 시간과 공간을 확보할 수 있습니다.

대시보드 및 보고서로 관리자를 최신 상태로 유지하세요

업무가 예정대로 완료되고 있는지, 또는 막바지 작업을 위해 어떤 사람(또는 팀)을 사용할 수 있는지 한눈에 확인하고 싶으신가요?

업무를 마스터하세요

프로젝트를 업무로 세분화하고 효과적으로 할당하려면 약간의 균형이 필요합니다.

업계 및 내부 워크플로우에 가장 적합한 프레임워크를 찾고 위의 팁과 페어링하면 팀이 번창할 수 있는 관리 및 자율성의 적절한 균형을 찾을 수 있습니다.

무엇을 선택하든 먼데이닷컴에는 프로젝트를 성공시키는 데 도움이 되는 적절한 템플릿과 도구가 있습니다.