프로젝트 폐쇄 - 할 일은 무엇입니까?

Question

우리 고객이 우리가 15 개월 동안 작업해온 프로젝트를 취소 할 것으로 보입니다.

어느 시점에서 다시 시작될 수 있습니다 (가능성은 낮지 만).

우리는 또한 이렇게하면서 몇 가지 영역에서 회사 제품을 확장했습니다. 다른 프로젝트 팀도 비슷한 확장을해야 할 수도 있습니다. 우리는 우리가했던 것을 활용할 수 있기를 바랍니다.

그래서 후대 (다른 인력을 포함 할 수도 있음)가 우리가 한 일에서 배울 수 있도록 후손을 위해 기록해야 할 핵심 사항은 무엇입니까?

사람들은 우리 프로젝트에 익숙하지 않은 사람들이 거의 도착하지 않을 것이고, 앞으로는 더 이상 관여하지 않을 것이기 때문에 이것은 미래의 관리자들에게 기록 할 내용과 약간 다릅니다.

지금까지 우리는 각 주요 기능/확장에 대한 정보를 수집했습니다. 그래서 요구 사항을 찾을 수있는 곳, 소스 코드를 가리키는 포인터, 테스트 케이스 등이 있으며 주요 디자인 포인트에 몇 가지 서술을 추가합니다/결정 등

프로젝트 팀이 아직 함께 있지만 우리는 무엇을하고 캡처해야합니까?

Answer 1

매우 구체적인 것은 아닙니다. 그러나 디자인이나 기술 선택에 대한 모든 주요 결정에 대해 "이유"를 반드시 기록하십시오.

향후 프로젝트에서 작업하는 사람이 원래 팀과 동일하지 않은 경우 특히 트랙을 훨씬 더 효과적으로 활용할 수 있습니다.

Answer 2

리포지토리 또는 각 파일 기록의 일부 표현을 저장해야합니다. 그것은 지식이없는 무언가로 들어서고, 진화 된 모습을보고, 특정 기능 (또는 버그)이 도입되었을 때 정말 유용합니다.

Answer 3

프로젝트를 종료하고 깨끗한 프로젝트가 끝나면이 작업을 수행하지 말아야합니다. 프로젝트 관리 문헌에서 읽을 수 있듯이 외부 프로젝트에 프로젝트에 참여할 수있는 가능성을 부여하는 프로젝트 닫기 문서가 있습니다. 그래서 당신의 임무는 드물지 않습니다.

우선 프로젝트 소스 코드를위한 전용 장소를 만들고, 브라우저로 탐색 할 수 있으므로 팀이 한 일을 조사하는 장벽이 매우 작습니다. 또한 문서 (아키텍처 등)를 사용할 수 있는지 확인하십시오. 그런 다음 특정 인공물을 깨끗하고 추적 가능한 방식으로 연결하는 프로젝트 경험 위키를 작성할 수 있습니다. 아마도 당신이 마주 치게되는 매우 어려운 문제들과 해결책을위한 wikipage와 함께. 이걸 가지고 있다면 프로젝트에 대한 지식을 다른 사람들이 활용하는 것이 매우 쉬울 것입니다.

Answer 4

다음 포스트에서 볼 수도 있습니다 : What's your Post-Mortem meeting format?

을 당신이 원하는 모든 것을 커버하지 않는 동안, 아마 좋은 출발점입니다.