오늘,우리는 포스트 프로젝트 검토로 알려진 소프트웨어 개발 라이프 사이클의 종종 지나친 측면을 살펴 보겠습니다. 우리는 무엇을 정의 하 여 시작 합니다.,정확 하 게,포스트 프로젝트 검토 이며 좋은 프로젝트 검토의 요소를 취재에 이동.
포스트 프로젝트 검토 란 무엇입니까?
프로젝트의 특징 중 하나는 명확한 시작과 끝이 있다는 것입니다. 때로는 시작과 끝이 매우 명확하게 정의되지 않을 수 있습니다(!)그러나 프로젝트가 시작될 때와 끝날 때 일반적으로 대략적인 아이디어를 얻을 수 있습니다. 이런 종류의 유한 수명이 없는 것은 실제로 프로젝트가 아닙니다. 그러나 진행중인 소프트웨어 유지 관리 및 지원과 같은 모든 활동을 일련의 명확한 프로젝트로 분할 할 수 있습니다.이 프로젝트는 일반적으로 소프트웨어 릴리스가 프로덕션에 투입되면 프로젝트를 종료하고 다음 릴리스 또는 업그레이드를 위해 새 프로젝트를 시작합니다.
포스트 프로젝트 검토는 지속적인 개선 메커니즘을 추가하는 매우 유용하고 강력한 방법입니다. 대부분의 활동은 위에서 언급 한대로 일련의 개별 프로젝트로 나눌 수 있습니다. 이 지속적인 개선 메커니즘은 각 성공 프로젝트를 더 성공적으로 만드는 데 도움이됩니다(그리고 모든 참가자에게 스트레스를 덜 자주). 포스트 프로젝트 검토는 일반적으로 함께 회의 프로젝트 팀과 주요 이해 관계자를 포함하고 잘 무슨 일이 프로젝트 기간 동안 심하게 갔다 검토. 이 입력은 참가자가 다음 프로젝트가 더 잘 실행되도록 올바른 결정과 계획을 세우는 데 도움이 될 수 있습니다. 또한 오해 및 기타 문제를 해결하는 데 도움이 될 수 있습니다.
읽기: 개발자를위한 프로젝트 관리 소프트웨어 란 무엇입니까?
예를 들어,내가 한 번 수행 한 사후 프로젝트 검토에서 품질 보증 팀은 프로젝트 중에 요구 사항 변경이 승인되고 입력없이 이루어 졌다고 생각하면서 화를 냈습니다. 이 피드백을 바탕으로 후속 프로젝트에서 품질보증팀의 담당자가 요구 사항에 대한 논의가 필요할 때 항상 참석하도록 하여 수정했습니다. 이 루프에 넣어뿐만 아니라 그들에게 품질 보증 마감 시간에 잠재적 인 영향을 가져올 수있는 기회를 주었다. 포스트 프로젝트 검토의 모든 참가자가 책임을 할당하거나 인신 공격을 할 때가 아니라는 것을 이해하는 것이 중요합니다. 아이디어는 일을 더 나은 조차 하는 방법을 발견하기아울러 잘 해내는 일에 칭찬한것을 이다. 하나는 포스트 프로젝트 검토가 운동을 가리키는 손가락이나 외치는 일치로 변질되지 않도록주의해야합니다.
좋은 포스트 프로젝트 검토의 요소
앞서 언급 한 바와 같이 포스트 프로젝트 검토의 주요 목적은 비난을 배분하는 것이 아니라 개선을위한 영역과 개선 방법을 식별하는 것입니다. 당신이 포스트 프로젝트 검토를 계획하기 전에 기본 목표를 식별하고 당신이 빼앗아 가고 싶어.
- 잘 수행 된 항목 식별:예를 들어 시간 추정치가 매우 좋았고 개발자와 품질 보증 팀이 함께 잘 작동했습니다.
- 개선할 수 있는 항목 식별:시스템 문서화가 제때에 준비되지 않았을 수도 있고,개발자들이 분석가들과 분쟁을 겪었을 수도 있다.
- 깨진 항목 식별: 이들은 매우 심각하고 그들이 수행하는 방법에 대한 완전한 재검토가 필요할 수 있습니다. 아마도 일부 프로세스를 삭제하거나 변경해야 할 수도 있습니다. 어쩌면 지속적으로 변화하는 요구 사항은 팀이 더 민첩한 개발 방법론으로 변경해야합니다. 서로 신경을 쓰는 두 사람은 함께 일할 필요가 없도록 재 할당해야 할 수도 있습니다.
- 실행계획 결정:개선이 필요한 항목을 개선하기 위한 실행계획 합의 및 깨진 항목을 수정하는 방법을 입력합니다. 이것은 장기 변화를 실행하게 매우 쉽게 하고 뿐 아니라 팀에 있는 투입 그리고 팀 정신의 강한 감을 건설하는 것을 도울 것이다.
회의를 위해 많은 이해 관계자와 팀원을 모으십시오. 그것은 혼돈에 대한 조리법처럼 보일 수 있지만(!),잘 계획 하는 경우 그것은 모두에 대 한 좋은 경험이 될 수 있습니다. 모두가 행동 계획 및 목표를 이해한다 것 을 확인하십시요. 이해 관계자 및 팀 구성원은 문제를 해결 하기 위해 작업 하는 기회로 그것을 볼 경우 열광 될 가능성이 있습니다. 내 경험에 비추어 볼 때 이러한 리뷰가 처음 수행 된 것은 일반적으로 사람들이 허용되는 것과 그렇지 않은 것을 확신하지 못하기 때문에 가장 어렵습니다. 일부 회원은 비판을 나쁘게 받아 들일 수도 있습니다. 그것은 잠재적으로 폭발성 문제점 및 회의로 들어가기 전에 그(것)들을 완화하는 방법의 아이디어가 있는 이해될지도 모른다. 회의 전에 영향을 받는 참가자와 개인 회의 기본 규칙을 이해 하 고 그들은 따라야 할 것입니다 약속을 얻을 수 있도록 매우 도움이 될 수 있습니다.
주요 이슈를 식별하는 데 도움이되는 좋은 기술은 투표와 같은 일을하는 것입니다. 각 참가자는 잘 카테고리 중 하나에 빠질 수있는 항목을 넣습니다,일부 조정이 필요하고 수정해야. 이것은 모든 사람이 자신의 의견이 계산되고 있다고 느끼게합니다. 게다가 그것은 많은 문제의 전체보기를 제공 할 수 있습니다. 자주 하나는 많은 문제에서 패턴을 찾을 수 있습니다. 사람이 느끼는 품목에 제안 칭찬은 잘 한다. 가장 빈번하게 언급되는 문제점은 주의를 필요로 하는 그들 이다. 이 시점에서 사람들이 개선이 필요한 항목을 개선하는 방법과 깨진 항목을 수정하는 방법에 대한 아이디어를 제공하는 데 도움이 될 수 있습니다. 아이디어가 제일 보이는 너는 조차 약식 투표가 있을지도 모른다.
회의가 끝나면 모든 정보를 수집하여 기록한다. 개선이 필요하고 어떤 고정 할 필요가 무엇 잘되고 있는지 자세히 확인하십시오. 모두가 개선 하 고 문제를 해결에 작동할 것 이라고 동의 하는 기술을 식별 합니다. 일부 수정 승인 또는 리소스를 필요로 하는 경우에 특히 고위 관리에이 제시 하는 것이 좋습니다. 이러한 보고서는 팀을 검토할 수 있는 방법을 제공하며,팀이 자신의 문제를 공격하고 해결하려고 한다는 확신을 심어줍니다. 문제를 너자신 고치는 방법을 발견하는것은 매우 낫다 오히려 수정을 발견하기안에 관련시키는 고위 관리를 있으십시요. 사람들은 일반적으로 행정 명령을 원망하지만 자신이 제안한 변경 사항을 기꺼이 처리합니다.
읽기:개발자를위한 최고의 프로젝트 관리 도구.
결론
포스트 프로젝트 검토는 팀이 성과와 기술을 향상시킬 수있는 귀중한 방법입니다. 그들은 연료 지속적인 개선 뿐만 아니라 팀 사기를 개선 하는 메커니즘을 제공 합니다. 이 프로젝트의 모든 부분을 검토하는 데 도움이뿐만 아니라 오해와 다른 문제를 정리하는 메커니즘을 제공하기 때문에 검토에서 가능한 한 많은 이해 관계자를 얻는 것이 중요합니다. 좋은 계획과 포스트 회의 속행은 이 검토에게 성공을 하 결정적 이다.
