完了した作業に関するレポートを削除するにはどうすればよいですか？
時間の無駄をなくす物語
はじめに
進捗レポートを使用したことがありますか？ それらを記入しますか？ それらを承認しますか？ オフィスの周りにそれらを運ぶ？
良い時間を過ごすようなものでしたか？
ステートメント1 ：進捗レポートが役立つ場合があります。
ステートメント2 ：しかし、このようなことはほとんどありません。
物語
むかしむかし、ソフトウェア開発会社があり、私は開発部門の責任者として就職しました。
面白くてクールな仕事でしたが、私の毎週の悩みの1つは、完了した作業に関するレポートを収集して承認する義務でした。 何十ものレポート、何百もの紙片。 人事部の懸念の1つは、私が時間通りにレポートを提出できるようにすることでした。したがって、毎週これについて開発者をキックする必要がありました。
迷惑だった。 時間がかかり、すべての人の注意をそらしただけでなく、「承認」レポートに関する私の仕事は基本的に推測ゲームであったためです。 レポートが正しいかどうかを確認する作業方法がありませんでした。 それはすべて迷惑でしたが、それについて騒ぎ始めるのに十分ではありませんでした-私はここの初心者で、より問題のあることに集中したかったです。
最大の問題の1つは、人々が「死ぬまで一生懸命働いた」ことでした。 多くの開発者は淡い幽霊のように見えました。 彼らは私が到着した朝、すでにオフィスにいましたが、夕方に去ったとき、まだそこにとどまりました。 主要な開発者の1人は、来週の土曜日に休日の声明を送ることさえできました。 彼は混同して間違った日付を入力したと思ったが、彼は数週間週末の間ずっと働いていて、本当にこの週末に少なくとも1日は家に帰りたかったことが分かった。 土曜日の休暇宣言は、馬鹿げているが、深刻な問題を指摘する非常に効果的な方法でした。
では、なぜ、計画および会計モジュールは、獲得した開発者の死について警告を発行しなかったのですか？ このモジュールがこのような単純で重要なことすらできない場合、それは一体何なのでしょうか？ すべての可能な情報を記録するトレンディな監視システムを備えた飛行機や原子力発電所を想像してください。
幸いなことに、私は開発者と一緒に座っていたので、この警告の兆候を見ることができました（そして、最初に提供されたオフィスの個人的な部屋を拒否したことは嬉しかったです）。
長い間、短い時間でしたが、数週間後、主な問題はすでに多かれ少なかれ制御されていたため、完了した作業のレポートに行きました。 その時までに、私は多くの異なる報告をしなければなりませんでしたが、これからのすべての欠点を除いて、1つの利点がありました：他の無駄な手順のための場所がありませんでした。
実行された作業のレポートは、私を悩ませるだけでなく、興味がありました。 なぜ必要なのですか？ 彼らはどこから来て、どこへ行くのですか？ だから私は尋ね始めました。
上司（CEO）は簿記が必要だと言った。 経理によると、それらは人事部に必要です。 人事部は、彼らが会社に必要であると言って、我々は給与を外注しました。 などなど。 これが私のバックグラウンドプロジェクトになりました。少し時間が経った後、「Secrets of Progress Reports」の調査を続けました。
最後に、私は論文で何が起こっているかを知りました。 一連の手渡しによる移転の後、彼らはそのアウトソーシング会社での生活を終え、そこで各レポートは電子人事会計システムに手動で入力されました。
うーん...
Mdaaaaaaa ...
まあ、つまり、一般的にはあまり効果的ではないということです。
私は心の中でITオタクであったため、すぐにプロセスを簡素化する方法について考え始めました。 そのため、各開発者はオンラインで作業内容を記入できます。ローカルチームリーダーはすべてのレポートをオンラインで確認し、[OK]をクリックして承認します。 うわー、すべてが非常にスムーズです。 うーん、多分このシステムをEclipseに接続して、コンピューターで開いている開発プロジェクトに応じて、実行された作業の時間を自動的に記録するようにしますか？ たぶん、アウトソーシング会社が使用する人事会計システムと直接統合できるでしょうか？ これはSOAにうまく当てはまる可能性があります...
ちょっと待って
「まったくする必要のないことを効果的に行うことほど無駄なことはありません。」-ピーター・ドラッカー
私の最初の質問は、パフォーマンス（効率）ではなく、実行された作業に関するレポートの有効性であることを思い出しました。
- パフォーマンス-システムの出力と入力の比率。
例：1時間あたりのコードの行数。 - 効率は、望ましい結果を生み出す能力の質です。
例：リリースごとのROI。
完了した作業のレポートが使用された理由はまだわかりませんでした。 私が受け取った回答は、「これが標準であるため、完了した作業を入力する必要があります」というタイプのバカでした（つまり、「私たちがしなければならないので」というタイプ）。 彼らが行った作業の報告について私に言わなかったのは、私が本当に知りたかったのは、これらの数字が必要だった理由でした。
それで、私は異なった質問をし始めました。 「完了した作業のレポートが必要な理由」を尋ねる代わりに、「レポートを失った場合はどうなりますか」または「不注意でレポートコンテンツをランダムに生成した場合はどうなりますか」と尋ね始めました。
その結果、レポートの本当の目的が明らかになりました。 彼らが使用された主なものは、処理のための補償を支払う金額を計算することです。 他の目標もありましたが、それらはすでに他のレポートでカバーされていました。 したがって、唯一の重要な目標は、正確に処理の計算でした。 また、スウェーデンの業界の伝統である「フレックスタイム」を計算する必要がありました。実際、先日早く到着した場合、人々は時々後で仕事に来ることができます。 進捗レポートを使用して、すべてが合計で少なくとも週40時間+ X（Xは時間外勤務）であることを確認しました。
真実の甘い味。
さて、真実で武装して、私は数人の開発者を集めて修辞的な質問をしました-「あなたは行った仕事に関する報告書に記入したいですか？」 彼らの顔の表情は私が必要とした答えでした：
それから私はこのように続けました：
「これらのレポートを使用して、残業時間をカウントします。 しかし、報告書に記入することは気のめいるようであり、残業はさらに気のめいるようです。 私たちは皆、1週間のゾンビコーディングよりも、1時間の精力的でやる気のある集中的な開発が有益であることを知っています。」
（ちょっとした特定のリンクは覚えていませんが、少なくともソフトウェア開発などの創造的な仕事に関しては、1週間の勤務時間と生み出される価値との関係が小さいかどうかを示す研究のトラックをすでに失っています。動機付けが重要です。時間ではなく焦点を合わせます）。
「だからオファーは何ですか。 これ以上のレポートはありません。 そして、残業はもうありません。 今日から、残業とは「やりたくないときに働く」ことを意味します。やる気がなくなったり疲れたりしたら、家に帰ります。 あなたが「ストリーム内」にいるので、あなたが長引いて、ぶらぶらしたいなら-残ります。 これは残業ではありません。 数日間遅れて働いていると感じたら、休みを取りましょう。 週が遅いことが判明した場合-必要に応じて、土曜日に追いつく。 あなたのリズムを見つけ、あなたのチームのリズムを見つけてください。」
「もちろん、例外がある場合もあります。 このような場合、従来の処理補償システムが機能します。 このようなケースを最小限に抑え、個々のケースごとに対処するようにします。 疑わしい場合は、私に電話してください。」
「通常を管理し、例外を例外として扱う」-エドワーズデミング
「最後に。 標準的なフルタイムにほぼ相当する限り、週に何時間働くかは気にしません。 仕事をするとき、あなたは集中し、やる気があるのではないかと心配しています。 責任を持ってこれを受け取ってくれると信頼できますか？」
誰もが熱心にうなずきます。
私は勇気を出し、CEOに行き、仕事の報告をもう送らないと言った。 対話は次のようになりました。
私：「完了した作業に関するレポートは送信しません」
CEO：「なぜ？」
私：「これは時間の無駄です。」
CEO：「そして人事部は動揺しませんか？」
私：「彼らに必要なものをもっと効率的に提供します。」
CEO：「オッケー、クール」
うわー、それは思ったより簡単だった。 私はさまざまな問題に備えました...私はそのCEOが好きでした：o）
それから私はフレームに行きました。
私：「完了した作業に関するレポートは送信しません。」
職員：「しかしあなたはしなければなりません。 これが標準です！」
私：「基準は変わりつつあります。CEOと話をしただけです」（まあ、はい、私は少し嘘をつきました、私は認めます）。
職員：「今、私たちは人々にいくら支払うべきかをどのように知るのでしょうか？」
私：「みんなの雇用契約があります。 全員に通常の月給を支払うだけです。」
職員：「残業はどうですか？」
私：「彼はもうほとんどいないでしょう。 もしそうなら、私はあなたに知らせます。 それ以外の時間は、週に40時間カウントします。」
担当者：「しかし、手順や基準を変更したくありません。以前のようにレポートを送信するだけでしょうか？」
I：「週に40時間自動生成され、毎週メールで自動的に送信されます。 これが必要ですか？」
職員：「うーん、かなり愚かだ」
私：「じゃあ、送らないよ。 必要に応じて。 あなたは私たちから40時間のレポートのパックを受け取ると仮定し、通常のようにこれをすべてシステムに入力します。 私たちは紙を走り書きする回数が減り、レポートを遅らせるために私を蹴る必要がなくなります。」
職員：「わかりました、まったく正しい、やってみましょう。」
完了した作業に関する報告についてst音を立てる人は他にいませんでした。
歴史の道徳
- 多くの組織は、規格で規定されているあらゆる種類の手順（さまざまな役に立たない規則、慣行、手順）を無駄に多くの時間を費やしています。 これをもう一度見てください。 積極的に受け入れてください-これらは改善の良い機会です。
- 一見したところで最も役に立たない手順にも目標があります。
- 役に立たない手順を拒否することに抵抗がある場合は、その原因を見つけてください。 この手順を終了する必要があるものを見つけます。 このニーズを解決するために、より安価で無駄な方法を提案してください。
- しつこい。 組織内で深く「ひっかかっている」手順をなくすには時間がかかります。
- この手順を導入した前任者を非難しないでください。 おそらく、これは過去の本当の問題に対する良い解決策でした。 そうではなかったかもしれませんが。 一般的に、これはもはや重要ではなく、未来に焦点を当てています。
「彼らはそのようになったので、彼らはあるものです」-ジェリー・ワインバーグ - 効率とパフォーマンスを混同しないでください。 最初に効率に焦点を当て、次に生産性に焦点を合わせます。
- 1時間は努力の尺度であり、価値の尺度ではありません。
よくある質問
残業のようなものの後、これはあなたがより少ない時間を始めたという事実につながっていませんでした
それで、コードの記述が少なくなりました。 悪いコード。 重要度の低いコード。 ゴミが少ない。 したがって、バグをキャッチする時間、システムがクラッシュしたときにサポートサービスへのパニックコールに応答する時間、バグのリストを維持する時間、修正を発行する時間、および曲がったコードを解読する時間は短くなります。
そして、それは良いコードを書くのにより多くの時間を意味する。
私たちは皆、残業を放棄した後の生産性の明確で顕著な改善に気づきました。 単位時間あたりのユーザー価値に関する生産性。
勤務時間を考慮する必要はありませんでしたか？
ああ、時々、特定のプロジェクトに費やされた時間を知るための完全に正しい理由があります。例えば、請求が必要な外部クライアントがある場合です。 しかし、これは完了した作業のレポートなしで簡単に行えます。 8人のチームがプロジェクトXで3つのスプリントを費やし、各スプリントが2週間かかった場合、8人が3×2週間フルタイムで働いたとおおよそ推測できます。 合計40時間x 6週間x 8人= 1920時間。 確かに、彼らは時間の一部を製品Yのサポートに同時に費やしているのかもしれません。 この場合、各回顧展で、プロジェクトYで作業した時間の割合（たとえば80％/ 20％）を大まかに見積もるようにチームに依頼します。 これを計算で考慮するのは非常に簡単です。
一部のチームはこれを毎日行います-家に帰る前に、各チームメンバーはボード上のチャートにマークを付け、その日の時間をさまざまな仕事に大まかに配分します。 これにより、精度が向上し、同時に低コストになります。
ただし、ここではより注意が必要です。 通常、マルチタスクは非常に悪い考えです。 人々がどのようにプロジェクトに時間を割り当てるかを正確に考慮に入れるために複雑なシステムを作成する必要がある場合、私たちは間違いなくそれに焦点を当てません-症状ではなく問題を修正する必要があります（同時に多くのプロジェクトを同時に行う） ）
月曜日を4つの異なるプロジェクトに費やし、それぞれに2時間、合計8時間費やしたとします。 完了した作業のアカウンティングシステムでプロジェクトごとに2時間をマークしますが、これらのすべての「コンテキストスイッチ」を使用すると、プロジェクトあたりの有効時間は30〜60分に近くなります。 そのため、一日の大半が無駄になりました。
時間の無駄を費やす時間追跡システム自体は時間の無駄です。
全員が一度に1つのプロジェクトのみで作業している場合、完了した作業を学習するのは簡単です。
一部の開発者が残業のために多くのお金を受け取るのをやめた可能性はありますか？
私は給料を上げて、残業補償がもはや原動力ではなくなった。 多くの場合、この増加は顕著でした。 それについて文句を言う人はいなかったし、古いシステムに切り替えることを提案した人もいなかった。
調査によると、金銭的なインセンティブは、ソフトウェア開発のような複雑で創造的な仕事に関しては、生産性を悪化させる可能性があります。 代わりに、人々がお金を考えないように十分なだけ給料を払ってください。 このテーマに関する短くて非常にクールなプレゼンテーションは必見です。-ドライブ：私たちの動機についての驚くべき真実。
人々に過度の負担を払うことは何よりも愚かなことの1つであり、非常に疲れた開発者と「技術的負債」（多くの曲がったコード、欠陥など、後で延期された）を与えてくれただけです。
次に何が起こりましたか？
私は本を「trenchからのスクラムとXP」と書きました。 驚いたことに、それは開発者コミュニティで非常に人気がありました（紙の上で自分の考えをすべて頭から出すために自分のために書いたものです）以来、私はすでに私の本に触発されたことを教えてくれた世界中の人々のトラックを失いましたソフトウェア開発プロセスを整理する方法を変更します。 非常にクール、フィードバックをありがとう！
この記事は、その話の反対側にすぎません。 最も重要なことは、私たちが出会った時間の無駄を絶えず積極的にクリーンアップし続けなければ、私たちがやったことを決してできないということです（完了した作業のレポートはほんの一例です）。 うーん...なぜ「リーン」という言葉が頭に浮かんだのですか？ ：o）
すべては2006年でした。 それ以来、私は過去4年間コンサルティングを行ってきたにもかかわらず、時間表に触れたり記入したりしたことがありません。 将来のクライアントがこの質問を提起する場合、私は彼の本当の必要性を見つけ、それを閉じる別の方法を見つけます。