기본 콘텐츠로 건너뛰기

생산성 지표 - 효과와 효율

생산성에 대한 패러다임에 대해 생각해 보도록 하자.

아래 그림을 보도록 하자.


앞부분의 화살표는 요구사항, 중간의 녹색 원통은 개발팀, 마지막 파란 원통은 테스팅 팀이라고 가정해 보자.

A의 경우에 개발팀은 10의 요구사항을 개발할 수 있는 능력이 있지만 요구사항은 5만 들어오고 있다. 개발팀만을 생각한다면 현재 개발팀의 생산성은 50%이다.

반면에 테스팅 팀은 5만큼의 개발 결과물을 테스팅 할 수 있고 개발팀으로부터는 5만큼의 개발 결과물이 만들어지고 있기 때문에 테스팅 팀의 생산성은 100%이다.

따라서 전체 프로젝트의 생산성은 75%이다.

B의 경우에는 개발팀은 100%의 생산성을 테스팅 팀 역시 100%의 생산성을 보인다. 반면에 테스팅 팀은 5의 능력뿐이지만 개발팀에서는 10만큼이 오고 있기 때문에 언제나 5의 재고가 쌓여있게 된다. 하지만 전체 프로젝트의 생산성은 100%이다.

당신은 어떤 팀이 더 훌륭한 팀이라고 생각되는가?

A팀은 효과적인 팀이라고 한다. 여기서 효과라는 것은 목표 달성율을 말한다. A팀의 경우에는 모든 요구사항과 모든 개발 결과물을 처리하고 있기 때문에 할당된 모든 목표를 달성하고 있다.

B팀은 효율적인 팀이라고 한다. 효율이라는 것은 자원 활용 능력을 말한다. A팀의 개발팀의 경우는 자원 활용율은 겨우 50%이다. 반면 B 팀은 모든 팀의 자원 활용율이 100%이다.

우리는 일반적으로 효과보다는 효율적인 팀에 집중한다.

B팀은 개발팀의 결과물을 테스팅 팀에서 모두 소화하지 못하고 만성적인 지연에 시달리고 있다. 이럴 때 많은 경우 테스팅 팀은 계속되는 야근과 철야 등으로 자원 활용율을 200%로 올리는 방식으로 최적화를 하게 된다.

이게 정말 좋은 방식일까?

여기서 생각해 볼 개념은 TOC의 Throughput, 투자, 운영비용 이다. 쓰루풋은 Input 대비 Output의 비율이다.

TOC에서는 개선을 할 때 투자와 운영비용의 추가 지출을 지양한다. 추가 지출을 하더라도 투자와 운영비용의 합이 쓰루풋보다 반드시 작아야 한다.

그리고 어떠한 경우에도 쓰루풋은 손상되서는 안된다.

위의 경우를 테스팅 팀의 관점에서 다시 한번 살펴보자.

B팀의 경우 테스팅 팀의 문제는 개발 결과물을 모두 테스팅할 능력이 부족해서 테스팅이 계속 지연되고 있는 것이 문제이다. 이것을 해결하고자 할 때 기존 방식대로 야근과 철야를 밥 먹듯이 한다면 일시적으로 투자와 운영비용이 상승하게 된다. 그런데 이러한 투자와 운영비용의 상승이 쓰루풋을 10으로 만든다는 보장이 없다.

오히려 장기적인 관점에서 팀원의 이직등으로 쓰루풋이 손상될 수가 있다.

이러한 부작용은 우리가 효과보다는 효율에 집중하기 때문에 전체를 바라보는 시각이 부족해서이다. 즉, 종속성을 고려하지 못하는 것이다.

쓰루풋과 효과로 본다면 A팀의 생산성은 100%이다. 개발팀은 모든 요구사항을 처리하고 있고 테스팅 팀 역시 모든 개발 결과물을 테스팅 하고 있다.

반면 B팀은 개발팀의 생산성은 100%지만 테스팅팀의 생산성은 겨우 50%이다. 즉, 전체적인 생산성은 50%이다.

즉, 가장 생산성이 낮은 팀이 전체 팀의 생산성을 결정하게 된다. 이러한 곳을 제약 혹은 병목이라도 한다.

이러한 결과가 나오게 된 것은 패러다임에 있다.

기존의 패러다임은 합의 법칙이라고 볼 수 있다.

즉, 부분 최적의 합이 전체 최적이 된다는 것이다. B팀은 부분 부분의 생산성이 100%이고 이러한 생산성의 합으로 전체 생산성을 100%로 보는 것이다.

반면 TOC는 곱의 법칙으로 생각한다. 제약이 전체 생산성을 결정짓는다고 생각한다.

그렇다면 B팀의 생산성을 높이기 위해서는 어떠한 방법이 좋을 것인가?

개선해야할 팀은 테스팅 팀이다. 문제는 테스팅 팀만을 고려해서는 절대로 개선이 이루어질 수 없다는 것이다.

하나의 프로젝트에는 많은 부서가 연관되어 있고 각 부서는 종속되어 있다. 그 많은 부서 중 가장 대표되는 부서라면 역시 개발팀과 테스팅 팀이다. 두 부서는 독립적인 부서가 아니라 서로 연관되어 있는 프로젝트라는 마차의 바퀴와 같은 존재이다. 서로의 균형이 맞지 않는다면 마차는 앞으로 나아갈 수가 없다.

B팀의 테스팅 팀을 개선하기 위해서는 그 앞단에 있는 개발팀의 협력이 필수불가결하다.

많은 개선 방법이 있을 수 있지만, 개발팀의 쓰루풋을 줄이는 것이 하나의 방법이 될 수 있다. 현재 들어오고 있는 요구사항을 우선순위에 따라 선별해서 조절할 수 있다. 그렇게 될 경우 개발팀은 자원활용에 대해 여유가 생기게 된다.
이러한 여유분은 단위 테스팅이나 테스트 자동화를 통해 테스팅 팀의 쓰루풋을 증대하는데 쓸 수 있다. 이러한 결과로 전체 최적화를 하고 이에 따라 이익이 증대하게 된다면 훗날 전체적인 쓰루풋을 증대하기 위한 투자로 이어질 수 있을 것이다.

이러한 개선이 되기 위해서는 경영진의 지원이 필수 불가결한 요소이다.

그리고 전문적인 컨설턴트의 도움이 필요하다.

왜냐하면 기존의 패러다임은 그렇게 쉽게 바뀌지 않기 때문이다.

생산성에 관련해서 컨설팅을 제공하는 업체나 컨설턴트는 매우 많다. 하지만 그러한 컨설턴트 중 테스팅 프로세스를 잘 아는 컨설턴트는 매우 드물다.

거기다 테스팅 팀만의 효율이 아닌 효과와 전체 프로젝트의 연관성에 대한 조언을 해주는 컨설턴트는 더욱 드물다.

위와 관련되어 강연이나 컨설팅이 필요하다면 murian.mentor@gmail.com 으로 연락을 주시기 바란다.

필요하다면 무료 컨설팅을 제공해 드릴 수도 있다.

무료 컨설팅에 대한 내용이 궁금하시다면 http://murian.textcube.com/notice/12 을 참고하시면 된다.


댓글

이 블로그의 인기 게시물

스위치봇 & 스위치봇 허브 미니 간단 사용기

제 블로그에 예전부터 오셨던 분들은 제가 사브작 사브작 홈 오토메이션을 어설프게 해온 것을 아실겁니다. 작년부터 너무 하고 싶었던 도어락 자동화에 도전해봤습니다. 우리 나라에 자체 서비스로 앱을 통해 도어락을 제어하는 제품은 꽤 있습니다. 게이트맨도 있고, 키위도 있고, 삼성도 있죠.. 그런데.. 전 그것보다 구글 어시스턴트를 지원하는 도어락이 필요했는데... 그런건 안만들더라구요.. 꼭 필요한건 아니지만 웬지 해보고 싶은데... 언제 제품이 출시될지도 몰라서.. 가능한 방법을 찾아보다가.. 스위치봇이라는 제품으로 도어락을 버튼을 꾹 누르는 방법을 찾아서 스위치봇이 직구가 아닌 국내에 출시되었길래 낼름 구매해서 도전해봤습니다. 스위치봇 제품에 대한 내용이나 구매는  https://www.wakers.shop/  에서 하시면 됩니다. 저는 스위치봇에 스위치봇을 구글 홈에 연결시키기 위해 스위치봇 허브 미니까지 구매했습니다. 스위치봇 허브 미니가 없으면 스위치봇을 외부에서 제어하거나 구글 홈에 연결할 수 없습니다. 그리고 제가 스위치봇 허브 미니를 구매한 이유 중 다른 하나는 이 제품이 RF 리모컨 기능이 지원됩니다. 집에 있는 모니터를 제어할 필요가 있어서 이참 저참으로 같이 구매했습니다. 제품 등록은 어렵지 않습니다. 여기서는 스위치봇 허브 미니에 RF 리모컨을 등록해서 구글 어시스턴트로 제어하는 방법을 소개해드릴까 합니다. 제가 스위치봇 허브 미니로 모니터를 제어하고 싶었던 부분은 컴퓨터에서 크롬캐스트로 외부 입력을 때에 따라 바꿔야 하는데.. 그때마다 리모컨을 찾는게 너무 불편해서였습니다.  어차피 리모컨은 외부 입력 바꿀 때 빼고는 쓸 일도 없는지라.. 매번 어디로 사라지면 정말 불편해서 이걸 자동화 하고 싶었습니다. 그런데, 처음에 스위치봇 허브 미니를 등록하고 여기에 리모컨을 등록하니.. 구글 홈에 등록된 리모컨이 자동으로 등록이 됩니다. 그런데, 등록된걸 확인해보니 전원 On/Off만 제어되는 것이고, 나머지 버튼은 구글 홈...

프로젝트의 3요소 - Project Management

프로젝트는 예산, 일정, 품질 3가지 요소로 이루어진다고 볼 수 있다. 물론 위 3가지 요소 외에도 개발 범위, 팀워크, 자원 조달 등 여러가지 요소들도 고려해 볼 수 있지만, 가장 중요한 요소를 꼽는다면 예산, 일정, 품질일 것이다. 위에서 말한 여러가지 요소들은 프로젝트를 계획하여 완료하는 순간까지 복합적으로 작용해서 프로젝트의 성과를 제한하게 된다. 위의 요소들을 잘 통제한다면 성공적인 프로젝트가 되는 것이고 그렇지 못한다면 실패하거나 사라지게 될 것이다. 프로젝트 관리란 그런 면에서 제한된 자원을 가지고 목적한 바를 제한된 기간내에 최소의 비용으로 완수할 수 있도록 하는 것으로 정의할 수 있을 것이다. 이것을 도식화 한다면 아래와 같은 그림으로 표현할 수 있을 것이다. 위의 그림에 보는 것처럼 일정과 품질, 예산은 우리의 프로젝트가 목적하는 바를 달성하도록 하기 위해 상호 연관되어 작용하게 된다. 우리가 접하게 되는 많은 방법론들의 가정에는 위의 요소들을 어떻게 관리할 것인가에 대한 기본적인 가정들이 설정되어 있다. 조직에서 어떤 특정한 방법론을 도입한다는 것은 그런 가정에 동의하는 것이고 그러한 철학을 받아들인다는 것이기 때문에, 방법론을 채택하기 전에 조직의 근본 문제와 문화에 대해 점검해 볼 필요가 있다. 그리고 위의 요소들 외에 고려해 볼 사항은 위의 요소들은 변동성과 불확실성을 내포하고 있다는 것이다. 특히 비용과 예산, 목적은 프로젝트를 진행하면서 가변할 가능성이 매우 큰 요소들이다. 대부분의 방법론은 이러한 변동성에 대한 안전장치들을 가정해서 세워져 있다. 변동성의 측면에서 위의 요소들을 다시 살펴본다면 아래와 같이 가정할 수 있다. 위의 그림을 일부 해석해 본다면 일정이 늘어난다면 비용은 늘어나게 된다. 범위가 변경되어도 비용은 늘어나게 된다. 범위와 일정은 상호 의존적이 된다. 만약 위 3가지 요소의 변동성을 통제하지 못하게 된다면 프로젝트는...

코디에서 클라우드 저장소 연동해서 비디오 라이브러리 생성하기

저희 집에는 TV가 없습니다. 모니터만 있지요.. 몇년 전까지만 해도 IPTV를 이용했지만.. 자주 보는 것도 아니고.. 비용도 비용인지라.. 그냥 TV를 없앴습니다. 사실은 기레기 시키들 보기 싫어서 KBS 수신료 내는거 싫어서 그냥 TV를 없애버렸습니다. 대신에 스마트폰에서 OTT 서비스 실행해서 크롬캐스트로 전송해서 보고 싶은 프로그램만 봤었는데 슬슬 불편해서 고민고민하다 그냥 질렀습니다. TV 보는 것도 불편했지만 다른 이유는 PC에 저장된 동영상을 보고 싶을 때 매번 PC를 켜야하는 것도 불편하더라고요. 저희 집 컴이 이제 10년이 넘어서.. 부팅 부터가.. ㅠㅠ 그래서 오피스 365 월결제를 끊으면 원드라이브 1테라를 사용할 수 있습니다. 이 원드라이브에 제가 가지고 있는 영화 200여편을 몽땅 올렸는데.. 원드라이브에 있는 영화를 스마트폰에서 실행해서 크롬캐스트로 전송하는 것도 불편하더군요. 어쨌든 이런 저런 이유로 너무 불편해서.. 지금은 사라진 TELEBEE 의 미박스 3에 글로벌 롬을 올려서 싸게 판다는 정보를 입수하고 그냥 질렀습니다. 싸다고 하는데 싼지는 모르겠지만.. 크롬캐스트 울트라보다는 싸더라구요. 넷플릭스를 이용하지는 않지만 조건만 맞으면 4K도 재생되고 국내 AS도 된다고 해서 질렀습니다. 관련 정보는 네이버 카페 [Eddy Lab] UHD 미니 PC 포럼 에서 보실 수 있고, 지금도 구매가 가능한지는 모르겠지만 MiBox3-EddyLab 에디션 안드로이드 셋탑 에서 구매하실 수 있습니다. 안드로이드 셋탑은 질렀는데.. 국내 IPTV처럼 친절하게 설정되어 있는 셋탑이 아닌지라 처음 켜보고 뭐부터 해야할지 참 막막하더라구요. 우선은 중요한건 TV를 편하게 보고 싶은것과 원드라이브의 영화를 편하게 감상하는 것이기 때문에 여기에 중점을 두고 네이버 카페와 구글을 하염없이 떠돌아다녀보니.. 코디라고 하는 앱이 가장 정보가 많다는 것을 알게되었습니다. 그래서 우선 무작정 코디를 설치했습니다. 코디...