민첩한 사례를 위한 조직 구조 정의
대부분의 조직에서 민첩하게 재구성하는 것은 어려운 일입니다. 조직 내의 많은 기존 정책, 프로세스 및 권력 구조에 도전하는 근본적인 사고 방식의 변화와 문화적 변화가 필요합니다.
조직 변환 과제
조직, 특히 대기업의 훌륭한 거버넌스는 종종 다음으로 이어집니다.
- 의사 결정을 느리게 하는 엄격한 계층 구조
- 속도보다 규정 준수의 우선 순위를 지정하는 프로세스 작업이 많은 워크플로
- 실험을 억제하는 위험 회피 문화들
- 전역이 아닌 로컬로 최적화하는 사일로드 부서
대부분의 대규모 조직은 민첩한 구조로 완전히 이동하지는 않았지만, 대부분은 다음과 같은 이유로 하이브리드 접근 방식을 실험하고 있습니다.
- 비즈니스 환경이 점점 더 불안정 해지고 복잡해지고 있습니다.
- 기존 시스템은 신속한 변경 요구 사항으로 어려움을 겪고 있습니다.
- 신생 기업들은 민첩한 접근 방식을 통해 기존 산업을 정기적으로 방해합니다.
- 고객의 기대는 더 빠른 혁신과 대응을 요구합니다.
문화 변환 전략
계층 구조에서 네트워크로
기존 접근 방식: 여러 승인 계층을 사용하는 하향식 의사 결정 Agile 접근 방식: 명확한 책임으로 분산된 의사 결정
구현 단계:
- 팀에 위임할 수 있는 의사 결정 지점을 식별하세요.
- 자율 의사 결정을 위한 명확한 경계 설정
- 팀 기관 외부의 의사 결정에 대한 에스컬레이션 경로 만들기
- 컨트롤러 가 아닌 코치가 되도록 관리자를 훈련시킵니다.
프로세스에서 결과로
기존 접근 방식: 결과와 무관하게 정의된 프로세스를 따름 애자일 접근 방식: 프로세스를 조정하면서 결과에 최적화
주요 변경 내용:
- 작업 완료를 통해 비즈니스 가치 전달에 집중
- 고객 만족도 및 비즈니스 메트릭별 성공 측정
- 팀이 작동하지 않는 프로세스를 수정할 수 있도록 지원
- 개선 사항을 식별하고 구현하는 정기적인 회고전
팀 구조 모델: 가로 및 세로
수평 팀(기존)
수평 팀 구조는 기술 계층 또는 소프트웨어 아키텍처 구성 요소에 따라 팀을 나눕니다. Teams는 비즈니스 기능이 아닌 기술 전문 분야로 구성됩니다.
예제 구조:
- UI 팀: 프런트 엔드 개발자, UX 디자이너
- 서비스 팀: 백 엔드 개발자, API 전문가
- 데이터 팀: 데이터베이스 관리자, 데이터 엔지니어
수평 팀의 과제:
- 통신 오버헤드: 기능을 사용하려면 여러 팀 간에 조정이 필요합니다.
- 책임 전가: 문제는 종종 "팀 사이"에 해당합니다.
- 느린 배달: 종속성으로 인해 병목 상태 및 지연이 생성됩니다.
- 제한된 비즈니스 컨텍스트: Teams는 사용자 가치에 대한 기술적 문제에 초점을 맞춥니다.
수직 팀(권장)
수직 팀 구조는 전체 기술 스택에 걸쳐 있으며 비즈니스 기능 또는 고객 가치 스트림과 일치합니다.
예제 구조:
- 이메일 팀: 전체 스택 개발자, UX 디자이너, 데이터 전문가
- 음성 팀: 전체 스택 개발자, UX 디자이너, 인프라 전문가
- TV 팀: 전체 스택 개발자, UX 디자이너, 플랫폼 엔지니어
수직 팀의 이점:
- 엔드 투 엔드 소유권: Teams는 전체 기능을 독립적으로 제공할 수 있습니다.
- 빠른 배달: 종속성 및 핸드오프 감소
- 더 나은 책임: 아이디어에서 프로덕션으로 소유권 지우기
- 고객 포커스: Teams는 비즈니스 컨텍스트 및 사용자 요구 사항을 이해합니다.
- 품질 향상: Teams는 전체 사용자 환경을 담당합니다.
수직 팀 크기 조정
수직 팀은 여러 수평 팀에서 조정하는 대신 전체 팀을 추가할 수 있으므로 더 효과적으로 확장할 수 있습니다. 프로젝트 팀 대신 장기 소유권이 있는 기능 팀을 만듭니다.
크기 조정 원칙:
- 팀 크기: 효과적인 커뮤니케이션을 위해 팀을 작게(5~9명) 유지
- 콘웨이의 법칙: 소프트웨어 아키텍처가 팀 구조를 반영합니다.
- 핸드오프 최소화: 각 팀이 독립적으로 제공할 수 있어야 합니다.
- 공유 서비스: 일반적인 요구 사항이 있는 기능 팀을 지원하는 플랫폼 팀 만들기
