왜 프로젝트는 항상 지연될 수 밖에 없는가
제약이론으로 살펴 본 프로젝트 일정의 비밀
*예전에 썼던 글들을 브런치로 옮기다 보니 작성 시점이 맞지 않습니다. 양해부탁드립니다.
어제 XPER에 다녀왔습니다. (XPER는 한달에 한 번 있는 애자일 관련 모임 중 하나입니다)
어제 주제가 ‘더 골’로 유명한 엘리 골드렛 박사의 제약이론이었습니다.
모임 전에 ‘한계를 넘어서’라는 저자의 3번째 책을 보면서 진짜 감탄을 많이 했었습니다. 왜 일정 추정이 잘못되는지, 항상 일정보다 더 걸리는지 이해가 쏙쏙 되었거든요.
아무튼 제약이론을 잘 설명할 만큼 이해하지 못했지만, 어제 모임에서 느낀 점도 많고, 나누고 싶은 내용들이 있어서 일단 글을 써 봅니다.
제가 느낀 점을 러프하게라도 전달하면 1. 가치가 빠르게 전달 되고, 2. 피드백을 통해 수정이 가능하고, 3. 시간 될 때 리팩토링하면 되니깐요. 글 쓰는 것도 애자일한 게 좋다는 의미죠! 아무튼.
* 제약이론이란
* 제약이론은 전체 최적화에 대한 얘기입니다.
* 우리는 대부분 부분 최적화를 통해 전체 최적화를 할 수 있다고 믿고, 부분적인 개선을 하려고 합니다. 하지만 제약이론에선 부분들이 최적화 해서 오히려 재고가 늘 수 있다고 얘기합니다.
* 제약이론은 병목지점과 관련된 얘깁니다. 병목지점을 발견하고, 이를 개선함으로써 전체적인 최적화를 하는 겁니다.
* 부분최적화를 한다고 병목이 해결될 수 없습니다.
* 예를 들어 순차적 작업 상황이 있고, C에서 병목이 있다고 하면, 전체적인 작업의 속도는 C에 의해 결정됩니다. 그러니까 C의 개선없이는, A나 D,E에서 부분적으로 최적화 하는 거 자체가 의미가 없어지게 됩니다.
* 그런 의미에서 병목지점이 아니라면 차라리 노는 게 재고를 늘리지 않는 일이기도 합니다.
* Slack 책에서 보면 개인이 100% 효율을 내는 것이 오히려 생산성을 낮춘다고 얘기합니다.
* 병목이 없다면 개인 개인이 100% 효율 내는 게 좋을 수도 있습니다.(물론, 전 그럼에도 80%를 유지하는게 훨씬 좋다고 생각하지만)
이미지 출처 : http://www.haebyeong.com/mcnews/553042* 행군을 생각해 봅시다.
* 20명의 학생과 한명의 인솔자가 있다고 생각해 보죠. 인솔자는 모든 학생들을 관리해야 합니다.
* 행군을 시작하면, 빠른 아이가 느린 아이를 추월하고, 느린 아이는 뒤로 쳐지면서 시간이 지나면 자연스럽게 속도 기준으로 정렬이 됩니다.
* 시간이 지나면 뒷쪽의 느린 아이는 점점 더 멀어지고, 결국 통제를 벗어나게 됩니다.
* 전체 행군의 속도는 당연하게도 가장 느린 아이의 속도에 좌우되게 됩니다.
* 이를 개선하려면 어떻게 해야 할까요? 바로 다음을 읽지 말고 한번 생각해보세요.
* 가장 느린 아이의 짐을 나눠 들면 해결이 될까요?
* 당장 개선이 될 순 있지만, 짐을 든 사람이 그 순간 제약이 될 확률이 높죠.
* 가장 느린 아이를 앞으로 세우면 어떻게 될까요?
* 느린 아이의 속도가 기준이 되기 때문에 훌륭한 해답이 될 수 있습니다.
* 근데, 순서를 바꿀 수 없을 땐요?
* 제약이론의 DBR(Drum, Buffer, Rope)이 여기에 쓰입니다.
* 모두를 로프로 연결합니다. 그리고 뒤의 느린 아이가 북을 치며 걷습니다.
* 모두 로프로 연결되었기 때문에, 혹시나 뒤의 아이가 쳐지면 줄이 팽팽해지고 서게 됩니다. 즉, 통신 수단이 되는 거죠. 게다가 로프의 상태가 느슨하냐 팽팽하냐로 상태도 가시화 되는 장점이 있습니다.
* 로프의 길이는 버퍼입니다. 어느 정도 여유 길이(재고)를 두게 되면, 앞에서 혹시라도 사고가 나 넘어지더라도 버퍼만큼의 안전여유가 생깁니다.
* 북은 가장 느린 아이의 속도를 계속해서 알리는 겁니다.
* 쇠사슬 비유
* 모든 일은 서로 연결되어 있는 쇠사슬과 같습니다.
* 쇠사슬의 강도는 가장 약한 연결 고리가 결정합니다.
* 약한 연결 고리가 아닌 부분에서 최적화 하는 게 의미없는 이유입니다
* 약한 연결 고리를 개선하면 전체적인 강도가 높아집니다.
* 실무 환경에서는 어떻게 적용할 수 있나?
* 어제 테스팅 교육하는 분이 계셨는데, 항상 병목은 테스트에서 발생한다고 합니다.
* 테스트 환경 구축하고 하면서 굉장한 시간이 들게 되고, 테스트가 끝나야만 제품 출시가 되는 것이니, 병목지점입니다.
* 병목이 전체 프로젝트 속도를 좌우하고, 병목의 속도에 맞춰서 일하는 게 재고를 낮추는 일입니다.
* 병목 지점인 테스트를 앞으로 가져오게 되면 TDD(Test Driven Development)가 되고, 병목을 해결하는 큰 역할을 할 수 있습니다.
* 테스트가 개발을 주도하니, 최대속도(병목지점 속도가 전체를 좌우하니)로 프로젝트를 할 수 있는 거죠.
* 스크럼에선 안 쓰지만, 칸반을 생각해보면요.
* 칸반의 핵심은 WIP(Work in Progress)의 제한입니다.
* 당김 방식이기 때문에 어디엔가 병목이 생기면 앞에서도 일을 넘길 수 없고, 뒤에서도 일을 받아갈 수 없습니다.
* 이때는 앞과 뒤의 작업자들이 모두 달라 붙어 병목을 해결합니다.
* 칸반과 스크럼 책에 보면, 뭐 커피를 타주는 것 같이 작은 도움이라도 주라고 말합니다.
* 뭐 예를 들어 야근해야 해서 법카 받아오고 해야 하면, 이런 것들을 도와주는 것도 병목을 해결하는 거란 거죠.
* 항상 세가지 매커니즘이 문제를 야기합니다.
* 학생 증후군 : 기말고사 준비를 며칠 전에 시작하는 것과 같은 겁니다. 닥쳐야만 한다는 거.
* 멀티 태스킹 : 각각 1일씩 걸리는 업무 3개를 0.5씩 병행한다 생각해보면, 순차적으로 할 땐 A의 리드타임이 1이지만, ABCABC이런 순서라면 A가 끝나는 게 2가 됩니다.
* 지연된 시간은 누적되지만, 일찍 끝냄으로써 절약되는 시간은 누적되지 않음 : 종속적인 경우 앞에서 시간을 벌어봤자, 병목에서 까먹으면 말짱 황이죠.
* 이런 것들을 최소화할 수 있는 일하는 방식을 정의하면 좋죠.
* 일정 추정과 관련해서
* 대체로 일정에 버퍼를 두고 굉장히 안전한 추정을 합니다.
* 여유시간이 거의 200%에 달하게 된다고 하죠. 그래서 개별 버퍼를 없애고, 프로젝트 버퍼를 둬서 해결할 수 있습니다.
이상입니다. 제가 책 보면서 느꼈던, 어제 모임에서 느꼈던 벅참을 전하기엔 택도 없을 것 같고요.
그냥 병목지점에 대해 생각해보는 계기만 되더라도 어느 정도 좋을 것 같습니다.
혹시 우리 안에 병목이 있다면, 그걸 어떻게 찾아 해소할지도 고민해보면 좋을 거 같고요
