間違ったトラックに費やした時間をクライアントに請求すべきですか？[閉まっている]

私はクライアントのために解決するために小さなCSSチャレンジを取り上げ、時間給で支払います。最終的にそれを解決しましたが、5時間かかりましたが、約25％の時間を間違ったトラックに費やし、最近のブラウザーでしか動作しないCSS3ソリューションを試し、最終的にJSを介してフォールバックが不可能であることを発見しました（当初考えていたように）。25％をクライアントに請求する必要がありますか？

詳細：見積もりを提供しなかったので、チャレンジ自体が好きだったので、見積もりを出す前に作業を開始しました（ただし、以前に彼と一緒に仕事をしたことがあるので、彼は非現実的な期待を持つ人ではないことがわかります）。最悪の場合、私は興味をそそられるCSSチャレンジに5時間の無給費を費やしていたでしょう。そして、私はすでに作業を完了しているので、私たちの両方に可能な限り公平な見積もりをします。:)

編集：ありがとうございました、私は私が複数の答えを受け入れることができればいいのに！私は結局彼に余分な時間を請求しませんでした（私は彼に3年半の請求をしました）が、私は彼に請求したよりも私がそれに取り組んだことを知っているように彼に言及しました。たぶんそれが彼がすぐに「推定値」を受け入れた理由かもしれません（その場合、それは推定値ではなかったので、引用です）。

数時間かけて何かをしてから、簡単な1行の解決策があることや、最初のアイデアがあまりにも悪いことなどに気づいたときに、よくそのような状況になります。

一般に、これらの場合、3つの状況に違いを生じます。

• 新たに発見されたソリューションは明らかではありませんでした、および/または平均的な開発者もおそらく間違った軌道に乗っているでしょう、そして/または間違った軌道は最終的な解決策を見つけるための前提条件でした。この場合、間違ったトラックで費やした時間に対して顧客に請求します。

• 新しく発見されたソリューションはそれほど明白ではありませんでしたが、おそらく多くの平均的な開発者がこの方法を直接採用するでしょう。言い換えれば、コードを書き始める前によく考えれば、おそらく最終的な解決策を直接見つけることができたかもしれません。この場合、私は顧客に請求しますが、価格を半額または最も適切と思われる割合で引き下げます。

• 明らかに、最終的な解決策を見つけるのは非常に簡単だったので、コードを書き始める前に、私はあまりにも愚かすぎたり、眠すぎたり、まったく考えられなかった。この場合、間違ったコースで2日間過ごしたとしても、それは私自身の責任であり、顧客はそのために支払う必要はありません。

間違った方向に進んでいるとは思わない。ソリューションをコーディングし、ソリューション（kudos）をテストしたところ、期待どおりに機能しないことがわかりました。ソリューションをデバッグしてから、別の方向に進んで修正しました。

私見、それは間違ったトラックではありません。それは通常のソフトウェア開発です。

もし私があなただったら、私は完全な4時間充電します。

私たちが書いているほとんどのプログラムは、ソリューションがすぐに簡単に入手できるわけではないため、書いています。私たちが行うすべてのことは、何か新しいことを学ぶことを伴います。クライアントは製品の代金を支払っていませんでした。彼は製品の作り方を学び、その結果をあなたに支払っていました（そして彼がそれを「チャレンジ」と呼んだなら、彼はあなたが何かを学ぶことを期待していました）。Tom de MarcoとTimothy Listerによる「Waltzing with Bears」を参照してください-「プロジェクトにリスクがなければ、やらないでください」。

クライアントに適切に返済したい場合は、ソリューションとうまくいかなかったソリューションの詳細を彼に送ってください。そうすれば、彼は彼が雇った他のスタッフにそれらを伝えて、彼らがあまり時間をかけないように助けます。

彼が多すぎると思ったら交渉するのはあなた次第です。確かに、私は彼が他の場所で簡単に使用できない学習に対して支払うことを期待するでしょう。

問題の解決には、妥当なオプションのセットから次善のソリューションを排除することが含まれることがあります。除去のプロセスは、問題解決ツールの1つです。クライアントはソリューションの代金を支払いますので、自由にツールを使用してください。

プロジェクトブリーフィングからキーボードまでまっすぐ歩いて、バックスペースのない最適なコードストリームを出力する最適なソリューションを即座に想像することを期待するのは不合理なクライアントです。そのようなクライアントがいないと言っているわけではありません。プロジェクトの途中で電話をかけてきた顧客に、実際には「デバッグではなくプログラミング」に対してのみ支払いを行っていることを確認してもらいました。そしてもちろん、プログラミングがタイピングの物理的行為であるクライアント（またはボス）もいます。

あなたの盲目の路地は、クライアントの最高のお金を表すことができます：別の開発者はあなたほど徹底的ではなかったかもしれませんし、将来噛み付くより安価で互換性の低いソリューションを提供しました。

これらの質問は私を夢中にさせます...

メカニックまたは弁護士があなたのケース/問題に取り組むのに時間を費やした場合、たとえ間違った道に時間を費やしたとしても、あなたは請求さ​​れる@ $$を賭けます

プログラマーは時間をもっと評価し始める必要がある

あなたがしたことは完全に普通でした。フレッドブルックスは、ソフトウェアエンジニアリングに関する彼の独創的な本「The Mythical Man-Month」の「Plan to Throw One Away」の章でこの現象について説明しています。

あなたは時間と材料の契約に取り組んでいました。したがって、プロジェクトでの作業に費やしたすべての時間に対してクライアントに請求する必要があります。クライアントが投資に十分な価値を受け取ったかどうかを判断するのはクライアント次第です。

私はこのように見ています。1日の終わりに、あなたが請求するのはあなたの電話です。クライアントの満足度、既存の関係、販売スキルなど、さまざまな変数があります。私たちは皆、それらに精通しています。最終的にクライアントに提供しているもの、そして彼らが本当に望んでいるのは価値です。クライアントにどのような価値を与えましたか？また、クライアントに提供する価値のあるソリューション/成果物は何ですか？

問題を解決するのに10分かかるかもしれませんが、その問題を解決する方法を学ぶのに10年かかりました。それは考慮に値する。同時に、私たちの中には、「仕事中の」補償を学ぶ能力を考慮している人もいます。私は頻繁に物事を学びますが、それは実際にクライアントのダイムにあります。私は非金銭的補償の一種だと考えています。

請求書に追加して、請求書に「優先顧客割引」としてマークし、請求せずに善意を構築することもできます。私は時々それをします、それはクライアントを気分が良くさせます。

また、1日に数千ドルを稼いでいる開発者がいるかどうかというあなたの質問は、答えはイエスです。あなたもあなたのスキルで彼らの一人でなければなりません。私は実際にそこにいて、CSSであなたと同じリーグにいることには程遠いです。

それは元の契約に依存します。

あなたはそれを完成させて行く準備ができていると言いましたか？その後、開発に費やしたすべての時間をより適切に請求します。それのすべて！

あなたが弁護士を雇ってあなたのために訴訟を起こし、彼らがそれを破ってあなたのために負けたとしても、あなたはまだ彼らの請求書を支払う。

それが他のすべての職業のやり方です。プログラマーがそうしなければならない理由はありません。

支払いが多すぎるとクライアントが考えた場合、彼らはあなたに戻ってきません。顧客をリピーターとして維持することが、勤務時間中に料金を請求しない唯一の正当な理由です。

誰かが私にお金を払うように私が具体的に取ったプロジェクトであり、新しいテクノロジーを自分自身に教えながら、私は通常の時間よりも少ない時間でそれをする傾向があります。一方、低すぎる入札はできません。さもないと、クライアントと物事が永遠に変わってしまいます（「本当にクールなことをやったときに戻ってきたので、これよりも少額請求しました！」）私は時間を無駄にしましたが、時間がかかりすぎました。

この規則の私の例外：問題が解決するのに何時間もかかった理由が、顧客が壊れたものについて私をでたらめにしたためである場合、すべてを請求します。

それが露骨に私のせいであり、私がただけいれんしていた場合、私は通常充電しませんが、私はビジネスに精通していません。ほとんどのビジネスに精通した人々は、クライアントが自分の時間にお金を払っているというこの哲学を適用し、単なる最終結果ではないことを発見しました。振り返ってみると、私はこのように考えなかったことを後悔しているキャリアが何度もあります。私が考えたのは、最終結果が価値があるということだけでした。最終結果を改善しない限り、私の時間は無意味です。しかし、クライアントが心を変えたり、同僚があなたに割り当てられたバグを引き起こしたり、仕事を遅らせたりした結果、多くの時間が浪費される可能性があります。あなたが何をしていたかを本当に知るために事前に。

ルールを曲げ始め、どのような労働時間を支払うべきか、何を無料にするべきかを例外にすると、最終的には簡単に利用できるようになります。時間は、支払いに使用する最も簡単な指標です。無責任に思えるかもしれない多くの複雑な責任からあなたを解放しますが、周りに引っ張られたり、クライアントの無責任がいくらかの給与削減につながることからあなたを守ります。

私の場合、間違った道をたどって料金を請求できなければ、次のようなことをすることが多いので絶望的です。

...業界に定着し、MicrosoftやPixarのような企業によって繰り返し改良されてきた、40年近く前のCatmull-Clark細分化アルゴリズムを打ち負かすことを試みます。速度的に。

このような場合、95％の時間、間違ったルートをたどり、失敗後も失敗後も常にホワイトボードに戻ります。失敗に対して料金を請求できなければ、ホームレスになります。私の仕事の半分以上が研究であり、これまで誰もこれらのことを試したことがなく、最初の試行（おそらく20回目の試行）で解決策に取り組むための完璧なアプローチを見つける方法はありません。私にとって目標は、最初の試みで成功することではなく、できるだけ早く失敗することであり、失敗後の各失敗は、実際に世界を変えることができる正しいソリューションが何であるかについての手がかりを提供します。

新鮮なプロジェクトを始めているという理由だけで、顧客があなたが最も確立された技術を打ち負かすことを望み、期待するような研究開発集約型の分野で全員が働いているわけではありませんが、私にとってプログラミングは決して日常的ではありませんシンプルで確立されたソリューションです。パーツの設計と統合の方法は依然としてユニークであり、常に何らかの形の芸術そのものが、機械的ではなく、完全に科学的ではなく、ユニークな長所と短所をもたらします。そうでなければ、ロボットがそれを行うことができます。必然的に、私たちはあちこちの間違ったルートを下るのに常に料金を請求しなければならないと思います。さもなければ、私たちがすでに何百回も行った最も日常的な仕事から利益を得ることができるでしょう。そのたびに、コピーアンドペーストボタンを押すと課金されます。

予測不能

もう1つは、プログラミングは常に難しく、予測不可能であり、決して日常的ではないということです。これは、ピザの配達とは異なり、自動車事故のようなもの以外のすべてを考慮することができます（残念ながら、上司の下で、プログラマーの見積もりをピザ配達の見積もりと同一視し、実際に行っている作業はタイピングだけだと考えていたのですが） 。常にサイトで学習しています-誰かが実際に何度も何度もクイックソートのように実装するために私に繰り返し支払わない限り、それが完全に日常的になるとは想像できません。常にいくつかの実験と学習が行われますが、それが過度でない限り、それについて罪悪感を感じる必要はありません。

私はしばしば、既存の知識の限界を常に押し広げるのではなく、仕事でより多くの日常的な動きを見つけることができるように、農民や何かになることを夢見ていました。代わりに、仕事以外の生活をできる限り日常的でありふれたものにして、正気のために予測可能性と日常的な動きをどこかに追加することで補おうとしています。仕事の-私は仕事で十分を十分に見つけます。

彼は間違ったことを解決するのではなく、新しいことを学ぶことについて話している。

間違った解決策に取り組むことは、新しいことを学ぶことではありませんか？開始時に間違ったソリューションであることを知っていましたか、それとも絶望的に間違っているとわかった後でも、継続的に作業を続けましたか？後者ではないことを願っています。多くの場合、学習のプロセスは間違いによるものです。最高の先生です。私が見つけた最も効果的な戦略は、できるだけ早くミスを犯すことです。実際にそれらがすべてにコミットし、そのような解決策と結婚する前に、間違いができるだけ早く設計ミスであることを発見することですほぼ100％の確実性で予測すると、間違いが発生するということです。彼らは本当に遅く発見された場合にのみ高価です。

それは、プロジェクトをどのように提案したか、そしてプロジェクトがどのように請求可能であるかに本当に依存します。

たとえば、成果物ベースの契約の場合、何か新しいことを学ぶためであったとしても、プロジェクトに向けてすべての時間を追跡する必要があります。

それが時間と材料に基づく契約であるなら、あなたはこれに対してもっと敏感である必要があります。たとえば、問題のコンテキスト内にあり、問題がある場合は、請求対象となります。この例は、レガシーAPIまたは少しのコードを学習していて、それをコードで動作させようとしている場合です。

ただし、何かをしようとしてサイドトラッキングを取得したり、新しい方法を学習したい場合は、実際のソリューションを実装するのにかかった時間に対してのみ請求します。

彼らは物事を学ぶために私たちにお金を払うという、Lunivoreには同意しません。彼らは、私たちの専門知識と、ほとんどの場合、すでにそれを行う方法を知っているはずであるため、私たちに支払います。彼らは実装のために私たちに支払います。

要するに、ffに最初の見積りに問題を学習するのにかかった時間が含まれていなかった場合、おそらくそれに対して請求すべきではないでしょう。学習経験としてそれをチョークで書き、あなたがその遅れを持たない次回を知ってください。

編集：後で見積もりがないことを指定したので、これが繰り返しクライアントになると思われる場合、私は確かにその時間を含めません。また、将来的には常に事前に見積もりを提供します。

これを回避するために、「悪い」ケースによって設定された見積もりの​​最大値で取得する必要があると思う時間に基づいて、悪いケースがどうなるかを考えて見積もります。このように、私たちは両方の勝者です。