3
클라이언트가 프로젝트 범위에없는 요구 사항을 요청할 경우 프로그래머는 얼마나 유연해야합니까?프로젝트 범위의 유연성?
A
답변
0
이 질문에 포괄적 인 답변을 드릴 수는 없습니다. 그것은 프로젝트 프로젝트에 달려 있습니다.
예 :
클라이언트 구울 돈, 긴 타임 라인을 가지고는 이동에 다른 프로젝트, 나는 매우 유연 생각하지 않습니다.
고객이 $$, 짧은 타임 라인, 이동 중에도 다른 프로젝트와 밀접한 관계가 없으며 유연성이 거의 없습니다.
프로젝트를 위해 선택한 프로세스와 같은 다른 요소도 적용됩니다. 예를 들어 애자일 프로세스에서보다 유연하고 폭포수 접근 방식에서는 유연성이 떨어집니다.
0
귀하의 질문에 대한 대답은이 두 가지 사항에 영향을 미치지 않고 프로젝트의 범위를 변경할 수 없으므로 클라이언트가 시간과 비용면에서 얼마나 유연한 지 알 수 있습니다.
범위 크립은 프로젝트가 진화하고 프로젝트의 결과에 전반적인 긍정적 인 영향을주는 경우 좋은 것일 수 있습니다. 범위 변경을 관리하려면 공식 변경 프로세스가 필요합니다.
1
일반 전망 :
생계비가 필요합니다. 클라이언트는 컴퓨팅 솔루션이 필요합니다. 클라이언트는 자신이 제공 할 솔루션이 자신의 필요에 맞는지 확인할 수있는 권리가 있습니다. 변경 사항 및 추가 사항과 합의가 이루어지면 사용자의 요구 사항을 시스템 설계로 분석하여 충분한 요구 사항을 세부적으로 조사하지 못한 사용자의 요구 사항을 반영합니다.이를 세 심하게 수행하고 서면으로 서명을 받아야합니다 고객으로부터 시스템 설계에 대한 동의.
법적 관점 :
당신은 아래 프로젝트의 범위를 고정하고, 그 범위의 계약을 체결하도록 클라이언트를 얻어야한다. 계약을 체결하면 그 계약에 포함되지 않은 모든 사항이 새로운 프로젝트로 간주됩니다.
비즈니스 관점 :
당신이 (현재뿐만 아니라 미래의 고객과의) 사업을 계속 하시겠습니까? 새로운 필수 기능이 현재 프로젝트에 추가 될 때 미치는 영향에 대한 평가를 수행해야합니다. 영향이 적다면 영향을 미칩니다. 그러나 클라이언트에게 서면으로 그에게 유리하게하고 있다고 말하십시오. 영향이 클 경우 고객과 협상하고 문제 개요를 작성하고 현재 계약을 변경하거나 새로운 계약을 만들어야합니다. 당신이 원하지 않는 것은 당신의 클라이언트를 적대하는 것입니다.
마지막으로 : "클라이언트는 항상 옳습니다." - (포기해야하는 곳까지)
0
고정 입찰 프로젝트 인 경우 협상에 동의하며 한 영역에서 범위를 확장하는 데 동의합니다. 다른 곳에서, 또는 예산 증가를 위해, 또는 다른 고려 사항과 교환합니다.
시간당 요금을 청구하는 클라이언트의 경우 원하는 범위를 확장 할 수 있습니다. 원하는 시간대에 비용을 청구 할 것이므로 원래의 프로젝트 여부.
0
시스템에서 수행 할 기능 목록을 미리 정의하십시오.
클라이언트가 새 기능을 추가하면 그에 따라 비용과 시간이 증가합니다.
클라이언트가 범위를 벗어나기로 결정한 경우 아직 구현하지 않은 경우 비용과 시간이 감소합니다.