手配管理

手配の管理について話しましょう。 なぜこれが突然なのでしょうか？ はい、 TeamLead Confでは痛みや問題について話し合うのが大好きですが、解決策を忘れないでください。 確かに誰もが仕事の手配に関連する問題を抱えています。

「アレンジメントは実装されていません」、キャプテンエビデンス

そもそも彼らとの苦労は、合意が満たされていないことです-この記事で私たちを助けてくれる友人のキャプテンエビデンスでさえ、誰もがこれを知っています。

問題は何ですか？ 私たちが望むように多くのことは進んでいません。 たとえば、晴れた日は必ずしもサンクトペテルブルクではありません。 それで、街が立っている、人々が来て、それを愛している。 思い通りにいかないのは、必ずしも本当に深刻な問題ではありません。

ただし、この場合、Stas Mikhalskyは、問題は深刻なものであると主張します。 カットの下で、合意が実施されていないという事実につながるものと、最終的にそれらを破壊不可能にする方法を理解します。


講演者について： Stas Mikhalskyは1998年からWeb開発に携わっています。 彼は、Perlの若手のプログラマーからBiglionの開発部長になりました。 彼は多数のプロジェクトの開発に参加し、多くの参加者を集めてサポートを提供しました。

なぜこれが問題なのですか

チームとチームリーダーとしての私たちのチームのビジネスとリーダーシップが結果を待っています。 タスクを時間通りに完了しても結果が得られない場合がありますが、これは別の話です。

仕事と結果は異なるものですが、これについてはまた別の話をしましょう。

結果は仕事の結果です-タスク、プロジェクト、サブプロジェクトの履行。 さまざまな分割が可能ですが、どういうわけか作業はいくつかのアクションで構成されており、各アクションは実際には合意の結果です。

それは思われる-すべてが明確です： アクションを実行しない場合、私たちは合意を破ります。

標準的な例を考えてみましょう。 コードスタイル標準への準拠は、特定の開発者との合意です。 チーム全員が「はい、賢明なKaa、コードスタイルを順守します」という1つの声で答えるわけではありませんが、誰もが彼がそれに従うと約束していると個人的に言います。 金曜日または月曜日にリリースを開始することも合意です。 私たちが何をするにしても、誰かがこれについて私たちに尋ねるか、私たち自身がこれが何かに必要であると決定しました。

-私たち自身がこれを私たちから期待していると判断した場合-これは合意ですか？
-はい、彼自身との合意ですが、これは特別な場合です。

ここで最も興味深いのは、実際には反対です：合意の失敗=アクションの失敗。

つまり、アクションが実行されない場合に合意が中断されることはありませんが、 実行されないアクションは、失敗した合意の結果です 。 私たちは同意しなかったので、そうしませんでした。 中央にあるのは、契約に関する問題です。 このように、合意に失敗すると、当然のことながら、仕事の質に影響を及ぼし、最終的に結果の欠如に影響する、満たされていない行動につながるという状況を把握します。

開発者、バックエンド、フロントエンド、テスター、チームリーダー、開発マネージャーはすべて、私たちが何かを行う機能と役割の一部であるという考えを伝えたいと思います。 しかし、もう少し高く見えるとすれば、 私たちの仕事はすべて、契約の締結とその実施です。 それはUDPのようなものです-他のすべては合意に包まれています。 契約を正しく締結する方法がわからない場合、優れたフロントエンドまたはバックエンドになり、優れたコードを記述できますが、結果はありません。

それどころか、正しい配置を作成する方法を学ぶと、次のようになります。

• 多くの時間を節約します。
• すべての制御、分解などのオーバーヘッドを大幅に削減します。
• 本当に仕事をすることができます。

どうする

「手配が実施されていることを確認する」

キャプテンの証拠

これは、エビデンスのキャプテンを含め、誰にとっても明らかです。契約が実施されていることを確認するだけでよく、契約が実施されないようにする必要はありません。

これを達成する方法の古典的なモデル：

1. 理由を理解してください。
   
2. これらの原因に対処し、結果を変えるための行動を特定し、実行します。
   

もう少し詳しく話しましょう。 3つのアクターがあります。

1. 対処する取り決め 。
   
2. 取り決めに生じる混乱 。
   
3. 失敗の理由 。
   

これをすべての側面から見ると、問題の内容と状況を改善する方法を理解できます。 状況に介入が必要であることを願っています、誰もが同意します。

アレンジとは何ですか？

取り決めは、コミットメントと約束の2つの部分で構成されています。 それらの違いは、 コミットメントが行われ、約束が行われることです。

約束は内臓であり、それは私が約束した誰かへのメッセージです。 これは単なる通知メッセージであるため、原則としてそれを与えることさえできません。 しかし、私はこの義務にコミットします。 したがって、約束のない約束は、約束のない約束よりもはるかに優れています。 後者に頻繁に遭遇します。

正直なところ、全体の問題は、合意を締結するときにすべて（および私たちも）ではなく、必ずしも義務ではないということです。 私たちは常に意識的に決定を下すわけではなく、この約束が私たちを脅かすものを本当に理解しています。 私たちはただうなずきます：「はい、はい」、私たちは去りますが、私たちは自分自身に対する義務を取り去っていません-これは大きな問題です。

実際、アレンジメントはタイプが異なるため、さらに複雑です。

• たとえば、 彼の直接の責任の一部として 、コードにコメントを書き、環境へのリリースを完了します。
• 主な仕事以外では、例えば、ウィキ内の情報の関連性を監視し、本を読み、コースに行きます。
• 動作を変更します 。たとえば、特定の時間に仕事を始めたり、タスクに費やした時間を追跡したりします。

これらは完全に異なる合意であり、人はそれらを異なる方法で扱い、完全に異なる方法でそれらを扱う必要があります。

原則として、主な仕事の範囲は質問を超えています。質問は、ある意味では、開発者の現在のコーディングレベルよりも重要だと思います。 人が学習方法を知っている場合、これは、10年以内にエラーなしで迅速にコーディングすることを単に学んだ場合とはまったく異なります。 開発者と本を読むことに同意することは、コードを文書化することを要求するよりもはるかに難しい場合があります。 しかし、行動を変えるということになると、さらに楽しくなります。

古典的な例として、以前は10または12に行くのは重要ではなかったが、もしあれば、それを遅らせて終わらせることができるが、今ではプロセスなどのために11時までに職場にいる必要があるため。 人が単純に同意する場合：「はい、明日11時に来ます」-これは行動の変化ではなく、偉業です。 このために、おそらく人生を立て直すことが必要であることが判明した場合、少し早く寝るか、Warcraftをプレイしないことが、それは人自身が変化しなければならないことを意味します。 それは困難であり、最も重要なことには、他のプロジェクトと同様に制御できません。

したがって、どのような合意について話しているのかを理解することは非常に重要です。 精緻化の程度は、どのようなタイプの契約を締結しようとしているかによって異なります。

混乱

契約が崩壊するだけでなく、最初に、予期せずに、そして次に、フィニッシュラインで崩壊します。 これは予想外ですが、通常は予測可能な時点です。 契約がいつ切れるかは常に知っています。

現在、私たちはチームで働いており、シングルやガレージコンピューターの時代は過ぎ去りました。 チーム、プロセス、およびすべてのアレンジメントがチェーン内にあります。 崩壊すると、すべてが崩壊します。 人が本を読んでいない場合、原則として、何も悪いことも壊れることもありませんが、1年後にはあなたのチームは突然、今より良くなることはありません。 私にとって、このファイルはすべてのシステムの2時間の障害よりもはるかに大きいものです。

中断も異なります。

失敗は私のお気に入りであり、最も正直で最も無害な種類の失敗です。 私たちは同意した、人は約束し、しなかった-それが起こる。 これは単純な内訳です​​。なぜなら、彼にはすべてが明らかだからです。

正式な実行など、より不快なオプションがあります。

正式な実行とは、金曜日の夜に開発者（インスピレーションを得るためのビールポッド用）が1週間で行ったタスクの作業時間を40時間に広げる場合です。 実際、あなたとこの契約を結んだ人は、現時点では何も受け取りません。 すべての人を釘に追いやるのではなく、さまざまな種類のタスクにかかる時間、平均的なエ​​ラーなどを統計的に把握するためにタイムロギングが必要な場合、そのような実行はイニシアチブ全体を台無しにします。 データはヘッドから取得されるため、統計はありません。 その結果、何かが行われたように見えますが、合意は満たされず、すべてが順調です。

問題は、正式な履行を破れた契約として常に登録するとは限らないことです。 特にあなた自身があまり興味を持っていない場合。 たとえば、私はチームリーダーで、監督は上から「時計を書いてください。そうでなければ、みんなを罰します！」と言った。 チームに来て、時計を記録する必要があることをブロードキャストします。そうしないと、全員が罰せられます。 結果として、時計は何らかの形で記録され、私は満足しています-監督に見せるものがあります。 私自身もこの妨害行為に参加していますが、私にとっては正式な執行が重要です。 タスクプロバイダーにとっては、受け入れられません。

置換は 、フォームの正式な実装とはわずかに異なりますが、本質的には、合意に違反するのと同じ試みです。 完了したタスクの可視性の代わりに、代替が作成されます。 時間ロギングの例を使用すると、次のように聞こえます。「各タスクの時間を記録するには、5分必要です。 合計で、これは週に2時間です。 まあ彼。 4時間以内に、意図しないタスクを実行しました。 しかし、私は約束した以上のことをし、ポーンタイムをしませんでした。

これは、テストを遅らせるための何かを提供する試みですが、実際には故障でもあります。 問題は、原則として、私たちには他にもたくさんのものがあり、安全でない時間は最悪のものではないということです。 私たちは自分自身を大目に見ています。

繰り返しますが、未解決の契約はマイナスの仕事、結果のマイナスです。

満たされていない取り決めの世界で生き残る方法は？

「時計を記録していることを覚えていますか？」 行動の変化に関しては、リマインダーは良いスキームです。 行動モデルをサポートする最もcなハングアップポスター：「約束された時間-ビーバーを救った！」。 実際、現時点ではそのステータスを確認せずに、合意があったことを思い出させます。

もう少ししつこくなり、その人がすでに何かをしているかどうか、契約がどのように実装されているかを尋ねることができます。 これはリマインダーとは異なり、何らかの明確な答えを与えることを強制します。 しかし、あなたはその人を選択の前に置きます：嘘をつくか嘘をつかないか。 ところで、答えは誰にとっても明らかではありません。 ある意味では、あなたは人を悪い人に押しやっています。 質問する-これは潜在的な制御形態です-質問されているようですが、チェックされていません。 男は嘘をついたが、私たちは彼の良心に任せた。

以下を確認できます。

• 結果により;
• ステップバイステップ;
• ダイナミクスについて。

すでに議論した結果による検証。 問題は、結果が不満足な場合にどうするかですが、後でこれに戻ります。

ステップとダイナミクスにより、仕事の内外で契約の履行を確認することができます。 たとえば、知識ベースに記入するように人を説得し、彼と一緒に計画を概説し、その計画に従って進めます-これはまだなくなっています。 しかし、行動の変化はどうですか？ 人は時間を記録するか、記録しません。 時間通りに来るかどうか。 この変換をステップとダイナミクスで追跡するのはばかげています。今日は30分遅れ、明日は25分、明後日は20分です。

検証の最大の問題は、これが常に可能であるとは限らないことです。 常に多くの人々と合意が行われていることを考えると、これも非常に労働集約的です。

マネージャーがほとんどすべての時間をタスクの実行の監視に費やす管理モデルが存在しますが、ITでの動作は不十分です。 はい、これは最後の世紀です。 最後の恐竜のように、そのような管理へのアプローチがいつか死ぬことを願っています。

制御するのではなく、故障が実際に発生する理由-約束を与えた人がそれを満たさなかった理由をよりよく理解しましょう。

内訳の理由

これはおそらく不完全なリストですが、最も顕著な例は次のとおりです。

• 不合理な同意。 拒否するのは恥ずかしいので、人は同意します。あなたは彼のリーダーであるか尊敬されている人であるか、あなたを心から助けたい、あなたが好き、または彼はまったく拒否したくないのです。
• 評価のエラー。 人は、考え、同意するが、評価を間違える可能性があります。 それから彼は来て言う：「はい、約束しましたが、仕事は私が期待したよりも二倍でした。」
• 優先順位の変更： 「ほぼ終了しましたが、その後、Vasyaが来ました。彼にはさらに重要な問題があるので、ごめんなさい。」
• リソース不足 -時間が足りません。
• 予期しない状況 -ピアノは上から落ちました。
• サボタージュ

多くの場合、すべての言い訳の背後には、 欲求不満の合意の王、妨害行為があります。 やりたくないし、やりたくないことを認めたくない場合は、妨害行為が行われます。 突く方法を使用してタスクのために週40時間飲むことは妨害行為です。 午前9時に仕事に来て、コーヒーを飲むのは妨害行為です。 これは、行うのを嫌がりに基づいていますが、明示的には表明されていません。

実際、 故障のより多くの体系的な原因があります。 私たちが言ったことは表面にあります、そして、あなたが深く掘り下げるならば、3つの理由だけがあります：

1. 考慮されていない配置のタイプ。
   
2. 取り決めのタイプは合意されていません。
   
3. 義務のない約束。
   

さらに、最初の段落と2番目の段落が同時に存在する場合があります。 契約を締結するとき、合意内容については考えません。 多くの場合、これは次のように聞こえます。

-エーゲウス、そう！
-OK、やります！ -そして逃げた。

これは、たとえば「28のタスクをすばやく実行する」モジュールの作成など、作業中の作業について話すときに行うことができます。 しかし、これは、たとえば集会での会議の準備に関してはできません。 良い方法では、会議でスピーチを準備するために、座って、それを整理し、それがいかに重要であるかなどを説明する必要があります。 しかし、多くの場合、すべてを同じリズムで実行します 。「これを実行する」または「もう遅刻しないでください！」- そして実行しました 。

契約の種類について異なる理解をしていると、私たちが同意することが起こります。 典型的な例は、コードのドキュメントです。 近年、すべてが変わったかもしれませんが、これに出くわしたとき、同僚と私は開発者がコードを文書化すべきかどうかについて絶えず議論していました。 リーダーとして、私はすべきだと思う。 開発者は、ワークロードと絶えず変化する優先順位を考えると、コードが機能することを確信しています。

取り決めの種類に関する理解の対立が常に明らかになるわけではありません。 私たちは、すべてがすでに明確であるため、この合意を明確にし、強化する必要はないとしばしば信じます。 部下は、彼がやりたくないことを上から望むと信じている。 そして、 妨害行為が始まります 。

私が言ったように、最も人気のある状況は義務のない約束です。 約束を生じさせたが義務を生じさせなかった合意は、何らかの理由で満たされません。ピアノが倒れ、人が気を散らされ、何かが起こるでしょう。

実際、システムの複雑さの状況、変化の激しさ：急いで書き込み、すぐに展開、やり直し、言い換えればエントロピーの状態では、合意の履行を妨げる何かが常に起こります。 もちろん、あなたはすべてのステップを制御し、各部下のすべてのケースを活用し、彼が私たちの契約の実施に来るのを助けようとすることができます。 しかし、そうすると、自分ですべてを引き出す以外に十分な時間がありません。

契約が履行される唯一の可能性は、人がそれを履行したいということです。

合意を達成したい場合は、すべての飛行の問題に対処します。落下するピアノ、評価を間違えたという事実などです。

これはスクラムのイデオロギーに似ていますが、タスクの複雑さは完全にはわかっていません。 私たちは、以前の経験でエラーを伴ういくつかの仮定を立て、評価し、それからスプリントを閉じるためにすべてをします。 はい、難しいです。評価のどこかで間違いを犯す可能性があります。システムが私たちを驚かせるかもしれませんが、問題を解決するためだけにそれを行います。

アレンジメントでは、スクラムのスプリントと同じことが起こるはずです。 何かをすることを約束した人はそれをしなければなりません。 すべてがシンプルです！

要約すると、合意の失敗の理由について言われたこと：

• 約束は保証ではありません。
• コントロールは難しいです。
• 失敗が明らかになります。

何をする必要があるかは明確です。管理しやすく、最後にバハマに行く永続的な取引を作成するだけです。

キャプテンの証拠

言い換えれば：

• 現状のまま-システムは次のようになります。管理が難しい、かなり壊れやすい配置です。
• あるべき-それはそうである必要があります：その管理は透明であり、面倒ではない不滅の契約。

標準的なGAP分析の状況では、「To Be」は私たちが目指している究極の目標ですが、到達するという事実ではありません。 しかし、努力しなければなりません。

強力な合意とは何か、それをどのように管理するかを理解することは依然として重要です。

強い同意

強い合意-これらは拘束力のある人と締結される真の義務です。 これは非常に重要です。 転送が必要な一部のパッケージなどの義務について話しました。次に、このパッケージの運送業者について少し説明します。

任意の人との取り決めは矛盾につながります。 バッチで異なる方向に送信される契約のストリームの形で作業を想像する場合、オプションの人と契約を締結しようとするとき、50％の確率で時間を失うという事実に備えてください。 したがって、まず最初に行うことは、単語の価格を上げることです。

ワード価格

同僚は、サービスの義務が彼らの主な仕事であることを理想的に理解する必要があります。 これが彼の作品の本質です。 書面によるコード、デフレートされたリリースは、履行された義務の派生物です。 したがって、私は特に義務について人々と話をしようとしますが、問題はコードが書かれていないことや結果がないことではありません。 これは結果であり、多くの苦痛です。 しかし、問題の本質は、自分自身をコミットしたが、それを実現する方法を見つけていないということです。

あなたがこれについて人々と話したことがないなら、これは概して、それほど明白ではありません。 これについて話すためには、最初にレポートの最初から「結果-仕事-行動-合意」のはしごを駆け抜ける必要があるかもしれません。 しかし、人々は核の合意とコミットメントのアイデアを得る必要があります。その合意は義務であり、もし取られたとしても、その義務は実質的に破壊されません。

おもしろいことに、これを伝えることができた場合、契約の数を減らす準備をしてください。 あなたは何も約束する可能性がはるかに低くなります。 あなたは合意を機能させようとしましたが、最終的には、10の約束の代わりに、3つしかありません。確かに、良い知らせは、それらが実質的に破壊できないことです。

各義務を果たす確率を高めることで、その数を減らします。

人々は客観的な理由で対処できないため、これは自然です-すべてを行うことは不可能です。 義務の数を減らすことは正常ですが、それらは本当に強力です。

そのような義務の束縛に人を巻き込むことが一般的に可能であるのは、それを侵害することも不可能である場合にのみ理解することです。

これにはいくつかの理由がありますが、本当の理由は雇用契約です：「あなたは私にお金を払っているので、これをすることを約束しました。」

機会は前提条件ですが、保証ではありません。 人が義務を果たせない場合、彼はそれを果たさないでしょう-それは明らかです。 これは注意すべき基準です。

欲望が主な理由です。 長い間、私は単純な考えを伝えるためだけにあなたの脳を膨らませました。

人は自分がやりたいことをやり、自分がやりたくないことはしません。

永続的な契約を本当に作成したい場合、私たちのタスクは、各契約の実装に人を関与させることです。

手綱手綱

J.ワインバーグによる「ラズベリージャムの法則」という本には、バイソンの手綱という、私が本当に気に入っている簡単なルールがあります。 著者は、バッファローを育てた友人がいたと書いています。 これらは健康で管理が不十分な動物です。 フェンスでさえも、それらをどこかに行かせないようにあまり役に立たない。 ワインバーグが友人にバイソンをどう扱うか尋ねたとき、彼は2つの部分からなる手綱を持っていると答えました。

1. バイソンはそこに行きたいならどこにでも連れて行くことができます。
   
2. そこに行きたくないなら、バイソンをどこにでも行かせることはできません。
   

トニー・ロビンスからほとんど引用されているにもかかわらず、それは理にかなっています。 あなたは乳母ではありません-彼の部下の後ろに行き、彼のすべてのステップを制御する人ではありません。 良い方法では、彼を行かせて結果を待つ必要があります。 あなたはコントロールパネルを持っていませんし、持ってはいけませんが、ほとんどの場合、すべての部下に持っています。 これはすべきではなく、人はすべて自分でやらなければなりません 。 これを行うには、彼は望みます。

「ブライドル」が強力になるように追加することが重要なものが3つあります。

• 取り決めは形式化されています。
• 人が関与しています。
• コンテンツがうまくいきました。

形式化

フォーマル化は、私たちが同意するプロトコルであり、一度設定する必要があり、それが機能することを確認し、彼らがそれを残していないことを確認するだけです。

合意が一方的に変わることはないということに同意しなければなりません。 Vasyaの優先順位の変更は、契約を一方的に変更する理由にはなりません。

取り決めを確認できるように、変更を即座に報告する必要があります。

微妙な点は、改訂の可能性に関連しています。 契約は修正できると信じていますが、これは抜け穴になる可能性があります。人がコミットメントを行い、管理していないと言い、期限を延期するように求めます。 実際、関係者はこの抜け穴を使用しませんが、一方で、彼は行動の自由と彼が追い詰められていないという理解を持っています。 義務を果たす唯一の機会は、問題が発生した時点で正しい解決策を見つけることであるため、人には柔軟性が必要です。 不安定な世界での義務の履行は常にタックです。

もちろん、義務には内容と期限が必要です。 コンテンツは、予想される「具体的な」結果です。 たとえば、動作が変更された場合、これはよく開発されたプロセスです。 友好的な方法で、行動を変えるという合意は、行動を変えることにあるべきではなく、行動を変える何らかのプロセスを経ることにあるべきです。 次のようになります。

-さあ、時間通りだよ！
-さあ。

しかし、別の方法でも可能です。「聞いてください、時間通りに来てください。 今週の時計に来て、10：55においしいカプチーノを飲みながら職場で待っています。 あなたが時間通りに到着したかどうかに関係なく、私たちは毎日掲示板に印を付けます。

仕事を始める5分前にコーヒーで遅れないように学ぶ必要がある人を待ちます-これは妨害行為ではなく、賄briですが、それは異なります。 したがって、アクションプラン、管理、評価基準があります。

そして、義務-これは重要です-行動の一時的な変化ではなく、この計画を通過することを指します。

人々を巻き込む方法は？

これは、すべてにかかっている最も重要な質問です：人を巻き込む方法？ 何かに同意する必要があるときに、スピーチを作成するための4つの質問があります。

1. なぜこれが必要なのですか？
   
2. なぜこれが必要なのですか？
   
3. するとどうなりますか？
   
4. そうしないとどうなりますか？
   

質問は異なる順序で進むことができます。 原則として、私は事前にそれらを調べます。 主なものは、人への私のスピーチの一環として、私はそれらの4つすべてに答える準備ができているということです。

会議の前に、テーマ別のコーチングの一環として、アレクサンダー・ジザは私を時流に乗せてこう言いました。次のレポートのトピック、私はまだこれを行う方法を理解していません。

実際、これがあらゆるレベルの人に有効かどうかはわかりません。 これまでのところ、私はこれを次のように使用します。 人に何かをするように頼むとき、なぜそれが私のためであるのか、なぜそれが彼のためであるのか、そして私がそれをしないでやるならどうなるのかを説明します。

私の理解における「なぜこれが必要なのか」という質問に対する答えは、合意全体に意味を与えます。 — . , , — .

« » , - , . , , — . , . , , .

, :

• .
• .
• , , — , .
• « » . , .

, Excel, : , , , . , .

?

, , , . , …

? ? — : — , — , — .

, «» , , . «» — - . « » , « ?» « ?»

…

しかし、私の意見では、TeamLead Confに参加するかどうかは明らかです。さらに、プログラムはほとんど準備ができています。ただし、2月にモスクワを選択するか、9月にピーターを選択してニュースレターに登録すると、新しいビデオや記事、論文の募集、重要な日付を見逃すことはありません。