메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

IT/모바일 >

성장하는 개발팀 만들기

한빛미디어

|

2017-01-03

|

by 한빛

16,407

fig1.jpg

 

대부분 무엇인가 관리할 때는 다양한 방향을 제시해야 한다고 생각합니다. 하지만 이 책에서는 우리 스스로가 아닌, 우리의 팀에게 어떻게 방향을 결정해야 하는지, 무엇을 해야 하는지 결정하게 합니다. 이런 것들이 어떻게 가능할까요?

 

다니엘 핑크가 쓴 『드라이브』에서, 그는 목적, 자율성, 숙련이 직원의 만족과 제품의 생산성을 이끄는 핵심이라고 설명합니다. 이는 제 의견과 상당히 비슷합니다. 이 책에서 설명하려는 본질적인 방법이 뜻하는 의미와 많은 부분에서 일치합니다. 왜 그런지 살펴봅시다.

 

 

fig2.jpg

 

목적은 비즈니스로부터 나옵니다.

 

반드시 만들어야 할 것과 연기해야 할 것을 구분하여 개발팀을 이끌어 나가기 위해서 한 사람은 반드시 비즈니스에만 전념해야 합니다. 이를 구분하는 사람이 제품 책임자나 사용자가 될 수도 있습니다. 하지만 이 책에서는 제품 책임자가 한다고 가정합니다. 비즈니스에 전념하는 사람이 제품을 관리하고 방향을 제시해야만 개발팀이 제품에 대한 주인 의식을 가질 수 있습니다. 또, 그렇게 됨으로써 최상의 결과를 얻어낼 수 있습니다.

 

제품 책임자는 제품의 목적을 제시해야 합니다. 대략적인 방향, 구체적인 방향 모두로 말이죠. 그리고 매일 팀과 소통합니다. 왜 이 일을 해야 하는지, 가장 중요한 문제는 무엇인지, 어떻게 이 문제를 해결할 수 있는지 의견을 나눕니다. 논의해야 할 것이 있거나 문제가 있을 때는 그것을 해당 개발팀에게 제시하기도 합니다. 그리고 개발팀이 함께 해결책을 마련할 수 있도록 도와줍니다.

 

어떤 조직에서는 제품 책임자가 논의나 문제 제기 없이 해결책만 가져올 때가 있습니다. 이 방법도 문제 없어 보이지만 이상적이지는 않습니다. 창의적으로 문제를 해결하는 것이 아니라 이미 논의가 끝난 해결책만으로 개발한다면 목표 의식을 얻을 수 없으므로 팀의 생산성은 크게 떨어집니다.

 

모든 팀이 함께 문제를 해결하려 할 때, 제품 책임자는 제품에 무엇이 필요한지 이를 어떻게 표현할 수 있을지를 배웁니다. 팀뿐만 아니라 제품 책임자도 같이 성장할 수 있게 됩니다. 최고의 순간이기도 하죠.

 

fig3.jpg

 

자율성은 팀에게 책임감을 부여합니다.

 

제품 책임자는 해결해야 할 문제가 무엇인지 제시합니다. 그리고 팀은 주어진 문제를 어떻게 해결할지 결정하죠. 진정한 자율성이 있다면 팀의 일을 중복으로 확인할 필요가 없습니다. 그들이 결정하고 그들이 만들고 조직 모두가 결과를 확인합니다. 모두가 배우는 것이죠.

 

개발팀은 1~2주에 해당하는 개발 주기를 거칠 때마다 제품 책임자와 함께 무엇을 완료해야 하는지 상의해야 합니다. 잘 작동하는 상태로 배포할 수 있는 피처들이 얼마나 되는지 구분합니다. 구분한 피처들을 어떻게 배포할 것인지 결정합니다. 그리고 그들 스스로가 계획을 세워 일을 끝냅니다. 이렇게 팀이 일을 끝낸 이후 "작동하는 소프트웨어를 보여주세요."라고 요구하면 됩니다.

 

자기 조직화(Self-Organizing)한 팀은 자율성이 높아지고, 문제를 해결하는 데 창의성을 더 많이 발휘할 수 있습니다. 그렇게 되면 생산성도 높아지게 되죠. 제품이 나아가야 할 목표를 함께 이해하는 자기 조직화한 팀을 만드는 것 또한 최고의 순간입니다.

 

fig4.jpg

 

반복적인 개발 주기로 완벽해질 수 있습니다.

 

개발 주기를 거칠 때마다 개발팀은 완료된 피처들을 증가시켜 나갑니다. 처음에는 어렵겠지만 개발 주기가 지날 때마다 더 나은 방법을 찾아갈 수 있습니다. 완벽하게 숙달할 때까지 배우는 것이죠. 개발 주기가 끝날 때마다 완료된 피처의 기준을 높이세요. 여기에서 말하는 기준은 배포할 수 있을 정도의 완성도를 뜻합니다. 배포할 수 있는 피처들의 품질을 더 높이고 기준을 엄격하게 만드세요. 완전히 여러분의 것으로 만들 때까지 말이죠.

 

각 개발 주기를 사용할 수 있는 소프트웨어를 만드는 연습 과정으로 여기세요. 마지막에 "작동하는 소프트웨어를 보여주세요."하면, 모든 사람이 소프트웨어의 상태를 볼 수 있겠죠. 그리고 더 나은 제품을 만들려면 무엇을 해야 하는지 고민하세요. 또한, 완전히 숙달할 때까지 나아가야 합니다.

 

관찰하고 적용해 나아간다는 스크럼의 정신처럼, 항상 무엇을 달성했는지 관찰하세요. 무엇이 일정을 지연시켰는지 기록하고 상황을 개선할 방법을 찾으세요. 팀의능력을 향상함으로써 조직 모두가 완벽하게 숙달할 때까지 나아갈 수 있습니다.

 

제품이 나아가야 할 목표를 함께 이해하는 숙련된 자기 조직화 팀이 되는 것이 핵심입니다.

 

The nature of software development

 

댓글 입력
자료실