時間追跡方法の代替案[終了]

最初の質問： Web /ソフトウェア開発会社の従業員の時間追跡に対するいくつかの実行可能な代替手段は何ですか？また、なぜ彼らはより良い選択肢ですか？

説明：

私はこのような会社で働いています。誰もが給与を支払われます。契約、アドホック、および内部（非課金）の3種類の作業があります。アドホックは数時間かかる小さな変更であり、月末にクライアントに請求するだけです。契約は締結されており、通常、この大きな長いプロセスがあります。

関係する時間の見積もりを取得して（設計と開発者から）、時間料金を掛けることで、いくら請求するかがわかります。したがって、ウェブサイトの推定時間は50時間だとします。時間追跡ソフトウェアがあり、それに費やした15時間（たとえば、7：00から7:15）の時間、プロジェクト名を記録し、コメントを付ける必要があります。

50時間を超えると、お金を失い、非効率になります。

今、私はどのようにシステムの動作について説明してきたことを、私の質問は、より良い方法が存在する場合、それは（私は必ず1必見だもの）に行うことができますどのように他です。現在のシステムが好きな人はいません。代わりのシステムが見つかりません。数時間後にプロジェクトを時間内に終わらせるために時間をかけて仕事をするつもりはありませんが、現在のシステムではそうするつもりです。マネージャーがこのシステムの代わりにabcシステムを使用する理由を示すために、この投稿を要約（またはリンク）できるようにしたいと思います。

ソフトウェアの見積もりは常に困難です。ソフトウェアは創造的なビジネスであり、創造性は衰退します。私はちょうど1週間のひどい疲労の後、跳ね返り始めています-他の夜は15-30分だったはずのタスクをするのに何時間もかかりました...

また、開発者ごとに異なる推定能力があることも考慮してください。規律のある開発者や上級の開発者はより正確になる傾向があり、より若くて規律のない開発者はより正確ではありません。また、その精度は時間とともに変化します（常に良いとは限りません）。

私の個人的なコンサルティングの経験では、現実的な見積もりと上限を組み合わせてみました。基本的に「この機能には7〜10時間かかると予想されますが、18時間に達する可能性があります。40時間かかったとしても、18の料金が請求されます」。通常、このタイプのアプローチはクライアントにとって新しいものであり、一部のクライアントは「堅実な価格を与える」ことでそれを拒否します。このアプローチを受け入れるクライアントの場合、彼らは私が正直に時間を追跡することを理解し、実際の最終請求書は私の費やした時間を反映します（ただし、上限を超えません）。基本的に、これは保証が追加されたリーンアプローチです。顧客は、要件の変更が見積もりの​​変更をもたらすことを認識しています。

全体として、そのアプローチは、それを受け入れようとするクライアントにとってはうまく機能しています。私の個人的な目標は、彼らの信頼を獲得し、ビジネスを繰り返すことですので、正直になり、天井の下にうまく入ろうとすることは私の利益になります。最新の変更など-変更がマイナーを超えるものである場合、見積もりを修正します）。

もしお持ちでなければ、The Mythical Man Monthを読むことをお勧めします

証拠に基づいたスケジューリングを見てください。見積もりがどれほど正確かを確認するのに本当に役立ちます。

過去1年ほどにわたってFog Creekで、私たちは、最もgroな開発者でも喜んでそれを採用できるシステムを非常に簡単に開発してきました。そして、私たちが知る限り、非常に信頼できるスケジュールを作成します。Evidence-Based Scheduling、またはEBSと呼ばれます。主に履歴タイムシートデータから、スケジュールにフィードバックする証拠を収集します。出荷日は1つだけではありません。特定の日付に出荷される確率を示す信頼分布曲線を取得します。次のようになります。

曲線が急峻であるほど、出荷日が本物であると確信できます。

方法は次のとおりです...

この方法の問題は、推定に固有のリスクを考慮していないことです。見積もりの​​ベストプラクティスは、50時間±15時間などの時間範囲で表すことです。エラー用語を見つけるのは難しいですが、とにかく正確に50時間かかるとは誰も信じていません。

固定価格モデル以外のアプローチもあります。より低いレートを使用し、数時間連続して請求することもできますが、最近では、クライアントがリスクを移転したいと思うでしょう。それは問題ありませんが、それはあなたが思いつく時間の範囲に基づいて合理的なリスクプレミアムを請求する必要があることを意味します。

「+/-」因子で推定しようとするのではなく、「不確実性」因子で推定を行います。プログラマーは、「何も問題がないと仮定して」何かがかかる時間を簡単に知ることができます。彼らが簡単にあなたに伝えることができないのは、何かがうまくいかない場合、どれくらい時間がかかるかです。したがって、不確実性係数を追加します-「L」は「25％を追加」-「M」は「50％を追加」、「H」は「100％を追加-倍増可能」を意味します。リアルタイムは、推定時間と推定値と不確実性時間の間にある傾向があります。

時間を追跡する限り、最も正確な方法は、1分ごとにダイアログボックスを表示し、「何をしているのですか？」という質問をドロップダウンリストボックスに表示するプログラムを作成することです。そのドロップダウンリストボックスで本当に必要なエントリは「時間の追跡」だけです。これは、毎分中断された場合、実際には他に何も行われないためです。同じ原則が15分間隔にも当てはまりますが、それほど悪くはありません。

私たちがしているのは、リストにタスクを追加し、作業中のタスクを選択できるようにする小さなプログラムを実行することです。セレクタを正しいタスクに移動するのを忘れた場合、合計は編集可能です。行の1つにないものはすべて「その他」になります。完全に正確ではありませんが、全体の正確さはフロー時間を取得することよりも重要ではありません。