エンジニアからリーダーへ。 パート3：レポート

レポートは素晴らしいものです。 プロジェクト全体で、顧客、上司、従業員の両方を保護できます。 それらを管理および評価できます。 最後に、あなたは訪問者パターンを何千回も書き直した訓練された猿の熱意でコードを書いていませんが、最初はまだ座って考え、紙に描き、コードとテストを計画します（私はあなたを信じます！）？ しかし、一方で、レポートはすべての人を直接の作業からそらすコントロールと組織のものです。 それでも、職場で何らかの形で、それらに対処する必要があります。 妥協を求める理由と方法 この問題に関する私の意見に興味のあるすべての人、そして私の以前の記事を読んでくれた人へようこそ：

エンジニアからリーダーへ。 パート1：正義感
エンジニアからリーダーへ。 パート2：委任と問題設定

オーバーフロー

私はバランスと調和の知恵をすべて学びました。さくらと私の上司の死体を見るのではなく、厳しい現実の中で。 そして現実は本当に厳しいものでした。 暗い時代に、彼らは私たちに遠くのアフリカから暗いマネージャーを送りました。 彼は壮大な白い笑顔を持っていたが、暗い路地で夜になると消えるチェシャ猫の笑顔と混同される可能性があったが、飛行機が何であるかという考えはほとんどなかった。 さらに、笑顔のマネージャーは、幸運な人が私たちのプロジェクトをリードするために飛んだとき、彼の人生で一度飛行機を見たようです。 そして、残念なことに、彼は明らかに、時間の経過とともに残酷に打たれた自転車とは異なり、コンピューターをマスターしました。プロジェクト。

プロジェクトは緊急かつ困難でした。次の認証の前に、すべての枠をなめ、修正する必要がありました。 なぜなら 彼は現場にいましたが、以前は目に見えなかったマシンに対処しなければならず、マシンに何を期待するのかを本当に理解していませんでした。 学ぶのに多くの時間を要したため、進行状況を監視し、プロセスを明確かつ明確に監視することが重要でした。 このプロジェクトには、それぞれ6〜7人の3つのチームが関与し、彼に責任がありました。 誰が何をしたかを考慮するために、マネージャーは各参加者が毎日記入しなければならないExcelテーブルを開始しました。これは、いくつのモジュールがレビューされ、テストされたかです。 つまり しました、タブレットに記載。 しかし、一番の問題がありました。人が多く、ファイルが1つしかありませんでした。 そのため、タスクのリストはローカルファイルの人々によって蓄積され、説明責任を示すテーブルの行に転送されました。 ファイルがリリースされた間、彼らは戦った。 また、ファイルのリリースを待つことができなかった場合は、タブレットに多色のステータスを表示するために勤務時間外に留まりました。

マネージャーは毎日集会を開催しました。 彼はテーブルに記入する方法を彼らに話しました、それは時間ごとに時間を消費しました。 そして集会の一つで、彼は人々が問題を抱えていることに気づきました。 また、それらはテーブルに入力する必要があります：見つかったバグ、シミュレータで実行している人の問題、モジュールの欠如など。ただし、テーブルに問題はありません。 そのため、バグを入力する必要のある2番目のファイルとテーブルが表示され、最初のステータスからすべてのチェック済みステータスが転送されました。 しかし、1週間後に判明したように、それはそれほど効果的ではありませんでしたが、それでも何かを数える必要があり、マネージャーは何百もの変更を数えて再数える時間を持っていませんでした。 したがって、彼はある朝、チェシャ猫の笑顔で来ました。「こんにちは、皆さん、調子はどうですか？」 彼は、マネージャーがセキュリティのためにテーブルをロックしているため、結果が数値、手動で計算された結果、およびそれらの割合になる3番目の項目に記入することを提案しました。 さらに、最初のフィードバックを追加しました-進捗状況を記入し、何かが成功しなかった場合はモジュールのステータスを「遅延」に表示し、2番目に修正を行います-時間の問題。

言うまでもなく、これらの革新のずっと前に、時間の経過とともに問題が発生しましたか？ 実際、各チームでは、参加者の1人がこれらのテーブルに記入するだけで、テキストファイルの山にあるものを恥知らずに混乱させ、スキップしました。 そして、テーブルファイルはエラーであることが判明したという事実により壊れたため、統計を保存するために、重要な変更後に全員（それぞれ別の名前で）に保存され、飛躍的に増加し、最新で関連性のあるものを理解します-問題がありました。

プロジェクトは時間通りに終了しました。 マネージャーは、プロジェクト終了の1週間前に彼の自由意志を残し、青いコウノトリのコウノトリを追い払って、私たちに厳しい日常生活と黒い思考を残しました。 これは次のとおりです。レポートは優れていますが、最小限の時間で済むはずです。 特にIT分野で。 これはワンクリックで行う必要があり、残りはプログラムによって検討および実行される必要があります。レポートとその準備は、作業中の他の人の邪魔をしないようにしてください。 理想的には、これは、必要に応じてバグ追跡システムのフィードバックが表示されるプログレスバーのチェックボックス\スライダーをクリックすることです。 これは常に可能であるとは限らず、一元化されたプラクティスがない場合は想像を絶する松葉杖で抜け出す必要がありますが、報告コストを簡素化し、テクニックを信頼する必要があります。そもそも対象分野を把握する必要があります。 少なくとも専門家を仕事からそらさないため。

アンダーフロー

コンピューティングテクノロジーへの信頼に加えて、人を理解するテクニックを指導する必要があります。 マネージャーの例によって教えられた、後続のプロジェクトの1つで日報を作成しました。日中に行われたすべてをリストすることに加えて、計画されたものと自動的に比較されましたが、実際のタスクの前に成功と失敗のみを置くだけで十分でした。 しかし、なぜなら 割り当ては1か月間の部下として私のために計画されました。仕事をより速く、より効率的に完了したとき、私はこれを報告書に反映しました。 「今日は5つのモジュールが作成されており、計画中の40のうち11は準備が整っています。」 そして、新しい週の初めに、仕事が2倍速く終わったことを報告したかったのです。 マネージャーの美しいスケジュールは「計画済み」と「完了」で楽観的に分かれており、さらに上昇します。 レポートはチームリーダーを通過し、進捗状況があります。いつ、何が行われたかは明らかです。 しかし、プロジェクトマネージャーによる毎週のブリーフィングは、私に電話して質問をする理由であることが判明しました。 一ヶ月？ なぜここにいるのですか？」 仕事が明日行われるという正当化は、誰にとってもほとんど興味がありませんでした。 彼らのそのような「計画された」スケジュールは、私の動機、つまり新しいタスクを実行する能力を表しています。 私は立ち止まって、何が悪いのか考えました。 まず、管理者は、計画する際に、しばしば最悪の例に導かれて、リスクと期限を定めます。 そして、従業員の最悪の例の代わりに、彼らが優れた専門家であることが判明したとき、彼らは常に結論を導き、マネージャーに彼らの肯定的な評価を与えるために急ぐ必要はありません。 特権と役割の分離のためではありませんが、大きな絵を見ることができない場合があります。大きなポジティブな飛躍は大きな船の穴にパッチを当てるだけで、プロジェクトを元の計画されたチャンネルに戻すことができます。

間違いから学ぶとき、やる気を失い、レポートは単なる義務であり、日常業務であるだけでなく、リーダー、プログラマー、テスター、システム管理者、そしてもちろんマネージャーの仕事のための鋭いツールであることを理解することが重要です。 必要なのは、それを入手してその場所に適用するだけです。 私の報告経験の真髄は、プロジェクトのロードマップを作成することでした。

ゼロ除算

ロードマップは、作業対象のすべてのモジュールのリストでした。 タスクのステータスを記録することだけが必要でした。 1日数分。 それ以外はシステムがそれ自体を行いました。 誰が、どの程度、何を、いつ、どのような進歩、どのような傾向、どのような問題、どのような計画、どのような調整された計画、効果などを行ったかを数えました チームメンバが行う必要があるのは、モジュールをクリックして合格と不合格を設定することだけでした。その後、リーダーが進捗をMSプロジェクトに移動し、必要に応じて修正するように、必要なすべての情報を含むリーダーのレポートを生成することができます必要だと思う。

プロジェクトは簡単ではありませんでした。通常の検証と完了の場所では、電気回路を調べ、電圧、電流強度を数え、回路の破壊/閉鎖の結果を見て、そのロジックとコードへの影響を転送する必要がありました。 幸いなことに、その時、趣味として、夕方に電気工学とはんだ付けされたボードに興味を持ったので、ADC、ポテンショメータ、電圧フェーズでさまざまな操作を行う回路は私にとってあまりにも曇っていませんでした。 しかし、これは私の仲間のプログラマー、特に1人の新人に説明する必要があります。 したがって、このようなタスクにどのように対処するか、リアルタイムがどれだけ必要か、設定された要件と期限に対するコストはどれくらいかを評価することが非常に重要でした。 そして私の幸福に、同時に私の休暇が来ました。 私がいなければ、私の推定によると、同僚は1週間かそれ以上でタスクを完了していました。 毎日更新を行い、ボスに情報を提供するよう指示する。 私は魚と2週間静かに泳ぎ、ワニに餌を与え、すべての問題を頭から完全に捨てました。 しかし、到着すると、予期しないことが私を待っていました。 上司は先輩たちを他の戦線に移し、すべてが予想以上に順調に進んでいるのを見て、このプロジェクトには初心者しか残しませんでした。 私が到着する前でさえ、新参者は私が予想したようにすべてを行い、正直に報告書に記入しました。 しかし、当局にそれを示す前にのみ。 つまり 上司を表示する前に、毎日のデータで算術平均をスコアリングしますが、一度だけスコアリングします。 そのようなデータは絶対に役に立たず、結果を示すだけでしたが、私たちが1日1週間にどれだけ、どのように（モジュールの複雑さを含めて）するかについてはまったく言いませんでした。 そして、これは深刻な問題となっています。 次の反復にはどれくらい時間がかかりますか？ 生産性の成長の見通しはありますか？ モジュールの複雑さは大きく異なりますか？ 新しい方法とアプローチをどのように学びましたか？ レポートのすべての可能性が失われ、前の例のように、最悪の場合のおおよその評価しか提供できませんでした。

このことから、私は教訓も学びました。通常の統計ではなく、評価と調査が必要な場合、過去のデータの変更を許可することはできません。 関連する。 したがって、これは要求され、リマインダー、強制された方法または制御が必要です。 テクノロジーによってリスクから保護されていても、プロセスシステムは人間のリスクから保護されていないため、予測して強制する必要があります。

理想的なレポートシステムとは何ですか？

おそらく、最善の解決策は、もう一度SMARTを使用することです。

特定の目標（ 特定 ）、その測定可能性（ 測定可能 ：モジュール、タスク、機能、テストなどの数）、および達成可能性の柔軟性（達成可能：このモジュールの存在、それを処理する能力）状況と時間の要件に応じて、その関連性のパラメーター（ 関連性 ：この問題について特定の方法で報告する必要性）を設定します（ 時間制限 ）。 これは、バグ追跡システムで優先度（低、標準、高、緊急）によって測定されるものです。 そして、更新が行われる方法と順序を決定します。

レポートの階層とは何ですか？

毎日報告してから、毎週および四半期ごとのレポートを生成します。 レベルごとに、システムを決定します。

タスクレベル：

原則として、タスクは他のサブタスクとステップがない原子量です。 タスクに優先順位が付けられている場合、（プロジェクトのタイミングに関係なく）スタンドアロンの方法で実装のタイミングを決定し、特定の動作とそこからのレポートを必要とします。 たとえば、優先度の低いタスクは時間をかけて延長でき、優先度の高いタスクは数分または数時間ですぐに完了します。 ただし、タスクが個別のレポートを超える時間を要する場合、タスクに関するレポートが作成されます。 奇妙に聞こえますが、実際には、「私は現在取り組んでいます。整数変換が実装されており、フロートはまだ進行中です」などのバグ追跡システムの登録解除です。 システムが存在しない場合、テーブル内のコメント、またはテキストファイル\レター、最後のコミットなしでタスクが実質的に信頼できるもの。 これは、プロジェクト全体に影響を与える前に、すでに解決済みと見なされているものを閉じずに問題をキャッチしないために、まず必要です。 Jira、Redmine、Bugzilla、Trac、GNAT、メールスクリプトを使用し、それを使用し、口頭で落胆しないでください（管理者はそれを任せない場合があります。または、忘れられて歪んだ数字と名前の最終報告で遅れた言及。

ロードマップレベル：

通常、これは、今日のXのうちYで作成された種の日報です。 新しい\古い\合計。 その目的は、タスク制御、タスクの複雑さの評価です。 これは、今日の更新（更新）タスクからの絞り込みです。 理想的には、システムのチェックボックス\問題への変更に基づいて自動的に生成されます。 これらのレポートの分析により、最も説明責任のある従業員、過去の彼の成長、能力について話すことができます。 これは、リーダーだけでなく、必要に応じて分析に基づいて、そのような一連のレポートに基づいた実際の有効性と開発の進捗状況を提示できる従業員にとっても重要です。 さらに、従業員自身の保護でもあります。 正式には、彼が働いているのは上司からの保護紙であり、ハッキングしませんが、これはリーダーシップの端末のスーパーコントロールの場合です（これは私たちが望むよりも頻繁に起こります）。 繰り返しになりますが、サービスにはバグ追跡システムとProjectやSAPなどのモンスターのようなプロジェクト管理システムの両方がありますが、最も単純なケースでは、特にオフィスとの関係が追加されたOutlookの機能も動作します。 不要で高価な山で5分間のビジネスを複雑にしないでください。

プロジェクトレベル：

通常、これは週次レポートです。 従業員が何に取り組んだか、彼がどれだけしたか、どれだけ残っていたか。 その目的は、プロジェクトの現在の状態を評価し、期限、計画、およびリスク管理を満たすことです。 これは、会社によって確立された形式の正式なレポートであり、通常はリスク、問題、解決策、および計画を示します。 自動化ツールを使用して、一般的なオフィスアプリケーションでテンプレートまたはテンプレートを生成します。 一部のバグ追跡システムにはすでに同様の機能がありますので、軽視しないでください。

分析レベル：

四半期ごとの進捗レポート。 これは、時間と効率を費やしたすべてのプロジェクトのリストです。 その目的は、管理と戦略的計画です。 多くの場合、プロジェクトの視覚的な視覚化をガントチャート、分析用のグラフ、およびこれらのグラフが構築される計算の形式で表します。 推奨事項と結論が含まれています。 それらのベースは、プロジェクト管理システムまたはバグ追跡システムから引き出すことができますが、実践が示すように、分析用のツールは常に不足しています。 はい、そしていくつかの問題はワークフローに書き込むことができません。そのため、そのようなレポートは記事や小さな研究に似ています。



これは、一見したところ、実際には報告する人がいないスタートアップには当てはまらないかもしれません。 しかし、彼らとフリーランスの両方で、あなたが知っているように、それは良い自己制御と自己管理の動機を与えます。 そして、頭の中ではなく、おそらくクラウド環境で同じバグ追跡システムにアクションを保存する方が便利です。そうすることで、時間の経過とともに、決定とその結果を追跡して見つけることができます。 そこに目標を設定-労働者と彼らの開発の個人的な目標。 成功と成長を喜び、失敗と困難を分析します。 また、管理者に何ができるかを尋ねるのではなく、管理者に何ができるのかを尋ねてください。 毎週、週の最後の営業日が終わると、私は統合レポートを作成し、習慣を失い、新しいプラットフォームの知識不足に関連するリスクを黄色で強調しました。 一週間。 月 二。 そして思いがけないことに、上司が私に電話をかけて電話にうなりました。「ねえ、効率を上げるために何ができる？ 手動で読むだけでは不十分ですか？ タルサはもっと速くすべきですか？」 私にとって、この項目はレポートでは重要ではありませんでした。 彼はレポートからレポートへとさまよい、私は自分のために働いており、マニュアルやフォーラムに取り組んでいると報告しましたが、目を閉じたままでタスクを完了できません。 しかし、当局にとっては、これは少なくとも小さいが、ロバに押し付けがましい痛みであることが判明した。 効果的で環境に優しいレポート全体、すべてが時間通りに、すべてがうまくいくように思えますが、1つのフレーズは、私が扱っていたオーガスの馬小屋の牧歌的な楽園を台無しにしました。 そして、氷が壊れ始めました。 シンプルで控えめ。 上記のソリューションを提供されました。 真実は東で話されており、緑茶のグラスを飲んでいます：「千人の旅は一歩から始まります。」 そして、私にとってのこの道は、フィードバックの存在のために、いつの間にか通り過ぎました。

レポートは会社のスタイルによって大きく異なりますが、私の結論は同じです：毎日のスタンドアップミーティング、論文のレポート、プロジェクト管理システム、バグ追跡システム、朝のお茶を飲む間の会話、レポートは規制に大きく役立ちますプロジェクトのステータスと企業の実行可能性。 最終的には、小さな従業員でもグローバルな何かの一部を感じることができます。 しかし、それは目標として、また従業員が小さなリーダーから優れたリーダーまで、効果的な仕事と理解のための構造、彼が報告する理由と対象、およびこれらのレポートの使用方法として実現する必要があります。

分析

この記事を書く過程で、私は私の愛する人に尋ねました：「なぜ私たちは報告が必要なのですか？」。 私は、「制御と分析の道具」または最悪の場合「文書化」のカテゴリーからのおおよその回答を望んでいました。 しかし、答えは得られました。「はい、必要ありません。 いいえ、もちろんそれらが必要であることは明らかですが、実際には時間を無駄にする以外は役に立ちません。」 それは誤解でさえありませんでしたが、上司を見せない限り、彼らが通常それらの使い方を知らないという事実でした。 しかし、上司は通常、それらを製品へのアプリケーションとして使用することはありません。

次に、レポートの使用の具体例を示します。

状況1.「生まれ変わったバグ」

おそらく、マーフィーの法則の1つを知っています。「 エラーのパリティの特性。 書かれたプログラムが正常に動作した場合、これはその作業中に偶数個のエラーが完了したか、プログラマーがタスクを理解しなかったことを意味します 。 残念ながら、これは私たちが望むよりも頻繁に起こります。



一部のタスクは、多大な時間の投資を必要とし、必ずしも完了する必要はありません。 したがって、バグをキャッチしている間、新しいリビジョンの1つが修正前に機能するようになり、バグは表示されなくなります。 開発者は、これ以上バグがないことを報告します。 ただし、最初のバグの原因は解決されず、しばらくしてから新しい修正が行われます。 ただし、これは開発者が混乱して何かを見逃したという意味ではありません。 彼には支点と防御があり、強力な議論があります。 彼の観点から、タスク-バグの影響を除去する-は完了し、コードは仕様に従って動作し、テストは合格です。 しかし、プロジェクトでは、このタスクを再発見して、バグと補正要因の両方をクリーンアップして、将来的にテールを持たないようにすることができます。

ケース2：「生産性」

通常、レポートは通常、プロジェクトマネージャーとタスクリーダーが必要とします。タスクマネージャーは、パフォーマンスに応じてタスクを配布し、ダウンロードをスケジュールします。 彼女は何とか数える必要があります。 しかし、生産性は従業員の効率と能力開発の尺度でもあります。 各従業員が週次レポートをタイムシート形式で送信することを覚えていますか？ 次に、彼が時間をかけてタスクにどれだけの時間を費やすかを見てみましょう。



ここで何が見えますか？ タスクの完了には1日あたりかなり安定した時間がかかりましたが、経験が蓄積されると、タスクに費やす時間が減少し始めました（ポイントA）。 自動化ツールの導入後（B）、デバッグ段階がありましたが、最終的にはタスクに費やされる時間が削減されました（C）。 ここでは、仕事の改善を伴う従業員の改善と成長、彼のイニシアチブを見ることができます。 この例は、従業員が自分自身にヒロイズムを帰するまで十分に活気に満ちています。 しかし、幸いなことにバグ追跡システムまたはロードマップは、実際に完了したものを追跡します。 したがって、単に抽象的な例として、完了したタスクの数の逆数に毎日の所要時間を掛けることで、このような分析を改善できます。



グラフは破れていることがわかりました（私はそれを偽造し、悔い改めました）が、自動化統合の傾向と影響を示しています。 得られた結果からの経験的データの分析は、この記事の主題ではない別のトピックです。 しかし、報告メカニズムの関与により、従業員と雇用主の両方が有効性を評価するための優れたツールを使用できます。 トレーニングに費やされるリソースの推定値を追加すると、他の興味深い結論を導き出すことができます。 いずれにせよ、分析と評価のために、ログ（レポート）作成メカニズムの可用性は非常に役立ちます。 人々をやる気にさせ、報告に関連する活動によってどのような機会がもたらされるかを伝えることだけが残っています。

結論

レポートの利点を説明し、ロギングシステムを実装する方法を見つけることに加えて、各従業員に個人的な時間管理を導入することは素晴らしい習慣です。 まだGTDを使用していない場合は、タスクを削除するのがどれほどクールでいいかを教えてください。 彼らは完了しました、結局のところ、利益です！ このテーマのジャングルに入らないで、問題からの乾燥抽出物に加えて個人ファイルで分析を補足することのみを目的とします。 従業員を正直にしましょう。 彼らに毎日のレポートを書いてもらいましょう：「私は3時間タスクに取り組み、4時間Pythonを勉強しました。」 悪くありませんが、ああ、私たちは1時間を失いました！ 実際、お茶を飲むのに20分、サーフィンに30分、同僚との論争に10分を費やしたという研究に進むことができます。 しかし、本質的に、これは個人情報です。 Trashy time、これは...しかし、やめてください！ 私たちの仕事は、不作為の従業員に有罪判決を下すのではなく、彼のやる気を起こさせることです。 彼は、実行されたタスクの数だけでなく、自分自身の日々の仕事にも進歩を見た。 そしてリーダーシップに関連して-誠実さとオープン性、それにより信頼と責任のある権限の委任に基づいて構築された対話があります。 結局、ある時点で彼は「私は勉強した、Pythonを勉強した、そして今、私のプロジェクトを取りたい」という言葉であなたのところに来ました。

記事のPS、財務報告、監査、および人事報告は根本的に影響を受けません。 これらのレポートは、開発者に関連したり、開発者が実行したりしないでください。 逆の場合は、管理上の問題の兆候でもあります。 たとえば、エンタープライズモードで厳しい時間管理が必要な場合は、自動アクセスシステムまたは秘書のEllochkaという開発エンジニアの時間を引き付けることなく、これを行う必要があります。 財務報告に開発エンジニアの署名が必要な場合、これは企業報告部門または会計担当者のElvira Mikhailovnaの関心事でもありますが、サイボーグの技術専門家から2.5リンクのプログラマー会計リスクマネージャーを作成する理由はありません。