제품 소유자도 팀의 개발자입니까?


9

나는 PO의 책임에 대해 혼란 스럽다. 저는 Game Feature Team의 개발자이자 PO이기도했습니다. 개발자의 일상적인 작업은 거의 풀 타임이므로 PO 의무를 처리하기 위해 시간이 지남에 따라 근무해야하며 PO의 책임은 개발자의 생각에 위배되는 것 같습니다.

PO로서 다음 스프린트에서 더 많은 기능을 선택하겠습니다. 그렇지 않으면, 나는 그 기능을 개발하는 팀원이기 때문에 그렇게하지 말라고 스스로에게 말할 것입니다. 이 상황은 혼란스러워서 여러분의 의견을 듣고 싶습니다.

저는 Scrum과 Game Dev (약 1 년 반)를 처음 접했고 여기와 영어를 처음 접했습니다.


나는 오후에 투표했는데, 그것이 존재하는지도 몰랐습니다!
ObscureRobot

2
나쁜 언어? 어떤 가난한 언어?
DeadMG

Plz는 저의 가난한 영어를 실례합니다. : |
Charlie

6
영어를 사용하는 것이 명확하고 정확합니다.
ObscureRobot

3
개발 작업이 풀 타임이지만 PO 의무가 "시간이 지남"이라고 말하면 적발입니다. 우선 순위를 설정하면 PO 작업이 자신에게 적합하지 않다는 것을 누구에게 설득하기 위해 팀과 자신에게 우선 순위를 부여해야합니다.
GuyR

답변:


2

약간 어색해 보이지만 실제로 이러한 역할을 결합 할 이유가 없어야합니다. 우선, 누군가가이 역할을 맡게되므로 팀은이를 존중해야합니다. 두 번째로, 이제해야 할 일을 우선 순위를 정할 수있는 위치에있게되므로 항상 일이 어떻게 진행되고 있는지 설명 할 수 있습니다. 셋째, 팀에 소속되어 있으므로 작업 부하를 공유하고 있습니다. 마지막으로, 당신은 열심히 일해야한다면 그것은 직업입니다. 팀은 항상 프로젝트에 가치를 더해야한다는 것을 기억해야합니다.

"이러한 미끼를 만들 물건이 있습니까?" 당신이 생각하는 경우에, 그것을하십시오!


3
나는 거의 5 개월 동안 개발자와 PO로 일해 왔습니다. 불가능하지는 않지만 "합리적이거나 생산적인가?"라는 질문이 있습니다. 내 작품에 점수를 줄 수 있다면, 개발 첫 해에는 "A +"를 받았지만, 5 개월 동안은 두 가지 의무에 대해 "B"또는 "B +"를 받았습니다.
Charlie

1
@Charlie 초점이 없으면 성능이 저하 될 수 있습니다. 동료들이 이러한 상황을 인식하는 한 모든 것이 여전히 양호해야합니다. 나는 팀이 이것을 해결할 수있는 추가 인원을 추가하는 것을 고려하지만 추가 비용을 초과하지 않을 수도 있습니다.
Carlo Kuip

8

내 경험상 제품 소유자는 PM / TPM 또는 비즈니스 팀의 구성원입니다. PO가 개발자가되는 것은 불가능하지만 이해 상충의 위험이 있습니다. 제품의 기술 수준이 높으면 PO에 개발 배경이 있어야합니다. 기술 수준이 낮고 최종 사용자에 중점을 둔다면 비즈니스 경험이있는 PO가 중요합니다.


개발 배경을 갖는 것은 작업 방법과 올바른 순서를 이해하는 기본입니다. 내 직업이 필요할 수도 있지만 아닐 수도 있습니다. 저는 모든 "게임 기능 팀"에서 PO로 유일하게 개발자입니다. 다른 팀의 PO는 실제로 요구 사항을 "코딩"하지 않는 디자이너로 일합니다.
Charlie

6

프로그래머로서 (당신이 좋은 사람이라고 가정하면) 코드에 투자하게됩니다. 소유자 또는 관리자로서 제품에 투자해야합니다.

이것들이 항상 같은 것은 아닙니다. 그리고 그들이 아닌 경우 큰 문제가 발생합니다.

나는 항상 좋은 관리자의 역할은 쓰레기를 위에서 막고 코드가 충분할 때 나에게서 멀어 지도록하는 것이라고 말했다. 관리자가 없으면 평생 동안 단 하나의 기능을 수행하여 영원히 개선 할 수있었습니다.

소유자는 큰 그림을보아야하고 프로그래머는 세부 사항을보아야합니다. 당신이 신이 아니면 둘 다 할 수 없습니다!


1
나는 오랫동안 그런 딜레마 (좋은 코드와 제품 일정)에 있었다. 역할을 선택하고 더 이상 고통받지 않기 위해 다른 역할을 포기해야한다고 생각하기 때문에이 질문을합니다. :)
Charlie

1
사실, 훌륭한 개발자는 큰 그림을 보려고 노력해야한다고 생각합니다. 그러나 세부 작업에 깊이 빠져 있으면 PO / 관리자가 필요하지 않습니다.
sleske

3

전통적인 Scrum에서 정의 되었기 때문에 제품 소유자로 기능하는 개발자에게는 문제가 없습니다. 그러나 여러 프로젝트를 수행하거나 동일한 팀에서 여러 역할을 수행하기 때문에 파트 타임으로 역할을 수행하는 사람을 고려할 때는주의를 기울여야합니다. 귀하의 경우, 제품 소유자의 의무를 수행하기 위해 각 반복에서 시간을 계획해야하기 때문에 풀 타임 개발자로 자신을 계산할 수 없습니다.

또한 귀하는 제품 소유자가하는 일에 대해 오해하고 있다고 생각합니다. 반복 할 기능을 선택하는 것은 귀하의 책임이 아닙니다. 대신, 새로운 이야기를 소개하고, 이러한 새로운 이야기에 우선 순위를 할당하며, 수락 테스트의 작성 및 실행을 통해 각 스토리의 구현이 수용 가능한지 확인하는 경우 프로젝트에서 고객의 목소리가되는 것이 귀하의 임무입니다. 스토리의 선택은 제품 소유자가 구현하려는 스토리의 수가 아니라 팀의 속도와 우선 순위에 따른 백 로그를 기반으로합니다.


2

찰리라는 사람에게 조언을 해준 것에 흥미가 있지만 (제 이름은 찰스입니다) 개발자 / PM으로서의 이중 역할에 대한 경험이 있습니다. 역할 또는 다른.

두 가지 역할을 모두 수행 할 수 있다면 반드시 그렇게하되 시간을 책정하고 두 역할 사이의 컨텍스트 전환을 특히 하루 안에 절대 최소로 유지하십시오.

이상적으로, 나는 당신이 알고 있듯이 이러한 역할이 서로 약간 충돌하는 것을 피하는 것이 좋습니다.


기억하기 쉽고 일반적으로 사용되기 때문에 "Charlie"를 영어 이름으로 선택합니다. TV 에피소드 "LOST"에서 Charlie라는 녀석은 "Claire"(내 여자 친구의 프랑스 이름 :)라는 소녀에 속합니다. 저는이 이름의 의미와 "Charles"와의 관계에 대해 전혀 모릅니다.
Charlie

1
문제는 프로그래머 타입의 사람이며 코딩 작업을 좋아한다는 것입니다. 따라서이 두 역할 사이를 전환하는 것은 어렵습니다. 이 프로젝트에서 PO의 일일 일정에는 "매일 검토"라는 회의가 포함됩니다. 매일 오후 5시에 발생합니다. IDE에 코드의 절반을 남겨두고 나중에 다시 끝내기 위해 끔찍한 일입니다 ...이 불가피한 만남을 제외하고 4-5 게임 기능 팀 간의 커뮤니케이션에는 많은 시간이 소요됩니다 내 일을 방해하고 다른 사람들이 사라 졌을 때 밤에만 코드를 생각하고 작성할 수 있습니다.
Charlie

찰리는 내가 주로 어렸을 때 사용했던 찰스의 별명이며 여전히 일부 친구들에게 사용됩니다.
SplinterReality

1
지금하는 방식으로이 전환에 대해 생각하지 않아야합니다. 개발 작업이 아닐 수도 있지만 작업을 수행하는 데 중요한 부분이므로 작업을 처리하기 전에 정신을 충분히 확보해야합니다. 회의를 준비하기 위해 오후 5시 이전에 프로그래밍을 중단하고 새로운 역할로 기어를 전환한다는 의미 일 것입니다. 당신은 그것을 할 때 yejoyce해야합니다! 작업이 더 이상 코드 원숭이 수준이 아니더라도이 프로젝트를 진행하고 있습니다.
SplinterReality

0

거의 항상 나쁜 생각입니다. 우리는 제품 소유자 인 프로젝트 관리자를 가지고 있었고 그것은 충분히 상충되었습니다.


0

두 역할 사이의 일반적인 균형 문제를 이해하지만 이해하지 못하는 것은 귀하의 특정 관심사입니다.

당신이 그렇게한다면 개발은 풀 타임 역할 일뿐입니다. 스프린트 계획 (사용 가능한 모든 개발자 시간 / 일 수를 계산할 때) 중에 자신을 50 %로만 계산하는 경우 PO 업무에 충분한 시간이 있어야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.