프로젝트 관리 치트 시트

지식을 수용하고 팀을 이끄는 완벽한 프로세스에 대해 읽는 것도 좋지만, 보편적으로 적용할 수 있는 완벽한 단일 프로세스는 없다는 것을 이해하는 것도 중요합니다. 이 기사에서는 사용하는 기술, 프레임워크 또는 방법론에 관계없이 더 나은 프로젝트 관리자가 되는 데 도움이 될 수 있는 가장 중요한 기술을 설명합니다.

팀, 팀, 팀

팀은 당신의 안전한 집입니다. 팀과 좋은 관계를 구축하고 팀 커뮤니케이션과 팀 정신을 향상시키는 것이 중요합니다. 팀은 모든 구성원이 가장 강하다고 느끼는 안전한 장소여야 합니다. 어떤 결정을 내리든 팀이 합니다. 어떤 기능이 구축되든 팀에서 구축합니다. 여러분 모두는 개인이 아닌 팀으로 인정을 받습니다.

몇 년 전 나는 '나'에서 '우리'로 바꿔 공식적인 커뮤니케이션 에티켓을 바꿨다. 예를 들어, 팀 외부의 이해 관계자와 무언가를 공유할 때 저는 다음과 같이 말합니다. “ 우리는 마지막 스프린트에 대한 속도 차트를 만들었습니다. 우리는 예산 및 일정 비용 예측을 완료했습니다 .” 이것은 처음에는 이상하게 보일 수 있지만 분명한 이점이 있습니다. 첫째, 권력은 팀 내에 있으며, 팀으로서 도달하면 결정이 더욱 강력해집니다. 둘째, 프로젝트 관리자는 모범을 보이고 "나"라는 말을 하지 않음으로써 우리가 스스로 어떤 것도 인정하지 않는다는 것을 보여줍니다. 실수에도 동일하게 적용됩니다. 잘못한 모든 것은 팀에 있습니다. 우리는 개별 팀원을 비난하지 않습니다. 이후 내부 검토를 통해 프로세스를 조정하고 개선하여 향후 유사한 실수가 발생하지 않도록 하겠습니다.

완벽한 프로세스에 대한 검색을 중단하십시오

팀을 위한 완벽한 프로세스를 찾고 있다면 지금 바로 멈출 수 있습니다. 보편적으로 적용할 수 있는 것은 없습니다.

프로젝트 관리자는 경력 전반에 걸쳐 다양한 프레임워크, 관행 및 프로세스에 노출됩니다. 그들은 구체적으로 작동하는 것을 발견하기 위해 팀 내에서 일부 프레임워크를 사용하기로 선택합니다. 그러나 팀이 프로세스를 거부하는 경우 "모든 경우에 적용되는" 모델을 따르지 않는 것이 중요합니다.

반대로 프로젝트 관리자는 팀과 함께 작업할 수 있도록 프로세스를 조정해야 합니다. IT 분야에서 경력을 쌓는 동안 "책에 따라" 완전히 프레임워크를 사용하는 팀을 본 적이 없습니다. 우리와 우리의 팀 구성, 문화 및 사고방식에 효과가 있는 것이 다른 팀에서는 작동할 가능성이 거의 없습니다. 따라서 프로젝트 관리자는 최적의 지점에 도달할 때까지 다양한 방식을 계속 테스트해야 합니다. 팀에 가장 적합한 방식의 조합입니다.

팀에서 스크럼을 도입했지만 일일 회의에 추가 오버헤드가 있는 경우 대안은 Slack에 회의 봇을 두고 필요할 때만 호출을 예약하는 것입니다. 스프린트 검토에도 동일한 태도를 적용할 수 있습니다. 팀 구성원이 비생산적이라고 생각하는 경우 관리자는 팀의 필요에 따라 검토 일정을 결정할 수 있습니다. 우리는 Scrum, Kanban 또는 기타 프레임워크의 수호자가 아니며 팀이 생산성과 동기 부여를 추구하도록 돕기 위한 것일 뿐임을 이해하는 것이 중요합니다.

많은 작업을 완료하기 위해 많은 손을 가짐

프로젝트 이해 관계자의 경우 커뮤니케이션이 핵심입니다. 좋든 싫든 프로젝트 관리자는 프로젝트의 모든 커뮤니케이션에 포함되어야 합니다. 때때로 관리자는 메시지와 작업의 과부하에 압도되지만 그것이 그들이 등록한 작업입니다.

경험 많은 프로젝트 관리자는 커뮤니케이션을 통해 신속하게 살펴보고 세심한 주의가 필요한 사항을 결정하는 기술을 습득합니다. 처음에는 이를 달성하기 위해 더 많은 노력이 필요할 수 있지만 목표는 프로젝트에 도움이 되지 않는 경우 심층 기술 토론과 같은 세부 사항에 들어가는 것을 자제하는 것입니다. 대신 시간을 절약하고 주고받는 메시지를 피하기 위해 프로젝트 관리자는 솔루션을 찾기 위해 팀 호출을 예약할 수 있습니다. 15분짜리 전화 한 통이 몇 시간 동안의 결정적이지 않은 서면 의사소통을 대체할 수 있습니다.

모든 이해 관계자는 프로젝트 관리자가 단일 연락 창구 라는 사실을 알고 있어야 합니다. 책임의 우선 순위를 지정하고 위임하는 것은 프로젝트가 순조롭게 진행되도록 하는 프로젝트 관리자의 필수 역할입니다. 많은 관리자가 요구 사항이 충족되었는지 확인하기 위해 스스로 작업을 완료하기로 선택하지만 장기적으로는 중요한 일에 집중하지 못할 수 있습니다. 위임할 수 있는 모든 것을 위임합니다. 일반적으로 프로젝트 관리자의 주의가 필요한 작업은 계속 수행할 수 있습니다. 예를 들어, 중요한 기능과 작업에 대해 몇 가지 QA를 수행하지만 다른 구성원의 할당에는 너무 관여하지 않습니다.

기본적으로 추정치를 신뢰한 다음 측정 및 논의

프로젝트 관리자는 팀 구성원이 작업에 대해 제공하는 견적을 신뢰해야 합니다. 프로젝트 매니저가 되기 전에 저는 4년 동안 개발자였습니다. 나는 내 주장을 뒷받침할 데이터가 없는 상태에서 개발자와 추정치에 대해 논쟁한 적이 없습니다. 그리고 데이터란 내 자신의 개발 경험이 아니라 작업에 소요된 예상 및 실제 시간에 대한 팀 구성원의 이전 기록을 의미합니다. 사람들이 작업을 평가할 때 사람들의 다양한 경험과 배경을 고려해야 합니다. 프로젝트 관리자가 추정치에 대해 논의하고 논쟁하기를 원한다면 데이터로 주장을 뒷받침하고 달성하고자 하는 것에 대해 명확해야 합니다.

민감한 정보의 투명성과 통제

프로젝트 관리자는 비즈니스와 기술을 연결하는 연결자이며 종종 양쪽의 정보를 모두 가지고 있습니다. 그들은 큰 그림을 보는 것 외에도 민감한 정보를 다루는 것과 같은 몇 가지 위험에 직면해 있습니다. 투명한 리더가 되는 것과 기밀 정보를 적절하게 처리하는 것 사이에서 미세한 선을 찾는 것이 중요합니다.

프로젝트 관리자가 최고 경영진으로 간주되지 않는 회사에서는 여전히 많은 기밀 정보에 액세스할 수 있습니다. 어떤 정보가 기밀인지 구체적으로 알려주지 않고 스스로 알아내야 하는 경우가 있습니다. 최종 목표는 팀에서 정보를 숨기지 않는 것이며 프로젝트 제공에 중요한 모든 정보는 팀의 모든 사람이 사용할 수 있어야 합니다. 그래도 일부는 팀 동기를 망치거나 불필요한 논쟁을 촉발할 수 있으므로 이유가 있어 기밀로 유지해야 합니다. 예를 들어 회사가 투자자들과 빅딜 계약을 앞두고 있다면 팀에 소식을 알리거나 거래가 확인될 때까지 특정 그룹의 사람들에게만 공개하는 옵션이 있다. 두 번째 옵션은 거래가 언제든지 옆으로 갈 수 있기 때문에 더 좋고 팀의 기대에 부응하지 못하면 동기가 떨어질 수 있습니다.

최대한의 투명성을 추구해야 하는 몇 가지 이유가 있습니다. 첫째, 다른 사람들을 커뮤니케이션 루프에 유지하면 중요한 것을 놓칠 위험이 줄어듭니다. 프로젝트 내에서 많은 논의가 있기 때문에 관리자가 일부 정보를 잘못 배치하거나 단순히 반응하는 것을 잊어버리는 경우가 있습니다. 둘째, 루프에 더 많은 사람들이 참여하면 이미 알고 있는 다른 팀원들에게 동일한 정보를 반복할 필요가 줄어듭니다.

위험에 조기에 플래그 지정

프로젝트 관리자는 팀 구성원이 모든 프로젝트 작업을 처리할 수 있도록 장애물을 제거하는 체계적인 접근 방식을 구성해야 합니다. 관리자가 스프린트 후에 차단자를 처리하지 않으면 많은 항목이 결국 백로그에서 차단된 것으로 표시될 수 있습니다. 가장 중요한 작업에서만 차단기를 제거하는 경향이 있지만, 이는 상호 의존적인 작업이 상당수 차단될 수 있으므로 잠재적으로 재앙으로 이어질 수 있습니다.

차단기 제거 전용 작업 항목 목록을 만들고 전담 이해 관계자와 함께 각 항목을 수행하는 것이 좋습니다. 낮은 수준의 차단기로 인해 어떤 높은 우선 순위 작업이 차단될 것인지 모두가 알 수 있도록 작업 간에 적절한 연결을 만드는 것도 마찬가지로 중요합니다. 결국 프로젝트 관리자는 두 가지 옵션을 갖게 됩니다. 첫째, 차단 요소 제거에 중점을 둔 우선 순위와 함께 자신의 할 일 목록을 유지할 수 있습니다. 둘째, 연결된 모든 작업에 대해 차단기를 정렬하는 종속성을 추가하여 작업에 세부 정보를 추가하고 철저하게 연결할 수 있습니다. 두 번째 옵션은 특히 큰 프로젝트에서 너무 복잡해집니다. 관리자는 작업을 계속 진행하고 제 시간에 방해 요소를 제거하기 위해 두 가지 모두를 수행하는 경우가 많습니다.

좌절과 힘든 시간에서 작은 승리까지

기한을 놓치는 것이 불가피한 경우 프로젝트 관리자는 팀에 화를 내지 않아야 합니다. 지금은 비난이 아니라 동기부여가 필요한 때입니다. 한 발 더 나아가 리더가 되십시오. 필요한 경우 자신을 탓하고 팀이 최대한의 기능을 극복하고 제공하도록 동기를 부여하십시오. 문제가 무엇인지 이해하고 이러한 차질을 다시 방지하기 위해 팀이 앞으로 어떻게 더 잘 일할 수 있는지 이해하기 위해 검토 일정을 잡으십시오.

마찬가지로 중요한 것은 작은 승리를 함께 축하하는 것입니다. 예를 들어 승인된 일정 내에 결과를 제공할 때 팀을 칭찬하기 위해 짧은 회의를 예약합니다. 누적된 작은 성공은 전체 프로젝트 성공으로 이어집니다.

문서 회의

일관된 문서화는 모든 프로젝트 관리자에게 가장 중요한 습관 중 하나입니다. 내 경험상 회의 관리는 일반적으로 과소 평가되어 결과적으로 프로젝트 관리 경력 동안 낭비적인 회의에 많은 시간을 보냈습니다. 준비는 모든 성공적인 회의의 핵심이며 대략 5분이 소요됩니다.

• 의제를 만들고 필요한 참가자를 결정합니다. 모든 참가자가 초대되었는지 확인합니다.
• 참가자들에게 의제를 보내고 다른 논의가 필요한지 확인하십시오.
• 가상 회의가 있는 경우 링크가 전송되었는지 확인하세요.

회의가 시작되면:

• 몇 분 일찍 참여하여 모두를 환영하고 인사하고 짧은 잡담 후에 의제에 직접 참여하십시오.
• 회의 중에는 메모를 하고, 모든 행동 항목을 기록하고, 안건을 처리한 후 질문이 있는지 확인하고 회의를 종료합니다.
• 회의가 끝나면 즉시 메모와 작업 항목을 팀과 공유합니다.

내 경험에 따르면 15분이 종종 1시간 또는 2시간 회의보다 더 생산적입니다. 왜냐하면 모든 사람이 요점을 유지하고 참가자가 의제에서 벗어나는 것을 방지할 수 있기 때문입니다. 중요한 논의가 없는 한.

많은 시간을 절약할 수 있는 몇 가지 보너스 팁:

• 회의록을 위한 템플릿이 있습니다.
• 가능하면 되풀이 초대장을 보냅니다.
• 작업 항목에 대한 후속 조치를 위한 템플릿을 만듭니다.
• 후속 이메일에 대한 미리 알림을 설정하세요.

올바른 도구가 차이를 만듭니다

올바른 소프트웨어 도구를 선택하는 것은 프로젝트 관리의 핵심 부분입니다. 프로젝트 관리자는 팀이 작업해야 하는 특정 도구에 대한 토론에 참여하는 것이 일반적입니다. 이러한 토론은 특정 도구로 달성하고자 하는 것이 무엇인지에 대한 팀의 이해에 따라 시간 낭비일 수도 있고 생산적일 수도 있습니다. 가장 적절한 도구를 결정할 때 고려해야 할 몇 가지 요소가 있습니다.

• 팀의 규모
• 팀 구성
• 프로젝트 방법론 또는 프레임워크
• 보고서에 포함되어야 하는 세부 정보의 양

팀 규모별로 도구 목록을 정리했습니다. 소규모 팀의 경우 특히 프로젝트 시작 단계인 경우 Trello를 사용합니다. 이 도구에는 Kanban 프레임워크에 필요한 대부분의 기능이 있습니다. 수십 명이 참여하는 중간 규모의 프로젝트를 수행할 때 Asana를 사용하는 것을 고려합니다. 일정 수준의 보고를 포함하여 몇 가지 괜찮은 프로젝트 관리 기능이 있습니다. 그러나 프로젝트에 20명 이상의 사람들과 세부적인 보고 수준이 포함되는 경우 Jira를 사용하는 경향이 있습니다. 시장에서 사용 가능한 다른 많은 솔루션과 잘 통합되어 뛰어난 사용자 정의가 가능합니다. 나는 또한 모든 중소 규모 프로젝트에 대한 나의 이동 도구로 Clubhouse를 사용하며 그곳에서 훌륭한 기능 세트를 발견했습니다.

조정이 핵심

프레임워크, 프로세스 및 도구는 팀의 필요와 어려움에 따라 조정되어야 하며 그 반대는 아닙니다. 경험을 쌓으면서 좋아하거나 싫어하거나 드물게 사용하거나 버린 도구와 방법론을 잔뜩 쌓습니다. 해가 지날수록 새로운 것이 생겨나고 오래된 것 중 일부는 구식이 될 것입니다. 그러나 리더로서 개발하는 기술을 통해 모든 프레임워크를 최대한 활용할 수 있습니다.