현재 위치 - 인적 자원 플랫폼망 - 미니프로그램 개발 - 제품 품목 복구 [방법+사례]
제품 품목 복구 [방법+사례]
복판은 바둑 용어에서 유래한 것으로, 기사가 바둑 한 판을 끝낸 후 다음 판을 다시 한 판 더 쳐서 자신이 어디에서 잘 내리는지, 어디서 내리는지, 심지어 어디에서 더 잘 내리는지 볼 수 있다는 뜻이다. (윌리엄 셰익스피어, 윈스턴, 바둑, 바둑, 바둑, 바둑, 바둑)

미국에서 가장 먼저 회복된 것은 미 육군으로' 행동 후 심사 (AAR)' 라고 불린다.

미군의 AAR 에 대한 정의는 다음과 같습니다. "한 사건에 대한 전문적인 논의는 표현에 초점을 맞추고, 참가자들이 무슨 일이 일어났는지, 왜 발생했는지, 어떻게 자신의 장점을 유지하고, 자신의 부족한 부분을 바로잡는 데 초점을 맞추고 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 전쟁명언)."

한 가지 일을 한 후에 성공했는지, 아니면 성공하지 못했는지, 특히 성공하지 못했다. 앉아서 이 일을 당시, 우리가 어떻게 미리 목표를 세웠는지, 중간에 무슨 문제가 생겼는데, 왜 할 수 없는가? 다시 한번 해보면, 경험과 교훈은 자연히 다음에 흡수될 것이다.

프로젝트 복판은 0 에서 1 또는 버전 반복에 관계없이 기본적으로 다음과 같은 핵심 단계 (아래 참조) 를 포함하는 프로젝트입니다. 즉, 각 단계의 특정 작업을 분해하고 각 작업이 순조롭게 진행되고 있는지, 문제가 어디에 있는지, 어떻게 더 잘 최적화되는지 분석하는 것입니다.

한 제품 매니저는 "제품 매니저의 자연 노선은 관리로 가는 것" 이라고 말했다. 관리를 향한 첫걸음으로서 득실을 요약할 필요가 있다. 각 프로젝트는 시작부터 끝까지 과정에서 어느 정도 예상치 못한 상황이 발생할 수 있다. 복판은 제품의 득실을 일일이 열거하는 절호의 반성 기회로, 당신이 계속 깊이 생각하고 총결산 능력을 향상시킬 수 있게 해 줍니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언)

물론 직위를 관리하지 않아도 복판의 의미는 대체하기 어렵다. 예를 들어, 현재 시장에는 데이터 제품 관리자, 전략 제품 관리자, 상업 제품 관리자 등 점점 더 전문화된 제품 관리자가 필요합니다. 좋은 프로젝트 복제 습관은 여전히 프로젝트 득실을 축적하고 요약하여 다음 제품 전략을 최적화하는 가장 좋은 방법이다.

또한 제품 관리자의 핵심 역량 중 하나는 수집된 수요 권장사항과 경쟁 우위를 요약하고 프로젝트 자체의 차이를 결합하여 자신의 수요 사고를 형성하는 능력을 요약하는 것입니다. 재시험은 네가 자신의 부족한 점을 빠르게 반성하고 제때에 시정하는 데 도움이 될 수 있다.

문제의 성패의 관건을 찾아내, 그 이유를 알다. 의미 있는 실패는 무의미한 성공을 피해야 한다. 또한 처리 방법을 실행 가능한 프로그램 세트로 구성하여 다음에 같은 문제가 발생할 때 사용할 수 있도록 합니다. 물론 상황을 봐야지, 융통성이 없어서는 안 된다.

Lenovo 그룹 복패 메커니즘을 통해 복패를 배우는 네 가지 단계와 주의사항.

재회는 예상 목표를 회고하는 것으로 시작한다. 이 단계에서 답한 주요 질문은 다음과 같다.

초기 행동의 의도나 목적은 무엇입니까?

사건/행동의 목표는 무엇입니까?

우리는 무엇을 할 계획입니까? 미리 해 놓은 계획은 무엇입니까?

어떤 일이 미리 발생해야 합니까?

이 단계에서 주요 문제는 다음과 같습니다.

복과의 학습 메커니즘에 따르면 예상 목표와 계획이 없으면 복수업이 없다. 목표가 없기 때문에, 잘하는 것과 하는 것의 차이는 없고, 참고할 의미도 없다. 따라서 명확하고 명확한 예상 목표와 계획을 미리 세우는 것은 복판에 매우 중요하다.

만약 당신이 복판 전에 프로젝트/사건에 목표가 없다는 것을 알고 있다면, 나는 당신이' 빨리 보충하는 것' 을 추천하고, 프로젝트 책임자를 인터뷰하거나 프로젝트 그룹 토론을 조직하여 프로젝트/사건 목표를 보충하고 확인하며, 복판 시작 시 이를 선언하여 특별한 주의를 환기시킬 것을 건의합니다. 사실 이것은 그 자체로도 중요한 학습점이 되어야 하며, 다음 단계 개선의 중요한 교훈 중 하나이기도 하다.

현실 세계에서 많은 사람들의 목표 설정은 비교적 모호하여 복잡함에서 충분히 배우는 데 불리하다. 이를 위해, 우리는 행동하기 전에 목표가 가능한 명확하고 상세해야 한다고 제안한다. 목표에 대한 주요 이정표와 주요 결과도 설정합니다.

기업 관리 분야에서는 일반적으로 목표 수립이 SMART 원칙에 부합해야 한다고 생각합니다. 즉, 다음 다섯 가지 요구 사항을 충족해야 합니다.

명확하고 구체적입니다.

측정 가능합니다.

도전적이지만 달성 가능합니다.

관련 제어 가능.

시간 제한이 있습니다.

나는 목표를 보여 줄 것을 제안한다. 즉, 목표에 대한 명확한 글을 어딘가에 써서, 행동에 참여하는 모든 사람이 볼 수 있도록 하는 것이다. (존 F. 케네디, 목표명언) 또한 작업 목적 및 성공 기준에 대한 팀 구성원의 이해가 일치하는지 확인하기 위해 미리 팀과 논의해야 합니다. 그렇지 않으면 성과를 평가하고 계획과 결과의 차이를 식별할 수 있는 근거가 없어집니다.

일부 팀은 조치를 취하기 전에 목표를 세웠지만 이러한 목표를 달성하는 방법, 즉 목표 달성을 위한 전략, 방법 및 조치 계획이 부족한 경우가 많습니다. 이 경우, 서둘러 행동하기 시작하면, 팀 구성원의 목표에 대한 이해가 일치하더라도, 팀의 모든 사람이 어떻게 목표를 달성할 수 있는지에 대한 자신의 이해를 가지고 있기 때문에 행동 과정에서 의견 차이가 생겨 힘을 얻기가 어려울 수 있습니다.

물론, 복판을 통해 팀원들은 행동을 취하기 전에 명확한 목표를 세우고 * * * 이해를 달성하며 목표를 달성하는 방법에 대해 함께 노력해야 한다는 것을 이해할 수 있습니다. 이것은 팀의 효율성을 높이는 데 도움이 될 것이다.

목표를 확정한 후에는 실제로 무슨 일이 일어났는지 되돌아볼 필요가 있다.

도대체 무슨 일이 있었던 거야?

어떤 상황? 어떻게 된 거야?

목표에 비해 당신이 잘 한 것은 무엇입니까? 무엇이 기대에 미치지 못했습니까?

유효한 AAR 은 "철의 사실" 을 기반으로해야합니다. 현실을 명확하게 진술하고 인정하기가 어렵다면 진전이 느리거나 깊이 들어가지 못할 수 있다.

일단 사실이 확인되면, 너는 차이의 원인을 진단하고 분석할 수 있다. 이 단계의 목표는 성패의 근본 원인을 찾아내는 것이다. 이 단계에서 대답해야 할 질문은 다음과 같습니다.

실제 상황과 예상이 다른가요?

그렇다면 왜 이러한 차이가 발생합니까? 우리가 원하는 목표를 달성하지 못한 이유는 무엇입니까? 실패의 근본 원인은 무엇입니까?

그렇지 않다면 성공의 핵심 요소는 무엇입니까?

실제로 많은 사람들이 이 단계에서 복습을 시작하는데, 당연히 처음 두 단계를 무시하는 것은 문제가 되지 않는다고 생각한다. 하지만 의사소통의 효율성을 높이고 끊임없는 다툼에 빠지지 않으려면 예상 목표 (1 단계) 와 실제 결과 (2 단계) 에 동의해야 한다.

일부 복잡한 프로젝트/이벤트의 경우 모든 차이를 일일이 분석할 필요가 없습니다. 대신 핵심 이벤트/문제를 심층적으로 분석하여 근본 원인을 찾아야 합니다.

이러한 질문에 답하려면 AAR 에 참여하는 사람들은 문제를 해결하는 기교와 개방적이고 솔직하며 남을 돕는 태도가 필요하다. 팀은' 브레인스톰' 의 몇 가지 가능한 해석을 통해 제한적이거나 모순된 정보에서 단서를 찾아 답을 탐구해야 한다. 이를 위해, 그들은 절대적으로 성실하고, 자신의 결점에 직면하고, 자신의 잘못을 인정하고, 실수나 결점 앞에서 책임을 떠넘기고, 귀머거리인 체해야 한다.

사실 다음에 무엇을 할지 결정하는 것은 종종 진단과 분석과 불가분의 관계에 있다. 참가자들은 문제가 무엇인지, 근본 원인이 어디에 있는지 진정으로 이해해야만 효과적인 해결책을 생각하고 제시할 수 있다.

이에 사용할 수 있는 도구와 방법은 브레인스토밍, 다섯 가지 이유, 어골도, 인과순환도 등이다. 역동적이고 복잡한 많은 문제에 대해 시스템 사고의 기교가 특히 중요하다.

복판의 핵심 가치는 두 가지 측면, 즉 성공 강화와 오류 수정으로 구성됩니다.

후속 조치가 왜 성공했는지, 어떤 주요 행동이 작용하는지, 이러한 행동이 적용 가능한 조건 (즉, 어떤 조건에서 이러한 행동을 취할 수 있는지) 을 이해하는 것은 후속 조치의 성공률을 높이는 데 매우 중요합니다.

회복시 다음과 같은 정신을 고수하십시오: 성공, 객관적인 요인 고려; 실패, 주관적인 원인을 많이 찾다. 겸허한 태도를 유지하고, 실사구시를 하고, 객관적으로 자신을 분석하고 평가하고, 과장하거나 과대평가하지 않고, 진정한 원인을 찾아야만 행동에서 효과적으로 배울 수 있다. 그렇지 않으면 자신을 속이는 것이다.

분석 단계에서는 "만약 ... 어떻게 될까요?" 라는 분석을 할 수 있습니다. 즉, 마음을 열고 상상할 수 있습니다 ... 다른 일이 생기면, 또는 수행 (만약 ...) 과 수행 (만약 ...) 이 어떤 모습일지 상상해 보세요. 이것은 머릿속에서 여러 가지 가능성을 하는' 연기' 와 비슷하다. 하지만 이런 연기도 허황된 것이 아니라' 말후포' 나' 후회약' 이 되는 것이 관건적인 원인을 분석하는 기초 위에 세워져야 한다.

복구의 핵심 목적은 행동으로부터 교훈을 얻어 후속 개선에 적용하는 것이다. 따라서 수술 성패의 핵심 원인을 파악하고 해결책을 찾는 것도 전체 과정에서 가장 중요한 단계다. 우리는 이 과정에서 어떤 새로운 것을 배웠습니까?

만약 누군가가 같은 일을 하고 싶다면, 나는 그에게 어떤 건의를 할 것인가?

다음에 우리는 무엇을 해야 합니까? 우리는 직접 무엇을 할 수 있습니까? 다른 관문은 무엇을 처리할 수 있습니까? 업그레이드하시겠습니까?

재실사는 구체적인 업무를 분해하고, 문제를 분석하고, 어떻게 개선할 것인가이다. 다음은 작업 분할 후 재실사에 대한 설명입니다.

UML 분류: blogs.com/vathe/p/7349816.html

즉, 프로그램 버전을 롤백합니다. 큰 버그가 나타나 프로그램이1..1에서 1.0 으로 후퇴했다. 반복 후 모두 버그, 수리 비용이 높습니다.

매번 프로젝트가 재개될 때마다 자신에 대한 고문과 단련이다. 반복 제품은 세 가지 버전마다 다시 시작됩니다.

일반적으로 출시 버전의 리듬은 한 달에 한 번 버전이므로 3 개월 리듬에 따라 반복할 수 있습니다. 마지막으로, 재입국할 때마다 결과는 서면으로 기록해야 한다.

다음으로, 프로젝트 목표 단계, 프로젝트 요구 단계, 개발 단계 3 단계에 대해 위에서 언급한 제품 프로젝트 복제 방법에 따라 프로젝트를 다시 검토해 보겠습니다.

원래 계획 납품 시간에 따라 납품합니까?

아니

2019.1..18 서비스 태그 기능이 완전합니다.

프로젝트 연기, 애플릿으로 구현, 다른 버전 개발 첫 번째 버전의 개발 진행은 70% 입니다.

SMART 원칙에 따라 목표를 명확하게 하지 않았고, 전체 프로젝트의 시간을 합리적으로 평가하지도 않았다.

목표를 달성할 합리적인 전략과 방법이 없다.

끝없는 수정 흐름도와 원형의 전투에 빠지다.

명확한 버전 반복 계획과 합리적인 수요 절차가 없습니다.

변경이 잦기 때문에 매번 변경되는 세부 사항이 많기 때문에 개발자와만 소통할 뿐, 테스터나 디자이너와 제때에 소통할 수는 없습니다.

수요 검토 단계에서는 개발 기간이 예상되지만 프런트 엔드 페이지의 수요가 계속 변화하기 때문에 프런트 엔드 개발 기간은 정해지지 않고 백그라운드 논리의 영향은 크지 않아 기본적으로 확정될 수 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 수요 검토 단계, 수요 검토 단계, 개발 단계, 개발 단계)

차이가 있습니다. 실제 개발 과정에서 백그라운드는 애플릿의 논리를 정리해야 할 뿐만 아니라 ERP 백그라운드와 공동으로 많은 인터페이스를 개발해 개발 시간을 연장해야 한다.

빗질 프로세스 흐름도 개발

주요 비즈니스 서비스에서 초기 설계는 사용자가 A 와 B 에 따라 Z 를 표시할 수 있도록 설계되어 사용자가 선택을 하고 사용자 입력을 줄일 수 있도록 도와줍니다.

제 3 자 응용 프로그램 선택 a 가 필요합니다. 불안정합니다. 동시에 타사 응용 프로그램 사용자도 찾을 수 없어 오류가 발생할 수 있습니다. 그래서 최종 결정은 사용자의 능동적인 입력을 채택하고 사용자의 능동적인 선택을 포기하기로 했다.

버전 계획은 각 요구 사항 검토의 목표가 현재 버전 또는 모든 기능 요구 사항, 현재 버전의 구현 목표 및 테스트 케이스 작성, UI 설계 레이아웃, 기술 아키텍처 구현 등에 영향을 줍니다.

우선, 가장 중요한 것은 개인의 요구 시간을 평가하고, 프로젝트의 온라인 시간과 온라인 목표를 결합하고, 개인의 요구 시간, 설계, 개발, 테스트 시간을 정하고, 실현 가능성을 명확히 하고, 프로젝트 기간을 합리적으로 배정하는 것이다.

1. 요구 사항을 적시에 확인하고 명확한 목표나 효과가 있는지 확인합니다. 반나절 이내에 불명확한 요구를 정리하여 제때에 관계자에게 연락하여 확인하고 기록하다. 각 항목에 대한 수요 확인 레코드를 생성하여 하나씩 깨뜨렸다.

2. 수요 획득에서 수출 수요까지의 시간을 엄격히 통제하며, 이후 시간은 실제 상황에 따라 변경된다.

수요 수신 -0.5 일 수요 내용 숙지 및 수요 확인 -0.5 일 경매 조회 및 분석 요약 -0.5 일 업무 흐름도 그리기 -0.5 일 정리 페이지 프로세스 -0.5 일 손으로 그린 프로토타입 +axure 프로토타입 1-2 일 내부 감사 수정 제품+

Ps: 요구 사항 과정에서 페이지 디자인이든 프로세스 디자인이든 제품 내부 및 제품 요구 사항 제출자와 지속적으로 수요를 확인해야 하며, 요구 사항 검토 시에만 수요를 제기하지 않도록 해야 합니다. 재작업, 팀 시간 낭비, 더욱 신중하게 고려해야 합니다! ! !

3. 회사 내 제품은 대부분 현재의 오프라인 장면과 결합되기 때문에 실제 애플리케이션 시나리오에 대해 더 많이 알아야 합니다. 시장의 일부 기능이나 참신한 수요가 반드시 이 제품에 적합한 것은 아니며, 반드시 회사의 실제 상황에 근거해야 한다.

플랫폼의 서비스 사용자는 누구입니까? 요구를 확인할 때는 분명히 하고, 스스로 똑똑히 생각해야 한다. 그렇지 않으면 재작업해야 한다! ! !

1. 요구 사항 검토에서 개인은 방향성과 목표성을 가지고 있습니다. 이번 수정으로 해결해야 할 문제와 달성해야 할 목표를 명심하고, 발산적 사고로 인해 회의 방향에서 벗어나지 않도록 해야 한다.

2. 수요 검토 시기를 통제하고, 특정 수요점을 견지하며, 회의 목표를 둘러싸고 혼란을 피한다. 교착 상태가 오래 지속되면 회의 후에 해결할 수 있다.

토론 기술 프로그램은 아직 불확실합니다. 회의 기간 동안 전반적인 기술 방안이 결정되며, 구체적인 기술 구현 세부 사항은 회의 후에 논의될 것입니다. 너의 건의를 진지하게 듣고 해결책을 제시하라. 회의에서 제기된 모든 질문은 기록과 답변을 잘 하고 냉정하고 객관적으로 자신의 관점을 진술해야 한다.

4. 매번 심사하기 전에 업무 프로세스, 해당 페이지를 한 번 거치며 논리적 누락이 있는지 확인합니다. 또한 페이지에 불명확하거나 누락된 마크업이 있는지, 대화형 점프 지침이 추가되었는지 확인합니다.

출력: 비즈니스 순서도와 원형 차트의 html 압축 패키지가 적합합니다. Png 그림 형식을 첨부할 수 있습니다.

5. 수요 검토에서 제기한 새로운 수요에 따라 현재 목표 달성에 중요한지 여부를 판단합니다. 그렇다면 추가, 명시적 수요, 그렇지 않은 경우 다음 수요 통합에 추가하여 수요 계획을 수립합니다! ! ! 평가 목표가 없으면 수요 평가는 끝이 없다!

6. 수요를 검토할 때 수요의 배경, 수요의 주요 과정, 수요의 주요 사고를 명확히 하는 데 중점을 둡니다. 디테일에 너무 일찍 들어가는 것을 피하고 디테일에 지나치게 얽매이는 것을 피하세요 ~

7, 요구 사항 평가자

개발: 프런트엔드는 구현 수준에 초점을 맞추고 있으며, 각 부분은 어떤 요소입니까? 백그라운드에서 논리 및 데이터 연결에 중점을 둡니다.

테스트: 프로세스 및 세부 사항에 중점을 둡니다

UI: 페이지 레이아웃 및 대화형 디자인에 중점을 둡니다.

8. 요구 사항 검토 전 소규모 커뮤니케이션 (프로그램 확인)

프로젝트 관계자와 미리 소통하고, 기술방안의 실현 가능성을 미리 이해하고, 실현할 수 없다면 대안을 미리 준비한다.

모든 것을 확인/해결하기 위해 요구 사항 검토 회의를 기다리지 마십시오. 사전에 의사 소통 작업을 잘하면 수요 검토의 효율성을 크게 높일 수 있다. 그러나 모든 요구를 미리 소통하는 것은 아니다! 모두들 바쁘니, 머리를 써서 방안을 가지고 다시 소통해라!

9, 제품 내부 요구 사항 검토

논리적 일관성을 보장하기 위해서는 먼저 제품 팀 내에서 작은 범위의 검토를 수행하는 것이 좋습니다.

내부 소규모의 검토는 대부분의 불합리한 요구를 피하고 수요 검토의 효율성을 직접 효과적으로 높이는 동시에 제품 팀에 대한 다른 팀의 신뢰를 높일 수 있습니다. 기능 논리가 여러 제품 책임자와 관련된다면 이 단계는 필수입니다!

10. 검토가 끝나면 개발주기와 설계주기를 확인합니다.

프로젝트 시간을 합리적으로 평가하고, 온라인 시간과 충돌하고, 적시에 의사 소통하여 수요 계획을 조정해야 하는지 확인합니다.

1 1. 회의가 끝난 후 회의록을 적시에 출력하고, 회의에서 논란이 되는 문제, 수정된 부분 및 결론을 나열하고, 개선 및 최종 업데이트된 요구 사항 문서를 참석자에게 보내 요구 사항 검토가 완료되었음을 알립니다. 그런 다음 평가 결과의 이행을 보장하기 위해 문제를 후속 조치하십시오.

12, 세부 차이 해결 ~ 원칙 수립:

보다 포괄적인 방향과 목표를 세우고 팀의 대다수 구성원의 인정을 받다. 의견 차이와 상대를 설득하기 어려운 상황에 직면할 때 정해진 목표나 방향에 따라 문제를 해결하거나 현재 가장 좋은 해결책을 제시한다.

예를 들어 텐센트 내부의 원칙은 모든 것이 사용자 경험이라는 것이다.

1. 요구 사항 비즈니스 논리와 페이지 구현의 전 과정을 빗질하는 중요한 단계인 비즈니스 흐름도와 페이지 흐름도에 초점을 맞춘다. 이 두 부분이 확인되면 후속 프로토타입 그리기가 더 원활해질 것입니다.

2. 다중 역할의 경우, visio 를 직접 사용하여 교차 기능 흐름도를 그리고, axure, processon 등의 흐름도 그리기 소프트웨어를 버리고, 도구 선택과 준비에 시간을 할애하지 않고 실제 수요 프로세스를 정리하는 데 시간을 할애합니다! 시간 낭비!

3. 순서도는 직관적이어야 합니다. 직접 순서도의 그리기 의미가 무엇인지 배우십시오 ~ 업무와 무관한 요소를 너무 많이 추가하지 마십시오. 각 흐름도는 한 가지만 설명하고 복잡한 프로세스를 분리하여 순서도를 단순화하는 방법을 배웁니다!

4. 페이지 레이아웃을 디자인할 때 사용자 사용 과정을 시뮬레이션하여 유창한지, 파생 요구 사항이 있는지, 현재 버전이 일치하는지 확인합니다.

5. 각 플랫폼의 특징을 명확히 합니다: 애플릿, 위챗 서비스 태그, app, 웹 사이트, H5 링크, 기술과 많이 소통하면서 동시에 많이 배우고, 해야 할 기능이 실현될 수 있는지, 어떻게 실현될 수 있는지, 비현실적인 기능을 하지 않도록 합니다.

또한 변환 플랫폼을 구현하면 장단점, 기술 구현에 있어서의 전후 차이, 변환 플랫폼을 통해 다른 부분을 실현할 수 있는지 여부, 그렇지 않은 경우 대안이 있는지 여부도 알 수 있습니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 성공명언) 기술 평가는 얼마나 걸립니까?

6. 경품을 분석할 때 UI, 디자인 페이지 레이아웃, 페이지 구성 요소의 구성과 기능, 페이지 상호 작용 점프 등을 포함한 일정 기간 동안 다양한 app 를 봅니다. 개인은 주말마다 신청에 대한 종합 분석과 총결산을 하나 이상 발표해야 한다. 신열매품 우선-엄격한 통제시간 ~ 0.5 일.

1, 프로젝트 주기 동안 테스트와 의사 소통이 거의 없고 테스트에 대한 대상 문서도 없어 어떻게 받아들여야 할지, 테스트가 어느 정도 온라인 상태가 될 수 있는지 알 수 없습니다! ! 따라서 개인은 시간을 들여 테스트 전달 방법, 요구 사항, 테스트 전달 시기 등을 학습하고 온라인 테스트의 중요성을 설명합니다.

2. 각 항목에 대하여, 나중에 복공할 수 있도록 상응하는 서면 기록을 세웠다.

프로젝트에는 수요의 논리적 정렬-수요 확인 기록-최종 수요-수요 검토 기록-수요 변경 기록-해결해야 할 문제, 문제-수요 반복 계획 ~ 등이 있습니다. 보충이 필요하다.

순서도 폴더, 원형 폴더, 설계 폴더

3. 일간지, 구체적인 업무 내용을 명확히 하고 진도에 적어 개인의 업무 진도를 조절하여 후기 복판을 용이하게 한다. (윌리엄 셰익스피어, 윈스턴, 일간지, 일간지, 일간지, 일간지, 일간지)

4. 수요심사에 대한 필기를 잘 하고, 이날 도운의 노트에 업데이트해 하나씩 해결한다.

객관적인 관점에서 다른 사람들이 제안한 타당성을 봅니다. 먼저 건의에 감사한 후에 직접 감정하겠습니다. 제품의 관점에서 그것을 설득하려고 노력하다. 고집 부리지 마, 얘야!

6. 프로젝트 관련 메시지 (예: 수요 변경) 를 적시에 통보하기 위해, 프로젝트의 모든 관계자를 위한 팀을 구성하고, 즉시 의사 소통하고 문제를 해결합니다.

이 글은 주로 복판의 출처, 의미, 방법, 기본 논리를 설명하고, 제품 프로젝트 복판의 방법론을 구체적으로 설명하고, 개인 프로젝트의 실제 사례와 연계하여 도움이 필요한 사람에게 도움이 되기를 희망하고 있다. 일부 내용은 내가 읽은 문장, 책에서 나온 것으로, 내 개인적인 이해로 더 많은 사람들이 복판의 중요성을 인식하길 바란다.

인생은 매일 생중계하는 여정이다. 바쁜 일과 생활의 틈바구니에서, 시간을 내서 자신의 일정 기간 근무생활을 보고, 자신의 원래 목표를 향해 나아가고 있는지, 성패의 관건을 찾아내며, 그 이유를 알 수 있다. 의미있는 실패를 피하고, 무의미한 성공을 피하고, 다음 여정에 더 효율적으로 투자하고, 목표에 더 가까워져야 한다. (존 F. 케네디, 실패명언)

문장 짱 좀 주세요. 오늘부터 깊이 생각하고 규칙적인 사람이 되어 주세요.

게임을 잘하는 사람, 전체 게임에는 마수, 연속 복판, 복리 체험, 뭐든지 할 수 있어요!

열심히 읽어 주셔서 감사합니다. 저는 0.5 세의 제품 매니저인 하비입니다. 수시로 학습과 재시험 진도를 알려드립니다. 많이 가르쳐 주세요 ~