제품 관리자는 리뷰 요약을 어떻게 작성하나요?

많은 회사(저희 회사 포함)에서는 직원에게 일별 업무 요약, 주간 업무 요약, 월별 업무 보고서, 분기별 업무 보고서, 반기별 업무 보고서, 연간 업무 보고서를 기한 내에 제출하도록 요구합니다. 그러므로 우리 각자는 매일 복습을 하고 있습니다. 그 중 일부는 우리가 알고 있지만 대부분은 우리가 깨닫지 못하는 반성입니다.

1. 우선 리뷰란 무엇인가

0~1이든 버전 반복이든 프로젝트에는 기본적으로 다음과 같은 핵심 단계가 포함됩니다(아래 그림 참조). 제품 리뷰는 각 단계의 구체적인 작업을 세분화하여 각 작업이 원활하게 진행되고 있는지, 문제점은 어디에 있는지, 어떻게 하면 더 잘 최적화할 수 있는지 분석하는 것입니다.

2. 둘째, 리뷰를 해야 하는 이유

이전 글에서는 "프로덕트 매니저의 당연한 길은 경영으로 나아가는 것"이라는 관점을 표현했습니다. 경영을 향한 첫 번째 단계는 손익을 요약할 수 있어야 합니다. 모든 프로젝트의 시작부터 끝까지, 프로세스 중에 계획되지 않은 긴급 상황이 어느 정도 발생하게 됩니다. 리뷰는 제품의 손익을 하나씩 나열함으로써 계속해서 깊이 생각하고 요약 능력을 향상시킬 수 있는 좋은 기회입니다.

제품 관리자의 핵심 능력 중 하나는 수집된 수요 제안, 제품 경쟁 우위 등을 요약하고 정리한 후, 프로젝트 자체의 차이점을 결합하여 자신만의 수요 아이디어를 형성하는 능력입니다. .

3. 마지막으로 리뷰 방법

리뷰란 위에서 언급한 바와 같이 구체적인 작업을 세분화하여 문제점을 분석하고 개선방안을 제시하는 것입니다. 작업이 세분화된 후 검토하고 설명하십시오.

1 프로젝트 목표 검토

1.1 프로젝트 진행 검토

1.1.1 원래 계획된 배송 시간에 맞춰 배송되었나요?

1.1.2 원래 계획된 수요 지점 중 몇 개나 달성되었습니까? 어떤 수요 지점이 계획대로 실현되지 않았습니까? 각 수요 지점에서 지연되는 이유는 무엇입니까?

1.1.3 어떤 마일스톤이 지연되고 지연 이유는 무엇입니까?

1.2 프로젝트 결과 검토

1.2.1 프로젝트에서 어떤 사고가 발생했나요? 왜 이런 사고가 발생하는 걸까요?

1.2.2 사용자가 새로운 기능 점수를 수용하는 것이 프로젝트 계획과 일치합니까?

2 요구사항 단계 검토

2.1 요구사항 정의 검토:

2.1.1 프로토타입, MRD, PRD, UML을 포함하여 완전한 요구사항 출력이 제공되는지 여부 등.

2.1.2 디자이너, 인터랙션 엔지니어, 개발자는 각각 요구 사항이 명확한지 여부를 결정합니다. 요구 사항이 명확하지 않으면 프로젝트 진행과 품질에 심각한 영향을 미칩니다.

2.1.3 일반적인 사용자와 사용 시나리오에 대한 명확한 설명이 있습니까?

2.2 수요 변화 검토

2.2.1 수요 변화 수: 민첩한 개발로 인해 수요 변화의 영향이 최소화되었지만 여전히 수요 변화가 적어 프로젝트가 원활하게 진행됩니다. 가옥.

2.2.2 어떤 요구사항 변경이 프로젝트의 실제 진행에 영향을 미쳤습니까?

2.2.3 각 변경의 이유: 리더십 개입? 초기 고려가 부족했나요? 요구 사항을 충족할 수 없나요? 이후 프로젝트에서 합리적으로 피할 수 있도록 각 변경의 이유를 분석합니다.

2.2.4 각 프로젝트 구성원이 각 변경 사항을 명확하게 이해하고 있는지 여부: 각 프로젝트 구성원이 각 요구 사항 변경 사항을 명확하게 이해하고 충분히 소통해야 프로젝트 진행 및 진행 품질이 보장될 수 있습니다.

2.2.5 프로젝트 구성원이 수요 변경을 수용할 수 있는지 여부: 이를 위해서는 수요가 변경될 때마다 관련 담당자와 의사소통이 이루어져야 합니다.

3 디자인 단계 검토

3.1 시각 디자인의 최종 검토자가 결정되나요?

3.2 UI 디자인 출력이 통일된 표준을 준수합니까?

3.3 디자인 작업이 개발 작업 진행에 영향을 미치나요? 원인은 무엇입니까?

3.4 제품 디자인 작업은 언제, 누가 완료했나요?

4 개발 단계 검토

4.1 공사 기간 평가 검토

4.1.1 개발 시행 전 공사 기간을 추정할 시간이 충분한가? : 공사기간평가 한편으로는 사업참여자들이 사업의 전반적인 진행상황에 대비할 수 있도록 하고, 사업요구사항을 세부적으로 정리하는 과정이기도 하다.

4.1.2 예상 공사 기간과 실제 개발 기간에 차이가 있는지 및 차이가 나는 이유 분석

4.2 개발 문서 검토

4.2.1 개발문서가 제공되나요?

4.2.2 개발 문서가 사양을 준수하는지 여부

4.3 긴급 상황 검토

4.3.1 요구 사항을 실현할 수 없는 상황이 있습니까? 이유는 무엇입니까?

4.3.2 팀원에 변화가 있나요? 회원 변경은 어떻게 처리하나요? 나중에 그것을 피하는 방법?

4.3.3 기능 모듈과 요구사항 간에 불일치가 있습니까? 이유는 무엇입니까?

4.4 코드 검토

4.4.1 수행 방법: 작업 분할 방법, 검토 방법 등

4.4.2 코드 검토 결과는 무엇입니까?

4.4.3 코드 사양이 엄격하게 구현되어 있습니까? 불규칙한 코드를 처리하는 방법은 무엇입니까?

5 테스트 단계 검토

5.1 테스트 계획 검토

5.1.1 완전하고 정확한 테스트 사례가 있습니까?

5.1.2 테스트 계획이 있나요? 그런 계획이 효과가 있나요?

5.1.3 팀은 제품 개발의 효율성을 어떻게 테스트하고 추적합니까?

5.2 테스트 도구 검토

5.2.1 테스트에 도움이 되는 테스트 도구는 무엇입니까? 지속적으로 사용할 수 있나요?

5.2.2 테스트를 위한 시간, 인력, 소프트웨어/하드웨어 자원이 충분합니까?

5.3 테스트 결과 검토

5.3.1 어떤 기능 모듈이 버그가 가장 많은 이유는 무엇입니까?

5.3.2 롤백되는 BUG는 무엇이며 그 이유는 무엇입니까?

6 온라인 접수 검토

6.1 접수 검토

6.1.1 정식 온라인 접수가 이루어졌나요?

6.1.2 정식 출시 과정에서 문제는 없나요? 앞으로 그것을 피하는 방법은 무엇입니까?

6.1.3 온라인에 접속하기 전에 운영 및 카피라이터와 충분한 의사소통이 이루어지나요?

6.1.4 데이터 저장 지점을 확인했으며 운영 요구 사항을 충족합니까?

6.2 온라인 접속 후 효과 검토

6.2.1 온라인 접속 후 주요 버그가 나타났습니까? 테스트 단계에서 발견되지 않은 이유는 무엇입니까?

6.2.2 제품 출시 후 피드백 채널에 대한 프로세스가 있나요?

6.2.3 제품 출시 후 어떤 피드백을 수집했나요? 어떤 유형인가요? 개선하는 방법은 무엇입니까?

모든 프로젝트 리뷰는 자신을 괴롭히고 단련하는 것입니다. 반복적인 제품은 3개 버전마다 검토됩니다. 일반적으로 출시 주기는 한 달에 1개입니다. -월 속도.

마지막으로, 각 리뷰의 결과는 반드시 서면으로 기록되어야 하며, 이는 여러분의 성장에 중요한 축적이 될 것입니다!