Close

복잡한 소프트웨어 프로젝트 관리


제품, 플랫폼 및 교차 기능 팀이 한데 모이는 소프트웨어 프로젝트를 관리해야 합니다. 말도 안 되게 복잡한 프로젝트를 다루는 데 필요한 원칙과 관행에 대해 알아보세요.

이 플레이를 사용하여...

멋지게 시작하고 높은 추진력을 유지합니다.

경력에서 한 번 있을 만한 획기적인 프로젝트를 제공할 가능성을 높입니다.

If you're struggling with shared understanding or velocity on your Health Monitor, running this play might help.

Copy link to heading Copied! 자세히 보기
이것이 필요한 이유

여러분은 회사에서 매우 복잡한 미션 크리티컬 기술 프로젝트를 이끌어 달라는 요청을 받았습니다. CEO는 이 프로젝트에 대해 생각하느라 밤에 잠도 줄이고 있으며, 프로젝트는 다음 중 하나 이상과 관련이 있을 것입니다.

  • 플랫폼 또는 여러 제품에 걸친 공통 컴포넌트 통합
  • 여러 팀 또는 부서 간의 협업(일부는 이전에 함께 일한 적 없음)
  • 중대한 기술적 위험
  • 서로 다른 팀 간의 많은 종속성
  • 여러 시간대에 있는 팀
  • 촉박한 타임라인
  • 고위 이해 관계자에 의한 집중 조사

대규모의 가시성 높은 프로젝트에서 신뢰를 받으신 것을 축하합니다. 여기는 인적이 드문 지역이며 용감한 자만 들어가고 약간 정신을 놓아야만 살아서 나올 수 있습니다. 약간 변형을 준 플레이가 필요합니다!

참여 대상

프로젝트 관리자로서 독립적으로 이 플레이를 읽어본 다음 정말 중요한 부분에 초점을 맞춰서 프로젝트 계획을 다시 수립하세요.

그런 다음 프로젝트 후원자 및 이해 관계자와 함께 진행하세요(성공하리라는 것을 알릴 수 있도록).

어떤 소프트웨어 프로젝트는 믿기지 않을 정도로 정말 복잡합니다. 그러한 프로젝트를 관리하는 방법을 알아보세요.
사용자 팀
인력

1

측정 시계
시간

60분

난이도 쉬움
난이도

어려움

플레이 실행

한 시간을 들여 표준 프로젝트 관리에서 한발 더 나아가도록 준비를 갖추고 도전을 받아들이고 완벽하게 해낼 준비를 하세요!

준비물

기존 계획

빨간색 펜

낙관적인 사고 방식

원칙 1

의식적인 협업

같은 공간에서 계획하세요 – 프로젝트에 참여하는 모든 팀이 계획 프로세스에 참여해야 하며 같은 공간에 있어야 합니다. 계획을 잘못 세우는 것으로 인한 비용에 비하면 이동 비용은 극히 일부분에 불과합니다.

참여 규칙에 미리 합의하세요 – “플랫폼 팀이 통합 작업을 합니까?” 및 "마케팅, 지원 및 운영 팀과 같은 팀을 어떻게 참여시킬 것입니까?"와 같은 질문에 답하세요.

팀 간에 교차 분배하세요 – 임시 파견, 교대, 포함된 팀 또는 심지어 통합된 팀도 위험을 줄이고 성과를 거두는 효과적인 방법입니다. 팀 간에 공감과 신뢰를 쌓는 장점도 있습니다.

롤아웃, 마이그레이션 및/또는 채택을 계획하세요 – 이 프로젝트를 고객에게 제공하는 방법을 확실히 파악하세요. 계획을 팀 및 이해 관계자와 공유하고 최신 정보를 제공하세요. 롤아웃 시뮬레이션을 실행하여 테스트해 보고 확신을 얻으면 더욱 좋습니다.

채택을 지원하고 보상을 제공하세요 – 해결해야 할 문제와 수정 사항이 있을 것입니다. 플랫폼 서비스를 구축하는 경우 예산을 조금 아껴 두었다가 이것을 처음으로 채택하는 첫 제품 측 팀을 지원하세요.

조직도에 신경 쓰지 마세요 - 전담 프로젝트 조직 내에서 프로젝트가 진행되는 동안 회사 전체의 팀을 한데 모으세요.

이렇게 하면 다음과 같은 상황을 방지할 수 있습니다...

  • 팀 간에 로드맵 및 우선 순위를 다시 정렬하기 위해 시간을 낭비
  • 계획을 수립한 후 다른 팀이 추가적으로 참여
  • 비생산적인 회의
  • 고통스러울 정도로 오래 걸리는 의사 결정
  • 플랫폼이 실제로 작동할지에 대한 의구심
다음과 같은 경우 효과가 있는 것입니다...
  • 팀이 서로를 믿습니다
  • 팀의 목표와 로드맵이 정렬되었습니다
  • 팀 간의 참여 모델 및 리소스 계획을 명확하게 이해합니다
원칙 2

공통된 이해

"왜" 및 "무엇"을 명확하게 설명하세요 – 모두가 정렬되도록 하나의 팀으로서 공동으로 목표를 설정하세요. 가능한 경우 플랫폼 팀은 제품 이니셔티브에 대해 우선 순위를 쉽게 정할 수 있도록 비즈니스 가치 측면에서 이니셔티브를 제안해야 합니다.

범위 및 진행률의 가시성을 유지하세요 – 로드맵을 공유하고 최신 상태로 유지하세요. 범위 및/또는 타임라인의 변경 사항(많을 것입니다!)에 대해 팀에 사전에 알리세요.

이렇게 하면 다음과 같은 상황을 방지할 수 있습니다...

  • 팀이 프로젝트에 동의하지 않음
  • 결정이 지연되거나 득과 실 논의에서 실수가 발생
  • 합의한 범위에 대해 리소스가 부족
  • 낭비되는 일 또는 중복된 노력과 같은 일상적인 조정 문제
다음과 같은 경우 효과가 있는 것입니다...
원칙 3

명확한 책임 의식

"관리" 작업 – 프로젝트의 전임 소유자를 할당하세요(이 글을 읽고 있다면 아마 여러분일 것입니다!). 경영진 후원자에게 내부적으로 프로젝트 홍보를 요청하고 병목 현상이 발생하면 문제를 해결할 수 있도록 대기하세요.

기술적인 작업 – 프로젝트 팀에 교차 제품 아키텍트를 포함하여 높은 수준의 설계 및 구현 문제를 처리할 수 있도록 하세요. 전체적인 고객 경험(예: 플랫폼 또는 제품)의 소유자 및 각 주요 산출물의 소유자에 합의를 이루세요.

매핑하세요 – 전체 프로젝트 팀(또는 각 하위 팀의 담당자)과 함께 역할 및 책임 플레이를 실행하세요. 각 하위 팀 내에서도 실행하면 더욱 좋습니다.

이렇게 하면 다음과 같은 상황을 방지할 수 있습니다...

  • 팀원이 서로의 영역을 침범
  • 일반적으로 병목 현상을 발생시킴
  • 작업을 놓치는 경우
  • 범위 또는 타임라인 변경에 대한 업데이트를 받지 못해 답답해 하는 후원자
다음과 같은 경우 효과가 있는 것입니다...
  • 결정이 빠르게 내려집니다
  • 이해 관계자는 질문이 있을 때 누구에게 연락해야 하는지 알고 있습니다
  • 전임 소유자가 매주 업데이트를 전달합니다
  • 산출물이 제때 제공됩니다
원칙 4

신뢰

적합한 관계자를 모으세요 – 신뢰를 빠르게 쌓고 긍정적인 태도를 가진 최고의 커뮤니케이션 담당자, 통합 담당자를 모으세요. 세부 사항과 긴급성에 높은 주의를 기울이는 인력이 필요합니다.

영업 비밀을 교환하세요 – 플랫폼 팀이 고객에 대한 제품 팀의 풍부한 지식을 활용하도록 권장하세요. 브라운 백 프레젠테이션, 내부 블로그, 점심 식사 등을 통해 제품 팀이 플랫폼 작업 속도를 높일 수 있도록 하세요.

추진력을 쌓으세요 – 사기를 북돋고 팀 서로에 대한 신뢰를 공고히 하기 위해 초반에 간단한 성과를 공유하세요. 그리고 상태 모니터 세션을 매달 실행하는 것도 잊지 마세요!

이렇게 하면 다음과 같은 상황을 방지할 수 있습니다...

  • 잦은 장애물 및 약속 위반

  • 의욕 없는 문제 해결

  • 낮은 사기

다음과 같은 경우 효과가 있는 것입니다...
  • 팀이 서로와 함께 일하는 것을 좋아합니다
  • 마일스톤을 함께 축하하고 커뮤니케이션합니다
  • 대인 관계 또는 협업 문제가 공개적으로 논의되고 신속하게 해결됩니다
원칙 5

공동의 마일스톤

진행률을 추적하세요 – 프로젝트 타임라인을 공유하고 단일 정보 출처로 활용하세요. 매주 조정이 필요하더라도 실제 상황을 반영하도록 최신 상태로 유지하세요. 조정은 매주 필요할 것입니다.

조금씩 점진적으로 제공(그리고 축하)하세요 – 속도와 사기를 높게 유지하는 데 도움을 주는 치어리더 역할을 맡을 프로젝트 팀원을 모집하세요.

Collectively own quality – Build integration and testing time into the plan, and make sure your "definition of done" is agreed upon and documented.

이렇게 하면 다음과 같은 상황을 방지할 수 있습니다...

  • 테스트 중에 예기치 못한 일 발생
  • 진전이 느리거나 없음
  • 산출물 및 제공 날짜가 잘못 정렬
다음과 같은 경우 효과가 있는 것입니다...
  • 이해 관계자가 꾸준한 진행률에 만족합니다

  • 고객은 프로젝트가 완료되기 훨씬 전부터 이점을 얻기 시작합니다

  • 오버헤드가 거의 없이 예상보다 빨리 플랫폼에서 가치를 얻고 있습니다

원칙 6

효과적인 결정

심사숙고하세요 – 장기적 영향과 단기적 영향을 모두 고려하세요. 누가 결정을 내려야 하는지 신중하게 생각하세요. 단순하게 전임 소유자 또는 경영진 스폰서가 가장 적합하다고 생각하지 마세요.

효율성을 위해 최적화하세요득과 실 슬라이더 플레이를 실행하면 팀원과 팀이 일상적인 결정을 자율적으로 내릴 수 있습니다. 주요 결정을 내리는 경우에는 DACI 프레임워크를 사용하세요.

체계화하고 커뮤니케이션하세요 – 의사 결정 장부를 마련하여 결정하려는(또는 결정된) 사항을 추적하고 주간 프로젝트 커뮤니케이션에서 참조하세요.

이렇게 하면 다음과 같은 상황을 방지할 수 있습니다...

  • 숨겨진 정보가 너무 많아서 결정을 내릴 때마다 팀의 확신이 더 없어짐
  • 오래되었거나 잘못된 정보를 바탕으로 해결책 또는 기간을 고려
  • 같은 결정을 여러 번 수정하고 다시 검토
다음과 같은 경우 효과가 있는 것입니다...
  • 결정이 빠르게 내려집니다
  • 하나의 결정을 받아들이기 전에 다양한 의견을 듣습니다
  • 결정한 사항은 다시 논의되거나 이의가 제기되지 않습니다
원칙 7

종속성 관리

병목 현상을 예상하세요 – 팀이 누구에게 의존하고 누가 팀에 의존하는지 나타내는 표 또는 다이어그램을 만드세요.

계속 주시하세요 – 각 종속성을 관리하는 소유자를 각 측에서 한 명씩 할당하세요. 종속성 소유자가 모든 업스트림 및 다운스트림 팀에 대한 변경의 영향을 파악하고 전달하도록 하세요.

이렇게 하면 다음과 같은 상황을 방지할 수 있습니다...

  • 다운스트림이 지연되고 마일스톤을 놓침
  • 불만, 혼란 및 스트레스로 인한 긴장
다음과 같은 경우 효과가 있는 것입니다...
  • 종속성을 추적할 수 있는 간결하고 포괄적인 셀프 서비스 방법이 마련되어 있습니다

  • 종속성을 맵이 또는 차트로 시각화할 수 있습니다

원칙 8

커뮤니케이션하고 조정하고 축하하세요!

공동의 커뮤니케이션 계획을 수립하세요 – 매주: 일반 프로젝트 업데이트를 위한 대면 회의, 격주: 데모, 이해 관계자를 위한 상태 업데이트, 매달: 상태 모니터, 프로젝트 "전체 회의" 또는 이와 비슷한 계획을 수립하세요. 엔지니어링 관리자, PM 및 아키텍트에게 도움을 요청하여 커뮤니케이션을 전달하세요.

프로젝트 회의를 최대한 활용하세요 – 주간 회의에 10분 데모 또는 문제 해결 세션을 포함하여 참여도를 유지하세요.

일대일로 동기화하세요 – 매주 또는 격주로 각 작업 스트림의 팀 리더 및 제품 관리자와 회의를 진행하여 일정 대비 진행률을 확인하고 일정의 변경 사항을 파악하고 새로운 위험이나 문제에 대해 논의하고 팀 사기에 대해 이야기하세요.

찾기 쉽게 만드세요 – HipChat 룸이나 Confluence 페이지를 Q&A 및/또는 문제 에스컬레이션을 위한 포럼으로 만드세요.

작은 성과라도 축하하세요 – 생각보다 빠르게 눈덩이처럼 불어나 큰 성과가 됩니다!

이렇게 하면 다음과 같은 상황을 방지할 수 있습니다...

  • 팀원이 더 큰 그림을 파악하지 못함
  • 사기가 낮고 번아웃이 심함
  • 목적이 분명하지 않고 비생산적인 회의
  • 이해 관계자가 상태, 위험, 마일스톤 날짜 등의 변경 사항을 모른다고 느낌
다음과 같은 경우 효과가 있는 것입니다...
  • 이해 관계자가 상태 업데이트를 받기를 기대합니다
  • 팀원이 큰 그림을 잘 파악하고 있습니다
  • 추진력이 쌓여서 멈출 수 없게 됩니다

성공하셨습니까?

팀과 함께 전체 상태 모니터 세션 또는 체크포인트를 실행하여 개선을 이루고 있는지 확인하세요.

변형

  • 누가 누구인지 모두가 알 수 있도록 이해 관계자 목록을 많은 팀원과 공유하세요.
  • 기존의 독립적인 계획을 조정하려는 유혹을 뿌리치세요. 처음부터 시작해서 모든 팀이 참여하는 통합 계획을 세우는 것이 훨씬 낫습니다.
  • 미리 함께 계획하는 데 더해 프로젝트 전반에 걸쳐 지속적으로 함께 계획을 다시 세우는 것을 기억하세요.
  • 조직도에 얽매이지 말고 팀을 한데 모으세요.
  • 각 팀이 작업하는 교차 제품 프로젝트 수를 제한하세요.
  • 모든 팀이 프로젝트 외 시간을 일정에 따로 포함하도록 하세요(예: 컨퍼런스, 휴가, 회사 행사, 기타 회의 등).

후속 조치

아마 프로젝트 계획에서 약간의 격차를 발견하고 접근 방식을 어떻게 변경할지에 대한 아이디어가 있을 것입니다.

여기서 중요한 점은 작업을 더 추가하지 않는 것입니다!

가치를 더하지 않는 활동을 중단하거나 회의를 취소하고 그 시간은 선택한 활동을 위해 사용하세요.

더 많은 플레이북을 보고 싶습니까?

새로운 상태 모니터 및 플레이를 추가할 때 통보할 이메일을 아래에 입력 후 전송해주세요.

Thanks! Now get back to work.

의견이 있으십니까?

Atlassian 커뮤니티 사이트에 질문이나 의견을 남겨주세요.