회사 A는 중국에 있는 미국 소유 소프트웨어 회사의 사무실입니다. 이 회사의 주요 목표는 중국 시장을 개발하고 중국 고객에게 서비스를 제공하며 일부 현지화 및 사용자 정의 작업을 수행하는 것입니다. 주요 소프트웨어 제품은 실리콘밸리에 본사를 둔 소프트웨어 개발기지에서 완성되며, 전 세계 지사 또는 사무실에서 맞춤형, 2차 개발 및 시스템 유지관리를 하고 있습니다. 일일 판매 및 시스템 핵심 유지 관리 외에도 이러한 작업은 모두 현지 소프트웨어 회사에 아웃소싱됩니다. Dongfang Company는 A사의 중국 파트너이며 주로 소프트웨어 현지화 및 테스트를 담당합니다.
밥 씨는 A사의 중국 지역 담당자이고, 헨리는 A사에 막 합류한 이번 아웃소싱 프로젝트를 담당하는 프로젝트 관리자입니다. Eastern Company는 프로젝트 관리 경험이 없는 기술자인 William이 개발하고 관리합니다.
헨리가 작업을 맡게 되었을 때 Dongfang Company의 프로젝트 개발 비용은 1인당 하루 130달러로 매우 높았으나 고객 만족도가 좋지 않아 모든 개발 진행이 지연되고 납품도 지연되는 것을 발견했습니다. 사용된 버전도 만족스럽지 못했습니다. 더욱이 동방회사와 A회사의 실리콘밸리 개발본부는 필요한 의사소통이 부족하여 헨리에게만 문제를 피드백할 수 있었고, 헨리는 이를 본사로 피드백했습니다. 하지만 헨리 자신도 이 소프트웨어 개발에 익숙하지 않았기 때문에 불필요한 문제도 많이 발생했습니다.
이를 위해 Bob은 Henry와 William이 프로젝트 관리 방법을 사용하여 프로젝트를 관리하고 개선하기를 바랍니다. 그 후 Henry와 William은 새로운 접근 방식을 제안하기 위해 일련의 회의를 가졌습니다.
첫째, 상세한 프로젝트 계획과 일정을 개발했으며, 둘째, 소프트웨어 개발과 테스트를 분리하기 위해 별도의 테스트 팀을 구성했으며, 커뮤니케이션 채널을 통해 일부 소프트웨어를 통해 실리콘 밸리와 동부 기업 간의 새로운 관계를 구축했습니다. 이슈 사항은 본사와 직접 소통할 수 있으며 동시에 마일스톤 관리도 도입됩니다.
6개월 후 소프트웨어가 출시되었습니다. 그러나 고객들은 여전히 이 버전에 만족하지 못하고 문제가 많다고 생각하고 있습니다. 프로젝트 관리 방법을 사용해도 이 프로젝트가 개선되지 않는 이유는 무엇입니까?
Henry와 William이 이에 대해 다시 논의한 결과 주로 세 가지 문제가 있음을 발견했습니다. 1. 소프트웨어 현지화로 인한 문제는 많지 않습니다. A사 자체에서 제공하는 기본 소프트웨어에 문제가 있습니다. 2. 소프트웨어 인터페이스에도 문제가 있습니다. 이는 세부적인 테스트 프로젝트가 부족하여 발생합니다. 3. 개발 주기가 아직 너무 짧고 시간이 없습니다. 일부 프로젝트의 디버깅을 완료하기 위해 새 버전에는 여전히 많은 문제가 있습니다.
이때 헨리는 밥에게 새롭고 강력한 파트너를 선택하기 위해 공개 입찰 방식을 채택할지 여부를 물었습니다. 그러나 Bob은 Dongfang Company와의 협력이 오랫동안 지속되어 새로운 파트너를 선택하면 적응 기간이 더 길어지고 비용도 더 높아질 수 있다고 생각합니다. 따라서 Henry는 Dongfang Company에 몇 가지 새로운 경영 제안을 제안했습니다. 첫째, 더 자세한 진행 계획을 분석하고 개발하기 위해 많은 양의 과거 데이터를 사용했으며, 둘째, Dongfang Company에 문서 없이 자세한 개발 문서와 테스트 문서를 제공하도록 요구하여 다른 작업에 많은 어려움을 초래했습니다. , 개발 주기를 재검토하고 마일스톤을 개선합니다.
또 6개월이 지나 새 버전이 완성됐다. 이번에 고객들은 이전 두 버전보다 훨씬 높은 평가를 내렸고 기본적으로 프로젝트 운영 요구 사항을 충족했습니다. 하지만 고객들은 여전히 프로젝트 진행 상황에 대해 의문을 제기했고, 실시간으로 대체 제품을 출시하는 데 그리 오랜 시간이 걸리지 않을 것이라고 믿었습니다.
보다 일반적인 접근 방식입니다. 소프트웨어 아웃소싱 프로젝트에서는 품질 보증의 진행 상황을 통제하기 어렵습니다. 프로젝트 관리자에게는 기획, 우선순위 지정, 이해관계자와의 의사소통, 평가 등 일련의 복잡한 능력이 필요합니다. 각 능력은 프로젝트의 최종 결과와 직간접적으로 관련됩니다.
그러나 대부분의 국내 프로젝트 관리자는 정식 교육을 받지 못했고 프로젝트 관리에 대한 전문적인 지식과 기술이 부족하여 이전 경험에 무작정 의존하는 경우가 많아 다양한 문제가 발생하기 쉽습니다. 특히 아웃소싱 프로젝트를 관리할 때 충분한 경험과 기술이 부족하여 지속적인 진행 지연과 품질 보장이 불가능한 경우가 많습니다.
이 경우 오늘날 IT 업계에서 많은 아웃소싱 프로젝트의 그림자를 볼 수 있습니다.
이 경우 둥팡컴퍼니에는 전담 프로젝트 매니저가 없었고, 기술자 윌리엄이 파트타임으로 관리했다. 국내 소프트웨어 업체에서 흔히 발생하는 문제다. 처음에는 일정이 늦어지는 문제가 발생하자 A회사의 Henry와 Eastern Company의 William이 마일스톤 관리를 포함한 프로젝트 관리에 계획 관리 및 기타 방법을 사용하기로 논의하고 결정했습니다. 이는 진행 상황을 제어하는 보다 일반적인 방법입니다.
마일스톤 관리 소개
일반적으로 프로젝트 시작 시 프로젝트 팀원은 프로젝트에 대한 세부 계획을 수립합니다. 일반적으로 명확한 작업 명세서(SOW) 및 WBS를 기반으로 특정 일정을 개발하려면 몇 가지 특정 기술이 필요합니다. 이와 같은 소프트웨어 아웃소싱 프로젝트의 경우 가장 성숙한 기술은 마일스톤 관리입니다.
마일스톤은 일반적으로 프로젝트의 단계별 작업 완료를 표시합니다. 다양한 유형의 프로젝트에는 다양한 마일스톤이 있습니다. 예를 들어, 개발 프로젝트에서는 요구사항 최종 확인, 제품 인도 등 주요 작업을 프로젝트 마일스톤으로 사용할 수 있습니다. 이런 경우 헨리가 프로젝트를 인수한 후 마일스톤 관리를 활용하는 것이 적절하다.
그러나 각 마일스톤마다 이전 작업을 적시에 요약하고 후속 작업 계획을 조정해야 한다는 점에 유의해야 합니다. 관리 효과가 분명한 일부 영역의 경우 더 많은 에너지를 투자할 필요가 없습니다. 다음 관리 과정에서 문제가 발생할 수 있는 부분에 더 많은 주의를 기울여야 합니다. 물론 진행 중인 변경은 소프트웨어 프로젝트에서 흔히 발생합니다.
이 경우 마일스톤 관리를 도입한 후에도 여전히 고객의 요구 사항이 충족되지 않아 진행이 계속 지연되었습니다. 여기서는 품질과 진행 사이의 관계라는 또 다른 요소를 고려해야 합니다.
일반적으로 프로젝트 관리의 전제는 프로젝트가 예산 내에서 일정대로 완료되고 품질을 충족시키는 것을 보장하는 것입니다. 따라서 품질 확보가 전제조건이라고 볼 수 있다. 그렇다면 품질을 만족시키면서 진행 상황을 관리하는 방법은 단순히 프로젝트 관리 이론 지식만으로는 효과적인 방법이 없습니다. 구체적인 단계는 다음과 같습니다.
먼저 과거 데이터를 활용해 보세요. 이 경우 Henry는 이전 프로젝트 상황을 조사하고 비교 가능한 상황을 찾아 관리해야 하는 품질과 일정 간의 관계를 미리 알 수 있어야 합니다.
둘째, 이 프로젝트는 소프트웨어 아웃소싱 프로젝트이기 때문에 헨리는 프로젝트의 리소스 일정을 완전히 파악하지 못하여 품질 관리가 부족합니다. 이는 대부분의 아웃소싱 프로젝트에서 마스터하기 가장 어려운 측면이기도 합니다. 여기서는 일정관리 계획에 품질변수를 추가하는 방법, 즉 일정을 조정하는 방법을 이용할 수 있습니다. 매개변수 관계를 통한 품질.
이 접근 방식의 전제는 특정 과거 데이터를 보유하는 것입니다. 예를 들어, 과거 데이터를 통해 하위 프로젝트를 완료하는 데 걸리는 시간은 5일이고 테스트 후 15개의 질문이 있으며 동일한 하위 프로젝트를 완료하는 데 걸리는 시간은 7일이며 이후에는 10개의 질문이 있는 것으로 알려져 있습니다. 테스트는 동일한 하위 프로젝트를 완료하는 데 걸리는 시간이 8일이며, 테스트 후에 5개의 질문이 있습니다.
데이터가 계속 증가함에 따라 2차원 좌표 차트를 사용하면 (자원 차이에 관계없이) 일부 불연속적인 지점이 얻어지고 그림 1과 같이 곡선이 형성됩니다. 프로젝트의 허용 가능한 품질 범위를 고려하고 이를 차트의 데이터와 비교하여 해당 매개변수를 찾습니다. 획득한 매개변수를 기반으로 적절한 일정을 결정하세요