수동 소득 아이디어 2023
민첩한 프레임워크가 대세입니다. Agile Manifesto가 발표된 이후 수많은 회사가 Scrum 및 Kanban과 협력해 왔으며 점점 더 폭포수 모델에서 벗어나고 있습니다.
그러나 실제로는 제품 소유자의 역할이 다양한 방식으로 수행되고 때로는 관련 작업, 책임 및 사고 방식에 대한 명확한 이해가 없다는 것이 반복해서 나타났습니다.
따라서 이 기사에서는 애자일 소프트웨어 개발 분야에서 서비스 공급자로서 작업하면서 반복적으로 관찰한 몇 가지 안티 패턴을 제시하고자 합니다. 그러나 이에 대해 알아보기 전에 먼저 이 역할의 정의를 살펴보겠습니다.
제품 소유자의 정의는 무엇이며 그들의 책임은 무엇입니까?
스크럼 가이드는 다음과 같이 말합니다. “제품 소유자는 개발 팀의 작업 결과인 제품의 가치를 극대화할 책임이 있습니다. 접근 방식은 조직, 스크럼 팀, 개인에 따라 매우 다를 수 있습니다.”
따라서 제품 소유자는 사용자의 “대사”입니다. 이상적으로는 그 자신이 사용자이기도 하므로 개발할 제품의 기술적 요구 사항에 대한 전문가이기도 합니다. 그의 역할에서 그는 개발 팀과의 긴밀한 협력을 통해 제품의 비즈니스 가치와 최종 고객에 대한 이점이 극대화되도록 합니다. 이해 관계자와 협력하여 요구 사항의 “무엇”과 우선 순위를 정의합니다.
실제로 제품 소유자의 역할을 이해하는 데 있어 가장 일반적인 결함은 무엇입니까?
- 그만큼 명령 수신자: 지침을 받아 개발팀에 직접 전달합니다.
- 그만큼 팀 매니저: 개발팀의 보스처럼 행동하며 적극적인 마이크로매니지먼트에 참여합니다.
- 그만큼 기술 설계자: “무엇”뿐만 아니라 “어떻게”도 정의하며 개발팀은 아키텍처 문제에 대해 목소리를 내지 않습니다.
- 그만큼 백로그 은둔자: 제품 백로그는 제품 소유자가 단독으로 관리하며 그렇지 않으면 잠겨 있습니다.
1. 명령 수신자
이러한 역할에 대한 이해를 바탕으로 제품 소유자는 제품 백로그의 우선 순위를 정하는 “마스터”가 아닙니다. 대신 그는 이해 관계자로부터 요구 사항이나 원하는 것을 얻고 적절한 제품 백로그 항목을 작성하여 요구 사항이나 비즈니스 가치에 도전하지 않고 팀에 전달합니다.
이 접근 방식은 실제로 매우 일반적입니다. 많은 회사는 스크럼 구현이 기본적으로 일련의 역할, 의식 및 아티팩트로 구성되어 있으므로 스크럼에 대한 기술 관료적 또는 절차적 접근 방식만 있다고 생각합니다. 마음가짐과 가치관의 핵심이 배경으로 물러나거나 충분히 투명하지 않은 경우가 많다. 따라서 실제로는 “프록시 PO”에 대해 말하는 것을 좋아합니다.
이 때문에 다양한 문제가 발생합니다. 이해 관계자가 전통적인 접근 방식(“명령 및 제어”)의 연습된 사고 방식을 지속한다면 스크럼 접근 방식과의 충돌이 불가피합니다.
따라서 문제는 회사에서 스크럼을 올바르게 구현하고 애자일이라는 용어에 기술관료적 프레임워크 이상의 의미가 있음을 이해하는 것입니다.
팀에서 함께 일하고 비즈니스 가치를 극대화하려는 마음가짐입니다. 따라서 이는 경영진과 이해 관계자의 지원도 받아야 합니다. 제품 소유자는 요구 사항에 도전하고 큰 그림을 보고 무엇이 이치에 맞고 비즈니스 가치를 창출하는지 이해함으로써 제품의 비전을 제시해야 합니다.
따라서 그는 경영진이나 이해 관계자의 “요구 사항 지침”이 아닌 제품의 성공과 비즈니스 가치 극대화에 주로 전념합니다. 즉, 제품 소유자는 자신의 환경에서 가져온 요구 사항의 “우체부”가 아니라 해당 의사 결정 권한을 가진 제품의 기술 요구 사항 전문가입니다.
이러한 역할에 대한 잘못된 이해를 바탕으로 판단할 수 있는 효과는 실제로 다음과 같습니다.
- 팀은 비즈니스 가치를 극대화하는 것이 아니라 작업을 완료하기 위해 노력합니다.
- 초점이 없습니다.
- 모든 것이 우선순위가 있습니다.
- 모두가 모든 것을 원하기 때문에 이해관계자들은 불행합니다.
- 팀은 무엇을 위해 싸우는지 모릅니다.
2. 팀장
실제로 두 번째로 흔한 현상은 제품 소유자가 자신이 팀에 대한 책임이 있다고 생각하고 팀 관리자 및 때로는 제품 관리자의 역할을 맡는 것입니다. 물론 이것은 제품 소유자가 실제로 스크럼 팀의 일부이기 때문에 의도된 것이 아닙니다. 스크럼에는 계층이 없습니다. 제품 소유자, 스크럼 마스터 및 구현 팀은 해당 분야의 전문가이므로 동등한 입장에서 동료로 일합니다.
일반적으로 제품 소유자가 관리자 역할을 맡는지 여부를 결정하는 방법은 다음과 같습니다.
- 제품 소유자는 “명령 및 제어”를 실행하고 팀의 진행 상황을 모니터링하고 스프린트 중에 팀에 압력을가합니다.
- 그는 모든 팀원과 일대일 인터뷰를 진행합니다.
- 이해 관계자와 경영진은 제품 소유자를 팀 리더로 봅니다.
- 제품 소유자는 각 팀 구성원의 개별 성과에 관심이 있습니다.
- 제품 소유자는 팀이 내린 결정을 승인해야 합니다.
제품 소유자는 스프린트 목표를 달성하기 위해 개발 팀과 동등한 입장에서 신뢰를 가지고 작업해야 하므로 관리자로서 제품 소유자의 행동이 중요합니다. 따라서 개발팀이나 스크럼팀을 관리하는 것은 제품 소유자의 일이 아닙니다.
대신 그는 비즈니스 가치에 우선순위를 둔 제품 백로그를 통해 제품 비전을 향해 팀을 안내합니다. 개발팀은 제품과 고객의 이익을 위해 독립적이고 자율적으로 결정을 내립니다.
3. 기술 설계자
실제로 자주 발생하는 역할 이해의 세 번째 문제는 제품 소유자가 자신의 역할과 개발 팀의 역할 구분에 대한 명확한 견해가 없다는 것입니다.
제품 소유자는 “무엇”뿐만 아니라 도전과 기회를 개발 팀에 제시하고 토론을 시작합니다.
개발 팀은 (기술적) 구현과 제품 소유자가 제시한 요구 사항, 문제 및 과제에 대한 솔루션으로서 “방법”을 담당합니다. 특히 구현 영역, 즉 “어떻게”에 대한 지식을 보유한 제품 소유자는 “구현 팀 분야에서 밀렵”하는 경향이 있습니다.
일반적으로 제품 소유자가 이러한 방식으로 자신의 역할을 생성했는지 여부를 어떻게 알 수 있습니까?
- 제품 소유자는 솔루션이 이미 정의된 완전히 준비된 사용자 스토리를 가지고 개선 회의에 참석합니다. 개발팀에는 논의할 공간이 없습니다.
- 개발팀은 디자인과 결정을 할 수 없고 실행만 할 수 있기 때문에 답답합니다.
- 서사시 또는 관련 도전이나 문제에 대한 논의가 없습니다.
여기에서도 개발팀에 대한 제품 소유자의 마음가짐이나 관점이 결정적입니다. 이것은 “데이터 타이피스트”로서 지시에 따라 코드를 작성하는 제품 소유자의 확장된 작업대가 아니라 자신의 업무를 알고 있는 구현 전문가 팀입니다.
개발팀도 이 주장에 부응한다면 제품 소유자의 설명된 행동은 예상되는 결과와 함께 개발팀에서 엄청난 좌절을 초래할 것입니다.
따라서 제품 소유자는 자신의 요구 사항, 문제 및 과제를 개발 팀에 제시하고 그들이 고객과 제품을 위한 최상의 (기술적) 솔루션을 찾을 것이라고 믿어야 합니다.
4. 백로그 은둔자
마지막 요점은 제품 백로그 관리에 관한 것입니다. 일부 제품 소유자는 자신이 제품 백로그를 관리할 수 있는 유일한 사람이라고 생각합니다. 그렇기 때문에 누구도 새 백로그 항목을 삽입할 수 없습니다.
제품 오너는 제품 백로그에 대한 책임이 있지만 이것이 그가 새로운 항목을 입력할 수 있는 유일한 사람이라는 의미는 아닙니다. 오히려 제품 백로그는 제품 소유자, 개발 팀 및 이해 관계자가 적극적으로 기여해야 하는 살아있는 인공물입니다.
제품 백로그에 대한 제품 소유자의 책임은 다음을 의미합니다.
- 백로그의 모든 항목 또는 항목을 이해해야 합니다.
- 항목은 비즈니스 가치에 따라 우선 순위가 지정됩니다.
- “준비의 정의”에 따라 개발 준비가 될 때까지 항목을 개선합니다.
스크럼은 협업 프레임워크입니다. 이것은 팀이 개인의 합 이상이라는 것을 의미합니다. 제품 백로그에 대한 모든 팀 구성원의 기여는 바람직할 뿐만 아니라 필요합니다. 모든 항목을 이해하고 항목이 비즈니스 또는 제품과 얼마나 관련이 있는지 평가하는 것은 제품 소유자의 임무이자 책임입니다. 따라서 스프린트 계획의 스프린트에 포함할지 여부와 시기를 결정합니다.
따라서 제품 소유자가 제품 백로그를 “소유”한다는 것은 신화입니다. 자세한 내용은 Christiaan Verwijs의 기사를 참조하십시오.
제품 소유자의 오해된 역할과 관련하여 유사한 기사가 Scrum.org에 게시되었는데, 이는 추가 읽기로 권장됩니다.
