🌈 Chapter 16: 경영진을 위한 소프트웨어 개발의 본질

• 본질적인 방법에서는 개발팀이 스스로를 관리한다.
• 제품 책임자는 제품이 나아가야 할 길을 제시하고 개발팀원, 이해관계자와 함께 일한다.
• 각 팀은 크로스펑셔널 팀으로서 각 피처를 추가하는 데 필요한 기술과 능력을 보유하고 있다. 본질적인 방법에 가까워질수록, 조율하는 빈도는 줄어들게 된다.
• 각 팀은 스스로가 계획을 세워 행동한다. 모든 개발팀이 이처럼 일한다면 최소한의 진행 사항만 관리하면 된다.
• 물론 그럼에도 관리 업무는 필요하다. 가능한 한 최고의 결과를 얻으려면 인력 선발은 팀에게 맡겨야 한다. 그러나 인사 결정, 채용과 해고는 반드시 경영진이 해야 한다.
• 경영진이 가치 있는 제품을 뚜렷하고 유연하게 개발하는 효율적인 팀을 만든다면 경영진이 해야 할 일도 그만큼 증가한다.

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

• 경영진은 조직의 비즈니스 방향을 결정한다. 이 결정들은 종합적인 계획과 함께 시작된다.
• 먼저 해결해야 할 문제와 진행해야 할 기회를 구분한다.
• 본질적인 방법의 관점에서 보면 장기적인 계획은 언제든 달성할 수 있다. 모든 분야의 사람들이 이런 계획 활동에 관여애햐 한다.
• 경영진은 우리가 맡을 수 있는 제품과 프로그램의 개수에 제한을 두는 일이 가장 중요한 일이다. 먼저 맡은 일을 끝내고 그 후에 다른 일을 더해야만 한다.
• 여러 일을 동시에 하는 것은 모든 일정을 지연시킬 뿐이다.

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

• 본질적인 방법을 따르자면, 우리는 높은 가치를 지닌 피처를 먼저 개발한다. 그리고 경영진은 자세한 내용을 깊게 파고들 필요 없이 진행 사항을 관찰할 수 있다.
• 먼저, 제품 책임자가 제품이 가진 핵심적인 것을 다루어 볼 수 있도록 도와주고 시간과 예산이 허용하는 한도 내에서 그다음 중요한 것을 채워 넣는다.

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

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

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

• 솔직히 말해 우리의 일은 계획을 따라가는 것이 아니고, 최선의 결과를 낼 수 있는 방향으로 프로젝트를 이끄는 것이다.
• 제품을 자주 배포할 때, 즉 사용자에게 실질적인 가치를 전달할 때는 우리에게 주어진 예산과 시간을 모두 쓰기 전에 프로젝트를 끝낼 수 있다. 이유는 이미 사용자가 정말로 원하는 피처들을 모두 완성했기 때문이다.
• 항상 가치에 집중하고 항상 계획 단계부터 가장 가치 있는 것이 무엇인지 확인해야 한다.
• 계획이 어떻게 진행되는지 확인하려면 제품 책임자에게 작동하는 소프트웨어를 보여 달라고 요청한 뒤 우리가 요청했던 가치가 어떻게 표현됐는지 살펴본다.

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

• 상위 경영진도 마찬가지로 일반적인 조직에 대한 책임이 있다.
• 일반적으로 예산을 결정할 때는 경영진이 제품 책임자를 지정하고 가능하다면 추가 인원을 지정하고 제품 책임자가 핵심 팀원들을 선택하고 팀 전체가 나머지 인원들을 선별한다.
• 이런 구조라면 제품 책임자와 각 개발팀은 맡은 일을 끝내기 위해 자기 조직화한다.
• 세부적인 내용은 하위 조직에서 결정하도록 밀어붙인다. 팀 규모를 제어할 수 있도록 예산을 편성하고, 우리가 할 수 있는 결과에 집중한다.

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

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

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

• 장기적인 계획을 기반으로 한다면 경영진은 어떤 프로젝트와 제품에 투자할지를 결정해야 한다.
• 가끔은 회사의 우선순위나 환경에 변화가 생길 수도 있다. 이는 제품의 비전, 예산, 그리고 이와 비슷한 것들이 조정됨으로써 조직 모든 곳으로 퍼지게 된다.
• 가끔은 경영진이 작업 결과물을 살펴보고 제대로 표현되지 못한 것을 보거나 경영진 스스로 무엇이 필요한지 깨닫게 될 때가 있다. 이때도 마찬가지로 팀의 비전이 조정된다.
• 가끔은 개발팀이 생각한 만큼 진행이 잘 안 될 때도 있다.

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

• 개발팀은 매일 어떻게 일을 할지 결정한다.
• 제품 책임자는 주 단위로 그들이 무슨 일을 하는지 관리한다.
• 경영진은 작업 결과물을 살펴보고 진행 상황이 예산과 시간에 어울리는지 검토한다.

📚 요약하자면 이렇습니다.

• 소프트웨어 개발의 본질적인 방법은 일하는 사람에게 권한을 위임하는 것이다.
• 몇몇 경영진은 필요할 때 도와줄 수 없다는 불암감에 위임하기를 주저해 왔다. 하지만 운이 좋게 본질적인 소프트웨어 개발에서는 무슨 일이 일어나는지 확실히 알 수 있으니 매우 안전하게 일을 위임할 수 있다.
• 개발팀이 "작동하는 소프트웨어를 보여주세요."를 받아드릴 때, 우리는 프로젝트가 얼마나 진행됐는지, 그들이 무엇을 작업하고 있는지, 어떻게 진행되는지 항상 알고 있다.