테스팅 히치하이커를 위한 안내서

지난 한달동안 정말 오랜만에 제약이론의 처음부터 끝까지 컨설팅을 한 뜻깊고 힘든 시간을 가졌습니다. 보안 어쩌구 때문에 자세한 자료를 여기서 공유할 수는 없고, 제약이론을 오랜만에 현장에 적용해서 개선 목표를 도출하는 과정에서 느꼈던 점과 어려웠던 점을 기록으로 남겨볼까 합니다. 사실, 이번 컨설팅은 개선 방안을 도출하는 과제였고, 추후에 정말 수행에 대한 컨설팅이 진행되어서 개선의 효과까지 검증 될 수 있다면 좋을 것 같습니다. 우선 저희 회사는 공식적으로 제약이론 컨설팅을 수행하지 않습니다. 모두들 제약이론을 그다지 신뢰하고 있지 않고 좋게 생각하지도 않습니다. 다른 분들이 워낙 바쁘신 관계로 저 하나 달랑 이 사이트에 방치하신 기념으로 제 독단적 판단에 따라 제약이론 컨설팅을 진행하게 되었습니다. 덕분에 참 힘든 시간을 보냈습니다. 제가 이 사이트에 제약이론을 적용하기로 마음을 먹게 된 이유는 이 사이트가 지난 5년간 무던한 개선 노력에도 개선이 이루어지지 않고 있고, 조직원들이 그런 사실에 피로감과 무력감을 나타내고 있었기 때문입니다. 이런 사이트에는 제 개인적으로 제약이론이 최고의 처방이라고 생각하고 있습니다. 아래는 그런 전차로 제약이론 컨설팅을 하면서 느꼈던 점과 어려웠던 점입니다. 1. 고객의 경력이 너무 높아도 문제입니다. 이론적인 설명을 듣지 않으려고 하시더군요. 덕분에 실제 수행 과정에서 왜 이런 일을 하는지 이해가 부족하다보니 충돌이 좀 많았습니다. 결국에는 수행 과정에서 공감을 어느정도는 하지만 이해가 부족하다보니 확신이 부족해지는 결과가 되었습니다. 제약이론은 수행하는 사람의 확신이 가장 큰 원동력인데 좀 난감합니다. 2. UDE라는 문제점으로부터 CRT를 작성하는데 있어서 그 상세함을 어느정도까지 가져가야할지 정말 힘들었습니다. 시간은 짧고 상세하게 만들기는 힘들어서 조금 압축된 형태로 만들다보니 나중에 검토 과정에서 상세한 내용이 빠져서 인과관계를 잘못 추론하게 되거나 정말 심각한 문제인데 누락되어버리는...

엊그제 제가 아는 어떤분으로부터 팀이 위기에 처해있다며 어려움을 겪고 계시다는 소식을 접했습니다. 오지랖이 넓은 제가 양해를 구하여 해당 팀의 문제를 수집하여 제약이론의 CRT를 작성해 보았습니다. 작성한 CRT는 아래와 같습니다. 직접적인 인터뷰나 현장 조사를 통하여 수집된 자료를 기반으로 하지 않았기 때문에 중간 중간 논리적 오류가 있을 수 있지만, 전체적으로 살펴보면 이 팀의 문제는 팀장이 팀에 바라는 능력과 팀이 현재 발휘할 수 있는 역량의 차이가 크고, 그에 대하여 소통이 되지 않는 것이 모든 문제의 근본 원인이라고 판단됩니다. 실제로, 능력이 뛰어난 팀장 중에는 팀이 자신에 기대에 미치지 못하는 경우 자기가 일을 몰아서 하는 워커 홀릭형이 되면서, 팀을 믿지 못하고 그러다 보니 팀과 의사소통의 문제를 겪는 경우가 있습니다. 이 팀의 경우에도 팀장은 경력이 25년이나 되는 사람인데 반해, 팀원은 평균 4년 정도로 격차가 너무 큽니다. 이런 팀들을 실제 인터뷰를 해보면 팀원들은 팀장이 자신들의 의견을 듣지 않고 독단적으로 일을 한다고 불만이고, 팀장은 팀원들이 일을 안해서 불만이라고 얘기하는 경우가 많습니다. 그리고 자신에게 문제를 얘기하지 않는다고 말하지요. 이런 경우 해결책은 어떤 것이 있을까요? 실제로 해당 팀을 찾아가 좀 더 심도있는 대화를 나누고 같이 고민할 수 있다면 좋겠지만 아쉽게도 제가 해줄 수 있는 조언은 여기까지인듯 합니다. 제 개인적인 생각으로는 이 팀에 즉흥연기를 통한 워크샵도 효과가 있을 듯 합니다. 내부적인 신뢰가 깨진 경우 내부에서 그 고름을 째서 짜낼 수 있는 사람은 많지 않습니다. 이럴때는 의사를 불러야 하는데, 이것도 참 쉽지 않죠. 부디 해당 팀이 문제를 원만하게 해결하기를 바랄 뿐입니다. 혹시 자신의 회사나 팀이 이런 문제에 처해 있다면 저에게 살짝 연락 주시면 도와드릴 수 있는 선까지 잘 도와드리겠습니다.

Eliyahu Moshe Goldratt(이하 골드렛 박사), 많은 분들은 이 분이 누구인지 알지 못할 것입다. 전성격상 누군가를 모방하거나 따라하는 성격이 못되지만 진정으로 만나고 싶고 닮고 싶고 저 사람처럼 되고 싶다는 사람이 딱 2사람이 있습니다. 한 사람은 Gerald Weinberg 이고 다른 한 사람이 골드렛 박사입니다. Gerald Weinberg 께서는 암 투병중이고 위독하시다는 소식도 들었지만 아직도 현업에서 열심히 활동 중이신 분이시고, 골드렛 박사께서도 작년까지만 해도 직접 세미나를 주관하시면서 열심히 활동하셨는데.. 지난 6월 11일 조용히 이 세상을 떠나시고 마셨다. 너무 늦게 알았고 직접 뵙지도 못했는데 떠나셨다는 소식에 그만 울컥했다. 골드렛 박사는 제약이론의 창시자로서 유명한 'The Goal'의 저자이기도 합니다. 뜬 구름만 같았던 제약이론을 하나 하나 알아가고 배워가며 부족함도 느끼고 참 그랬는데..(많은 분들이 모르시지만 전 제약이론 컨설턴트이자 기술전도사 중 한명 입니다. 뭐.. 한참 부족하기는 하지만..) 골드렛 박사에게 직접 제약이론을 접할 수 있을 기회가 이제는 다시 없겠지만.. 골드렛 박사가 우리에게 전하고자 했던 메시지는 앞으로도 쭈욱 계속될거라고 생각됩니다. 부디 좋은 곳에서 평안히 쉬시기를 바랍니다. 아래 영상은 그를 추모하는 영상으로 그가 우리에게 전하고자 했던 핵심적인 메시지가 담겨 있습니다. 이제 그를 이런 영상으로만 만날 수 있다는 것이 너무 아쉽습니다. "I smile and start to count on my fingers: One, people are good. Two, every conflict can be removed. Three, every situation, no matter how complex it initially looks, is exceedingly simple. Four, every situation can ...

지난 토요일 'Kanban 과 DBR 을 게임으로 경험하기' 라는 워크샵이 있었습니다. 제가 개인적으로 2달에 한번씩 진행하던 제약이론 세미나의 주제를 바꾸어서 이번에는 DBR를 게임으로 경험할 수 있는 'Job Shop Game'을 진행했습니다. Kanban 때문인지 몰라도 온오프믹스에 개설 후 빠른 시간안에 목표로 했던 분들이 신청해주셔서 매우 흐뭇했었는데.. 막상 토요일에는 절반이 넘는 분들이 신청을 하시고도 오지 않으셨더군요. 제 생각에는 아마 대기자분들도 오시지 않으셨던 것 같습니다. 이런 세미나를 진행하면서 가장 어려운 것이 신청하신 분들이 아무 연락 없이 오시지 않는 경우더군요. 이번에 참여하시지 못하신 분은 다음 세미나는 내년에 있으니 꼭 참여해보시기 바랍니다. 덕분에 시작은 조금은 우울하게 시작했습니다. 끝난 후에 만족도 그래프를 그려본 결과로도 참여자가 많지 않고 준비하는 사람들의 준비 미비로 사전 안내를 제대로 하지 못한 부분에 대해 불만을 느끼신 분들이 많았습니다. 어찌 되었든 계홍님의 Kanban 게임이 진행되었고, 많은 분들이 즐겁게 그리고 의미있게 즐기셨습니다. Kanban 에 관련된 자료는 https://sites.google.com/site/ thekanbangame/ 에서 구하실 수 있습니다. 계홍님의 후기는 http://gyehongpark.blogspot.com/2010/11/kanban-dbr.html 에서 보실 수 있습니다. 그런데 Kanban 게임에 예상 밖으로 시간을 너무 많이 쓰는 바람에 DBR에 대한 설명을 충분히 전달해 드리지 못하여서 그 부분에 불만을 가지시는 분들도 계시고 실제 게임을 진행할때에도 약간의 어려움이 있었습니다. 다음에는 좀 더 충실하게 제가 준비할 수 있도록 노력해야할 것 같습니다. DBR은 Drum - Buffer - Rope의 약자로 제약이론에서 공정 최적화를 수행하는 기법 중 하나입니다. 요점은 제약 즉, 병목에 맞춰서 공정을 진행한다는 것입니다. Job Sho...

스위치 - 칩 히스 & 댄 히스 지음, 안진환 옮김/웅진지식하우스(웅진닷컴) 매트릭스의 워쇼스키 형제가 있다면 최근 화두가 되고 있는 행동설계 분야에는 바로 히스 형제가 있습니다. 스위치는 히스 형제의 신간으로 국내에 번역되어 나온지는 시간이 조금 지났기 때문에 이미 많은 분들이 읽어보셨으리라고 생각됩니다. 저도 진작에 책은 읽어놓고 리뷰를 쓴다 쓴다 하면서 차일 피일 미루다 오늘에서야 리뷰 몇글자 적게 되네요.. 그렇습니다.. 사실은.. 옵티머스 Q 구매 이후에 앱 리뷰와 옵티머스 Q 테스트 하느라고 정신이 없었습니다. 스위치는 극적인 변화를 이끌어내기 위하여 다른 사람에게 동기부여를 꾀하는 방법에 대하여 간결하면서도 통쾌한 해법을 제시하고 있는 책입니다. 실제로 우리가 방안의 불을 키거나 TV를 키기 위해서 스위치 하나만 누르면 되는 것처럼 무엇인가를 할때 다른 사람이 나의 뜻대로 움직일 수 있도록 스위치 하나만 누르듯이 간단하다면 얼마나 좋을까? 라는 생각을 할때가 많습니다. 스위치는 그런 바램에 있어서 은총알은 될 수 없겠지만 기존의 다른 책들에 비해 풍부한 예제로 간결하게 메시지를 전달하고 있기 때문에 흡입력 있게 책에 빠져들 수 있습니다만.. 솔직히 저는 이 책처럼 과연 사람이 그렇게 손쉽게 설득을 당할지는 조금 의문이 듭니다. 아직 제 내공이 깊지 못한듯 합니다. 출처가 어딘지 모르겠지만 우리의 인생은 BCD로 요약된다고 합니다. 태어나고 죽는 그 순간까지 우리 인생은 선택의 연속이라는 겁니다. 그런데, 이 선택이라는 것이 나 홀로 살아가는 세상이라면 분명 내 안의 갈등은 있겠지만 그다지 큰 문제를 일으키지는 않습니다. 내가 아침을 먹을것인가? 말것인가? 라는 선택은 나에게만 영향을 미칠 뿐 이 선택이 다른 사람에게 영향을 끼치지는 않습니다. (머.. 나비효과라든가 프렉탈 어쩌구 하는 측면에서는 영향을 끼칠 수 있을지도 모르지만..) 하지만 나의 선택이 다른 사람에게 영향을 미치거나 다른 사람과의 관계 속에서 도출되어야 하는 선택인 경우 ...

제 개인적으로 지난 4월 말에 TOC-TP 세미나를 적어도 2달에 한번씩은 하자라고 다짐했었는데.. 이런 저런 사정으로 조금 늦어졌습니다. 과연 이 세미나를 기다리고 계셨던 분이 계실지는 알 수 없지만.. 세번째 저항의 극복, 갈등의 해소를 위한 TOC-TP 세미나를 엽니다. 2010년 7월 24일 제약이론에 대한 간단한 소개와 사고프로세의 증발구름과 CRT를 실습하는 작은 세미나를 준비했습니다. 제약이론에 관심 있으신 분들은 http://twtmt.com/cards/3828 에서 신청해 주시기 바랍니다. 신청하실때는 트위터 아이디가 필요합니다. 트위터 아이디가 없으신 분들은 비밀댓글로 제가 연락할 수 있는 메일과 전화번호를 남겨주시면 제가 추후에 연락드리도록 하겠습니다.

2009년 11월 진행했던 세미나에 이어 같은 내용으로 2번째 세미나를 준비했습니다. 2010년 5월 22일 제약이론에 대한 간단한 소개와 사고프로세의 증발구름과 CRT를 실습하는 작은 세미나를 준비했습니다. 제약이론에 관심 있으신 분들은 http://twtmt.com/cards/2847 에서 신청해 주시기 바랍니다. 신청하실때는 트위터 아이디가 필요합니다.

xper 모임을 나가보거나 주변에서 얘기되는 Agile 얘기를 나눠본지도 벌써 2년이 다되어 가는 것 같습니다. STA Consulting Inc. 에서는 얼마전 2010년 테스팅 트렌드의 하나로 Agile Testing 을 이야기했고, 4월 21일에는 애자일(Agile) 소프트웨어 개발 및 테스팅 세미나 가 열리기도 합니다. 그런데, 여기저기 이야기를 나누고 다니다 보면 Waterfall 개발방법론과 Agile 개발방법론을 대척점으로 놓고 이해하고 있는 사람들이 은근히 많습니다. 마치 흑백의 논리 처럼 명확하게 둘을 구분짓고 대척점에 놓는 사람들 말입니다. 과연 그런것일까요? Agile 과 Waterfall 은 흑백처럼 서로 절대 만날 수 없는 견우와 직녀와 같은 그런 관계일까요? 저는 아니라고 생각합니다. 제약이론의 사고 프로세스에 의하면 Agile 개발 방법론은 궁극적으로 발전된 형태의 Waterfall 로 규정할 수 있습니다. 팀의 진화에 따라 많은 조직은 Waterfall 에서 Agile 로 자연스럽게 이동하게 되어 있다라는 결론에 도달합니다. 또한 Agile 그 너머를 생각해 볼 수도 있습니다. 많은 조직에서 Waterfall 을 통해 실패와 한계를 경험하고 그것을 극복하기 위한 방법의 하나로 Agile 을 도입하려고 합니다. 하지만 생각보다 Agile 로 성공적으로 이행하는 조직은 많지 않습니다. 분명 많은 성공사례가 보고되고 있지만 실제 현실에서는 여러 이유로 실패하는 경우가 많습니다. 왜 그런것일까요? 전 이것을 '모 아니면 도'와 같은 생각으로 Agile 을 도입하였기 때문이라고 생각합니다. 사람들은 Waterfall 반대편에 있는 것을 Agile 로 규정하고 Agile 을 도입하면 Waterfall 에서 발생한 모든 문제가 모두 해결될 것처럼 생각하기 때문에 실패한다고 생각합니다. 그리고 그러한 가정은 틀렸다라는 것이 제 생각입니다. Waterfall 에서도 제대로 된 성공경험이 없는 조직은 Agile 을 도입한다고 해도 ...

얼마전 UXcampSeoul 에서 소원의 나무 만들기라는 세션을 진행했습니다. 바쁘다는 핑계로 PT 자료를 만들지도 못했고 소원의 나무라는 것 자체가 아직까지는 저도 컨셉만을 가지고 있고 적용사례도 저 혼자이기 때문에 준비되지 못한 발표에 많은 분들에게 폐를 끼친 것은 아닌지 반성하게 되는 계기였습니다. 발표가 끝나고 발표자료를 PT로 만들어 볼까 몇차례 고민해 보았지만 PT까지 만들 자료는 아닌 것 같고 그렇다고 발표자료를 공유하지 않고 지나가자니 저 자신도 제 생각을 정리하고 다시금 돌아보는 기회를 놓치는 것 같아 이 포스팅을 발표자료로 갈음하는 바입니다. 소원의 나무라는 컨셉에 대해 읽어보시고 적용해보고 싶으시거나 의견이 있으시면 댓글이나 "murian.mentor 골뱅이 지메일 닷컴" 으로 연락주시기 바랍니다. 필요한 분이 계시다면 컨설팅이나 강연도 해드립니다. 그리고 소원의 나무는 제약이론을 수정한 개념으로 혹시 IT 조직에 제약이론을 적용하기 위해 제약이론을 같이 공부하기 원하시는 분은 " IT와 TOC의 융합을 연구하는 사람들 " 에 가입해 주시면 고맙겠습니다. 소원의 나무의 출발점은 "콘웨이의 법칙" 에 대한 고민쯤부터입니다. " 콘웨이의 법칙 " 에 대해서는 제가 이전에 적었던 글을 읽어보시기 바랍니다. 처음 콘웨이의 법칙을 적을 때 저는 콘웨이의 법칙에 대해 '팀의 프로세스가 복잡할수록 소프트웨어는 매우 복잡해진다.' 라고 소개했습니다. 그럼 이번에는 이걸 UX라는 관점에서 바꾸어 생각해 보면 이렇게 소개할 수 있을 것 같습니다. "팀 구성원들의 사용자 경험이 나쁠 수록 소프트웨어 사용자의 경험은 더 나빠진다." 우리는 UX에 대해서 이야기 할때 많은 경우 User 즉, 사용자에만 집중합니다. 사용자가 더 나은 경험을 할 수 있게 하기 위해서 어떻게 할 것인지에 대해 논의합니다. 그 과정에 제품을 만드는 사람들의 경험은 빠져 있습니다. 그...

오늘로 프로젝트가 서쪽으로 간 까닭에 대한 정리를 얼추 끝냈습니다. 더 깊은 부분까지는 더 많이 고민해봐야겠지만 오늘까지 정리한 것들을 공유하고 의견을 듣는 차원에서 글을 적어 봅니다. 이 책은 분명 피와 살이 되는 좋은 내용들이 적혀 있는 것은 맞지만 단점이라면 각각의 현상들을 유기적으로 파악하기 힘들고, 명확한 해결책이 제시되지 못했고, 나쁜 패턴과 좋은 패턴이 뒤섞여서 제시되기 때문에 꼼꼼이 읽지 않으면 저자의 의도를 쉽게 파악하기 힘든것이 아닌가 생각합니다. 그래서 책에 나와 있는 모든 패턴의 내용을 다시 한번 정리하고 각 패턴의 논리적인 연관 관계와 핵심적인 원인에 대해 제약이론의 사고 프로세스를 응용해서 정리하고 아주 쪼끔 고민해 보았습니다. 이 책에는 총 86가지의 패턴이 소개되어 있는 데 개인적인 기준으로 분류했을 때 나쁜 패턴이 50가지이고 나머지 36가지를 좋은 패턴이라고 볼 수 있습니다. 각각의 패턴 이름과 패턴 유형을 정리한 표는 아래와 같습니다. 패턴의 내용은 책을 사서 읽어보시기 바랍니다. 목록 중에서 나쁜 패턴을 UDE라고 가정하고 각각의 나쁜 패턴의 연관 관계를 그려본 자료는 아래와 같습니다. 위 UDE Map을 통해 생각해 볼 수 있는 근본원인을 정리해 보면 아래와 같습니다. 불필요한 정보과잉 특정 이론 신봉 잘못된 인력관리 비용 절감 강조 계속되는 기능 추가 감정 표현을 억눌러서 충돌이 표출되지 못하는 조직 문화 제약이론에 따르면 조직의 많은 나쁜 패턴(UDE, 좋지 않은 현상)들의 근본원인은 하나 또는 아주 드물게 두개 정도의 아주 극소수라고 가정한다면 '프로젝트가 서쪽으로 간 까닭은' 책을 정리해서 나온 위 리스트도 분명 어떤 논리적인 관계에 따라 좀 더 깊은 곳까지 생각해 볼 수 있을 것입니다. 많은 경우 우리들은 위의 리스트를 뽑는 작업까지는 잘 합니다. 하지만 여러 이유로 더 깊은 곳까지는 들어가지 않습니다. 그에 관련되어서는 제가 이전에 적은 ' 순환논리의 함정 - 인식의 한계를 넘어서 '...

소프트웨어 개발에 발을 담그고 있는 많은 사람들은 경력이 오래되면 여러 프로젝트를 경험하게 됩니다. 그 프로젝트 중에는 성공하는 프로젝트(나름 자기 생각에 성공한 것 같은 프로젝트 포함해서)가 있는가 하면 다시는 기억하고 싶지 않을 정도로 끔찍했던 프로젝트도 있을 것이다. 이러한 성공과 실패라는 두가지 갈림길을 나누는 것은 과연 무엇일까요? 주변의 많은 정보로부터 우리는 프로젝트가 실패하는 많은 경우를 접해 볼 수 있습니다. 그러한 정보를 기초로 이러이러하게 하면 프로젝트가 성공할 수 있다고 가르쳐주는 많은 방법론도 있습니다. 하지만 그러한 수많은 방법론 중에서도 성공률 100%를 보장하는 방법론은 없습니다. 과연 무엇이 문제인것일까요? 우리가 프로젝트를 시작하게 되면 우리는 희망에 부풀어 있습니다. 프로젝트를 시작하기 위한 기획서와 같은 문서를 들여다 보면 모든 것이 희망적입니다. 물론리스크 분석 보고서와 같은 문서가 첨부되는 경우도 있지만 많은 경우에는 이러이러한 것을 개발하면 이러이러한 수익을 얻을 수 있다는 그리고 이러이러한 제품은 아직 누구도 개발해 보지 못한 것이고 사용자가 정말 원하는 제품이기 때문에 개발만 한다면 대박이라는 그런 핑크빛 희망으로만 가득차 있습니다. 실제로 기획 단계에서 최악의 상황을 고민하거나 정말로 우리가 개발하는 제품이 상품성이 있는 것인지에 대한 진지한 고민은 찾아보기 힘듭니다. 그렇게 모두들 커다란 꿈을 가지고 핑크빛 미래와 거대한 인센티브를 바라면서 개발에 착수합니다. 하지만 그러한 희망은 얼마 지나지 않아 무참히 삐그덕 거리기 시작합니다. 어디서부터 무엇이 잘못되었는지 알지도 못한채 프로젝트는 여기저기서 비명을 지르기 시작합니다. 예산 초과, 개발 기간 초과는 다반사요.. 어떤 경우는 핵심 개발자가 하루 아침에 사라지기도 합니다. 어제까지 멀쩡하던 개발 서버가 하루 아침에 모든 데이터를 맛있게 먹어버리고 복구조차 못하는 경우도 있습니다. 무엇인지 모르지만 잘못되어 가고 있고, 계속되는 야근과 철야에 프로젝트에 참여한 모...

2010년 1월 14일 어제 저녁 TOC 포럼에서 제약이론의 확산에 대한 저의 고민을 발표하는 자리를 가졌습니다. 제약이론과 명확하게 연관된 주제가 아님에도 관심있게 경청해 주시고 여러 의견을 주신 많은 참석자 분들께 이 글을 빌어서 고마움을 표하는 바입니다. TOC 포럼은 국내에 몇 안되는(실제로 활동을 하고 있는 모임으로는 거의 유일하다고 봐도 무방할 것 같습니다.) 모임 중 하나로 10여년에 가까운 역사와 100회가 넘는 모임을 꾸준히 이어오고 있고, 잘 정리된 자료도 무궁무진한 처음 제약이론을 시작하는 사람들이라면 꼭 가입해야하는 모임 중 하나입니다. TOC 포럼은 현재 SERI 안에 둥지를 틀고 있습니다. 가입을 원하시는 분은 아래 URL로 가셔서 가입하시면 됩니다. TOC 포럼: http://seri.org/forum/toc/ 그런 곳에서 발표 의뢰가 들어왔을 때 정말.. 무엇을 발표해야할지.. 막막한 심정이었다. 한참을 고민하던 끝에 얼마전 읽었던 '티핑포인트'라는 책을 떠올렸다. 내가 제약이론을 접하고 적용하고 고민한 1년의 시간과 올해 내가 제약이론을 통해 하고 싶은 일을 담담하게 발표하기로 마음먹고 준비한 발표를 어제 했습니다. 솔직히 거대한 고민 보따리만 풀어놓고 무엇 하나 명확한 답변도 내놓지 못했지만 많은 분들이 같은 고민을 하고 여러 의견을 주셔서 다시 한번 고마운 마음입니다. 아래는 어제 발표한 내용의 요약본입니다. TOC의 TIPPING POINT 발표 보기 화두는 내가 왜 제약이론에 집중하게 되었는가에 대한 것이었다. 소프트웨어 개발을 위해서는 회사에 따라 다르기는 하지만 확실한건 2명 이상의 사람과 필요에 따라서는 여러부서가 협력해야 한다는 것이다. 그런데 조직이 커지면 커질수록 내부의 정치적인 이슈가 더욱 중요해지고 각 부서간의 반목으로 인해 프로젝트가 표류하는 경우가 많아진다는 것이다. 또한 재미있는 것은 예를 들어 개발부서와 QA부서가 있다면 분명 소프트웨어...

깨진 유리창 이론은 범죄학자인 제임스 Q. 윌슨과 조지 Q. 켈링이 주장한 이론으로 만약 한 창문이 깨져 있고 그것을 수리하지 않고 내버려둔다면, 조만간 더 많은 창문이 깨지게 된다는 범죄의 전염 이론이다. 자세한 것은 위키피디아를 통해 확인을 해보시기 바란다. 깨진 유리창 이론 - 위키백과, 우리 모두의 백과사전 ko.wikipedia.org 깨진 유리창 이론 (영어: Broken Windows Theory)은 미국의 범죄학자인 제임스 윌슨과 조지 켈링이 1982년 3월에 공동 발표한 깨진 유리창(영어: Fixing Broken ... 새해 첫 포스팅으로 이 이론을 다시금 떠올리게 된 이유는 여러가지이다. 하나는 우리는 사소한 것에는 그다지 관심을 두지 않지만 그 사소한 것이 모든 것을 그르치는 원인이 될 수 있다는 것이다. 우리가 사소하게 지나치는 것들 중요하게 생각하지 않는 것들이 인과관계에 따른 전염으로 커다란 문제들을 야기할 수 있다는 것이다. 실제로 제약이론을 통해 여러 제약들의 근본원인을 찾고 보면 매우 사소한 문제 즉, 아무도 중요하게 여기지 않는 문제나 모두가 당연하다고 생각하는 문제가 근본원인인 경우가 많다는 것이다. 둘째는 상황과 맥락의 힘이다. 많은 곳에서 선택과 집중에 대해 이야기한다. 하지만 우리의 선택은 얼마나 올바르고 얼마나 일관성이 있는 것일까? 많은 사람들이 자신의 행동이 일관되다고 생각하지만 실제로 그러한 것일까? 많은 사람들이 그렇게 믿고 있지만 사실은 사람은 주변 상황과 맥락에 따라 선택과 행동이 달라지는 것이 사실이다. 그 대표적인 예로 방관자 효과라는 것이 있다. 방관자 효과 - 위키백과, 우리 모두의 백과사전 ko.wikipedia.org 방관자 효과 (傍觀者效果, 영어: bystander effect) 또는 제노비스 신드롬(영어: Genovese syndrome)은 주위에 사람들이 많을수록 어려움에 처한 사람을 돕지 않게 되는 ... 우리가 흔히 머피의 법칙이라고 부르는 것은 위 두가지가 복합적으로 작용하...

프로젝트 관리자로서 갖춰야 할 것들과 알아야 할 것들은 얼마나 되는 걸까 ? 내 기억에 내가 프로젝트 관리자가 되었을 때 그 이전에도 그 이후에도 나에게 프로젝트 관리자가 무엇을 해야 하고 무엇을 알아야 하는지에 대해 누구도 가르쳐준 적이 없었다 . 모든 것은 내가 공부하고 스스로 해결해야 될 문제였고 , 해결하지 못한다면 모든 것은 나의 책임이었다 . 돌이켜보면 즐거웠던 팀이 있었던 반면에 정말 기억도 하기 싫은 팀도 있었다 . 솔직히 그때 무엇을 잘했던 것이고 무엇을 잘 못했던 것인지는 기억도 나지 않고 지금도 잘 모르는 것 같다 . 한가지 분명한 것은 내가 스스로 더 잘하고자 할수록 프로젝트는 더욱더 미궁 속으로만 빠져 들어갔던 것은 확실했다 . 시간이 흐르고 많은 책을 읽었고 많은 선배들의 이야기를 듣고 지금 돌이켜보면 문제는 나에게 있었던 것이 확실하다 . 팀원들에 대한 불신 , 나의 방식에 대한 독선 등 난 참 못난 프로젝트 관리자이었다 . 프로젝트 관리자가 되면 참 할 일도 많다 . 끊임없는 회의와 일정 관리 , 리스크 관리 , 프로젝트 범위 관리 , 통합 관리 , 품질 관리 , 인력 관리 , 커뮤니케이션 관리 등등 정말 할 일은 끝도 없다 . 그런데 , 내가 이 모든 것을 잘하려고 하면 할수록 프로젝트는 점점 꼬여만 갔다 . 하나의 문제를 해결하고 나면 다른 곳에서 문제가 발생했다 . 정말로 문제가 하루라도 없는 날이 있었더라면 하는 것이 소원일 지경이었다 . 그때에는 내가 능력이 부족해서 그렇게 하루도 끊임없이 문제가 발생하고 내가 그러한 문제들을 잘 해결하지 못하는 것이라고 생각했다 . 그것도 일견 맞는 얘기지만 지금 돌이켜 생각해 보면 난 핵심을 보지 못했던 것이다 . 지금 나는 내가 인식하지 못하고 지나쳤던 그 핵심을 ‘ 제약 ’ 이라고 부른다 . 예를 하나 들어보자 . 여기 저기 물이 새고 있는 둑 앞에 당신이 서 있다면 당신은 둑에서 새고 있는 여러 구멍 중 어느 것부터 막을 것...

'린 소프트웨어 개발의 적용'이라는 책을 보면 뒷부분에 제약이론에 대해 소개하고 있다. 그 중에는 제약이론의 CCPM에 대하여 아래와 같은 문구가 있다. '소프트웨어 개발에 에로사슬을 사용하는데 있어서의 부가적인 문제는, 개발을 완료할 모든 업무를 사전에 알고 있어야하고 그들 간의 의존관계를 잘 파악하고 있어야 한다는 가정에 있다. 앞서 살펴본 바와 같이 이러한 가정들은 대다수 소프트웨어 개발에 적절치 않다.' - 린 소프트웨어 개발의 적용 - 나도 처음에 CCPM을 배울 때 위와 같은 생각을 했었다. CCPM을 하려면 프로젝트 전체 기간의 모든 작업과 모든 일정을 모두 알아야 하는 것이 아닌가? 그런게 정말 가능하긴 한걸까? 우리의 추정이 과연 그 먼 기간까지 유효할 수 있을까? 표면적인 CCPM의 모습은 기존의 PERT/CPM이나  Gantt chart와 별반 다를바가 없어 보인다. CCPM이라는 것이 기존의 WBS 관리 방법의 제약을 해소하고자 하는 사고 프로세스의 산물이기 때문에 CCPM을 작성하기 위해서는 기본적으로 최소한 Gantt chart와 같은 방법으로 WBS를 관리하고 있어야 한다. 이것은 기존의 일정관리가 안고 있던 여러 가정들을 그대로 승계하게 된다. 하지만 CCPM에서 정작 가장 중요하게 강조하는 것은 자원 경합의 해소이다. 기계이든 사람이든 작업을 수행하는 주체가 하나의 작업에 온전히 집중할 수 있도록 일정을 관리하고자 하는 것이 CCPM의 핵심이다. 만약 Agile 방법론에서 말하는 것과 같이 팀의 모든 구성원들이 모든 역할을 수행할 수 있다면 자원의 경합은 더 이상 문제가 되지 않을 것이다. 하지만 실제 프로젝트에서 그런 경우는 거의 없다. 자원의 경합은 언제 어디서나 쉽게 찾아볼 수 있다. CCPM에 문제가 있다면 우리는 그것을 더욱 더 개선할 수 있다. TOC의 입장에서 본다면 Agile 은 폭포수 모델에서 TOC를 적용하여 궁극적으로 도달하는 하나의 지향점이라고 ...