잘못된 트랙에서 보낸 고객 시간을 청구해야합니까? [닫은]

클라이언트를 해결하기 위해 작은 CSS 과제를 해결했으며 시간당 요금을 지불하게됩니다. 나는 결국 그것을 해결했고, 5 시간이 걸렸지 만 약 25 %의 시간을 잘못된 트랙에서 보냈으며 최근 브라우저에서만 작동하는 CSS3 솔루션을 시도하고 마침내 원래 생각했던 것처럼 JS를 통해 대체가 불가능하다는 것을 발견했습니다. 고객에게 25 %를 청구해야합니까?

자세한 내용 : 견적을 제공하지 않았고 도전 자체가 마음에 들었습니다. 따라서 견적을 제공하기 전에 작업을 시작했습니다 (그러나 이전에 그와 함께 일한 적이 있기 때문에 비현실적인 기대를 가진 사람들 중 하나가 아니라는 것을 알고 있습니다 ). 최악의 상황에서 나는 흥미로운 CSS 도전에 5 시간을 보냈다. 이미 작업을 완료 했으므로 두 사람 모두에게 가장 공정한 견적을 제공 할 것입니다. :)

편집 : 모두 감사합니다. 하나 이상의 답변을받을 수 있기를 바랍니다! 나는 여분의 시간 동안 그에게 청구하지 않았고 (3 시간 반 동안 그에게 청구했다), 나는 그들이 청구 한 것보다 더 많이 일했다는 것을 알기 위해 그것들을 언급했다. 아마 그가 바로 "추정"(이 경우 추정치가 아니기 때문에 견적)을 수락 한 이유 일 것입니다.

나는 종종 몇 시간 동안 무언가를하고, 더 쉬운 단선 솔루션이 있거나 내 첫 번째 아이디어가 너무 나쁘다는 것을 알면서 그러한 상황을 겪습니다.

일반적으로 이러한 경우에는 세 가지 상황에서 차이를 만듭니다.

• 새로 발견 된 솔루션은 명확하지 않았고 / 또는 일반 개발자가 잘못된 길을 가고 있거나 잘못된 해결책이 최종 솔루션을 찾기위한 전제 조건이었습니다. 이 경우 잘못된 트랙에서 보낸 시간에 대해 고객에게 청구합니다.

• 새로 발견 된 솔루션은 그다지 명확하지 않았지만, 많은 일반 개발자가 직접이 방법을 사용했을 것입니다. 다시 말해, 코드를 작성하기 전에 더 나은 생각을하면 최종 솔루션을 직접 찾거나 찾지 못할 수 있습니다. 이 경우 고객에게 요금을 청구하지만 가장 적합한 것으로 보이는 비율을 절반이나 백분율로 줄입니다.

• 분명히, 최종 솔루션을 찾기가 쉽기 때문에 코드 작성을 시작하기 전에 너무 어리 석거나 졸리거나 전혀 생각하지 않았습니다. 이 경우, 잘못된 길에서 이틀을 보냈더라도 내 책임이며 고객은 그 비용을 지불 할 필요가 없습니다.

난 당신이 잘못된 길을 가고 있다고 생각하지 않습니다. 솔루션을 코딩하고 솔루션 (kudos)을 테스트 한 결과 예상대로 작동하지 않는 것으로 나타났습니다. 솔루션을 디버깅 한 다음 다른 방향으로 이동하여 수정했습니다.

IMHO, 그것은 잘못된 길이 아닙니다. 정기적 인 소프트웨어 개발입니다.

내가 당신이라면, 나는 4 시간 동안 완전히 청구 할 것입니다.

우리가 작성하는 대부분의 프로그램은 솔루션을 즉시 사용할 수 없기 때문에 작성하고 있습니다. 우리가하는 모든 일은 새로운 것을 배우는 것과 관련이 있습니다. 고객이 제품에 대한 비용을 지불하지 않았습니다. 그는 제품을 구축하는 방법을 배우고 결과를 제공하는 데 대해 비용을 지불했습니다 (그리고 그가 "도전"이라고 불렀다면 무언가를 배우기를 기대했습니다). Tom de Marco와 Timothy Lister의 "곰과 함께 늑대 잡기"- "프로젝트에 위험이 없다면 그렇게하지 마십시오"를 참조하십시오.

고객에게 제대로 대금을 지불하려면 작동하지 않는 솔루션의 세부 정보와 함께 솔루션을 보내 직원이 다른 직원에게 전달하여 시간이 덜 걸리도록 도와줍니다.

그가 너무 많이 지불한다고 생각하면 협상하는 것은 당신에게 달려 있습니다. 물론 다른 곳에서는 쉽게 사용할 수없는 학습에 대해 비용을 지불 할 것으로 예상됩니다.

때때로 문제를 해결하려면 합리적인 옵션 세트에서 차선책을 제거해야합니다. 제거 과정은 문제 해결 도구 중 하나입니다. 고객이 솔루션에 대한 비용을 지불하고 있으므로 귀하는 원하는 도구를 사용할 것을 기대해야합니다.

프로젝트 브리핑에서 키보드로 바로 이동하여 신속하고 최적의 백 스페이스가없는 코드 스트림을 생성하는 최상의 솔루션을 즉시 구상하는 것은 합리적이지 않은 고객입니다. 그런 클라이언트가 없다고 말하는 것은 아닙니다. 프로젝트 중간에 전화를 한 고객에게 실제로 "디버깅이 아닌 프로그래밍"에 대해서만 비용을 지불하고 있는지 확인했습니다. 물론 프로그래밍이 타이핑의 물리적 행위 인 클라이언트 (또는 보스)가 있습니다.

맹인 골목은 고객이 가장 많이 쓴 돈을 나타낼 수 있습니다. 다른 개발자가 당신만큼 철저하지 않았을 수도 있고, 나중에 물지 않을 싸지 만 호환성이 낮은 솔루션을 제공했을 수도 있습니다.

이 질문은 나를 미치게한다 ...

정비사 또는 변호사가 귀하의 사례 / 문제를 해결하는 데 시간을 소비 한 경우, 잘못된 트랙에서 시간을 보냈더라도 청구 된 @ $$에 베팅합니다

프로그래머는 더 많은 시간을 평가해야합니다

당신이 한 일은 완벽하게 정상이었습니다. 프레드 브룩스 (Fred Brooks)는 소프트웨어 엔지니어링 "신화적인 인간-달 (Mythical Man-Month)"에 관한 그의 저서에서 "일회성 계획"장에서이 현상에 대해 설명합니다.

시간과 자재 계약을하고있었습니다. 따라서 프로젝트 작업에 소비 한 모든 시간 동안 고객에게 비용을 청구해야합니다. 고객이 투자 할 가치가 충분한 지 판단하는 것은 고객의 몫입니다.

나는 이런 식으로 그것을 본다 : 하루의 끝에서, 당신이 청구하는 것은 당신의 전화입니다. 고객, 기존 관계, 영업 기술 등을 얼마나 행복하게 생각하는지와 같은 많은 변수가 있습니다. 궁극적으로 고객에게 제공하는 것은 고객이 원하는 것은 가치입니다. 고객에게 어떤 가치를 주었으며 고객에게 가치있는 솔루션 / 제공 가능한 가치는 무엇입니까?

문제를 해결하는 데 10 분이 걸릴 수 있지만 해당 문제를 해결하는 방법을 배우는 데 10 년이 걸렸습니다. 그것은 고려할 가치가있다. 동시에, 우리 중 일부는 "직무 상"보상을 배우는 능력을 고려합니다. 나는 종종 고객의 소동에있는 것들을 배운다. 비 금전적 보상의 형태라고 생각한다.

또한 청구서에 청구서를 추가 한 다음 청구서에 "우선 고객 할인"으로 표시하고 청구하지 않고 선의의 의지를 구축 할 수 있습니다. 나는 때때로 그렇게하고, 그 결과 클라이언트가 기분이 좋아진다.

또한 하루에 수천 달러를 벌고있는 개발자가 있는지에 대한 귀하의 질문은 그렇습니다. 당신도 당신의 기술과 함께 그들 중 하나가되어야합니다. 나는 실제로 거기에 있으며 CSS에서 당신과 같은 리그에 가까이 있지 않습니다.

원래 계약에 따라 다릅니다.

당신은 그것을 완료하고 갈 준비가됐다고 말했습니까? 그런 다음 개발하는 데 소요되는 모든 시간에 대해 더 나은 요금을 청구하십시오. 그것의 모든!

변호사를 고용하여 귀하를 대신하여 소송을 제기 한 후 변호사가 소송을 제기하고 귀하를 잃는 경우에도 귀하는 여전히 청구서를 지불합니다.

그것이 다른 모든 직업들이하는 방식입니다. 프로그래머가 달리해야 할 이유가 없습니다.

고객이 너무 많이 지불했다고 생각하면 다시 연락을받지 않습니다. 반복되는 고객으로 유지하는 것이 근무 시간 동안 청구되지 않는 유일한 이유입니다.

내가 구체적으로 취한 프로젝트라면 누군가가 내게 돈을 지불하고 새로운 기술을 가르쳤을 때 나는 보통 시간을 청구하는 것보다 적게하는 경향이있다. 반면에, 당신은 너무 낮은 입찰을 할 수 없습니다, 또는 그 후 영원히 그 클라이언트와 일을 퀴어 것입니다 ( "이봐, 정말 멋진 일을했을 때, 당신은 이것보다 적은 금액을 청구!") 그렇지 않으면, 나는하지 않습니다 내가 망쳐 놓은 시간에 대한 청구서가 너무 오래 걸렸습니다.

이 규칙에 대한 나의 예외 : 문제를 해결하는 데 몇 시간이 걸리는 이유는 고객이 파손 된 것에 대해 나를 괴롭 혔기 때문에 모든 비용을 청구합니다.

나는 그것이 뻔뻔스럽게 내 잘못이었고 나는 단지 저주를 당했다면 나는 일반적으로 청구하지 않을 것이지만, 나는 비즈니스 영리하지 않다. 나는 대부분의 비즈니스 영리한 사람들이 단지 최종 결과가 아니라 고객이 시간을 지불한다는이 철학을 적용한다는 것을 알았습니다 . 내 경력에는 이런 생각을하지 않은 것을 후회했던 많은 시간이있다. 내가 생각한 모든 것은 최종 결과가 가치있는 것으로, 최종 결과를 개선하지 않으면 내 시간은 의미가 없습니다. 그러나 고객이 마음을 바꾸고 동료가 자신에게 할당 된 버그를 일으켜 작업을 지연시키는 등의 결과로 인해 시간이 낭비 될 수 있습니다. 실제로 무엇을하고 있는지 알기 위해

규칙을 구부리고 어떤 종류의 노동 시간을 지불해야하는지, 무료로 지불해야하는 것을 예외로하면 결국 활용하기가 쉬울 수 있습니다. 시간은 결제에 사용하기 가장 쉬운 측정 항목입니다. 그것은 당신에게 무책임한 것처럼 보일 수있는 많은 복잡한 책임을 풀어 주지만, 고객의 무책임으로 인해 임금이 인하되는 것을 막아줍니다.

필자의 경우에는 종종 다음과 같은 작업을 수행하기 때문에 잘못된 길을 가고 싶을 수 없다면 희망이 없을 것입니다.

... 거의 40 년 전의 Catmull-Clark 하위 분할 알고리즘을 이겨내려고 노력했지만이 거대 회사만큼 경쟁력을 유지하면서보다 직관적 인 결과를 제공하려고 노력함으로써 Microsoft 및 Pixar와 같은 회사에서 반복적으로 개선 한 Catmull-Clark 하위 분할 알고리즘 속도로.

그러한 경우 시간의 95 %, 나는 잘못된 길을 가고 실패 후 실패 후 실패 후 화이트 보드로 끊임없이 돌아갑니다. 실패에 대한 비용을 청구 할 수 없다면 이미 노숙자 일 것입니다. 내 연구의 절반 이상을 연구로 본 적이 있는데, 이전에 아무도 시도하지 않았을 때, 첫 번째 시도에서 솔루션을 다루는 완벽한 방법을 찾을 수있는 방법은 없습니다 (20 회 시도). 나에게 목표는 첫 번째 시도에서 성공하는 것이 아니라 가능한 한 빨리 실패하는 것이었고, 실패 후 각 실패는 실제로 세상을 바꿀 수있는 올바른 솔루션이 무엇인지에 대한 단서를 제공합니다.

모든 사람들이 R & D 집약적 인 지역에서 일하는 것은 아닙니다. 고객이 새로운 프로젝트를 시작했기 때문에 가장 잘 확립 된 기술을 이길 수 있기를 기대하지만, 나에게 프로그래밍은 결코 일상적이지 않습니다. 간단하고 확실한 해결책입니다. 부품을 설계하고 통합하는 방법은 여전히 ​​독창적이며, 항상 어떤 형태의 예술 자체도 기계적인 것이 아니라 완벽하게 과학적이지 않은 독창적 인 장단점을 산출합니다. 그렇지 않으면 로봇이 할 수 있습니다. 필자는 필연적으로 여기저기서 잘못된 경로를 내려가는 것에 대해 항상 비용을 청구해야한다고 생각합니다. 복사 및 붙여 넣기 버튼을 눌렀을 때 요금이 청구됩니다.

예측 불가

또 다른 것은 프로그래밍이 항상 어렵고 예측할 수 없으며 결코 일상적이지 않다는 것입니다. 그것은 자동차 사고와 같은 것을 제외한 모든 것을 설명 할 수있는 일상적인 피자 배달과는 다릅니다. . 그것은 항상 사이트에서 배우고 있습니다. 누군가가 반복해서 퀵 정렬과 같은 구현을 반복적으로 지불하지 않으면 완전히 일상적인 것으로 상상할 수 없습니다. 거기에는 항상 실험과 학습이 진행될 것입니다. 과도하지 않은 한 죄책감을 느끼지 않아도됩니다.

나는 종종 기존 지식의 한계를 뛰어 넘는 것이 아니라 일에서 더 많은 일상적인 움직임을 찾을 수 있도록 농부가되기를 꿈꿨다. 대신 나는 평생을 평범하고 평범한 일상 생활로 만들어 보상을 시도하고 정신을 위해 어딘가에 예측 가능성과 일상적인 움직임을 추가하여 외부의 삶에서 흥분을 느끼고 싶은 사람들 사이에서 나를 괴롭힌다. 일의-나는 직장에서 충분히 찾을 수 있습니다.

그는 잘못된 해결책을 찾지 않고 새로운 것을 배우는 것에 대해 이야기하고 있습니다.

잘못된 해결책을 연구하는 것은 새로운 것을 배우는 것입니까? 시작했을 때 솔루션이 잘못되었다는 것을 알고 있습니까, 아니면 희망이 잘못되었다는 것을 알고 난 후에도 계속 노력하고 있습니까? 바라건대 후자가 아닙니다. 학습 과정은 종종 실수를 통해 이루어진다. 최고의 선생님입니다. 내가 찾은 가장 효과적인 전략은 가능한 한 빨리 실수를하고 실제로 가능한 한 빨리 실수를 디자인하여 모든 것을 저지르고 그 해결책을 결혼하기 전에 실수를 발견하는 것입니다. 거의 100 % 확실하게 실수를 저지를 것이라고 예측합니다. 그들이 정말로 늦게 발견된다면 그들은 비싸다.

실제로 프로젝트 제안 방법과 프로젝트 청구 방법에 따라 다릅니다.

예를 들어, 산출물 기반 계약 인 경우 새로운 것을 배우기 위해라도 프로젝트에 관계없이 모든 시간을 추적해야합니다.

시간과 재료에 기초한 계약이라면 이것에 대해 훨씬 더 민감해야합니다. 예를 들어, 문제의 상황 내에 있고 문제가있는 경우 청구 가능해야합니다. 예를 들어 레거시 API 또는 코드를 배우고 코드로 작동시키려는 경우입니다.

그러나 측면에서 무언가를 시도하거나 새로운 방식으로 배우는 방법을 배우고 싶다면 실제 솔루션을 구현하는 데 걸리는 시간이 아니라 실제 솔루션을 구현하는 데 걸린 시간에 대해서만 요금을 청구합니다.

나는 Lunivore에 동의하지 않습니다. 그들은 우리의 전문 지식과 우리가 이미 그것을하는 방법을 알아야 할 대부분의 시간 때문에 우리에게 돈을 지불합니다. 그들은 우리에게 구현 비용을 지불합니다.

간단히 말해, 초기 추정치에 문제를 배우는 데 걸리는 시간이 포함되어 있지 않은 경우 청구하지 않아야 할 것입니다. 학습 경험으로 작성하고 다음에 그 지연이 없을 때를 알아 두십시오.

편집 : 나중에 견적이 없다고 지정했기 때문에 이것이 반복 고객이라고 생각한다면 분명히 그 시간을 포함시키지 않을 것입니다. 또한 앞으로도 항상 선불 견적을 제공 할 것입니다.

이 문제를 해결하기 위해 나는 나쁜 경우가 될 것이라고 생각하고 "나쁜"경우에 의해 설정된 최대 견적으로 취해야한다고 생각하는 시간을 기준으로 시간을 기준으로 인용합니다. 이런 식으로 우리는 둘 다 승자입니다.