웹 사이트 구축 비용을 어떻게 청구합니까?
누군가 소기업 용 웹 사이트를 구축하기 위해 저에게 접근했습니다. 가격과 관련하여 웹 사이트 구축 제안을 제시하는 프로토콜은 무엇입니까?
페이지 수에 대해 요금을 부과합니까? 고급 기능 (Flash, Ajax 등)을 원한다면 개발 시간당 가격일까요? 얼마나 걸릴지 모르겠다면 어떻게해야합니까? 어떤 것이 20 시간 작업인지 100 시간 작업인지 결정하는 데 도움이되는 유사한 웹 사이트를 보는 좋은 방법이 있습니까?
웹 사이트 개발 작업의 범위와 가격을 결정할 때 사용되는 표준 템플릿이 있습니까?
이 질문은 "집을 짓는 데 드는 비용은 얼마입니까?"와 정확히 동일합니다. 두 경우 모두 대답은 고객이 원하는 것에 따라 다릅니다. 특히 집에 사는 사람의 다리가 네 개이고 꼬리가 한 개인 경우 $ 100 미만으로 "집"을 지을 수 있습니다.
비용에 대해 이야기하기 전에 해당 기업이 원하는 것을 구체적으로 파악하십시오. 고객은 "페이지"가 귀하와 매우 다른 아이디어를 갖게 될 것입니다. ( "내 재고를 자동으로 쿼리 및 업데이트하고, 내가 부족할 때 공급 업체에 연락하고, 설문 조사와 함께 감사 편지를 보내는 장바구니에 대해 추가 요금을 부과한다는 의미는 무엇입니까? 한 페이지에 있어야합니다! ")
비즈니스가 원하는 것이 무엇인지 모르는 경우 (그리고 자주 발생할 것입니다!), 하루 동안 다양한 아이디어를 모의하기 위해 비용을 청구하십시오. (목업이 무엇을 의미하는지 강조해야합니다. 많은 사람들은 페이지가 표시되면 모든 작업이 완료된다고 생각합니다.)
목표를 달성 할 수있는 충분한 정보를 알게되면 (웹 사이트의 최종 목표가 아니더라도) 시간과 노력을 추정 할 수 있습니다.
나는 Steve McConnell 의 Software Estimation : Demystifying the Black Art 책을 강력히 추천합니다 . 행운을 빕니다.
내 조언은 작성해야 할 내용을 정확히 알고 고객이 범위에 서명 하도록 할 때까지 인용하지 않는 것 입니다. 마음이 바뀌면 견적이 더 이상 유효하지 않으며 더 많은 비용이들 것임을 이해하도록하십시오.
필요한 사항에 따라 원시 html / css를 고수하거나 CMS를 활용하거나 웹 애플리케이션을 처음부터 작성할 수도 있습니다.
위의 결정과 해당 기술에 대한 이전 경험 (있는 경우)을 기반으로 필요한 각 기능 또는 페이지를 분류하여 소요 시간을 추정 할 수 있습니다. 과소 평가하기보다는 과대 평가하십시오. 스타일과 레이아웃에 대한 오버 헤드를 추가하고, 배포 및 버그 수정을 위해 더 많은 것을 추가하고이를 추정의 기초로 사용하십시오.
예를 들어 상당히 정적 인 정보 페이지 5 개, 고객이 업데이트 할 수 있어야하는 10 페이지, 상당히 복잡한 기능 (예 : 매장 및 서비스 계산기 매핑)이있는 2 페이지가있는 사이트를 작성하라는 요청을받은 경우, 다음과 같이 분류 할 수 있습니다.
- 스타일 및 레이아웃 오버 헤드 : 5 일
- 정적 페이지 x 5 : 페이지 당 1 일 = 5 일
- 편집 가능한 페이지 x 10 : 페이지 당 2 일 = 20 일
- 복잡한 페이지 x 2 : 페이지 당 6 일 = 12 일
- 배포 및 변경 : 3 일
- 합계 : 45 일
여기에 만족스러운 시간당 요금을 곱하면 견적이 있습니다.
즉, 일이 얼마나 오래 걸릴지 정직하게 모른다면 어쨌든 야구장 추정치를 제공 할 것입니다. 추정에 최선을 다하고 (가능한 한 많이 분해) , 인용문을 제공하고, 심각하게 과소 평가하지 않은 손가락을 교차 시키십시오. 그럴 경우 실수로부터 배우도록하십시오.
업데이트 : T he Design Cubicle의 블로그 게시물을 우연히 발견했습니다 . 웹 사이트를 디자인하기 전에 고객에게 물어볼 질문 .
충전 속도 X 시간을 으로 매주 청구 (이것이 내가 모든 시간을 사용하는 것입니다)주기.
내 대답 에서 프리랜서 웹 개발에서 가장 일반적인 문제는 무엇입니까?
열악한 지불 구조-매주주기를 수행하고 매주 제공 하므로 매주 지불을 기대합니다. 이것은 완전히 자동화 된 것입니다 (내가 프로젝트에 사용하는 서비스의 일부), 이것이 어떻게 거기 밖으로 나가게 될지 잘 모르겠지만, 당신은 정말로 이것에 최대한 가까이 가고 싶습니다. 처음 7 ~ 12 일 (리뷰 등을 위해 지연이 있음)부터 바로 지급을 받고 있음을 확실히 알 수 있습니다. 또한 그 과정에서 고객에게 경제적으로 문제가 발생하면 몇 달이 아닌 몇 주 안에 확실히 알게 될 것입니다. 물론, 당신은 더 빨리 알아 내려고하지만 그것이 잘못되면 약간의 영향을받습니다.
즉 , 처음부터 가치 를 제공 해야하며 이는 건전합니다. 고객 이 달성하고자 하는 주요 부분 과 시작하기에 가장 좋은 부분 이 무엇인지 파악하는 데 중점을두고 고객과 대화하십시오 . 이는 고객의 우선 순위 와이를 수행하는 데 필요한 사항에 대한 자신의 지식을 기반으로합니다. 구체적으로 얼마나 많은 노력이 필요한지 알지 못하더라도 일반적으로 각기 다른 주요 요구 사항이 얼마나 복잡한 지 전반적으로 알 수 있습니다. 다른.
진행하는 가장 좋은 방법 은 문제 를 분석하고 가치 창출 을 시작할 기능 의 하위 집합에 집중 하는 것임을 설명 합니다. 초점을 맞출 위치에 대해 조언하고 다른 기능은 그림에서 완전히 벗어나도록하십시오 .
범위에 포함될 항목에 대한 전반적인 아이디어를 형성합니다. 처음 2 주 동안 수행 할 작업 / 추정 및 약정해야하는 작업에 대해서만 자세히 설명합니다. 첫 주 항목의 세부 사항으로 이동할 때 얻은 편차를 사용하여 전체 편차에 대한 아이디어를 얻으십시오.이 조정 된 전체 추정값을 사용하면 정확도가 약간 증가합니다.
그들이 처음 2 주 항목의 가치 대 비용에 맞지 않는다면, 일반적으로 떠나는 것이 가장 좋을 것입니다 (위의 링크에서 다른 사람들의 답변을 참조하십시오- 아니오라고 말하는 것을 배우십시오 ). 클라이언트의 잘못된 기대 때문에 끝날 것입니다. 그들이 수반되는 노력에 대해 실망시키지 마십시오. 여전히 노력하고 싶다면 필요한만큼의 시간이 필요합니다. 첫 x에 대한 요금에서 x 시간 / 또는 x $를 할인 할 것이라고 알려주십시오. 주.
첫 주에 배운 것을 사용하여 다른 주에 나아갈 길을 안내하십시오. 고객과 지속적인 커뮤니케이션을 유지하십시오. 고객과의 신뢰 를 구축 하면 고객 은 예상치 에 덜 관심을 갖게되고 다음에 얻을 내용에 대해 더 많이 이야기 할 것입니다. 해야합니다 당신이 빨리보고 어떤 문제를 제기 , 그것을위한 이번 주말에 대기하지 않습니다.
대폭적인 조각 (가능한 한 적은 수)을 추정 할 것이며 단 몇 주 동안 더 자세히 추정 할 것임을 기억하십시오. 우리는 며칠이 아닌 시간을 추정하고 있습니다.
우리 회사가 우리를 위해 일하기 때문에 우리 회사가 어떻게하는지 말해 줄 것입니다. 우리는 행복하고 고객은 행복합니다 (우리가 말할 수있는 한).
비리 테이너 작업의 경우 항상 시간 단위로 요금이 부과됩니다. 우리는 우리가하는 일의 유형에 관계없이 동일한 요금을 청구합니다 (예 : WordPress 스킨 대 맞춤형 전자 상거래 플랫폼). 시간이 그만한 가치가 있다고 생각하기 때문입니다. 시간이 촉박 한 일부 프로젝트에서는 다른 프로젝트를 연기해야하므로 시간당 추가 요금이 부과되어 비즈니스의 수익성이 떨어집니다. 그러나 우리는 재량에 따라이 작업을 수행하며 작년에 요금을 한두 번만 인상했습니다.
청구 할 금액은 청구시기와 매우 다릅니다. 엄마와 팝에서 대기업에 이르기까지 다양한 고객을 처리 한 결과 청구시기가 고객마다 다를 수 있음을 말씀 드릴 수 있습니다. 중소 기업의 경우 3 분의 1을 보증금으로 선불로 청구하고 일부 마일스톤이 충족되면 중간 지점에서 3 분의 1을, 완료 및 배송시 마지막 3 분의 1을 청구하는 것이 좋습니다.
이는 특히 소규모 회사의 경우 중요합니다. 왜냐하면 2 주마다 수표를 삭감하는 것에 대해 걱정할 필요가 없기 때문입니다. 이는 때때로 자체 고객과 청구로 인해 어려운 일입니다. 또한 소기업은 일반적으로 소수에 불과하며 전담 회계사가있는 경우는 매우 드뭅니다. 즉, 빈번한 지불에 대한 청구를 구성하면 종종 늦게 와서 프로젝트를 지연시킬 수 있습니다. 청구 빈도가 낮다는 것은 인보이스 발행이 적다는 것을 의미하며, 이는 종종 귀하와 고객 모두에게 좋습니다.
중대형 기업은 결제와 관련하여 더 많은 옵션을 제공합니다. 마일스톤, 격주 또는 배송시 청구 할 수 있습니다. 그것은 정말로 당신과 클라이언트가 동의 할 수있는 것에 달려 있습니다. 대기업에는 일반적으로 자체 인보이스 시스템이 있으며, 이는 청구시기와 방법을 결정할 수 있습니다. 이 시나리오는 정상적인 작업 라인이 아닌 것 같으므로 상황에 적용 할 수없는 것 같습니다.
무엇을 충전할지 결정하는 것이 가장 어려운 부분입니다. 다른 사람들은 Hofstadter의 법칙 을 인용 했으며 그렇게하는 것이 옳습니다. 작업 및 전체 프로젝트 시간을 추정 한 경험의 공평한 몫을 초과 할 때까지 항상 추정치보다 낮을 가능성이 높습니다. 어떤 사람들은 당신의 시간에 2 또는 3 배를 제안하지만 이것은 약간 과도 할 수 있습니다. 저는 개인적으로이 사고 방식을 따르지 않습니다. 고객에게 불공평하고 일반적으로 과다 청구로 끝납니다.하지만 승수를 사용해야한다면 1.5가 더 적절할 것입니다. 특정 구성 요소가 얼마나 오래 걸릴지 확실하지 않으면 여기에 몇 시간을 추가하지만 전체 프로젝트를 알려지지 않은 거대한 것으로 취급하지는 않습니다.
우리가 수행하는 대부분의 작업에 대해 좋지 않은 지표이므로 일반적으로 페이지 수로 비용을 청구하지 않습니다. 한동안 사업을하면서 특정 작업에 걸리는 시간을 결정하는 것이 더 쉽다는 것을 알게되었습니다. 사이트의 영역을 가능한 한 특정 모듈로 나누십시오. 이렇게하면 시간이 얼마나 걸리는지 쉽게 결정할 수 있습니다. 이것은 완전한 목록이 아니며 고객마다 다를 수 있지만 주요 영역은 다음과 같습니다.
- 데이터베이스 디자인
- 모델
- 견해
- 컨트롤러
- HTML / CSS 구현 및 IE 디버깅을위한 추가 시간 (재미 있지만, 완전히 정확함)
- JavaScript (프로젝트가 JavaScript를 많이 사용하는 경우 클라이언트 측에 대해 유사한 추가 영역이 있음)
- CMS / 관리자 제어 (해당하는 경우)
- 콘텐츠 입력 (클라이언트가 제공하는 내용을 복사하여 붙여 넣어야하며 페이지 당 시간이 오래 걸립니다)
많은 양의 실제 프로그래밍이 필요하거나 변경 가능성이 큰 복잡한 개발 프로젝트의 경우 QA 및 수정을 위해 총 프로젝트 시간의 최대 20 %까지 시간 블록을 포함합니다.. 이것은 몇 가지 이점이 있습니다. 첫째, 그것은 당신을 보호합니다. 특히 크고 복잡한 시스템의 경우 더 많이 개발할수록 특히 여러 플랫폼을 대상으로하는 경우 (예 : 여러 브라우저에서 CSS / JavaScript 호환성) 더 많이 디버깅해야합니다. 둘째, 기존 계약을 수정하지 않고도 사소한 변경을 요청할 수있는 적절한 유연성을 고객에게 제공합니다. 이 두 번째 혜택은 정보가 부족한 고객이이를 악용 할 것이라는 경고와 (자세한 내용은 다음 단락 참조) 고객이받을 자격이있는 서비스를 제공 할 수 있다는 경고와 함께 제공됩니다. 모두) 약간 변경되는 사양에 유연하게 적용 할 수 있습니다 ( 모두 변경 되기 때문에 ).
고객이 귀하의 서비스 유형에 익숙하지 않더라도 항상 고객을 교육하는 것이 중요합니다. 클라이언트는 귀하가 알리는 방식과 비슷하게 행동합니다. 프로세스, 청구 방법, 마일스톤, 의사 소통 빈도, 사소한 수정에 해당하는 사항 및 계약 수정이 필요한 사항, 청구하는 이유에 대해 알려주지 않는 경우 그들이 당신이 정확하게 당신이 그들이 무엇인지, 제공하는 무엇, 무엇을 충전 하지 등, 점점, 그들은 당신이 제공 할 수없는 일을 기대하는 것은 무료입니다. 이것은 결코 좋은 상황을 만들지 않습니다. 개발자에게는 실망스럽고 클라이언트에게는 나쁘게 보입니다. 항상 계약을 맺고 그 계약서에 가능한 한 많은 철자를 적으십시오. 모든 사람을 보호합니다.
이 주제는 저에게 수년 동안 만들어져 왔으며 이것들은 더 광범위하고 중요한 요점 일 뿐이지 만 어쨌든 도움이 되었기를 바랍니다.
프로세스는 다음과 같습니다.
1) 시장에서 당신의 가치를 결정하십시오. 자신의 기술에 자신감이 있고 탄탄한 포트폴리오가 있고 시장에서 일한 경험이 있다면 변호사처럼 청구해야합니다. 프로모션 및 광고와 같은 비즈니스를 수행하는 데 드는 비용은 청구서에서 보충해야합니다. 회사를 시작하고 변호사처럼 청구 할 자신감이 없다면 독립적 인 컨설팅을 수행 할 준비가되지 않은 것입니다. 전문가처럼 청구하면 전문가처럼 대우받을 것입니다. 아이처럼 요금을 청구하면 아이처럼 대우 받게됩니다. 내가 프리랜서 비즈니스 에이전트라면 시간당 $ 150를 청구 할 것입니다., 이는 다양한 분야의 외부 비즈니스 서비스에 대한 상당히 표준 요금입니다. 프로그래머 나 데이터베이스 설계자라면 더 많은 비용을 청구 할 수 있습니다. 자유 계약자로서 401K, 건강 보험 또는 기타 기업 혜택이 없음을 기억해야합니다.
2) 서면 계약으로 모든 작업을 시작하십시오. 이 계약은 다음을 정의해야합니다.
2a) 귀하의 청구 요율. 출장이 필요하지 않은 경우 추가 비용으로 사업 비용을 포함하지 마십시오. 귀하의 청구 비율은 비즈니스 비용을 상쇄 할 수있을만큼 높아야합니다.
2b) 출장비가 존재하는 경우 표준 청구 범위를 벗어난 출장 관련 경비에 대한 영수증을 제공하겠다는 계약서에 작성해야합니다. 여행의 유무를 정의하는 계약서에 해당 여행과 관련된 비용이 표준 청구 범위를 벗어나 고객에게 청구될 것임을 정의하는 언어가 있어야합니다.
2c) 고객이 구체적으로 정의 된 요구 사항 목록을 자세히 설명하는 계약에 추가 할 때까지 작업이 수행되지 않는다는 내용을 포함합니다. 요구 사항의 완료는 그들이 지불하는 것이며 귀하가 할 일을 나타냅니다. 다른 작업을 제공하지 말고 다른 작업을 수행하지 마십시오. 자선 단체로 활동하고 추가 서비스를 제공하거나 요구 사항을 벗어난 일을한다면 혼자서 일할 준비가되지 않은 것입니다.
2d) 결과물 및 기타 외부 요구 사항을 정의합니다. 당신은 아마도 사람들의 마음을 읽지 않을 것입니다. 클라이언트가 특정한 것을 원하면 대략적인 사양을 제공합니다.
2e) 정의 된 서면 요구 사항 외에 추가 작업을 제공하지 않을 언어를 포함합니다.
2f) 어느 한 당사자가 언제든지 계약을 해체 할 수 있다는 표현을 포함합니다. 본격적인 금액은 환불되지 않지만 계약이 사양에 따라 완료되지 않으면 모든 청구는 환불됩니다.
2g) 변호사에게 귀하의 계약 언어를 작성하게하고 명확성을 위해 해당 언어를 검토하고 질문해야합니다. 변호사들은 종종 인간의 언어를 사용하지 않으며 때로는 지구로 다시 내려 와야합니다. 고객이 당신의 계약을 이해할 수 없다면 그들은 그것을 따르지 않을 것이고 당신은 그것을 집행하지 않을 것입니다.
3) 진지한 돈을 청구하십시오. 일부 고객은 Leonardo와 Michelangelo의 비전이 결합되어 있다고 믿지만 사양서에 맞게 만든 작업이 기대에 부응하지 않을 때 완전히 놀랐습니다. 이러한 조건에서 클라이언트는 추가 비용없이 작업을 수행하기를 원할 수 있습니다. 당신은 자선 단체가 아닙니다. 선불 요금보다 2 ~ 3 배 더 높은 고정 가입 요금을 청구합니다. 이것은 당신이 프로젝트를 끝내기 전에 클라이언트가 물러 나면 적어도 당신이 무언가를 얻을 수 있도록 보장하기위한 투자 수익입니다.
4) 귀하에게 제공된 사양서에 대한 작업이 수행되고 고객이 만족하지 않는 경우 고객에게 추가 계약을 제출하고이를 변경 부록 이라고합니다 . 결과가 마음에 들지 않으면 더 많은 작업을 수행하기 위해 더 많은 돈을 지불하거나 제공된 작업을 진행할 수 있습니다. 귀하는 자선 단체가 아니므로 작업이 서면 요구 사항을 벗어나지 않는 한 두 번 청구하지 않고 동일한 작업을 두 번 수행하지 마십시오.
5) 능력이 허용하는 것 이상으로 판매하지 마십시오. 한 달 동안 JavaScript를 작성했다면 JavaScript 상호 작용을 완전히 기반으로하는 대화 형 AJAX 준비 사이트를 구축 할 수있는 서비스를 판매 할 것으로 기대하지 마십시오. 당신이 충분히 높은 금액을 청구하고 당신의 클라이언트를 속이려고하면 그들은 당신을 고소 할 것입니다. 추가 기술이 필요한 경우 프로젝트를 다른 사람에게 소개하거나 파트너를 고용하십시오.
6) 모든 요구 사항이 매우 구체적으로 정의 될 때까지 작업을 시작하지 마십시오. 이것은 여러 회의와 클라이언트에 대한 많은 의사 소통이 필요할 수 있습니다. 프로젝트를 계획하는 데 소요 된 시간은 청구되어야하는 작업이므로이 시간을 추적하십시오. 프로젝트의 나중 단계에서 요구 사항을 결정하는 데 필요한 개발 과정에 존재하는 종속성이있을 수 있습니다. 이 경우 프로젝트를 여러 단계로 나누고 프로젝트 단계별로 요구 사항 목록을 지정합니다. 다시 말하지만, 요구 사항이 정의되고 작성되고 승인 될 때까지 어떤 작업도 수행하지 마십시오.
7) 귀하는 귀하의 서비스를 요청하는 모든 고객을 데려 갈 의무가 없습니다. 당신은 정당화없이 누구든지 자유롭게 외면 할 수 있습니다. 고객이 신뢰할 수없는 것처럼 보이거나 고객이 시간을 낭비 할 것이라고 생각하면 일을하지 마십시오. 시간은 돈이고 당신은 자선 단체가 아닙니다.
8) 고객이 당신의 시간을 끝없이 낭비한다면 계약을 해산하고 지불 된 청구를 환불하고 떠나십시오.
9) 변호사처럼 청구하고 견적을 제공하지 마십시오. 프로젝트는 작업을 계획하고 수행하는 데 걸리는 시간이 걸립니다. 그 시간은 전적으로 요구 사항과 관련이 있으며 고객의 수표와 관련이 없습니다. 고객에게 청구 요율을 알리고 견적서에 정해져 있지 않은 경우 초기 예상 시간을 제공하고 스스로 견적을 계산할 수 있습니다. 견적이 견적을 반영하지 않는다고 말하고 그러한 언어를 계약서에 포함 시키십시오.
10) 가장 빠른 작업이 아닌 항상 최상의 품질 작업을 제공합니다. 이것이 당신이 전문가처럼 책임을지는 이유입니다. 작업이 다른 유사한 컨설턴트보다 약간 더 오래 걸리는 경우 접근성 법, 조정 가능한 기능 및 효율성, 보안 등과 관련하여 서비스의 가치를 설명하기 만하면됩니다. 요구 사항을 정의 할 때 이러한 기능의 중요성을 명확하게 설명함으로써 프로젝트 품질의 이점을 위해 고객의 계획 결정을 변경할 수 있습니다.
11) 고객은 보스이며 청구서를 지불합니다. 당신이 그들에게 말을 걸어도 그들은 매우 나쁜 결정을 내릴 것입니다. 논쟁하지 마십시오. 작업을 수행하고 다음 프로젝트로 이동하십시오. 이 조언에주의를 기울이지 않으면 독립적 인 컨설턴트로 일할 준비가되지 않은 것입니다.
가능한 한 작업 시간별로 청구 할 것입니다. 개별 페이지에 넣기 위해 필요한 시간이 많지 않습니다. 따라서 고객의 요구 사항에 따라 저렴하게 (즉, 더 적은 시간 사용) 또는 더 좋고 더 비싸게 (더 많은 시간 청구) 얻을 수 있습니다.
2 주 단위로 충전 해보세요. 2 주 동안 일정량의 기능을 제공하기로 약속하고 2 주가 지나면 둘 다 상황을 재평가하고 필요한 경우 방향을 변경할 수있는 기회를 갖게됩니다. 2 주 이상 주머니에 들어 가지 않으며, 고객은 2 주에 한 번 유용한 정보를 얻고 범위 크립에 대해 걱정할 필요없이 원하는 작업에 대해 마음을 바꿀 수 있습니다.
내가 일반적으로하는 일은 내가 청구하는 시간당 요금에 완료까지 걸리는 시간을 곱한 것입니다.
그런 다음 나는 항상 필요한 시간을 과소 평가하기 때문에 보통 1 ~ 2 주 정도의 시간을 내 견적 끝에 추가합니다 (작업이 얼마나 복잡한 지에 따라 다름). 나는 보통 낮게 추정하고 있다는 것을 고려하여도 낮게 추정합니다 (Hofstadter의 법칙).
고객과 고객이 원하는 것에 대해 얼마나 확신하는지에 따라 여러 가지 방법으로이를 수행 할 수 있습니다. 다음과 같은 여러 옵션을 제공하는 것이 좋습니다.
- 고정 비용 사이트 -특정 페이지 수와 표준 디자인을 기반으로합니다. 이 옵션은 덜 유연하지만 완료되면 시간당 요금으로 변경할 수 있음을 강조해야합니다.
- 사용자 정의 템플릿 -시간당 요금을 기준으로 한 다음 그 뒤에 오는 각 페이지에 대한 고정 비용이 적용됩니다.
- ** 사용자 지정 사이트-시간당 요금 기준.
시간당 요율로 작업 중이고 일종의 지침 가격이 필요한 경우이를 여러 작업 항목으로 나누고 항목 당 시간과 비용을 추정합니다.
- 기본 템플릿 디자인-4 시간-$ 200
- CMS 설정-2 시간-$ 100
- 연락처 및 정보 페이지-1 시간-$ 50
- 뉴스 페이지-1 시간-$ 50
- 총 비용 $ 400 @ 시간당 $ 50
또한 업데이트를 위해 시간당 변경 수수료를 협상해야합니다.
위의 시간을 추정하는 방법에는 여러 가지가 있습니다. 가장 좋은 측정 항목은 항목이 얼마나 오래 걸릴지에 대한 사전 경험이지만 이것이 처음 인 경우에는 불가능합니다. 귀하의 번호를 확인하는 데 도움을 줄 수있는 다른 웹 디자인 친구가있는 경우에도 유용합니다. 도움이되기를 바랍니다.
미끄러짐과 기능 크립이 고객의 문제가되기 때문에 시간당 일반적으로 위험이 낮습니다.
반면에 고객과 고정 비용 프로젝트를 협상하는 것이 일반적으로 훨씬 쉽습니다. 고객에 대한 위험이 훨씬 낮고, 고객이 청구하는 시간을 실제로 일하고 있는지 또는 StackOverflow 질문에 답하기 :-P
프로젝트를 위해 다른 사람들과 경쟁해야하는 경우 고정 비용이 더 경쟁적이지만 위험합니다. 프로젝트를 완료 할 것으로 예상되는 시간의 10 배가 소요될 수 있습니다.
하지만 고정 비용에는 유연성이라는 한 가지 주요 이점이 있습니다. 프로젝트에 1 시간 밖에 걸리지 않고 10 시간 동안 고정 비용을 청구하면 어떻게됩니까? 여가 시간에 StackOverflow를 탐색 할 수있는 9 시간을 벌었습니다. 또는 다른 말로하면 : 더 이상 자신의 움직임이나 행동을 설명하거나 시간을 기록하거나 일하는 동안 googletalk에서 사람들과 채팅하지 않을 의무가 없습니다. 기분이 좋네요 ...
'페이지 당'또는 무엇이든 ... 좀 더 일반적으로, 저는 프로젝트를 각 지점에서 특정 기술적으로 객관적인 측정 값을 사용하여 작은 덩어리로 나누고 고객이 승인하고 해당 덩어리에 대해 지불하도록합니다. 완료하십시오. 그렇게하면 귀하와 고객에게 놀라운 일이 거의 없습니다. 클라이언트는 당신이 일을하고 있고 적시에 진행하고 있다는 따뜻하고 흐릿한 느낌을받습니다. 그 / 그녀는 그것이 상당히 투명하다는 것을 알 수 있습니다. 당신은 클라이언트가 그 과정에서 적은 금액을 지불하기 때문에 클라이언트가 마지막에 코드로 실행되지 않을 것이라는 비슷한 확신을 얻습니다. 마지막으로 시간을 과소 평가하거나 과소 평가하고 있다는 사실을 알게된다면 당연히 고객과의 협상을 통해 나중에 청크를 위해 시간을 다소 수정할 여유가 있습니다. 하지만 상황은 둘 다 상당히 투명합니다. 몇 달 동안 일하다가 실제로 몇 년이 걸릴 것임을 깨닫는 것과는 다릅니다 ...
요약:
- 고정 비용은 더 위험하지만 더 많은 유연성을 제공하고 훨씬 더 경쟁력있는 경향이 있습니다.
- 시간당은 위험이 낮지 만 그렇게 흥미롭지는 않습니다. 빠른 코딩에 대한 직접적인 보상은 없으며 시간표를 작성해야하며 해당 시간 동안 작업 외에는 아무것도하지 않는 등의 작업을 수행해야합니다.
- 고정 비용의 경우 위험을 낮게 유지하고 고객을 만족시키기 위해 프로젝트를 작은 단위로 나누면 고객은 작업이 진행되고 있음을 알 수 있으며 막대한 비용을 청구하는 대신 고객에게 비용을 청구 할 수 있습니다. 끝, 그리고 그와 관련된 스트레스와 위험
첫 번째 빌드의 경우 소요되는 시간 / 일 수를 추정 한 다음 내 시간 / 일 요금 *을 기준으로 고정 가격을 청구합니다.
스톡 사진 및 호스팅은 고객에게 직접 청구되며 합의 된 첫 번째 빌드에 대한 변경 사항은 시간당 요금으로 청구됩니다.
As a freelancer I also always try to charge in weekly/fortnightly blocks if possible, not only does it get the money flowing early, but it also focuses my mind and the clients.
Clients will always try to wriggle more out of you, so you must be strict about what's in the first build and what's not.
*(Then my project manager/wife multiplies it by 3. Seriously, developers are awful at predicting how long something will take - See also the already cited Hofstadter's law)
Here are the steps I usually follow :
- List the various tasks the project includes
- Evaluate how many hours each task will take me
- Sum the hours, and probably add or remove a few ("H")
- Think of an acceptable hourly rate ("R")
At this point you can see how much you should ask theorically : H * R
But that price isn't necessarily the price you have to ask. You will probably want to play with R (up or down) depending on the wealth of your customer, the fact he's a friend, how much your competitors are asking, and whatever parameters you have to take into account...
Golden rule : If you know you can get the job done with a good level of quality, don't be afraid to ask (what looks to you like) a lot.
I've always been very upfront with my costs. I usually put a spreadsheet together of my costs and what I'm charging for. The general rules it follows are:
My General Rules
- If you have a detailed Functional Specification for the work to be done, I can give you an estimate, at no charge, and we can agree upon a set price for what is contained in (and only what is contained in) that Function Specification.
- If you don't have a Functional Spec or a design, I can put one together for you for my usual hourly fee (which I sometimes waive), then we can go over it (see #1).
- If you can't stick to a Functional Spec, or the work is ongoing after the original development is completed, then it's hourly work, plain and simple.
Outside of all of that, there's the level of skill required to do the job that figures into the pricing. Do I just build them an ASP.Net app? Or is it MVC? Does it have any Flash Development? A combination? Is it a really short contract? Those sorts of things raise or lower my prices by a few dollars an hour.
It's also an extremely good idea to put all of this in a spreadsheet and explain all of your charges to your client and why you're charging for it. Be sure to include things like hardware and software use so they understand that you've got overhead on your end too. Some clients don't seem to get that.
Above all, put yourself in their shoes. We've all hired a plumber or electrician once or twice and got a bill and thought, "What the $#@! is this charge for?!"... So be straight forward and transparent with your billing and you'll get repeat business.
One more thing:
When working for a fixed price project, always be sure to write up and sign a contract! You can work out a payment schedule if you like, you can even try to collect up front, but the bottom line is, a contract is the only way you can get money for your hard work if the client backs out. It's not going to offend them, they'll get it.
The first thing that you should do is draw up a Statement of Work document that details what you will be doing for your client, how much you will charge, tentative work schedules and payment schedules. You can give verbal estimates to your client, e.g. "It should only take about twenty-five hours of work, I charge $50 an hour, so $1250" but make sure that you go home, calculate, and add about 25 percent more hours to your estimate.
Here are some things to think about when drawing up a statement of work proposal.
- Take it seriously. You are drawing up a contract between yourself and your client. It does not have to have any legalese inside of it, but make sure that it is signed by the person that you are doing the work for. You want do get paid, don't you?
- When doing actual work estimates make sure to into account any time that you should be spending debugging, setting up web servers, deployment and database migrations. Some of these things you may take for granted because you are used to working with LAMP software, but what about if your client wants to run this pig on Windows?
- Be clear in what you are working on inside of the document. If you state that your web application will run on a LAMP platform and later they tell you that they need it to run on Windows with SQL Server, you are going to be doing more work and charging them for it.
- Make sure that payments are received after milestones are complete. You might want to charge 25 percent of the fee up front then after the first milestone another 25 percent of the fee and then finally when the project is finished the remaining 50 percent of the fee. These numbers are aribtrary and completely up to you.
- Install software to track your hours so that you can show your client when you actually worked on their software. I would personally suggest something along the lines of Redmine because you can also print out the bug reports from testing.
- Always, always, always delegate time inside of the SOW for testing and charge for it.
- Last but certainly not least be sure that the statement of work document is signed by both parties.
I hope that this helps you out a little. It is up for you if you want to charge hourly or not. What I usually do is estimate the number of hours that it is going to take, lay it out inside of the SOW, and put a single price which reflects an hourly wage that I am used to receiving.
Good luck!
A lot of good stuff here, but mainly coming from the risk limitation POV. So at the risk of being both academic and progressive, I'd like to provide something different by highlighting the phenomenon of the "relational contract" which is easier to find in peer-reviewed economics journals than elsewhere, but was apparently used in the expansion of London's Heathrow Airport.
Instead of defining what is to be delivered, a relational contract defines HOW the relationship or collaboration is to proceed, explicitly including things like releasing work in stages and periodic reflection points (where all parties "settle up" and either party can then exit the relationship if unhappy with the progress).
This is also been talked about by Lean Software Engineering evangelist Mary Poppendieck; here is a slidedeck of her's on "agile" contracts.
Relational contracts are supposed to get both parties pulling in the same direction and of course engender trust, which, ultimately, is the best and most productive partnership that a client and consultant can enjoy.
[Update] See here for how New Bamboo do their contracts (I thought this was pretty cool).
I would either determine what your normal hourly rate would be and use that, or discuss the client's set of needs and determine what an appropriate "flat" rate would be. Don't go the route of charging per page.
Personally if it were me I would determine the "scope of work" for the project and give it a flat rate, but inform the client that the rate can change if (when?) they decide to change things.
It's impossible to give a price estimate if you don't know the requirements. First find out what they actually want, then estimate how much it will take time and give your quota according to that.
Hint: Don't give a fixed price for the whole project - that will mean that it will never be finished as the customer will always come up with something to fix, you'll end up doing stuff "for free". Been there, done that.
Rather give a fixed price for a first version and then charge per hour for any modifications they want to make.
Charge according to the mental strain and work you are required to do. For some web pages, it might take more time, but we won't have much stress. Similarly for some others, you need to work really hard, out of your screws, but for a lesser period of time. So you have to give weightage for both when charging your work.
mostly client paid for hours if you not like it then you got paid for a project means Big project give you big money & small project give you small money
참고URL : https://stackoverflow.com/questions/1692754/how-do-you-go-about-charging-for-building-a-website
'Nice programing' 카테고리의 다른 글
| Symfony의 서비스에 저장소를 삽입하는 방법은 무엇입니까? (0) | 2020.10.20 |
|---|---|
| Visual Studio Team Services에서 팀 프로젝트 삭제 (0) | 2020.10.20 |
| Javascript는 Java에 비해 얼마나 빠릅니까? (0) | 2020.10.20 |
| Spring에서 ObjectMapper 구성 (0) | 2020.10.20 |
| Java에서 변경 불가능한 클래스를 final로 선언하는 이유는 무엇입니까? (0) | 2020.10.20 |