프로젝트 후 시간 낭비?

우리는 직장에서 심각한 고통을 겪었습니다. 우리는 3 ~ 10 명의 개발 팀에서 근무했으며 회사 자체는 지난 해 30 % 성장했습니다. 대부분의 측정으로 우리는 잘하고 있습니다. 불행히도 소프트웨어 품질이 떨어졌습니다.

오늘 부서 부서장과의 회의에서 제품 출시 후 하루나 이틀 후에 프로젝트 팀 회의를 제안했습니다. 우리는 예산 문제, 범위, 무엇이 잘못되었는지, 무엇이 잘못되었는지에 대해 논의 할 수있었습니다. 이상적으로, 우리의 실수로부터 배우십시오. 우리는 다른 사람들을 위해 사이트 / 앱을 구축하므로 시간은 청구 불가능한 청구 가능합니다. 이와 같은 회의는 후자에 해당합니다.

관리자는 거의 즉시이 문제를 해결했습니다. "이 시간은 청구 할 수 없습니다. 다른 프로젝트에 대해 이야기하는 데 시간을 낭비하기 때문에 다른 프로젝트에 참여하게 할 것입니다." 나는이 논리에 너무 푹 빠져서 그와 싸우는 것도 귀찮게하지 않았다.

그래서 내 질문 : 가치는 프로젝트 후 회의이지만, 그는 그렇지 않습니다. 거기 문서화 된 긴 (또는 짧은) 실행에 시간과 돈 저장 돕는 후 프로젝트 회의의 증거? 직감적으로 나는 그렇게 할 것이라고 생각하지만, 그는 거기에 있어야 할 5 명의 사람들이 청구 할 수없는 적은 시간에 대해 더 걱정하고 있습니다.

되돌아 보면, 앞 을 내다 보는 것은 그 아이디어에 대한 문서화 된 증거에 가깝습니다. 프로젝트 포스트 모템 : 지속적인 개선을위한 귀중한 도구 는 블로그 포스트가 될 것입니다.

포스트 모템의 예술 은이 아이디어에 대해 다음과 같은 요점을 가지고 있습니다.

Post-Mortem의 기원은 군대와 함께 일하는 사람들이 일상적으로 이런 종류의 과정을 사용하여 최전선에서 사람들을 브리핑합니다. 그러나 관리 응용 프로그램은 모든 고성능 학습 조직에 필수적입니다.

관리자가 기술 부채 개념을 이해하지 못합니다 .

프로젝트 후 회의는 비용이 아니라 투자입니다. 그것이 당신이 그들을 팔아야하는 방법입니다. 회의의 목적 은 장기적으로 돈을 절약하고 회사의 목표 를 달성하는 방법에 대한 아이디어를 교환하는 것 입니다.

관리자는 이러한 장기 목표를 다루기 때문에 관리자입니다. 내 견해로는 두 가지 가능한 진실이 있습니다. 관리자는 자신의 모든 통제력을 원하거나 관리자가 자신의 일을하지 않습니다. 회사에 "올바른 방식으로"일하고 자신의 성공에 투자 한 역사와 철학이 있다면 관리자보다 문제를 고려하십시오.

이것은 본질적으로 사후 조치 검토 이며, 군대뿐만 아니라 많은 다른 상황에서 특히 유용합니다.

내 개발주기에는 다음 반복 또는 프로젝트에서 수행 할 작업과 이전 프로젝트에서 수행 할 수있는 작업을 모두 분석하는 작업이 포함됩니다. 프로젝트가 잠시 보류 된 경우에도 작업 할 작업 목록을 가지고 있으면 선반에서 떨어질 때 도움이되고 다시 활성 프로젝트가됩니다. 다음에 만질 때, 내가해야 할 일을 검토하는 데 많은 시간을 소비하지 않아도됩니다.

또한 프로젝트를 검토하고 나 또는 다른 사람들이 구현 한 깔끔한 트릭을 찾아 내면 다음 프로젝트 또는 다음 반복이 훨씬 좋습니다. (반복에 대해 자주 생각한다는 것은 놀라운 일이 아닙니다.)

이것의 가치는 단순한 논리이며 본질적으로 명백합니다. 이전 프로젝트의 실수로부터 배우지 않으면 어떻게 미래의 프로젝트를 개선 할 수 있습니까?

특별히 문서화는 아니지만 프로세스 검토 (완료 중 또는 완료 후)는 CMMI 및 Lean 6 Sigma에 대해 알고있는 거의 모든 표준 기반 품질 관리 시스템의 주요 구성 요소입니다.

어쩌면 점심 모임이나 자발적으로 수행 된 것 또는 의무가 아닌 것으로 제안 할 수 있습니까? 많은 개발 팀이 와서 새로운 것을 시도하기를 간절히 바랄 것입니다. 따라서 적어도 첫 번째 팀을 스윙 할 수 있다면 결과는 스스로 말할 것입니다.

관리자가 예산 압박을 받고있을 수 있습니다. 단기간에 개발자를 3 명에서 10 명으로 확장 할 때 큰 관심사가되어야합니다. 이 경우 사후 회의를 건너 뛰고 몇 개월 안에 다시 예산을 제시하는 것이 좋습니다.

질이 어려울 수있는 한 가지 이유는 10 명 사이의 의사 소통이 3 명 사이의 의사 소통보다 훨씬 더 큰 문제이기 때문입니다. 3! << 10 !. 잠시 동안 당신은 아마도 혼란 스러울 수 있지만, 결국 개발자들 사이의 더 나은 의사 소통을 촉진하고 원래의 3 명의 개발자들이 확립 한 원칙들이 새로운 사람들과 새로운 대규모 그룹에서 잘 작동하도록 업데이트되었습니다. 사후 회의 프로젝트는이를위한 한 가지 방법입니다. 정기적 인 코드 검토는 또 다른 것입니다. 사후 회의는 의약에서 제조에 이르기까지 산업에서 품질 개선의 중요한 부분이라는 점은 아프지 않을 것입니다.

관리자가 단순히 추가 인력을 고용하여 개발 팀을 확장 할 수 있다고 생각한다고 생각하기 어렵습니다. 훈련과 팀 구축에는 절대적으로 투자가 필요합니다. 그렇지 않으면 조직은 자체 무게로 무너질 것입니다. 조금만 기다리면 조직에서 의사 소통이 제대로 이루어지지 않아 발생하는 구체적인 문제가 발생할 수 있습니다. 이 시점에서 관리자는 아마도 "모든 사람을 같은 페이지에 배치해야합니다! 모든 개발자와 회의를 예약하십시오!"라고 말합니다. 도움이 될 것 같으면 아마도 "모든 프로젝트 후에이 작업을 수행해야합니다!"라고 말할 것입니다. ;-)

따라서 인내심을 가지십시오.

나는 추세를 버릴 것이다 : 나는 매니저와 동의한다.

공개 된 문제를 해결하기 위해 많은 일을하기에는 너무 늦었 기 때문에 프로젝트 후 리뷰가 무의미하다는 것을 알았습니다.

내가 가장 권장 하는 것은 프로젝트 중에 수행 되는 주기적 회고 입니다. 한 달에 한두 번 팀이 잘 된 일과 그렇지 않은 일에 대해 이야기하게합니다. 더해야 할 일, 덜해야 할 일 이 작업을 수행 프로젝트 중 즉시 제안을 적용하고 작동 방법을 잘 볼 수 있도록.

회의에 집중하는 것을보십시오. 많은 사후 프로젝트 회의는 말이 많으며 관리자는 회의를 지원하지 않는 것이 절대적으로 정확합니다.

회의를 관리하고 (의장 / 보좌 요청) 의제를 순환 시키며 구체적인 결과를 가져 오십시오. 그런 다음 관리자는 회의에서 가치를 볼 수 있습니다.

우리는 de Bono의 "6 Thinking Hats"검토 과정을 사용하는 것이 좋습니다 ( Wikipidia 참조 ). 결과는 회의에서 가장 중요한 레슨 학습자 인 것으로 식별되는 몇 가지 행동 포인트입니다. 처음 몇 번이나 시작 블록을 꺼내는 데 문제가 있었지만 일단 익숙해지면 다시 돌아 가지 않습니다.

프로젝트 후 검토를 수행하지 않으면 이전 프로젝트에서했던 것과 같은 실수를 범하게됩니다.