한빛출판네트워크

 

 

누군가 저에게 이렇게 말했습니다.

 

"론, 현실 세계에는 경영진이 있어요. 그들은 필요한 존재죠. 하지만 이 책에서는 경영진이 하는 일이 그다지 많지 않네요. 경영진은 무엇을 해야 하죠?"

 

먼저 저는 우리가 현실에 처한 문제를 해결하는 것이 목적이라고 생각합니다. 경영진은 꼭 필요하죠. 하지만 항상 경영해야 할 필요는 없습니다. 이제 그 이유를 살펴봅시다.

 

본질적인 방법에서는 개발팀이 스스로를 관리합니다. 제품 책임자는 제품이 나아가야 할 길을 제시하고 개발팀원, 이해관계자와 함께 일합니다. 개발 주기마다 "작동하는 소프트웨어를 보여주세요."라고 확인하기 때문에 모두가 진행 상황을 알 수 있습니다. 이 단계는 팀 외부에 있는 이해관계자를 조율하고 팀에게 도움이 더 필요한지를 쉽게 판단할 수 있게 합니다.

 

각 팀은 크로스펑셔널 팀으로서 각 피처를 추가하는 데 필요한 기술과 능력을 보유하고 있습니다. 팀원들은 스스로 테스트하고 문서로 만드는 등, 모든 일을 합니다. 본질적인 방법에 가까워질수록, 조율하는 빈도는 줄어들게 됩니다.

 

각 팀은 스스로가 계획을 세워 행동합니다. 팀원들은 업무를 분담하고 맡은 일을 끝낼 수 있도록 하죠. 모든 개발팀이 이처럼 일한다면 최소한의 진행 사항만 관리하면 됩니다.

 

물론 그럼에도 관리 업무는 필요합니다. 가능한 한 최고의 결과를 얻으려면 인력 선발은 팀에게 맡겨야 합니다. 그러나 인사 결정, 채용과 해고는 반드시 경영진이 해야 합니다. 프로젝트에 필요한 예산은 제품 책임자와 팀이 함께 제안해야 합니다. 그러나 프로젝트 내외부에서 사용할 예산을 결정하는 일은 경영진이 맡아야 하죠.

 

경영진은 가끔 자신이 해야 할 많은 일을 팀에게 넘기면 경영진이 필요 없어지진 않을까 생각하곤 합니다. 하지만 생각해보세요. 경영에서는 이런 일을 위임이라고 부릅니다. 경영진이 가치 있는 제품을 뚜렷하고 유연하게 개발하는 효율적인 팀을 만든다면 경영진이 해야 할 일도 그만큼 증가합니다. 또 다른 팀을 만들고 그 후 또 다른 팀을 만드는 일이죠.

 

이제 피터 드러커(Peter Drucker)가 언급한 경영의 요소들을 살펴봅시다. 이 요소들은 계획, 조직화, 인원 선별, 목표 설정, 통제입니다. 이 책에서 각각 알아볼 것입니다. 이 요소들이 본질적인 방법이 가지는 맥락과 경영에서 어떤 의미가 있는지도 살펴보겠습니다.

 

 

 

장기적인 목표에는 어떻게 접근하는 것이 좋을까요?

 

론, '평소와 다름없는 경영'은 괜찮은 의견입니다. 하지만 저는 장기적인 목표를 가진 회사에서 일합니다.

이 책에서도 장기적인 계획이 필요하다고 말했고요. 장기적인 목표에는 어떻게 접근하는 것이 좋을까요?

 

'회사 위쪽' 어딘가 있는 경영진은 조직의 비즈니스 방향을 결정합니다. 그들은 무엇이 완성돼야 하고 누가 그 일을 할지와 같은 일반적인 것을 결정하죠. 이 결정들은 종합적인 계획과 함께 시작됩니다. 먼저 해결해야 할 문제와 진행해야 할 기회를 구분합니다. 그리고 시간, 인력, 예산이라는 기준으로 문제를 해결하고 기회를 잡는 데 필요한 노력의 규모를 정의합니다.

 

본질적인 방법의 관점에서 보면 장기적인 계획은 언제든 달성할 수 있습니다. 모든 분야의 사람들이 이런 계획 활동에 관여해야 합니다. 관리, 재정, 제품, 기술 부문에 있는 모든 사람 말이죠.

 

경영진이 해야 할 가장 중요한 일은 무엇이라고 생각하나요? 우리가 맡을 수 있는 제품과 프로그램의 개수에 제한을 두는 것입니다. 먼저 맡은 일을 끝내고 그 후에 다른 일을 더해야만 합니다. 여러 일을 동시에 하는 것은 모든 일정을 지연 시킬 뿐입니다.

 

 

 

월이나 연 단위의 프로젝트 계획은 어떻게 세울까요?

 

중기나 장기적인 노력은 꽤 일반적인 목표와 함께 시작합니다. 본질적인 방법을 따르자면, 우리는 높은 가치를 지닌 피처를 먼저 개발합니다. 그리고 경영진은 자세한 내용을 깊게 파고들 필요 없이 진행 사항을 관찰할 수 있습니다. 상급 기획자와 경영진은 큰 프로젝트에는 일반적인 피처들이 필요하다는 점을 명확히 하고 제품 책임자에게 "작동하는 소프트웨어를 보여주세요."를 요청하면 됩니다.

 

먼저, 제품 책임자가 제품이 가진 핵심적인 것을 다루어 볼 수 있도록 도와주세요. 그리고 시간과 예산이 허용하는 한도 내에서 그다음 중요한 것을 채워 넣읍시다.

 

 

 

일이나 주 단위의 단기 계획은요?

 

본질적인 방법을 따르면, 단기 계획은 개발 단계에서 지속됩니다. 가치 있는 피처에 우선순위를 매기고 그 순서에 따라 개발을 끝내기 때문이죠. 한주 한주가 지나갈 때마다 가치는 눈에 띄게 발전합니다. 계획은 개발 주기를 지나갈 때마다 수정될 것이고 우리 모두가 진행 상황을 볼 수 있습니다.

 

이 방법은 매우 간결합니다. 개발 주기마다 무엇을 달성했는지 관찰할 수 있고 다음 개발 주기에는 무엇을 해야 하는지 계획하는 것이죠. 우리의 노력이 전체적인 비전과 목표에 어떤 영향을 끼쳤는지 꾸준히 살펴보세요.

 

 

 

제 관리 경험은 대부분 프로젝트를 올바른 길로 이끄는 것이었습니다. 계획을 잘 따라가고 있는지 어떻게 확신할 수 있을까요?

 

솔직히 말해 우리의 일은 계획을 따라가는 것이 아닙니다. 최선의 결과를 낼 수 있는 방향으로 프로젝트를 이끄는 것입니다. 단순히 목표 몇 가지를 수정하는 것이 아닙니다.

 

제품을 자주 배포할 때, 즉 사용자에게 실질적인 가치를 전달할 때는 우리에게 주어진 예산과 시간을 모두 쓰기 전에 프로젝트를 끝낼 수 있습니다. 왜일까요? 이미 사용자가 정말로 원한 피처들을 모두 완성했기 때문입니다. 이런 일은 자주 생깁니다. 제품이 어떻게 될지 상상하는 것과 상관없이 새로운 아이디어는 언제나 떠오르는 법이니까요. 본질적인 방법으로 개발한다는 의미는 우리가 프로젝트의 방향을 조정할 수 있다는 뜻과 같습니다. 단순히 계획을 짜고 모든 것에 희망을 걸지 않기 때문이죠.

 

항상 가치에 집중하세요. 항상 계획 단계부터 가장 가치 있는 것이 무엇인지 확인하세요. 계획이 어떻게 진행되는지 확인하려면 제품 책임자에게 작동하는 소프트웨어를 보여 달라고 요청하세요. 우리가 요청했던 가치가 어떻게 표현됐는지 잘 살펴보세요.

 

 

 

어떻게 해야 최선의 결정을 내릴 수 있을까요?

 

론, 당신의 조언은 좋은 생각입니다. 하지만 저는 사람을 적재적소에 배치해야 하는 문제에 자주 직면했습니다. 어떻게 해야 최선의 결정을 내릴 수 있을까요?

 

상위 경영진도 마찬가지로 일반적인 조직에 대한 책임이 있습니다. 그들은 개발을 위한 예산과 인력을 할당하죠. 일반적으로 예산을 결정할 때는 경영진이 제품 책임자를 지정하고 가능하다면 추가 인원을 지정합니다. 그리고 제품 책임자가 핵심 팀원들을 선택하고 팀 전체가 나머지 인원들을 선별합니다. 이런 구조라면 제품 책임자와 각 개발팀은 맡은 일을 끝내기 위해 자기 조직화합니다.

 

세부적인 내용은 하위 조직에서 결정하도록 밀어붙이세요. 팀 규모를 제어할 수 있도록 예산을 편성하세요. 우리가 할 수 있는 결과에 집중하기 바랍니다. 그리고 팀이 무엇을 해야 하고 어떻게 조직돼야 하는지 결정하는 데 집중할 수 있도록 도와주세요.

 

 

 

인사 결정은 어떻게 하나요? 채용과 해고는 누가 결정하나요?

 

물론 인사 활동은 관리 부서에서 다루어야 합니다. 적어도 관리 부서의 동의가 필요하죠. 하지만 구성원 선택과 추천은 팀에게 위임해야 합니다. 인력을 더 충원할지 말지 팀 스스로 결정하도록 두세요. 누구를 선택할지도 말이죠. 무엇이 필요할지 팀에서 더 잘 알기 때문입니다.

 

전반적인 채용 가이드라인과 계획, 우리에게 인력이 얼마나 있는지를 팀이 이해할 수 있도록 도와주세요. 팀이 큰 그림을 잘 이해할수록 더 나은 결과를 보여줍니다.

 

 

 

경영진은 프로젝트가 나아가야 할 방향을 제시해야 합니다.

 

조직의 아래쪽에서 모든 결정이 이루어진다면 경영진은 어떻게 나아가야 할 방향을 제시할 수 있을까요?

 

장기적인 계획을 기반으로 한다면 경영진은 어떤 프로젝트와 제품에 투자할지를 결정해야 합니다. 경영진은 각 프로젝트를 책임질 제품 책임자를 지정했습니다. 경영진은 상용화 단계에 가까워질 때마다 제품을 살펴보고 제품 책임자에게 지원과 도움을 줌으로써 제품이 회사의 목표와 계속 부합할 수 있도록 해야 합니다. 방향을 정하는 방법에는 몇 가지 유형이 있습니다.

 

가끔은 회사의 우선순위나 환경에 변화가 생길 수도 있습니다. 제품의 비전, 예산, 그리고 이와 비슷한 것들이 조정됨으로써 조직 모든 곳으로 퍼지게 되죠. 가끔은 경영진이 작업 결과물을 살펴보고 제대로 표현되지 못한 것을 보거나 경영진 스스로가 무엇이 필요한지 깨닫게 될 때가 있습니다. 이때도 마찬가지로 팀의 비전이 조정됩니다.

 

가끔은 개발팀이 생각한 만큼 진행이 잘 안 될 때도 있습니다. 이 책에서 추천하는 방법으로 일한다면 프로젝트가 탈선하는 즉시 알 수 있죠. 그리고 제품 책임자와 팀이 더 나은 일을 하도록 도와줄 수 있습니다. 개발 주기마다 제품을 볼 수 있다면 큰 문제가 생길 확률은 불가능에 가깝습니다.

 

 

 

하지만 업무는 반드시 관리돼야 합니다. 일 단위로 모든 것이 제대로 관리되는지 어떻게 확신할 수 있을까요?

 

개발팀은 매일 어떻게 일을 할지 결정합니다. 제품 책임자는 주 단위로 그들이 무슨 일을 하는지 관리하죠. 경영진은 작업 결과물을 살펴보고 진행 상황이 예산과 시간에 어울리는지 검토합니다. 프로젝트와 맞지 않는 부분이 있다면, 경영진은 조치를 취해야 합니다. 이때 직접 개입하지 않고 해결할 수 있습니다. 조언과 훈련을 제공하되 필요하다면 예산과 인력, 책임을 조정하면 됩니다.

 

 

 

요약하자면 이렇습니다.

 

소프트웨어 개발의 본질적인 방법은 일하는 사람에게 권한을 위임하는 것입니다. 이것 외에 다른 것은 아무것도 없습니다. 이것이 항상 경영진이 일해왔던 방법입니다.

 

사실입니다. 몇몇 경영진은 필요할 때 도와줄 수 없다는 불안감에 위임하기를 주저해 왔습니다. 하지만 운이 좋게도 본질적인 소프트웨어 개발에서는 무슨 일이 일어나는지 확실히 알 수 있으니 매우 안전하게 일을 위임할 수 있습니다.

 

개발팀이 "작동하는 소프트웨어를 보여주세요."를 받아드릴 때, 우리는 프로젝트가 얼마나 진행됐는지, 그들이 무엇을 작업하고 있는지, 어떻게 진행되는지 항상 알고 있습니다. 앞에서 설명했던 지침을 깊이 고민해보고 따른다면 좋은 결과를 얻을 것입니다.