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

前回の記事では、エンジニアからリーダーへ。 パート1：正義感正義感について話しました。 彼女に戻って、正義感が基本的なポイントであることを繰り返したいと思います。 そして、何かを話すことを考えた場合、私のあらゆる不正確さ、さらには嘘、事実に裏付けられていない意見、つづりの間違い、動揺が彼らの不満を感じるでしょう。 実際、ここや日常生活で観察できること。 ホリバーの特定の側面（パラダイム、標準、プロセス）を順守し、一部の人からカフを受け取り、他の人からサポートを受けることは1つのことです。 また、独自の視点、経験、スタイルの維持について説明し、それに従うことはまったく異なります。 これは、ゲームのルールが知られている地雷原に似ていますが、あなたがするすべてのことに対して、あなたは責任を負います。 エグゼキュータとリーダーの間にも同じ違いがあります。リーダーは、ミスの場合、マニフェスト「不正」のためにキックを受け取り、ミスをした場合、彼の後を追う人を救いますが、多くの衝突を打ちます。 したがって、私の理解では、従業員レベルからコーンを事前に満たして、体の柔らかい部分で道を感じ、後ろから余分なキックを受け取らない方が良いです-しかし、主なことは遅れることなくリーダーに逆行しないことです。 そうでなければ、あなたは馬を保持します。 この記事では、適切な目標を設定する方法と、他の人と協力して作業を行う方法について説明します。

友情は魔法です！

かつて、悪い秋の日に、彼らは私を他の国に呼び、誰かのプロジェクトで他の人々の問題を解決しました。 言語の壁に加えて、技術的な壁を解決することも必要でした。 どのようなプロジェクトを手に入れたのか、その中ですべてがどのように機能し、何をする必要があるのか​​、私にはまったく分かりませんでした。 一つだけ言われました-あなたは、適切な品質と確立された基準でモジュールのセットを時間通りに引き渡すように招待されました。 私にとっての設定作業は完全に普通で理解可能であり、私の経験と知識が簡単になり、不足していることは、数日を費やさずにマニュアルとデータシートを読むことで解決できました。 しかし、実際にコードに記述する必要があるもの、仕様の理解方法と読み方、およびそれに基づいて構築するアーキテクチャ、UMLモデルで見たフレームワークとの関係についてはわかりませんでした。



幸いなことに、この問題を解決するために、Maynulという名前のシニア開発者が紹介されました。 メイヌルは明らかにバラモン一家の出身で、非常に友好的で訓練を受けた、インドから来た賢明な人でした。 インド人と手に会わなければならなかったのは初めてでした。 遠く離れた場所ではなく、バンガロールがコードを入手してケーキのテストを行い、そこから次のラマナママシャカティの魔法の数字3、9、24で明確な結果が出ましたが、彼の職業のエリート代表はここに住んでいます。



-こんにちは、元気ですか？

-わかった。 どうやって書くのですか？ 開発はありますか？ モデルに何かを追加できますか？



彼は私に、このように書く必要があると答えました...そして彼は私に彼のコードを持ってきました。 まあ、彼のコードがインド人であると言うことは何も言わないことです。 その中で、現在の要件から一定のタッチがありましたが、次の種類の構造は恐ろしいものでした：

sint16_t Temperature = nInTemp; bool_t Sign = TRUE; Sign = Temperature >> 15; if (Sign = TRUE) // do something // and do a little bit more else if (Sign == FALSE) { // do something }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いくつかのことがまったくコンパイルされませんでした。 私は行方不明になったと書きました。少なくとも標準に違反してコンパイルしないように彼の小さなショールを修正しました。 その後、私と彼の間で仕様に矛盾があり、彼はヒンドゥー教のアプローチも提案しました。 ヒンドゥー教のコードが動作しているのを見ました！ 彼は私がインドのコーダーの偏見を信じるようにすべてをしましたが、彼は私の鼻の下で踊りませんでした。 しかし、疑問が生じ、蓄積され、インドの決定は私に合わなかった。 したがって、ある日、私は彼に言った：「私たちは問題を抱えている、それを解決しなければならない」。 そして、次のことが起こりました-Maynulは、Shivaに引き継がれたかのように、仕様を書いて解釈した人、マイクロコントローラをはんだ付けした人、数学モデルを実行した人など、専門家を連れてきました。 そして彼らは私に答えをくれました。 彼は、これがどのように機能するかを知っている人々を見つける方法を知っていました。 1つのチームの人々。 私は州全体から千軍を知らなかっただけで、一般に誰にも近づくことは難しく、説明には多くの時間がかかりました。 そして、私は理解しました。 私は彼に私の問題と責任を与えました-人々のメカニズムのデバイスを見つけるために、そして彼は彼自身をカバーしました-適切なコードを書きました。 すべてが機能し、4つの統合を選択して3週間でプロジェクトを終了しました。



リーダー- デリゲートに関するルールがあります。 しかし、実際には、時計のように誰もが自分の場所を持っている合理化されたチームにいない場合でも、これをうまく行える人に任務を委任することもできます。 普通の従業員の観点からでも。 効率的に機能しますが、無料であることを意味するものではありません。 指示を与えることで、特定のコストと責任、場合によっては計画段階で追加のコストと責任を負います。 イニシアチブを取り、パラダイムに関係なく、あなたが持っている意見に耳を傾けます。



リーダーの側では、あなたの従業員を信頼し、彼らは通常、より良い情報を与えられ、彼らは誰に仕事を与えるべきかをよりよく知っており、彼らは誰が最大の熱意を示すかを知っています。 選択を委任し、責任を委任します。 従業員のために働くことを恐れないでください。現時点で重要なこととその修正方法を伝え、楕円形のオフィスでの会議ではなく、同じ職場の作業プロセスでアドバイスを与えてください。 他の人の仕事をしないで、誰にとっても有益な方法で配布してください。 突然従業員の能力が不足した場合、この問題をどのように解決するか、問題を解決するために必要なことについて意見を聞いてください。 あなたが言うよりももっと聞いてください。 そして、独自の厳しい、ユニークなソリューションを提供してください。 委任したら、仕事への貢献、動機付けの重要性を評価し、好転して自分自身を示す機会を与えます。 人と方法、仕事の遂行を動機付ける方法、独立を奨励する方法（「劇場」のロリポップまたは成功の転がる豪華なお守りでも）を探し、助けてください。 この本に助言し、放映することを勧めますが、いかなる状況でも決して従業員のコードと仕事に登らないでください。「十分な」基準でスローダウンせず、設定された時間枠で彼を良いコードの尺度にしてください。

目標設定

リーダーへのアドバイス、オリエンテーション、およびソリューションの両方を正しく提供し、開発者にタスクを策定するには、タスクを正しく設定する必要があります。 しかし、タスクを設定する方法は？ まず、 SMART方法論があります。 第二に、タスクが理解可能であるためには、相手もそれを理解しなければなりません。 これは、タスクを設定する人が理解の正確さもチェックしなければならないことを意味します。最も単純なケースでは、実行者からタスクのステートメントを繰り返します。 タスクを最も簡単に理解し、エラーなしで再現できるようにするには、できるだけシンプルにする必要があります。 必要に応じて基本的な部分とステップに分割され、視覚的であるため、タスクの構造が複雑な場合は、簡単に紙に描くことができます。



私の実践では、次のようにプロジェクト全体で非常に重要で重要なタスクを与えられた場合がありました。「重要なモニターのセットが必要です。 理解してみてください。」 さて、どのようなモニターリストが必要かを明確にする必要がありました。 他のすべては専ら私の設計決定でした。 まあ、少しで1週間以上、私はクラスの構造全体を考え、迅速な方法とアラートシステムを作りました。 既製のインターフェイスで接続された既製のモジュールがありました。 しかし、変更の前日、私はすべてをやり直さなければなりませんでした。 コードレビューの後、私よりも3倍広い身長の恐ろしい上司から、エラーとモニターは異なるクラスに実装する必要があると（エラーに1つのフィールドがあったとしても）通知され、スピードハックを使用する必要はないため、ビット演算と1ワードのビットへのエラーパックはまったく必要ありませんが、エラーごとに個別のintを使用する場合は、一連の視覚的なスイッチ\を使用する必要があります。 一般的に、監視の問題は懸念事項で長い間解決されていたことが報告され、完成したコードを繰り返すのが私の仕事でした。 ただし、インターフェイスは異なりますが、不要なメソッドを削除し、可能な場合はインターフェイスをゼロでミュートします。 原則として、適切な場合にはリファクタリングに反対しませんが、タスクが「あなたの設計決定」から比類のないプロジェクトの「古いいまいましいコードを使用する」に変換されると、残りの1日間の実行段階で混乱します。 そして、最も興味深いのは、私がこの点で間違っていたことです。 ゲームのルールを決定する必要がありました。

技術仕様

最良のアイデアは、次の考慮事項から仕様を作成することです。

• 仕様には、決定的な一連のアクションと条件を含める必要があります
• 仕様要件は、必要に応じて親タスクまでとサブタスク（アクション）まで追跡する必要があります。
• 各アクションは基本的であり、異なる解釈を許可してはなりません。
• 仕様には、紙または疑似グラフィックで簡単に説明できるシナリオまたは関係図を含める必要があります。
• 仕様は、開発者に設計とツールの質問を残して、疑似コードまたはアクションと指示のシーケンスであってはなりません。
• 理想的には、1つのアクションが1つのテスト（または、プログラムコードの問題でない場合はテスト）でカバーされるべきです。
• 上記の結果は、検証不可能な非機能要件（ツールの説明）が仕様にないことです。

良い仕様 ：

 11. RAM Functionality [Requirement ID 111] [Actual Baseline 1 \ Iteration 8] [Parent requirement 11] The functionality of the RAM devices shall be tested by a write / read test of at least all used memory locations. [Requirement ID 112] [Actual Baseline 1 \ Iteration 8] [Parent requirement 11] In case of detecting a RAM fault, the unit shall be halted.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり アーキテクチャにおける仕様の場所を理解でき、2つのアクション（スクリプトを実行）の2つのテストでカバーできるアクションのセットがあります。

1. エラーなしの場合
2. エラーケース

読み取り/書き込みテストの実行方法とCPUの停止方法を書きませんか？ まず、開発者にこれを行う方法を決定させます。 第二に、テスターに​​ついて考えてみましょう-それをテストする方法、そして1つのテストが必要な場合でも？ または、さらに悪いことに、CPUシャットダウン機能をテストするにはどうすればよいですか？ 常に詳細に取り組むのは良いことではありません。 低レベルの要件であっても、テストの作成を可能にする抽象レベルを維持し、テスト不可*とマークされたコードのレビューに限定されません。 （*ただし、同じユニットテストのブラックボックス原則は常に可能であるとは限らないため、データシートへのリンクを提供したり、放電カテゴリの非機能要件や、EEPROMが安全に書き込まれている間にISRを停止するなど、アセンブラー命令を使用する必要性を説明したりすることは理にかなっています。可能であれば、明確化は避けてください。この実装では、10個の近似関数のどれを使用する必要があります-これは論理的に仕様に準拠する必要があります。



悪い仕様 ：

 Fault machine [Requirement 31] [Actual Baseline 1 \ Iteration 8] [Parent requirement: 3, 5, 7, 8, 9, datasheet 23 page 5] System shall catch and store all errors in None-Volatile Memory. Errors shall be stored as follows: 1. Set IE to OFF; 2. Write Date; 3. Write Time; 4. Write Error ID; 5. Write '\0'; 6. Set IE to ON;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

逆の例。 どんなミス？ オーバーフローは間違いですか？ センサーのしきい値を超えました-エラー？ 最後にバグシートがありますか？ キャッチする方法は？ いつ？ 毎秒来るメッセージがあります-それぞれをチェックする必要がありますか？ そして、受け取りを待っている間？ 次に、保存の詳細を説明します。 フォーマットを説明する必要があります-これは良いことですが、すでにアルゴリズムを作成しており、開発者をエンコーダーに変えています-それが必要ですか-二重の仕事をしていますか？ また、テスターは一連のアクションをどのようにテストしますか？ 特に設定レジスタ。 デバッガー？ しかし、ブラックボックスはどうでしょうか。 はい、冗談です！



仕様は、アーキテクトが対処すべきような一方的なものではありません。 開発者側では、これは同じテスターのコードの機能と動作の説明です。 テスターの側から-実行中にエラーが発生したシナリオ、または標準に違反したシナリオ、開発者が理解できる参照、最終的にはテストケースと環境の説明です。 頭の部分-技術的な問題の明確な声明および/またはそれらの説明。 プロセス。 考えを正しく説明してください。シナリオと関係を記述するために、必要に応じてスタイリスト的にサブステップに分割できるように構造化してください。 これががらくたの場合、あなたは直接、「このくずの山を作り直しなさい」と書くべきです。もちろん、あなたが正しいなら、あなたの立場は合理的であるという条件で。 適切な仕様を作成するには、作成を練習します。 1日に少なくとも半ページはテキストを書きます。 ブログへ、コミュニティへ、テーブルへ。 考えを書いて、元のメッセージで聞いたり受け取ったりできるように考えてください。 少なくとも家でコイルを作る複雑さについて、少なくともポニーの柔らかいたてがみについて。 猫のテストを確認して読み、階段の吹き抜けやインターネットで掃除の計画をたてましょう。苦労する時間がありませんでした。 あなたの仕事は、できるだけ簡単かつ正確に考えを伝える方法を学ぶことです。 一 二。 三。 私の場合、メッセージは既成の「ベストプラクティス」のセットではなく、新しい状況に陥った開発者の目を通して私自身の経験からの例である、私と一緒に反省し、通常のプロセスを見る呼び出しです。

タスク設定

技術仕様がコードに近い場合、タスクの設定はどうですか？



悪い仕事 ：

 Create input monitoring functionality urgently.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

良い例には、一連のアクションを含めるか、ロードマップで完全に説明する必要があります。

 Try to integrate last application release (from SVN) till Friday 13 in the following way: 1) Build new framework 2) Build new application with the new framework 3) Run tests 4) Run all benchmarks 5) Report to Jira If one of the steps breaks, try to re-check its default settings, and if all is correct, then report status.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

適切な割り当ては次のとおりです。

S ）具体的（正確には何をしているのか）

M ）詳細、したがって測定可能（この例では、タスクがどの段階にあるかを確認できます）

A ）理解可能で十分（この例では、SVNで最新のソースを使用し、特定の環境でアセンブリします）

R ）前のステップが正常に完了した場合、各アクションは関連しています。 テストが突然失敗した場合、パフォーマンスをテストすることは意味がありません。 さらに、アセンブリが合格しなかったかどうかをテストするものはありません。

T ）時間の制限（期限に間に合い、プロジェクトを同期するため）。







つまり 私の場合、Meinulへの指示は、「今日、同じ識別子（M1）の2つのメッセージが到着し、バッファーがいっぱいになったとき（T）アプリケーションレベルA429インターフェースのARINCメッセージバッファー（S）を処理する方法を学ぶ必要があります（ M2）。 これはタイミングエラーが原因である可能性があります。ハードウェア®の動作を確認してください。



これらすべてが、最終的に、請負業者と管理者（または顧客）間の対話を構築し、記録します。 タスクが明確でない場合は、アトミックフレーズに言い換えるまで質問してください。 理解したい場合は、このタスクがどの程度理解できるかを尋ねてください。 開発者はどのようなソリューションと提案を使用したいのか、また、彼はアーキテクチャ/プロジェクトのどこに見ているのか。 仕事に取りかかる前に同意し、計画してください。 まず第一に、これは双方がゲームのルールを採用しているため、最終的に不満を避けるのに役立ちます。 これにより、コードがすでに「十分」であるという無限の変更やin辱からあなたを救います。 これにより、質問が保存されます。 すべてのルールと回答は、マニュアル、wiki、およびタスクまたはそのプロセスで説明されているすべてのものにあります。 これは、最終的に、理解しやすいレポートにつながり、実行者の保護とリーダーの議論の両方になります。



レポートの利点とそれらが必要な理由については、次回で説明します。