9.0 폭포수 대 주기적 프로젝트 관리(2부) – 시간 및 자원 추정

폭포수 기법은 단계로 나뉩니다. 프로젝트 리더는 프로젝트 계획의 각 단계에 필요한 시간(및 그에 따른 비용)의 추정치를 포함해야 합니다. 우리는 이전에 시간 추정치가 모든 프로젝트에 본질적으로 문제가 있다는 점을 확인했으며, 프로젝트 수명 초기에 설정해야 하는 경우에는 더욱 그렇습니다. 소프트웨어 프로젝트에서는 실현 가능하지 않습니다. 정의 단계에서 질적으로 수용 가능한 기능 목록이 컴파일될 가능성을 고려하십시오. 원칙적으로 이를 통해 프로젝트 팀은 각 기능을 개발하는 데 필요한 시간을 현실적으로 추정할 수 있습니다. 그러나 실제로는 공정한 근사치를 제공하기에는 불확실성이 너무 많습니다.

그러나 실제로는 공정한 근사치를 제공하기에는 불확실성이 너무 많습니다.

  • 기능이 개발된 후 클라이언트에 필요하지 않은 경우가 종종 있습니다. 따라서 이 기능을 개발하는 데 소비한 시간은 헛된 것으로 간주될 수 있습니다.
  • 프로젝트가 진행되는 동안 요구 사항이 변경될 수 있습니다.
  • 기능을 높은 비용으로 제공해야 할까요 아니면 낮은 비용으로 제공해야 할까요? 많은 구현 및 구현 기술이 있습니다.
  • 기능은 기술적으로 어떻게 설계됩니까? 디자인은 그것을 만드는 데 필요한 시간에 큰 영향을 미칩니다.
  • 기능은 어느 정도 높은 수준이어야 합니까? 예를 들어, 웹 애플리케이션은 항상 완전히 액세스할 수 있어야 합니까, 아니면 1년에 몇 시간 동안 다운되도록 허용해야 합니까?
  • 소프트웨어 문제를 감지하고 수정하는 데 필요한 시간은 몇 분에서 몇 주까지 다양합니다.
  • 새 소프트웨어를 설치하고 고객의 현재 시스템과 통합하는 데 얼마나 걸립니까?
  • 잠재적 솔루션에 대한 정보가 부족하면 예상 시간에 더 큰 영향을 미칩니다. 또한 필요한 전문 지식을 습득하는 데 필요한 시간을 추정하는 것도 어렵습니다.

위의 목록은 다양한 변수가 새로운 소프트웨어를 개발하는 데 필요한 시간에 영향을 줄 수 있음을 보여줍니다. 프로젝트 시작 시 기능을 개발하는 데 필요한 예상 시간은 종종 4배 너무 낮거나 4배 너무 높습니다. 이것은 필요한 시간이 잘못된 추정보다 4배 더 많거나 4배 적을 수 있음을 의미합니다. 프로젝트가 진행됨에 따라 이러한 추정치는 더욱 정확해집니다. 기능적 디자인을 완성한 후 마진을 25%로 너무 많이 또는 너무 적게 줄입니다. 기능이 개발되었을 때만 높은 신뢰도로 추정이 가능합니다.

소프트웨어 위험 #

프로젝트 관리 소프트웨어 완전히 오류가 발생하지 않습니다. 널리 사용되는 잘 알려진 프로그램(예: Word, Excel, Explorer, OS X, PHP, Flash)의 경우에도 인터넷에는 알려진 결함 목록이 있습니다. 정기적으로 소프트웨어 버그를 수정하는 새 버전이 시장에 출시됩니다. 고객은 때때로 소프트웨어에 오류가 없는 것을 요구합니다. 그러나 실제로 그러한 목표는 소프트웨어를 완성하는 것을 불가능하게 만들 것입니다. 또한 소프트웨어 오류는 종종 프로그램에 내재되어 있지 않습니다.

Flash는 교육용 게임을 만드는 데 사용되었습니다. 클라이언트는 게임을 파일로 받아 자신의 서버에 설치하는 데 동의했습니다. 프로젝트 과정에서 클라이언트는 플레이어의 경쟁력을 높이기 위해 게임에 고득점 기능을 추가할 것을 요청했습니다. 이것은 약간의 PHP 스크립트 코드가 필요합니다. 게임 개발자는 Linux를 실행하는 자체 서버에서 스크립트 코드를 개발하고 테스트했습니다. 성공했습니다. 클라이언트는 게임 및 스크립트 코드를 받았습니다. 그러나 클라이언트는 Windows 서버를 사용했고 어떤 이유로 스크립트가 제대로 작동하지 않았습니다. 최고 등급은 유지되지 않았습니다. 프로그래머는 궁극적으로 문제를 해결하는 데 일주일이 필요합니다. 결과적으로 PHP와 Windows가 항상 함께 잘 작동하는 것은 아닙니다. 대본 전체에 실수가 전혀 없었습니다! 그는 해킹을 사용하여 작동하도록 만들 수 있었고 모두가 만족했습니다. 하지만 추가로 1주일 동안의 노동 비용을 누가 지불해야 할까요?

또 다른 소프트웨어 개발 프로젝트에는 교육용 응용 프로그램의 생성도 포함되었습니다. 문제는 소프트웨어가 개발자에게는 훌륭하게 작동했지만 클라이언트에게는 좋지 않았다는 것입니다. 다른 모든 가능성을 소진한 후 프로그래머는 클라이언트를 방문하기로 결정했습니다. 결과적으로 클라이언트는 1990년대 초부터 Pentium III 시스템을 실행하고 있었습니다. 컴퓨터의 느림은 소프트웨어의 성능 저하에 기여했습니다. 또한 프로그래머는 Pentium III에서 소프트웨어를 시도했고 잘 작동했습니다. 추가 조사 결과 고객의 PC가 바이러스 및 스파이웨어 감염으로 인해 느리게 실행되는 것으로 나타났습니다.

프로젝트 개발의 불확실성 관리 #

위의 사례에서 나타난 불확실성은 다음의 과정을 복잡하게 만듭니다. 프로젝트 계획 개발 . 또한 당사자 간의 협상을 복잡하게 만듭니다. 누군가는 수행해야 하는 추가 노동과 관련된 위험을 감수해야 합니다. 시간당 지불하는 경우 모든 위험은 고객이 부담합니다. 정해진 수수료가 합의되면(보조금 지원 프로젝트의 경우와 같이) 소프트웨어 개발자가 위험을 감수합니다. 2명 이상이 관련되면 상황이 더 복잡해집니다. 이 시나리오에서 프로젝트에서 추가로 작업한 시간에 대한 비용은 누가 부담해야 합니까?

지연에 대해 누가 책임을 져야 하는지에 대한 분쟁이 자주 발생합니다. 책임자를 식별하기 어려운 경우가 많습니다. ‘지연’이 필요한 시간의 잘못된 초기 추정으로 인해 발생했기 때문에 관련된 당사자 중 누구도 책임이 없다고 생각할 수 있습니다. 과도한 프로젝트 시간과 누가 지불해야 하는지에 대한 문제는 정보 기술 산업에서 일반적인 논쟁의 원인입니다.