“낭비”를 없앨 수 있도록 조직에서 가치를 창출하고 고객에게 제공하기 위해 진행할 단계를 시각화합니다. 일반적인 사용 사례는 운영 및 제품 개발 수명주기에 이르는 길입니다.
단계
제안 시간
1~2시간
참가자
핵심 팀, 실무 전문가(필요한 경우)
수행 이유
- 지연, 불필요한 기능 및 핸드오프를 확인하여 사용자 및/또는 비즈니스 가치를 더 빠르게 및/또는 더 자주 제공할 수 있는 방법을 파악하기 위해서입니다.
- 공동 작업을 개선하고 잠재적인 방해물을 차단할 수 있도록 프로세스와 관련된 단계 및 사람들을 파악하기 위해서입니다.
수행 시기
이 활동은 많은 팀이 하나의 시스템을 만드는 데 우려가 있거나 제품 개발 수명주기에 알려진 문제가 있는 경우 킥오프 초기에 수행할 수 있습니다. 또는 기술 검색, 프레이밍의 일부로 수행하거나 팀이 비효율적인 프로세스로 교착 상태에 빠진 경우 언제든지 수행할 수 있습니다.
필요한 물품
- 화이트보드 또는 Miro와 같은 디지털 버전
- 스티커 메모
- 네임펜/마커
이 방식을 활용하는 방법
샘플 안건 및 메시지
워크숍의 목적을 설명합니다.
제품 개발 수명주기를 예로 사용합니다. 다음과 같이 말할 수 있습니다.
“제품 개발 수명주기를 확인하기 위해 사용자가 피드백을 제공하는 순간부터(예: 스토리 작성) 운영 시 배포까지 기능을 따라가 보겠습니다. 향후 상태 전에 현재 배포 프로세스에 집중하겠습니다. 현재 어떤 일이 발생하고 있는지 파악하는 것이 실제 방해 요소를 신속하게 밝히고 이해관계자에게 이상적인 워크플로우를 빠르게 제시할 수 있기 때문입니다. 또한 단계뿐만 아니라 각 단계의 역할과 리드 타임도 알아보겠습니다.”
현재 제품 개발 프로세스로 시작합니다. 화이트보드 한쪽 끝이나 디지털 공동 작업 보드의 섹션에 선택한 가치 스트림의 첫 번째 단계를 적습니다. 다른 쪽 끝에 마지막 단계를 적습니다.
제품 개발 수명주기에 대해 첫 번째 단계로 “사용자 피드백”을 적고 마지막 단계로 “운영 환경에 릴리스”를 적습니다.
팁: 팀이 엔드포인트를 결정하는 데 문제가 있는 경우 “이 여정에 대한 작업이 언제 끝날까요?”와 같은 질문을 하십시오.
그룹이 가치 스트림의 처음부터 끝까지 발생하는 개괄적인 단계를 가능한 한 자세하게 파악하도록 합니다. 스티커 메모에 각 단계를 적고 화이트보드에 순서대로 배치합니다. 필요한 경우 반복합니다.
팁: 이상적으로 처음부터 끝까지 이동할 수 있겠지만, 스티커 메모를 간편하게 이동시킬 수 있으므로 순서에 얽매이지 마십시오. 팀으로서 아이디어를 내기 시작합니다.
그룹이 모든 개괄적인 단계를 올바른 순서로 파악했다고 만족하면 이 흐름을 다시 반복합니다. 이번에는 다른 스티커 메모 또는 화이트보드의 각 단계에 대해 다음과 같은 정보를 파악합니다.
- 이 단계에서는 무슨 일이 발생하는가?
- 이 단계는 어디서 발생하는가?
- 이 단계는 누가 담당하는가? (예: 자동인가 수동인가, 언제 참여해야 하는가, 직원인가 제3자인가)
- 이 단계는 언제 발생하는가? (예: 진행되려면 어떤 일이 발생해야 하는가)
- 이 단계는 얼마나 지속되는가? (예: 프로세스 시간)
- 리드 타임은 얼마나 필요한가?
- 이 단계에 관한 효과적인 부분이나 문제 부분은 무엇인가?
- 이 단계가 완료되었는지 어떻게 알 수 있나?
- 전체 가치 스트림은 얼마나 지속되며 팀은 이에 대해 어떻게 생각하나?
팁: 위 질문은 예시입니다. 컨텐츠에 적합한 모든 “렌즈 데이터”를 사용하여 문제를 전체적으로 파악하십시오. 핸드오프를 신경 쓴다면 명확하게 파악하십시오. 시스템 터치 포인트를 시각화하고 싶으십니까? 서비스 Blueprint 형식의 세부 사항을 포함하십시오. 간단히 말해서 중요한 사항을 파악하십시오.
팀이 뒤로 물러서서 흐름을 검토하고 잘못된 점을 조정하도록 합니다.
가치 스트림 맵이 현재 프로세스의 적절한 가상화라고 생각하면 전체 프로세스의 총 리드 타임을 계산하고 팀과 함께 토론하여 개선할 영역을 찾습니다.
“향후” 프로세스에 대해 2~6단계를 반복합니다.
성공/예상되는 성과
화이트보드에 시각적 가치 스트림이 있고 팀이 현재 프로세스를 정확하게 나타내고 있다고 확신한다면 성공한 것입니다.
진행자 메모 및 팁
일부 팀은 프로세스에서 “낭비”라고 불리는 아이디어에 민감합니다. 이 활동의 목적을 규정하는 또 다른 방법은 효율성을 높이는 기회로 삼는 것입니다.
제품 개발 관련 7가지 낭비
- 부분적으로 수행한 작업(릴리스할 수 없기 때문에)
- 추가 기능(지금 당장 또는 아마도 항상 필요하지 않기 때문에)
- 재학습(새로운 것을 배우고 작동하는 소프트웨어를 릴리스하느라 시간을 빼앗기기 때문에)
- 핸드오프(대기로 이어지고 커뮤니케이션이 추가되기 때문에)
- 지연(팀의 작업 속도를 늦추기 때문에)
- 작업 전환(집중을 흐리고 작업 속도를 느리게 만드는 컨텍스트 전환으로 이어지기 때문에)
- 결함(작업 주기를 추가하기 때문에)
변형
운영 환경 경로 연습
실제 예시
제품 개발 수명주기 예시
권장 자료
Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation(저자: Mike Osterling & Karen Martin)
The Seven Wastes of Software Development - Michael Szul의 블로그 게시물
Software Development Waste - Todd Sedano의 학회 논문
Lean Software Development: An Agile Toolkit(저자: Mary Poppendieck & Tom Poppendieck)
DevOps Processes: Value Stream Mapping(Mandy Storbakken 작성)
