디지털라이프
제공 : 한빛 네트워크
저자 : Jeff Gothelf
역자 : 권원상
원문 : Four Qualities of Successful In-House Innovation Teams
린(Lean) 방법론을 제품 설계와 개발에 적용하는 문제에 대해 내가 가장 자주 받은 질문은 "어떻게 하면 우리 조직에서도 이런 일이 가능할까요?"라는 질문이다. 뿌리깊은 회사 내 조직 간의 장벽(corporate silos)과 기존의 팀 관리 구조 사이의 틈을 비집고, 이러한 방법론을 대기업에 뿌리 내리도록 하는 것은 불가능해 보일 수도 있다. 이와 관련된 내용을 몇 번에 걸쳐 블로그에 올리면서 내가 직접 적용했거나 나와 같이 일했던 다른 팀에서 사용했던 몇 가지 전략을 공유하는 것이 독자들에게 도움이 되겠다는 생각이 들었다. 그 중 첫번째인 이 글에서는 팀 구성에 대해 이야기 하려고 한다.
인재 채용만큼이나 효율적인 팀 구성도 린 팀 성공에서 중요한 열쇠다. 많은 기업들이 제품 개발 조직을 마치 서비스 제공자(내부 에이전시)와 같은 관점으로 보는 경우가 있다. 비즈니스 측면에서 이들 에이전시(엔지니어링, UX/디자인, 제품 관리 등)와 이야기 할 때는 인원 배치 필요성과 전문성, 가용성, 적합성에 근거하여 자원을 제공한다는 원칙에 따라 팀이 만들어 지게 된다. 이런 방법은 합리적이고 효율적인 기준으로 할당하는 프로젝트 팀의 인원을 할당하는 방법이긴 하지만, 우리의 목표는 프로젝트 팀원이 모이도록 하는 것이 아니고 정말로 팀을 구성하는 것이다.
성공 가능성을 최대로 높이기 위한 것이라면 팀을 구성할 때 다음의 네 가지 조건에 초점을 맞출 필요가 있다.
1. 작은 규모로 구성한다(Small)
팀의 인원을 작게 한다는 것은 팀원이 서로를 잘 알 수 있게 한다는 의미가 된다. 소규모 팀을 관리하는 것이 훨씬 쉽다. 팀의 구성원 입장에서도 어떤 것이 필요할 때 누구와 이야기하면 되는지를 더 간단하게 정리할 수 있을 것이다. 완료된 일이 무엇이고 남은 일이 무엇인지를 파악하는 것도 더 쉬워진다.
작은 팀이 신속하고 효율적으로 자기 조직화하는 경향이 있다. 그들은 실수의 영향을 인지하고 그 실수를 반복하지 않도록 신속하게 행동하게 된다. 작은 팀에서는 서로 책임을 다하려고 하며(서로 잘 알고 있기 때문에) 회사 내 규칙을 넘어서는 일정한 수준의 신뢰 관계를 구축하게 된다.
팀의 크기를 고려할 때는 제프 베저스(Jeff Bezos)의 "피자 두판(two-pizza) 팀" 이라는 마법 주문을 염두에 두자. 이 주문은 (미국식) 피자 두판을 나누어 먹으면 충분한 정도의 인원으로 구성된 팀이라는 의미이다. 대략 6명에서 10명 정도 규모가 되겠다. 그간 내가 같이 일했던 성공적인 팀은 대개 다음과 같은 역할로 구분되었다.
2. 같은 공간에 배치한다(Collocated)
질문에 대한 답을 얻는 가장 쉬운 방법은 자리에서 일어나서, 그 질문에 대답할 수 있는 사람에게 걸어간 다음, 질문 하는 것이다. 한 장소에 있는 팀은 훨씬 더 효율적이다. 이런 팀은 칸반/스크럼 보드, 화이트보드 스케치, 종이 프로토타입 같은 물리적인 도구들을 함께 사용할 수 있다. 비언어적인 커뮤니케이션의 장점을 얻을 수도 있다. 그때 그때 커뮤니케이션 할 수 있는 기회가 많아지면 뜻밖의 결과를 얻게 되는 경우도 많다.
한 공간에 배치된 팀은 "공간"을 함께 구성할 수 있다. 이 공간은 그 자체가 커뮤니케이션의 일부가 될 것이다. 다양한 도구들을 벽에 붙이게 된다. (분석판과 같은) 정보 방열판을 통해서 팀원들이 팀의 목표의 진척에 대해 그 때 그 때 파악할 수 있다. 그리고 이러한 공간에서 함께 일하면서 팀은 그 팀 고유의 기운과 에너지가 생기게 된다. 이렇게 활발한 상황에서 팀원들 사이에서 에너지가 전해지며 사무실에 있는 다른 팀원 모두에게 영향을 미칠 수 있다.
나는 많은 사람들이 이렇게 100% 같은 공간에서 일하는 팀이라는 장점을 누릴 수 없다는 것도 잘 알고 있다. 이런 상황에 처한 팀에서도 혁신이 가능하지만, 혁신을 촉진할 수 있는 약간의 도구가 필요하다. 이 주제에 대해서는 다른 글(Designing with remote teams)에서 다루었다.
3. 한 팀에 속하도록 한다(Dedicated)
한 팀에 속하도록 하기가 쉽지 않은 경우가 많으며, 특히 디자이너를 배치할 때 이런 문제가 생기는 경우가 많다. 어떤 이유에서인지 개발자들은 한 팀에만 속할 수 있지만, 디자이너는 동시에 여러 팀의 과제를 쉽게 처리할 수 있다는 믿음이 업계에 널리 퍼져 있다. 이런 생각은 분명히 잘못된 것이다. 어떤 팀 구성원이 여러 팀을 지원하는 경우, 대개는 컨텍스트 스위칭, 우선순위화, 이메일 등의 부차적인 일을 해야 하고, 결국 여러 작업을 맡기면서 기대했던 생산성보다 훨씬 더 많은 비용이 들게 된다.
세 팀의 업무를 담당하는 디자이너(개발자든 제품 관리자 등 어떤 사람이라도)가 매일 두 팀 사람들을 애먹이는 경우를 생각해 볼 수 있다. 그 디자이너는 어떤 우선 순위에 따라 한 팀의 일을 선택한 다음, 나머지 두 팀 사람들에게 오늘은 왜 그 팀의 일을 할 수 없는지를 설명하게 될 것이다. 이런 일 때문에 효율성이 떨어지는 것은 물론이고 그 디자이너는 어떤 팀에 줄을 서야 할지, 소위 사내 정치를 의식하거나 아니면 모든 팀과 잘 지낼 수 있도록 하루에 18시간씩 일을 하는 방법 중 하나를 선택할 수 밖에 없는 데, 둘다 썩 좋은 옵션은 아니다.
한 팀에만 속하는 사람은 자신의 일에 집중할 수 있는 기회가 있다. 그리고, P1(최우선순위의 일)이 명확하기 때문에 작업 시간을 어떻게 해야 할지도 알고 있다. 작업이 끝나기를 기다리고 있는 같은 팀의 동료에게 일을 미루어서도 안된다. 이런 팀이 작업 결과도 더 좋고 효율적으로 일하게 된다. 또한 여러 팀의 사람들과 일하기 위해서 "일단 끝내고 보자"는 식의 태도가 아니라 지속적으로 같은 문제에 집중하게 되므로 혁신적인 돌파구를 찾아낼 수 있는 기회가 많아진다.
4. 팀 내에서 해결한다(Self-sufficient)
혁신적인 팀의 가장 중요한 자산 중 하나는 할 필요가 있는 일을 해야 할 때 바로 실행에 옮길 수 있는 능력이다. 무엇인가를 해보려고 할 때 다른 팀을 의존해야 한다면 팀의 모멘텀, 그리고 더 중요한 학습과 발전에 영향을 미치는 연습과 실험 과정의 진행 속도가 느려질 수 밖에 없다. 성과를 얻기 위해 필요한 모든 역량으로 팀을 만들면, 기존의 전통적인 팀에서 안고 있던 많은 제약들을 해소할 수 있다.
팀 내에서 해결한다는 것은 여러 의미가 있겠지만, 그 핵심은 적어도 기술, 제품, 디자인에 있어서 각각을 대표할 사람이 있어야 한다는 의미다. 프로젝트가 고유 시스템과 인터페이스를 한다거나 위의 세가지 요소외의 다른 원칙에서 통찰을 얻어야 한다면 피자 두판 크기의 팀이라는 조건을 염두에 두고 필요한 것을 추가하면 된다. 작은 규모로 팀을 유지하되 팀에서 필요한 일은 팀에서 처리할 수 있도록 하기 위한 방법으로 다방면의 능력이 있는 사람을 채용하기도 한다. 이를 테면 연구 주제를 설계하고 수행하거나 전체 스택을 개발할 수 있는 사람들이 그런 사람들이다. 팀의 역량이 커질 수록(그것에 반드시 역할일 필요는 없다), 여러 가지 이슈를 내부에서 처리할 수 있는 팀이 될 것이다.
혁신 팀을 구성할 때는 위의 네 가지의 특성을 고려한다. 이들 특성은 초기 팀 구조를 잡을 때 가이드라인으로 쓸 수 있을 것이다. 시간이 지나면 조직의 고유한 컨텍스트에 따라서 이러한 구조는 각각의 회사에 맞도록 변형될 것이다. 그렇지만, 이 글에서 설명한 접근 방법을 바꾸는 경우에도 가장 기본이 되는 목표, 즉 조직으로써 우리 팀의 성공하기 위해서 무엇을 할 것인지라는 목표를 기억해 두기 바란다.
저자 : Jeff Gothelf
역자 : 권원상
원문 : Four Qualities of Successful In-House Innovation Teams
린(Lean) 방법론을 제품 설계와 개발에 적용하는 문제에 대해 내가 가장 자주 받은 질문은 "어떻게 하면 우리 조직에서도 이런 일이 가능할까요?"라는 질문이다. 뿌리깊은 회사 내 조직 간의 장벽(corporate silos)과 기존의 팀 관리 구조 사이의 틈을 비집고, 이러한 방법론을 대기업에 뿌리 내리도록 하는 것은 불가능해 보일 수도 있다. 이와 관련된 내용을 몇 번에 걸쳐 블로그에 올리면서 내가 직접 적용했거나 나와 같이 일했던 다른 팀에서 사용했던 몇 가지 전략을 공유하는 것이 독자들에게 도움이 되겠다는 생각이 들었다. 그 중 첫번째인 이 글에서는 팀 구성에 대해 이야기 하려고 한다.
인재 채용만큼이나 효율적인 팀 구성도 린 팀 성공에서 중요한 열쇠다. 많은 기업들이 제품 개발 조직을 마치 서비스 제공자(내부 에이전시)와 같은 관점으로 보는 경우가 있다. 비즈니스 측면에서 이들 에이전시(엔지니어링, UX/디자인, 제품 관리 등)와 이야기 할 때는 인원 배치 필요성과 전문성, 가용성, 적합성에 근거하여 자원을 제공한다는 원칙에 따라 팀이 만들어 지게 된다. 이런 방법은 합리적이고 효율적인 기준으로 할당하는 프로젝트 팀의 인원을 할당하는 방법이긴 하지만, 우리의 목표는 프로젝트 팀원이 모이도록 하는 것이 아니고 정말로 팀을 구성하는 것이다.
성공 가능성을 최대로 높이기 위한 것이라면 팀을 구성할 때 다음의 네 가지 조건에 초점을 맞출 필요가 있다.
1. 작은 규모로 구성한다(Small)
팀의 인원을 작게 한다는 것은 팀원이 서로를 잘 알 수 있게 한다는 의미가 된다. 소규모 팀을 관리하는 것이 훨씬 쉽다. 팀의 구성원 입장에서도 어떤 것이 필요할 때 누구와 이야기하면 되는지를 더 간단하게 정리할 수 있을 것이다. 완료된 일이 무엇이고 남은 일이 무엇인지를 파악하는 것도 더 쉬워진다.
작은 팀이 신속하고 효율적으로 자기 조직화하는 경향이 있다. 그들은 실수의 영향을 인지하고 그 실수를 반복하지 않도록 신속하게 행동하게 된다. 작은 팀에서는 서로 책임을 다하려고 하며(서로 잘 알고 있기 때문에) 회사 내 규칙을 넘어서는 일정한 수준의 신뢰 관계를 구축하게 된다.
팀의 크기를 고려할 때는 제프 베저스(Jeff Bezos)의 "피자 두판(two-pizza) 팀" 이라는 마법 주문을 염두에 두자. 이 주문은 (미국식) 피자 두판을 나누어 먹으면 충분한 정도의 인원으로 구성된 팀이라는 의미이다. 대략 6명에서 10명 정도 규모가 되겠다. 그간 내가 같이 일했던 성공적인 팀은 대개 다음과 같은 역할로 구분되었다.
- 1명의 UX 디자이너
- 1명의 제품 관리자
- 4-5명의 엔지니어
- 1명의 QA
2. 같은 공간에 배치한다(Collocated)
질문에 대한 답을 얻는 가장 쉬운 방법은 자리에서 일어나서, 그 질문에 대답할 수 있는 사람에게 걸어간 다음, 질문 하는 것이다. 한 장소에 있는 팀은 훨씬 더 효율적이다. 이런 팀은 칸반/스크럼 보드, 화이트보드 스케치, 종이 프로토타입 같은 물리적인 도구들을 함께 사용할 수 있다. 비언어적인 커뮤니케이션의 장점을 얻을 수도 있다. 그때 그때 커뮤니케이션 할 수 있는 기회가 많아지면 뜻밖의 결과를 얻게 되는 경우도 많다.
한 공간에 배치된 팀은 "공간"을 함께 구성할 수 있다. 이 공간은 그 자체가 커뮤니케이션의 일부가 될 것이다. 다양한 도구들을 벽에 붙이게 된다. (분석판과 같은) 정보 방열판을 통해서 팀원들이 팀의 목표의 진척에 대해 그 때 그 때 파악할 수 있다. 그리고 이러한 공간에서 함께 일하면서 팀은 그 팀 고유의 기운과 에너지가 생기게 된다. 이렇게 활발한 상황에서 팀원들 사이에서 에너지가 전해지며 사무실에 있는 다른 팀원 모두에게 영향을 미칠 수 있다.
나는 많은 사람들이 이렇게 100% 같은 공간에서 일하는 팀이라는 장점을 누릴 수 없다는 것도 잘 알고 있다. 이런 상황에 처한 팀에서도 혁신이 가능하지만, 혁신을 촉진할 수 있는 약간의 도구가 필요하다. 이 주제에 대해서는 다른 글(Designing with remote teams)에서 다루었다.
3. 한 팀에 속하도록 한다(Dedicated)
한 팀에 속하도록 하기가 쉽지 않은 경우가 많으며, 특히 디자이너를 배치할 때 이런 문제가 생기는 경우가 많다. 어떤 이유에서인지 개발자들은 한 팀에만 속할 수 있지만, 디자이너는 동시에 여러 팀의 과제를 쉽게 처리할 수 있다는 믿음이 업계에 널리 퍼져 있다. 이런 생각은 분명히 잘못된 것이다. 어떤 팀 구성원이 여러 팀을 지원하는 경우, 대개는 컨텍스트 스위칭, 우선순위화, 이메일 등의 부차적인 일을 해야 하고, 결국 여러 작업을 맡기면서 기대했던 생산성보다 훨씬 더 많은 비용이 들게 된다.
세 팀의 업무를 담당하는 디자이너(개발자든 제품 관리자 등 어떤 사람이라도)가 매일 두 팀 사람들을 애먹이는 경우를 생각해 볼 수 있다. 그 디자이너는 어떤 우선 순위에 따라 한 팀의 일을 선택한 다음, 나머지 두 팀 사람들에게 오늘은 왜 그 팀의 일을 할 수 없는지를 설명하게 될 것이다. 이런 일 때문에 효율성이 떨어지는 것은 물론이고 그 디자이너는 어떤 팀에 줄을 서야 할지, 소위 사내 정치를 의식하거나 아니면 모든 팀과 잘 지낼 수 있도록 하루에 18시간씩 일을 하는 방법 중 하나를 선택할 수 밖에 없는 데, 둘다 썩 좋은 옵션은 아니다.
한 팀에만 속하는 사람은 자신의 일에 집중할 수 있는 기회가 있다. 그리고, P1(최우선순위의 일)이 명확하기 때문에 작업 시간을 어떻게 해야 할지도 알고 있다. 작업이 끝나기를 기다리고 있는 같은 팀의 동료에게 일을 미루어서도 안된다. 이런 팀이 작업 결과도 더 좋고 효율적으로 일하게 된다. 또한 여러 팀의 사람들과 일하기 위해서 "일단 끝내고 보자"는 식의 태도가 아니라 지속적으로 같은 문제에 집중하게 되므로 혁신적인 돌파구를 찾아낼 수 있는 기회가 많아진다.
4. 팀 내에서 해결한다(Self-sufficient)
혁신적인 팀의 가장 중요한 자산 중 하나는 할 필요가 있는 일을 해야 할 때 바로 실행에 옮길 수 있는 능력이다. 무엇인가를 해보려고 할 때 다른 팀을 의존해야 한다면 팀의 모멘텀, 그리고 더 중요한 학습과 발전에 영향을 미치는 연습과 실험 과정의 진행 속도가 느려질 수 밖에 없다. 성과를 얻기 위해 필요한 모든 역량으로 팀을 만들면, 기존의 전통적인 팀에서 안고 있던 많은 제약들을 해소할 수 있다.
팀 내에서 해결한다는 것은 여러 의미가 있겠지만, 그 핵심은 적어도 기술, 제품, 디자인에 있어서 각각을 대표할 사람이 있어야 한다는 의미다. 프로젝트가 고유 시스템과 인터페이스를 한다거나 위의 세가지 요소외의 다른 원칙에서 통찰을 얻어야 한다면 피자 두판 크기의 팀이라는 조건을 염두에 두고 필요한 것을 추가하면 된다. 작은 규모로 팀을 유지하되 팀에서 필요한 일은 팀에서 처리할 수 있도록 하기 위한 방법으로 다방면의 능력이 있는 사람을 채용하기도 한다. 이를 테면 연구 주제를 설계하고 수행하거나 전체 스택을 개발할 수 있는 사람들이 그런 사람들이다. 팀의 역량이 커질 수록(그것에 반드시 역할일 필요는 없다), 여러 가지 이슈를 내부에서 처리할 수 있는 팀이 될 것이다.
혁신 팀을 구성할 때는 위의 네 가지의 특성을 고려한다. 이들 특성은 초기 팀 구조를 잡을 때 가이드라인으로 쓸 수 있을 것이다. 시간이 지나면 조직의 고유한 컨텍스트에 따라서 이러한 구조는 각각의 회사에 맞도록 변형될 것이다. 그렇지만, 이 글에서 설명한 접근 방법을 바꾸는 경우에도 가장 기본이 되는 목표, 즉 조직으로써 우리 팀의 성공하기 위해서 무엇을 할 것인지라는 목표를 기억해 두기 바란다.
TAG :
이전 글 : 소프트웨어와 하드웨어, 가치의 균형점은 어디일까?
다음 글 : 구글 글래스와 미래
최신 콘텐츠