看板 — 간판
칸반(看板)은 일본어입니다. 글자는 다음과 같이 분해됩니다: 看(칸), 보다, 관찰하다, & 板(반): 판, 널빤지, 표지. 함께: 시각적 신호판.
이 단어는 경영 시스템보다 수세기 앞서 존재했습니다. 에도 시대 일본의 모든 가게에는 칸반이 있었습니다: 안에서 무엇을 파는지 알리는 외부의 나무 표지. 시각적 신호는 광고이자 재고 표시이자 재주문 트리거였으며, 한 번에 모두였습니다.
다이이치 오노의 슈퍼마켓 통찰
1950년대, 도요타 엔지니어 다이이치 오노는 미국 슈퍼마켓을 방문했습니다. 그가 본 것이 제조 역사를 바꾸었습니다.
전통적인 공장에서 푸시 모델은 일정에 따라 생산을 진행했습니다. 예측이 "다음 달에 500개의 단위가 필요할 것"이라고 말하면, 공장은 500개를 만들어 선반에 푸시했습니다. 수요가 잘못되면 선반이 넘쳤습니다. 수요가 예측을 초과하면 선반이 비었습니다. 어느 쪽이든, 누군가가 틀렸습니다.
슈퍼마켓은 다르게 작동했습니다. 선반에는 각 품목의 고정된 수량이 있었습니다. 고객이 마지막 땅콩버터 병을 가져갈 때, 빈 자리 자체가 재주문 신호였습니다. 재고 직원은 재주문하라고 말해줄 관리자가 필요하지 않았습니다: 선반이 그들에게 알려주었습니다. 이것이 풀 모델입니다: 하류 수요가 상류 보충을 신호합니다.
오노는 이 통찰을 도요타로 가져왔습니다. 부품 통에 부착된 물리적 카드(칸반)가 신호가 되었습니다: "이 통이 비었습니다: 더 생산하세요." 예측 불필요. 중앙 계획자 불필요. 일이 스스로를 앞으로 끌어당겼습니다.
푸시 vs. 풀
푸시/풀 구분은 그 다음에 오는 모든 것의 기초입니다.
상태로서의 열
칸반판은 일을 가시화합니다. 모든 작업 단위는 카드입니다. 카드는 상태를 나타내는 열을 통해 왼쪽에서 오른쪽으로 이동합니다.
고전적인 열은 다음과 같습니다: 백로그 → 선택됨 → 진행 중 → 검토 → 완료
그러나 정확한 열은 중요하지 않습니다. 중요한 것은 모든 카드가 정확히 하나의 현재 상태를 가지고 있고, 그 상태가 그 시스템에서 일하는 모든 사람에게 보인다는 것입니다.
카드가 나타내는 것
카드는 독립적으로 완료할 수 있는 작업 단위를 나타냅니다. 프로젝트가 아닙니다. 목표가 아닙니다. 명확한 완료 정의가 있는 구체적이고 범위가 정해진 것입니다.
좋은 카드: 프로덕션 서버에서 SSH 키 회전: 모든 서버가 authorized_keys에서 새 키를 표시하고 이전 키가 제거되면 완료.
나쁜 카드: 보안 개선. (이것은 작업이 아니라 프로젝트입니다. 분해하세요.)
WIP 제한
다이어그램의 진행 중 열은 WIP 제한: 3을 표시합니다. 이는 동시에 3개 이하의 카드만 진행 중일 수 있음을 의미합니다. 네 번째 카드를 끌어오려면, 먼저 하나를 끝내야 합니다.
이는 제약처럼 느껴집니다. 그렇습니다: 의도적으로. WIP 제한은 새로운 것을 시작하기 전에 시작한 것을 끝내도록 강제합니다. 이것이 왜 중요한지에 대해서는 이후 섹션에서 더 다룹니다.
작업 카드 범위 정하기
칸반에서 가장 어려운 기술은 판을 그리는 것이 아닙니다. 카드의 범위를 정하는 것입니다. 너무 크면 카드가 진행 중에서 몇 주 동안 머물러 다른 일을 차단합니다. 너무 작으면 판이 잡음으로 가득 찹니다.
사일로는 잘 작동합니다
어떤 다중 분야 운영도 기능적 작업 센터를 가지고 있습니다: 빵집에는 페이스트리, 빵, 짭짤한 음식, 그리고 프론트 카운터가 있습니다. 제품 스튜디오에는 디자인, 콘텐츠, 빌드, 그리고 운영이 있습니다. 건설 프로젝트에는 골조, 배관, 전기, 그리고 마감이 있습니다. 이러한 센터는 좋은 이유로 존재합니다: 깊은 전문화는 집중된 소유권을 요구합니다.
칸반은 이러한 분할을 해체하지 않습니다. 그것들 사이의 인수인계를 가시적이고 명시적으로 만듭니다.
인수인계 카드
작업 단위가 한 작업 센터에서 다른 곳으로 이동할 때, 예를 들어 빌더가 페이지를 조립하기 전에 카피가 작성되어야 하는 디자인 자산처럼, 인수인계 카드가 그것과 함께 이동합니다. 하류 센터는 자신의 백로그에서 카드가 나타나는 것을 봅니다. 그들은 용량이 있을 때 그것을 끌어옵니다. 이메일 불필요. 조율을 위한 회의 불필요. 카드가 신호입니다.
다이어그램이 보여주는 것
★ 티켓은 디자인(진행 중: 시각적 자산)에서 시작합니다. 디자인이 그들의 부분을 끝내면, 인수인계 카드가 생성되고 ★ 티켓이 빌드 센터의 백로그에 나타납니다. 빌드는 그것을 끌어옵니다. 그 다음 운영이 그것을 끌어옵니다. 각 센터는 자신의 판을 가지고 있습니다. 각 판은 그 센터의 현재 일만 보여줍니다. 그러나 ★는 그것들 모두를 통과하고, 모두가 그것이 어디에 있는지 볼 수 있습니다.
이것이 슈퍼마켓 통찰을 조직에 적용한 것입니다: 각 작업 센터는 선반입니다. 카드는 상류 작업이 끌어와져 소비될 때만 하류 선반을 다시 채웁니다.
인수인계 설계
인수인계 카드는 작업 센터 간의 계약입니다. 받는 팀이 회의 없이 행동할 수 있도록 충분한 맥락을 포함해야 합니다.
시작을 멈추세요. 끝내기를 시작하세요.
WIP는 진행 중인 작업(Work In Progress)의 약자입니다. WIP 제한은 한 번에 주어진 열에 있을 수 있는 카드 수의 상한입니다.
이것은 제한처럼 들립니다. 그렇습니다. 그것이 핵심입니다.
제한이 도움이 되는 이유
이전 작업을 끝내지 않고 새 작업을 시작할 때마다, 당신은 컨텍스트 전환 세금을 지불합니다. 당신의 뇌는 새 작업의 컨텍스트를 로드하고 이전 것을 부분적으로 언로드합니다. 당신이 이전 작업으로 돌아갈 때, 당신은 그것을 다시 로드합니다. 지식 노동, 글쓰기, 디버깅, 디자인, 검토의 경우, 이 다시 로드 비용은 초가 아니라 시간 단위로 측정됩니다.
WIP 제한은 절반이 끝난 작업의 축적을 방지합니다. 그것들은 또한 더 가치 있는 일을 합니다: 병목을 표면화합니다.
병목이 가시화됩니다
검토 열의 WIP 제한이 2이고 항상 2에 있다면, 그것은 신호입니다: 검토가 생산보다 느립니다. 더 많은 일이 진행 중에서 완료되고 있고 검토에서 소비될 수 있는 것보다 더 많이. WIP 제한 없이는, 판이 '완료-하지만-검토-대기' 카드로 채워지고 병목이 보이지 않습니다. WIP 제한과 함께라면, 진행 중 열은 새 카드를 받아들일 수 없고, 전체 팀이 제약을 봅니다.
이것은 실패가 아닙니다. 정보입니다. 시스템이 당신에게 검토를 고치라고, 고용하라고, 짝을 이루라고, 배치 크기를 줄이라고 말하고 있습니다, 더 많은 일을 맹목적으로 통과시키는 대신.
리틀의 법칙(비공식적으로)
리드 타임(카드가 시작에서 완료까지 걸리는 시간) = 진행 중인 작업 ÷ 처리량(단위 시간당 완료된 카드). 고용 없이 리드 타임을 단축하고 싶다면, WIP를 줄이세요. 비행 중인 것이 적을수록 각각이 더 빨리 완료됩니다.
R = (W × C) + T
WIP 제한은 세 가지 변수를 보호합니다. 효율 컨설턴트 브라이언 트레이시는 1986년에 그것들을 명명했습니다.
R = (W × C) + T
- R: 결과: 당신이 원하는 결과
- W: 목표의 명확성: 당신이 원하는 것을 얼마나 정확하게 아는가 (0–10)
- C: 집중: 집중된 노력의 강도 (0–10)
- T: 방해 없이 작업한 시간 (중단 없는 시간)
W와 C가 곱해지는 이유
명확성과 집중은 독립적이지 않습니다. 모호한 목표에 대한 높은 집중은 잘못된 방향으로 빠르게 움직이는 결과를 낳습니다. 집중 없는 완벽한 목표 명확성은 아무것도 만들어내지 않습니다. 그것들은 상호작용합니다: 그래서 트레이시는 그것들을 합이 아니라 곱으로 썼습니다. 각각에 9/10이면 R = 81 + T입니다. 각각에 3/10이면 R = 9 + T입니다. 차이는 가산적이지 않습니다.
T가 더해지는 이유
모든 방해 없는 시간은 결과에 선형적으로 추가됩니다. T는 W와 C를 복합화할 수 없습니다: 그것은 곱 위에 쌓일 수만 있습니다. 이것이 첫 번째 움직임이 항상 더 오랜 시간 일하는 것이 아니라 W와 C를 개선하는 것인 이유를 설명합니다. 낮은 (W × C) 곱에 더 많은 T는 여전히 형편없는 결과입니다.
칸반판이 각 변수에 하는 일
- W: 잘 범위가 정해진 카드(명확한 제목, 측정 가능한 수용 기준, 단일 소유자)는 작업이 시작되기 전에 W를 높입니다. 모호한 카드는 자동으로 그것을 낮춥니다.
- C: WIP 제한은 집중을 강요합니다. 활성에 한 카드는 한 문제에 완전한 주의를 의미합니다. 활성에 세 카드는 C가 세 가지로 나뉘는 것을 의미합니다.
- T: 포모도로 블록과 캘린더 보호는 T가 측정하는 방해 없는 시간을 만듭니다. 판 타이머는 장식이 아닙니다: 그것은 실시간으로 T를 추적합니다.
트레이시는 W, C, & T가 모두 최적화되었을 때 어떤 문제든 30분 안에 해결될 수 있다고 주장했습니다. 칸반판은 셋 모두를 동시에 최적화하기 위한 도구입니다.
판 읽기
판 상태에서 병목을 읽는 연습을 합니다.
애자일도 아닙니다. 워터폴도 아닙니다.
애자일은 방법론입니다. 워터폴은 방법론입니다. 칸반은 시스템입니다.
방법론은 어떻게 일해야 하는지를 규정합니다. 시스템은 업무에 대해 무엇이 사실인지를 설명합니다. 칸반은 2주 스프린트, 일일 스탠드업, 또는 회고를 가져야 한다고 말하지 않습니다. 한 가지를 말합니다: 업무를 가시화하고, WIP를 제한하고, & 당기세요.
방법론의 문제
애자일은 제품을 반복적으로 구축하는 팀에 잘 작동합니다, 소프트웨어, 주로. 워터폴은 고정된 요구사항과 알려진 알 수 없는 것이 있는 프로젝트에 잘 작동합니다, 건설, 하드웨어 제조. 어느 것도 디자인 작업과 이행 작업이 완전히 다른 주기 시간과 '완료'의 정의를 가진 기능 간 업무에 깔끔하게 매핑되지 않습니다.
디자인 센터와 운영 센터를 같은 스프린트 리듬에 강제하는 것은 카테고리 오류입니다. 콘텐츠 제작에 잘 작동하는 2주 스프린트는 물류 업무에 인위적인 긴박감을 생성합니다. 함께 위치한 팀을 위해 구축된 스탠드업 의식은 독립적인 솔로에게 오버헤드를 생성합니다.
해야 할 업무에 대한 공통 기반 찾기
un 접근 방식: 해야 할 업무를 찾습니다. 그것을 수행하기에 가장 좋은 위치에 있는 사람이나 파트너를 찾습니다. 그 위에 프로세스를 부과하지 마세요: 공유 가시성 시스템을 통해 업무가 자신의 프로세스를 표면화하도록 하세요.
이것은 프로세스의 부재가 아닙니다. 올바른 양의 프로세스입니다: 조율하기에 충분하고, 업무의 가치를 초과하는 조율 오버헤드를 만들지 않을 만큼.
구매할 수 있는 것을 구축하지 마세요. 성장시킬 수 있는 것을 구매하지 마세요.
업무 카드가 생성되기 전에 물어보세요: 이것이 전혀 존재해야 합니까? 구축하는 모든 업무는 영원히 소유합니다. 구독하는 모든 SaaS는 영원히 의존합니다. 포크하는 모든 오픈소스 의존성은 영원히 유지합니다.
결정 트리: 우리가 이것을 성장시킬 수 있습니까? 기능을 지속 가능하게 생산하는 프로세스, 기술, 관계를 선호하세요. 성장이 실행 가능하지 않은 경우: 우리가 이것을 구매할 수 있습니까? 맞춤 작업 없이 문제의 80%를 해결하는 기성품 도구를 선호하세요. 구매가 실행 가능하지 않은 경우: 구축하세요. 그리고 이제 소유한다는 것을 알고 구축하세요.
대부분의 조직은 이 순서를 반전시킵니다. 그들은 상품 도구가 잘 해결하는 문제에 대한 맞춤 인프라를 구축하고, 그런 다음 구축한 것을 유지하기 위해 허둥댑니다. 칸반은 이것을 가시화합니다: 백로그의 모든 카드는 구축하기로 선택한 것입니다. 솔직한 질문은 그것이 전혀 거기에 있어야 하는지 여부입니다.
구축 / 구매 / 성장
결정 프레임워크를 적용하세요.
판 설계
그것을 함께 넣으세요. 특정 부서 간 시나리오에 대한 칸반 시스템을 설계할 것입니다.
시나리오
작은 스튜디오는 새로운 브랜드로 제품을 다시 출시하고 있습니다. 일은 네 개의 센터를 포함합니다:
- 디자인: 새로운 로고, 시각적 정체성, 제품 사진, 페이지 레이아웃
- 콘텐츠: 다시 작성된 제품 설명, 랜딩 페이지 텍스트, 이메일 공지
- 빌드: 업데이트된 웹사이트, 새로운 결제 흐름, 이전 URL에서의 리디렉션
- 운영: 업데이트된 결제 처리 설정, 이행 파트너 브리핑, 분석 재구성
다시 출시에는 하드 마감이 있습니다: 새로운 브랜드가 공개되는 45일 내 무역 박람회.
솔로는 부서로 남아 있습니다
대부분의 조직에서, 칸반은 경영 계층 전체의 업무를 가시화하기 위해 존재합니다. 관리자는 부서 간을 조율합니다. 칸반은 조율 오버헤드를 줄입니다.
un 모델에서는 관리자가 없습니다. 솔로가 있습니다. 솔로는 독립적으로 엔터프라이즈를 운영합니다: 디자인 솔로, 빌더 솔로, 작가 솔로, 운영 솔로. 각 솔로는 정의에 따라 부서입니다. 그들을 연결하는 조직도가 없습니다. 보고 관계 없음. 그들을 조율하도록 강제할 관리자 없음.
칸반은 조율 레이어가 됩니다. 부서를 평탄화하지 않음으로써, 솔로는 완전히 독립적으로 남아 있고, 그들 사이의 인수인계를 눈에 띄게 & 명시적으로 만듭니다. 솔로는 이메일을 보내거나 회의를 예약하여 업무를 인수인계하지 않습니다. 그들은 공유된 판에 카드를 놓습니다. 받는 솔로는 용량이 있을 때 그것을 당깁니다.
이것은 칸반이 un 모델보다 민첩성이나 폭포보다 더 잘 맞는 이유를 설명합니다: 공유 주기가 필요 없고, 공동 회고가 없고, 동기화된 계획이 없습니다. 각 솔로는 자신의 WIP 제한, 자신의 주기 시간, 자신의 완료 정의를 설정합니다. 조율은 카드 수준에서 발생하고, 프로세스 수준이 아닙니다.