Scrum에서 개발자가 고객과 직접 대화해야합니까 (PO를 우회)?


12

스크럼의 제품 소유자는 자신이 즉시 응답 할 수없는 구현 기능에 대해 팀의 매우 자세한 질문을 어떻게 처리해야합니까? 개발자가 고객과 직접 대화 할 수있는 가장 빠른 솔루션은 언제입니까?

팀과 고객 간의 직접적인 의사 소통이 제품 소유자의 역할을 훼손하는지 궁금합니다. PO가 독점적으로 고객을 대표해야하므로 요구 사항과 관련된 모든 질문에 답변해야한다고 생각합니다. 그를 우회하면 약해져 결국에는 불필요 해집니다 ...

스크럼에 모범 사례가 있습니까?


2
나는 소유자가 개발과 고객 사이의 유일한 연락 지점이어야한다는 것에 동의해야합니다. 제품 소유자를 불필요하게 만드는 것이 원인이거나 역할을 우회하는 것이 더 빠르다는 데 동의하지 않습니다. 이것을 10 명의 개발자가있는 프로젝트에서 10 명의 사람들이 고객과 지속적으로 대화하고 기능을 협상하는 것을 원하지 않습니다. 첫째, 고객을 성가 시게하고, 둘째, 실제로 개발하는 데 시간이 걸립니다. 추가 정보가 필요하여 모든 작업을 차단 한 경우 요구 사항 캡처 단계를 수정하고 소유권을 수정하지 않아야합니다.
Patrick Hughes

"확실히 빠른 솔루션 일 때 ..."분명한 점을 지적하고 싶을 때 : 더 빠를수록 좋은 것은 아닙니다.
Eric King

답변:


23

"누가 누구에게 말하지 말아야합니까?"라고 말하는화물 숭배 또는 교과서에 집착하지 말고 두뇌를 켜고 가장 잘 작동하는 것을하는 것은 항상 좋은 생각입니다 (특히 소위 애자일 프로젝트에서). 계획.

@PatrickHughes의 의견에 따라 PO와 고객 간의 커뮤니케이션이 표준이되어야하지만 복잡한 비즈니스 요구 사항을 명확히해야하는 상황과 개발자와 개발자 간의 직접적인 커뮤니케이션이 필요할 수 있습니다. 비즈니스 전문가가 업무 속도를 크게 높일 것입니다. 이러한 상황에서는 중간에 PO를 사용하여 "중국인 속삭임"을하지 말고 개발자와 비즈니스 전문가가 서로 직접 대화 할 수 있도록해야합니다.

그러나 PO를 우회해서는 안됩니다. 이상적으로 그는 대화에 참여할 가능성이 높습니다. 고객은 대화 중에 고객이 테이블에 완전히 새로운 요구 사항을 제시하지 않았거나 이전에 합의 된 요구 사항과 상반되는 요구 사항을 제시하지 않았 음을 확인할 수 있습니다.

이것은 또한 관련된 사람들과 상황에 달려 있습니다. PO는 특정 개발자와 고객의 전문가를 충분히 신뢰하여 두 사람이 특정 주제에 대해 이야기하고 나중에 말한 내용을보고하게 할 수 있습니다. 다른 상황에서는 다른 사람들과 관련하여 더 적극적으로 참여하는 것을 선호 할 수 있습니다. 이 결정을 올바르게하는 것은 훌륭한 프로젝트 관리의 핵심입니다.


"애자일 개발의 전체 아이디어는화물 컬트 또는 교과서에 집중하는 것이 아니라 두뇌를 켜고 프로젝트에서 가장 잘 작동하는 것을 수행하는 것입니다."
Giorgio

1
+1 민첩한 방식으로 스크럼을 수행하는 경우 비즈니스 전문가가 아마도 팀의 일원이되어 어쨌든 가능할 것입니다.
Marjan Venema

1
권리. PO는 게이트 키퍼가되어서는 안됩니다. 대신 PO는 궁극적으로 제품에 대한 책임입니다.
로봇 고트

@StevenBurnap은 PO가 처음부터 현장에서 전문가가되어야한다는 것을 의미합니다 ... 제 경험에 따르면 항상 그런 것은 아닙니다.
tizenegy

3
@Giorgio : 절대적으로, IMHO "Agile development"는 용어보다 훨씬 오래되고 그 자체로 제한되지 않는 좋은 습관을 통합 한 용어입니다.
Doc Brown

2

개발자로 귀하를 고용 한 회사의 고객은 귀하를 고용하는 회사와 다른 목표를 가지고 있음을 기억해야합니다.

제품 소유자는 고객의 목표보다는 회사의 목표를 나타내야합니다. 따라서 개발자가 고객에게 직접 가면 자신의 회사를 손상시킬 수 있습니다.


모든 사람의 목표는 예산과 목표에 따라 가능한 최고의 제품을 제공하는 것이어야합니다. 그것을하는 방법 만이 가능한 토론의 원천입니다.
jwenting

2
그래도 순진하지 않습니다. 회사는 최소 계약 사양을 수행하고 더 수익성있는 프로젝트로 전환하는 것을 선호 할 수 있습니다. 또는 내 경험상 고객은 가격을 동일하게 유지하면서 기능을 추가하고 범위를 확장하려고 할 것입니다.
Ewan

1

개발자에게는 제품 소유자가 고객입니다. 이상적으로는 (항상 가능한 것은 아님) 제품 소유자는 고객, 도메인 전문가 및 시스템의 미래 사용자를 직접 대표해야합니다.
이것이 바로 직접적이고 정확한 정보를 얻을 수 있고 프로세스에 가능한 한 짧은 라인을 확보 할 수있는 가장 좋은 방법입니다.

이상적인 예는 아마도 지금 함께 일하고있는 팀일 것입니다. 제품 소유자는 현장에서 설계 결정을 승인 할 수있는 모든 권한을 가진 최종 사용자 및 도메인 전문가입니다 (실제로 그렇게 할 의지와 능력). 그는 팀의 핵심 부분으로, 구현 관련 질문 및 테스트 시나리오에 대한 즉각적인 피드백을 제공함으로써 제품 구축시 프로그래머 및 테스터뿐만 아니라 사용자 스토리를 작성하는 분석가 및 디자이너를 직접 지원합니다.
코딩하는 동안 미래의 사용자가 옆에 앉아있는 것보다 줄이 실제로 짧을 수는 없습니다. :)


"코딩하는 동안 미래의 사용자가 옆에 앉아있는 것보다 줄이 실제로 짧을 수는 없습니다.": 이것이 항상 좋은지 여부는 의문입니다.
Giorgio

@Giorgio는 물론 관련된 사람들에 따라 다릅니다. 그러나 SCRUM (및 민첩한 관행)은 짧은 선으로 신속한 의사 결정을 촉진합니다. 우리의 경우 고객이 실제로 열정적이고 제품이 성공하기를 원하기 때문에 효과가 있지만 모든 것이 가능하지는 않습니다 (확실히 예산 및 기술적 한계 내에 있지 않음).
jwenting

물론 나는 그것이 프로젝트의 종류에 달려 있다고 생각합니다. 일부 프로젝트는 다른 프로젝트보다 더 자주 피드백을 요구합니다. 또한 일부 프로젝트 / 제품에서는 정보를 직접 유지하려고합니다. 그러나 그렇습니다. 고객이 같은 사무실에 앉아 개발을 따르는 특정 프로젝트의 경우 아마도 최상의 설정일 것입니다.
Giorgio

@Giorgio : "제품 소유자는 현장에서 설계 결정을 승인 할 권한이있는 선임 최종 사용자 및 도메인 전문가입니다."PO가 개발자가 가질 수있는 모든 질문에 답변 할 수있는 것처럼 들립니다. 저는 다른 상황에 대해 이야기하고있었습니다. 아직 고객과 동일한 수준의 전문 지식을 갖추고 있지 않아보다 어려운 질문에 답변하기 위해 정기적으로 고객에게 연락해야하는 PO.
tizenegy
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.