프로젝트가 예산을 초과하는 것이 허용됩니까?

이 질문은 프리랜서에서 웹 디자인 회사로 일한 후 지난 3 개월 동안 나를 괴롭 혔습니다.

영업 사원은 종종 다음과 같은 일련의 질문을합니다.

• 위젯을 프로그래밍하는 데 드는 비용
• 이 웹 사이트를이 소프트웨어로 변환하는 데 몇 시간이 걸립니까?
  (현재 웹 사이트가 무엇인지 알지 못함)
• 기타

1. 정보없이 어떻게 견적을 줄 수 있습니까? ( 아니, 더 많은 정보를 요청할 수 없습니다! )

프로젝트가 예산을 초과하면 또 다른 질문이 있습니다. 최근에 웹 사이트를 새로운 플랫폼으로 이전하는 비용을 계산할 때 전체 메뉴가 누락되어 프로젝트 예산이 초과되었습니다. 내 상사는 전혀 행복하지 않았으며, 이와 같은 것들을 피할 수 없다는 내 의견입니다.

   2. 예산 초과를 다루는 일반적인 관행은 무엇이며
        웹 개발과 같은 프로젝트는 종종 예산을 초과합니까?

웹 개발 / 디자인 / 유사 회사에서 근무하는 경우 :

   3. 청구 가능 시간 시스템은 어떻게 작동합니까?

저에게는 프로젝트 추적 시간과 청구 가능 또는 내부 (AKA 청구 불가능) 시간을 기록하는 시간 추적 애플리케이션이 있습니다. 일주일에 xx 청구 가능 시간을 충족하지 않으면 결국 문제에 봉착 할 수 있습니다. 당신은 회사 또는 청구하지 않습니다 고객을 위해 할 일이 시스템의 일부가 아닌, 우리는 종종 이 어떤 대안 시스템이 존재하는 경우 궁금 해요, 그래서 내부 작업을 할 수 있습니다.

편집 : 좋아, 나는이 회사의 개발자가 아닌 개발자입니다 :)

둘째, 급여가 지급되지만 여기에 경영진이 보는 방식이 있습니다. 일주일에 35 시간을 일해야합니다. 35 시간 안에 고객에게 청구하는 작업을 수행 할 수 있으며 그렇게해야합니다. 그들이 프로젝트에 50 시간이 걸리고 55 시간이 걸린다는 것을 알면 예산을 초과하지 않은 다른 프로젝트에 5 시간을 소비 할 수 있었기 때문에 돈을 잃어 버렸습니다.

또 다른 예는 2 주 만에 프로젝트가 1 개만 있고 내부 작업에 하루를 보낸다면 일부는 일하지 않아서 돈을 잃어버린 방법입니다. 그날 일을했다면 하루를 일찍 끝내도 일이 없습니다. 어느 쪽이든, 일은 계약이므로 우리는 내가 일하는 날에 관계없이 같은 금액을 지불받을 것입니다!

영업 사원은 종종 다음과 같은 일련의 질문을합니다.

위젯 프로그래밍 비용은 얼마나됩니까?

영업 사원이 왜 디자이너에게 질문합니까? 판매에는 실제 비용과의 상관 관계가 거의없는 견적을위한 견적 및 시스템이 미리 준비되어 있어야합니다. 당신이 봉급을 받고 있다고 가정합니다.

정보없이 어떻게 견적을 줄 수 있습니까? (아니요, 더 많은 정보를 요청할 수 없습니다!)

짧은 답변? 시도 할 수 없습니다.

긴 대답은 여전히 ​​짧습니다. 전화를 걸고 사람들이 로그인하고 다른 사용자에게 메시지를 게시하고 사진을 업로드하고 친구를 사귀는 웹 사이트가 있다고 가정하면 구축 비용은 어떻게됩니까? 상상할 수있는 최악의 소셜 네트워크 또는 Facebook을 설명 할 수있었습니다. 정보가 충분하지 않아 정확한 평가를 할 수 없습니다.

프로젝트가 예산을 초과하면 또 다른 질문이 있습니다. 최근에 웹 사이트를 새로운 플랫폼으로 이전하는 비용을 계산할 때 전체 메뉴가 누락되어 프로젝트 예산이 초과되었습니다. 내 상사는 전혀 행복하지 않았으며, 이와 같은 것들을 피할 수 없다는 내 의견입니다.

"예산 초과"를 정의하십시오. 다시, 나는 시간당 급여가 아니라고 가정합니다. 시간 예산을 초과 한 경우, 긴 밤 을 지내고 같은 실수를 다시하지 마십시오.

저에게는 프로젝트 추적 시간과 청구 가능 또는 내부 (AKA 청구 불가능) 시간을 기록하는 시간 추적 애플리케이션이 있습니다. 일주일에 xx 청구 가능 시간을 충족하지 못하면 결국 문제에 봉착 할 수 있습니다. 회사 나 고객이 청구 할 수없는 고객을위한 업무는이 시스템의 일부가 아니므로 종종 내부 업무를 수행해야하므로 대체 시스템이 있는지 궁금합니다.

"청구 가능"시간 레코드를 작성해야하는 경우 어떻게 설정했는지 잘 모르겠습니다. 당신은 아마 일주일에 수백 시간 +/-로 바람을 불렀을 것입니다. 나는 코드에 대해 생각하는 것을 멈추지 않습니다.

Scotty가하는 일을하십시오 : 합리적인 견적을 제시하고 두 배로 늘리십시오.

추정치가 두 배로 증가하면 a) 일반적으로 인간이 엉뚱한 견적 자이므로 b) 약간 여유를 두어 갑작스러운 기능과 기타 비상 사태에 대한 여지가 있으며 c) 때때로 시간이 걸리는 경우가 있습니다 예산 아래.

추정치가 상사 나 판매원에게 배가된다는 사실을 언급하지 마십시오. 사업가는 섬세한 생물이며 엔지니어가 다루어야 할 어려운 사실을 다룰 수없는 경우가 많습니다.

행운을 빕니다.

당신이 할 수있는 최선의 방법은 견적에 항목별로 목록을 작성하는 것입니다. 각 "작업"옆에 시간을 넣습니다. 이와 같이 분류하면 수행해야 할 작업에 대해 생각할 수있을뿐만 아니라 상사 및 / 또는 고객에게 견적 범위를 알려줄 수 있습니다. 상사 / 계정 관리자 / 클라이언트가 작업을 시작하기 전에이 범위 / 견적에 서명하는 것이 좋습니다. 이런 식으로 무언가를 잊어 버리면 책임이 퍼질 수 있으며 개발자에게 책임이있는 것은 아닙니다.

프로젝트에 대한 추가 세부 정보를 얻을 수 없다면 사람들이 진화 한 것을 보여 주어야한다고 생각합니다.

이 인용구 중 몇 개를 한 것이기 때문에 새 인용구를 만들 때 이전 인용구를 다시 참조 할 수 있기 때문에이 방법도 좋습니다.

Hofstadter의 법칙을 받아 들일 수는 있지만 결코 효과가 없습니다 .

이것은 실제로 3 인의 첫 번째 부분에 대한 답변 일 뿐이지 만 큰 질문입니다.

최근에 시작한 작업은 다음과 같습니다. 그리고 이것은 이런 종류의 일에 대한 많은 영혼의 탐구 이후입니다.

본인은 "Good-Faith Estimate"라고 부르는 잠재 고객 또는 고객의 요청에 응답합니다. 총 CYA에 대해 일요일부터 9 가지 방법으로 채워진 달러 수치입니다. 나는이 숫자가 대략 여기에서 고려되는 프로젝트의 규모에 대한 나의 프로젝트 경험에 근거한다고 말한다.

킥오프시 첫 송장이 견적의 25 %라고합니다. 해당 가격에 대해 완벽한 요구 사항 수집 노력을 수행하고 자세한 세부 사양을 작성합니다. 프로젝트 규모에 따라 몇 주일이 소요될 수 있습니다. 마지막에, 우리는 완전한 문서 세트를 갖게 될 것이며, 그 추정에 대한 우리의 행동을 알게 될 것입니다. 이 시점에서 가격을 미세 조정해야하고 (상승 또는 하강 할 수있는 경우) 고객에게 알려야합니다.

가격이 올라가서 프로젝트를 지속 할 수 없다면, 그 시점에 더 이상 지불 할 필요가없는 시점에 취소됩니다. 이것은 분명히 바람직하지 않은 결과이며 마지막 복원 결과로 간주되어야합니다. 계획 B는 프로젝트 예산 등으로 범위를 낮추기 위해 프로젝트 요구 사항을 재 조립하는 것입니다. 모든 것을 끝내기 전에 시도 할 수있는 것이 많지만, 필요한 경우 우리가 할 수있는 곳이 있습니다.

우리가 그렇지 않다고 가정하면 그 시점에서 50 %가 청구될 수있는 최종 가격 (수정 될 수 있음)과 배송 및 수락시 최종 25 % 정도가 나옵니다. 모두가 같은 페이지에 있고 아무도 "분석"과 같은 무형의 대가로 돈을 지불해야한다고 느끼지 않으며 모든 사람들이 (이상적으로) 행복합니다.

지금까지 나는 이것으로 꽤 좋은 결과를 얻었습니다. 분석 / 사양 작업에 대한 별도의 청구서로 고객을 때리는 것보다 확실히 낫습니다. 아무도 그 돈을 지불하고 싶지 않습니다. 그러나 총 프로젝트 가격의 처음 25 %에서 숨기면 즉시 맛볼 수 있고 이해할 수있게됩니다.

더 많은 정보를 얻는 방법을 찾아야합니다. 요구 사항이 명확하게 명시되지 않은 경우 프로젝트를 평가 한 적이 없습니다. 그들이 지속되면 그것을 가질 수 없다면 그냥 끝내는 것이 좋습니다.

당신은 매우 일반적인 시나리오에 있습니다. 판매에는 실마리가 없으며 기술 담당자가 업무를 수행하는 데 의존합니다. 당신이 알기 불가능하기 때문에 정확한 견적을 제공하기 위해 계속해서 실패 할 것입니다.

실제로하는 것을 경험적 평가라고합니다.

당신은 시간과 경험으로 더 잘 합니다 .

회사에 다른 디자이너가 있습니까? 그렇다면 계획 포커 를 수행하는 것이 좋습니다 . 매우 강력한 집단 추정 기술입니다.

Planning Poker는 합의에 기반한 추정 기술로, 소프트웨어 개발에서 작업의 상대적 크기 또는 노력을 추정하는 데 주로 사용됩니다.

더 많은 사람들의 지식과 경험을 사용하여보다 정확한 견적을 얻는 데 도움이되며 한 사람이 아닌 팀 전체에 견적 책임이 분산됩니다. 더 정확한 견적을 얻을 수 있기 때문에 판매는 행복 할 것입니다. 그리고 당신이 4 세 또는 5 세일 때는 "나 자신 만있을 때보 다"추정 할 수 없습니다 "라고 말하는 것이 더 쉽습니다.