고객은 다르게 생각하기 때문에 약간의 교육이 필요합니다. 고객은 다음을 생각합니다.
프로젝트의 어떤 시점에서도 변화는 문제가되지 않습니다
세부 사항은 중요하지 않습니다 (예외는 더 적음)
시간은 돈이 들지 않습니다 (수정 가격이 합의되었습니다)
사양의 한 문장은 실제 요구에 맞게 자유롭게 확장 / 읽을 수 있으며 이는 계약에 영향을 미치지 않습니다. (여기서 "상식"토론을 자주 봅니다. 예 : "물론 회계 관리에 대해 이야기 할 때 송장 관리 화면이 필요합니다. 이것은 상식입니다!"
주요 문제는 고객 (외부 또는 내부 / 부서와 상관없이)이 원하지 않거나 이해할 수 없다는 것입니다. 소프트웨어 제작 과정을 이해하는 데 몇 년이 걸렸으며 여전히 배우고 있습니다. 몇 달 안에 어떻게 할 수 있습니까?
당신의 경험은 무엇입니까, 고객 교육을위한 최선의 방법은 무엇입니까?
답변:
지난 여름, 나는 고객과 매우 비슷한 대화를 나 have습니다.
고객은 정의 된 작업에 대해 경쟁력있는 가격을 제공하기를 원했고, 요구가 변경되거나 요구에 대한 이해가 변경되면 작업 변경을 반영하기 위해 비용을 변경하지 않고도 사양을 변경하려고했습니다.
고객에게 견적의 일부로 알 수없는 변경에 대해 비용을 청구 할 수있는 방법에 대한 제안이 있는지 물었습니다. 우리가 해결 한 솔루션은 15 %의 항목 별 비상 수당을 포함하여 견적하는 것이 었습니다. 그런 다음 고객과 협력하여 해당 수당을 활용하기 위해 변경 사항의 우선 순위를 정합니다. 결국 우발 사태가 완전히 사용되지는 않았고 나는 그 일에 대해서만 송장을 작성했다.
최종 결과는 내가 수행 한 작업에 대한 대가를 지불하고, 고객이 예산 내에서 내부적으로 인도 한 것에 대해 기뻤으며, 전문가와 함께 문제를 사전에 제기했기 때문에 실제로 경쟁 업체보다 저를 선택했습니다. 작품.
나는 모든 잠재 고객이이 전문적이고 실제로 가치있는 솜씨가 있기를 바랍니다.
고객 교육 . 나는 당신의 고객 중 하나가 아니길 바랍니다.)
진심으로, 귀하의 문제에 대해 잘 알고 있으며 문제는 고객이라고 생각합니다. 어쩌면 그것은 중요하지 않습니다. 고객을 바꾸는 것은 정말 어려운 일이지만 고객과의 작업 방식을 바꾸는 것이 훨씬 쉽습니다.
문제는 대부분의 고객이 소프트웨어 개발의 모든 영향을 인식하지 못하고 자신의 비즈니스를 자세하게 알고 있지 않다는 것입니다.
하나의 작은 것 :
프로젝트의 어떤 시점에서도 변화는 문제가되지 않습니다
"얼마나 길을 잘못 가고 있든 뒤로 물러서십시오." 터키어 속담
나는 그 속담을 좋아하기 때문에 그것을 사용할 수 있으면 행복합니다. 기회에 감사드립니다;)
다음은 몇 가지 솔루션입니다.
고객이 마음을 바꿀 수있는 가능성을 제공해야합니다. 이는 고객의 요구에 맞는 올바른 소프트웨어를 얻는 데 도움이되기 때문입니다. 그는 당신이 그것을 개발하는 동안 결국 더 많은 아이디어를 얻을 것입니다.
귀하는 고정 가격 계약을 맺고 있으므로 요구 사항을 수집하고 견적을 정하고 각각에 가격을 정해야한다고 생각하십니까?
새로운 것을 만들어야하는 경우 동일한 프로세스를 사용하십시오. 추가 요구 사항으로 고정 가격 계약을 수정합니다. 쓸모없는 요구 사항을 제거하는 것을 수락하십시오 (물론 이미 구축하지 않은 경우).
또 다른 접근 방식은 협상 된 내용 (사용할 필요가없고 개발되지 않은 요구 사항은 없음)을 버전 1로 완료하고 버전 2를 새로운 아이디어와 협상하는 것입니다.
두 번째 해결책은 Scrum 과 같은 개발에서 반복을 만드는 것 입니다. 나는 고정 가격 프로젝트에서 아직 경험이 없기 때문에 (더 이상 고정 프로젝트를 수행하지 않기 때문에) 그것이 작동하는지 여부를 모르겠습니다. Scrum (또는 Agile )이 모든 소프트웨어 개발 프로젝트에 대한 솔루션이라는 데는 의문의 여지가 많지만 설명 된 일부 관행 이 도움이 될 것입니다.
고정 가격 계약을 체결 한 경우 모든 범위 변경에 비용이 발생한다는 점을 분명히해야하며 변경을 평가하고 변경을 구현하기 위해 비용이 많이 드는 견적을 제시해야합니다.
이것은 대부분의 산업에서 널리 인정되는 관행이지만 일부 고객은 이에 대해 매우 화를 낼 것입니다.
"상식"이 있다고 주장하지만 더 큰 문제가있는 것처럼 들린다면.
몇 년 전에 내가 사양을 읽고 "XXX를 수행하는 암시 적 요구 사항이 있습니다"라고 말한 고객과 약간 비슷합니다. 답은 다음과 같습니다. 암시 적 요구 사항이 없습니다. 서면 요구 사항 만이 요구 사항입니다. 요구 사항을 추가하거나 변경하려면 사양 변경 요청을 제출하십시오. 범위 변경을 인용하겠습니다.
메시지는 결국 통과되었지만 시간이 오래 걸렸습니다.
한 가지 해결책은 작업을 시작 하기 전에 동의 한 내용을 정의하는 데 더 많은 작업을하는 것 입니다. 당신이 말했듯이, 계약서의 한 문장은 당신과 고객에 의해 쉽게 읽을 수 있습니다. 프로젝트 계획이 상세할수록 그들이 원하는 추가 거래가 원래 거래의 일부가 아니라고 말하는 것이 더 쉽습니다.
일관성을 유지하는 것도 중요합니다. 고객은 주어진 새로운 기능에 대해 얼마나 많은 작업이 있는지 알지 못합니다. 신속하게 구현할 수있는 기능을 무료로 추가하는 데 동의하는 경우 나중에 고객에게 상식적으로 말하면 더 이상이 기능을 무료로 수행 할 수없는 이유를 고객에게 설명하기가 매우 어렵습니다.
고정 가격 계약의 한 가지 트릭은 고정 가격으로 작업을 수행하더라도 작업 소요 시간을 추정하는 것입니다. 시간 단위로 요금을 청구하지 않더라도 고정 가격이 무한 근무 시간과 같다는 착각이 사라집니다.