IT 프로젝트 품질관리 기법 적용 시 주의사항
IT 프로젝트 개발자는 일반적으로 프로젝트를 고품질로 제 시간에 완료하는 것이 어렵다고 생각합니다. 프로젝트 관리자가 고품질 프로젝트 결과를 원하지 않는 것이 아니라 단지 프로젝트를 완료할 수 있기를 원할 뿐입니다. 품질을 기준으로 기한 내에 이 프로젝트를 완료하고 예산에 맞춰 달성합니다. 일부 프로젝트 관리 기술은 실제로 품질 저하 없이 비용과 개발 시간을 줄이는 데 성공할 수 있지만 이러한 기술을 과도하게 사용하면 재앙적인 결과를 초래할 수 있다는 점에 유의하는 것이 중요합니다.
1. 타임박스
프로젝트의 질을 떨어뜨리는 사건 중 누군가에게 작업을 넘겨줘야 한다고 말할 때 타임박스 적용이 1위를 차지합니다. 이전에는 작업을 완료하는 데 얼마나 걸리나요? "완료"보다는 "인계"라고 말합니다. 극단적인 경우 이는 코드가 완벽하지 않고 작업을 완료하는 데 시간 문제일 뿐이라는 의미가 되기 때문입니다.
대부분의 경우 타임박싱은 다음 네 가지 기능을 수행하므로 효과적입니다.
1. 개발자가 예산 내에서 창의력을 발휘하고 작업하도록 합니다.
2. 소프트웨어에 흔히 추가되는 불필요한 장식을 제거하며, 이러한 장식은 소프트웨어의 가치를 높이지 못하는 경우가 많습니다.
3. 개발자의 과도한 테스트를 방지합니다.
4. 목적은 단지 이 제품을 얻는 것입니다. 전체 품질 평가(QA) 단계에서 자세한 테스트가 있을 예정입니다. 이 단계에서 코드의 문제를 찾을 수 있기를 바랍니다.
알 수 없는 문제가 있거나 기술이 테스트되지 않았거나 결과를 확인할 수 있는 올바른 방법이 없을 때 타임박스가 작고 할당된 시간 내에 존재하지 않으면 타임박싱은 무력합니다. 목표를 달성하는 방법도 접근 방식이 효과적이지 않습니다. 즉, 타임박싱은 작업을 완전히 이해하고 신중하게 평가하고 실행하는 등의 일부 문제를 잘 해결할 수 있지만 연구 개발, 문제 해결 등과 같이 타임박싱 방법으로 해결할 수 없는 문제도 있습니다.
타임박싱을 올바르게 사용하면 수백 시간의 진단 및 재작업으로 이어질 수 있는 잘못된 코드 테스트가 발생해서는 안 됩니다. 최저 비용, 가장 빠른 속도, 최고 품질의 소프트웨어를 보장하려면 타임박싱을 적절하게 사용해야 합니다.
2. 지연
모든 사람은 노력해야 할 목표가 있어야 합니다. 마일스톤은 사람들이 동일한 목표를 향해 나아가도록 영감을 주는 데 사용되는 존경받는 방법입니다. 아주 짧은 시간 안에. 그러나 모든 사람은 목표가 항상 달성되는 것은 아니며 새로운 결정을 내려야 한다는 점을 받아들여야 합니다.
프로젝트 관리자는 팀이 앞으로 나아갈 동기를 부여하기 위해 마일스톤 목표를 설정해야 합니다. 그러나 마일스톤으로 설정한 날짜가 현실적이지 않고 팀원이 반복적으로 실수를 하는 경우 이를 재평가해야 합니다. . 어떤 특별한 상황으로 인해 이 날짜가 더 이상 중요하지 않게 되면 중요한 날짜가 도래했을 때 전체 팀은 이 마일스톤 날짜를 달성할 동기가 거의 없게 됩니다. 팀 전체가 10번의 데이트를 연속으로 놓치면 11번째 데이트가 중요한가요? 마치 어린아이가 우는 늑대와 같나요?
설정된 타임라인 이후에도 페널티가 없으면 이 시간을 놓쳤을 때 전체 타임라인을 강제로 강제로 이동하거나 이동해야 합니다.
장기적으로 끊임없이 스트레스를 주고 혼란스러운 환경을 조성한다고 해서 좋은 소프트웨어가 탄생하는 것은 아닙니다. 개발자에게는 업무에 집중할 수 있는 환경이 필요합니다. 프로젝트 완료 날짜와 마일스톤 날짜가 실제인지에 대한 혼란으로 인해 개발자는 개발 프로세스에서 중요한 단계를 건너뛰거나 찾기 어려운 문제를 일으키는 경우가 많습니다.
3. 종속성 무시
소프트웨어 개발에는 종속성을 지연시키는 기술이 많이 있습니다. 일부 기능을 비활성화하거나 연결의 기본 구조를 이동하거나 우회할 수 있습니다. 수많은 오류가 있습니다. 이러한 기술을 올바르게 사용하면 프로젝트 진행에 도움이 될 수 있지만 이러한 기술의 비용 요소가 프로젝트 완료를 위한 전체 계획에 고려되지 않으면 문제가 발생합니다.
프로젝트에서 소프트웨어 개발의 순서를 정하는 것은 매우 어려운 일이기 때문에 관련성을 찾기가 쉽지 않기 때문에 계획에서 많은 관련 요소가 정리되지 않는 것은 불가피합니다. 이러한 예상치 못한 종속성에 대한 일정을 계획하면 종속성을 억제하는 방법이 자주 사용되지만 이러한 기술을 과도하게 사용하면 이러한 비용이 프로젝트의 전체 프로젝트 비용의 상당 부분을 차지할 수 있으며 그렇지 않을 수도 있습니다. 프로젝트가 끝날 때까지 발견됩니다.
그러므로 지금 하고 있는 일이 종속성을 관리하는 데 필요하고 비용이 너무 많이 추가되지 않으며 전체 소프트웨어 개발 프로젝트의 필수적인 부분인지 확인하세요. 프로젝트 관리자가 종속성 감소의 편리함과 비용의 균형을 맞추지 못하면 그들이 엉성하게 조립한 코드에 품질 문제가 나타납니다.
4. 실수 없는 척
프로젝트 관리에 있어서 방치는 축복이 아닙니다. 프로젝트를 성공적으로 완료하기 위해서는 거침없는 정치적 압력과 더불어 프로젝트의 위험성에 대해 회사 전체에 교육이 필요합니다. 거의 모든 소프트웨어 개발 프로젝트에는 지연, 예산 초과 또는 두 가지 모두의 위험이 있습니다.
문제는 결국 어느 시점에 이러한 리스크가 실제로 현실화되면 패닉을 불러일으키고 모두가 나머지 프로젝트를 혼란에 빠뜨리게 되고 전체의 품질이 저하된다는 점입니다. 프로젝트가 엉성한 조립으로 인해 영향을 받게 됩니다.
물론 이 문제는 전체 프로젝트가 일정보다 늦어질 때까지 완전히 드러나지 않을 것입니다. 그러나 대부분의 프로젝트에는 프로젝트의 특정 부분만 약간 뒤쳐지게 하고 거의 절대 빠지지 않게 하는 방법이 있습니다. 모든 프로젝트는 프로젝트에서 문제가 해결된 후에도 오랫동안 프로젝트의 실제 상태를 알지 못하기 때문에 서두르게 될 위험이 있습니다.