🚶🏻 🏂🏾 👩🏾‍✈️ マネージャーだけでなくプログラマーの便利な仕事にかんばんを使用する方法 🚲 🗑️ 👨🏼‍🔬

かんばんは、スクラムよりも約10倍少ない頻度で使用される管理方法ですが、これはそれほど面白くなりません。これは、組織全体のプロセスを相互接続された一連のサービスとして提示することに基づいており、最終的にはエンドユーザー向けのサービスです。

カンバンは、トップマネジメントから始めて実装するのが特に簡単であり、 エリヤフゴールドラットの著書「目標」に示されている制限の理論と完全に組み合わされています。かんばんは、テクニカルサポート部門、システム管理者、さらにはITと密接に連携する人事マネージャーや会計士によって選ばれます。

主な際立った特徴の1つは、かんばんの実装の原則です。「あなたが持っているものから始め、プロセスを視覚化し、プロセスの進化的変化に同意します。」

これはかんばんの導入を大々的に発表することではなく、改善に向けて進化的に変化するプロセスについてのみであることに注意してください。あなたはおそらく考えました：「それは恐ろしく聞こえない。誰がそのようなことを拒否しますか？」それにもかかわらず、大きな変化なしにビジネスの観点から重要な結果を達成することはうまくいきません。

「プロセスの進化的変化に同意しましょう」という無邪気なフレーズに続いて、さまざまな提案が出てくる可能性があります。そして、実装中のかんばんが十分に経験されている場合、それはすべて非常に慎重に行われます。以下に説明する利点は、かんばんおよびプロセスを改善するために使用できるプラクティスに値します。

当然、プログラマーにこれらのメソッドを使用してより速くプログラミングすることを教えることはありません。しかし、ほとんどの場合、タスクは何らかの理由で並んでいるか、何らかの理由でブロックされており、未完成のビジネスの厚い部分で単に忘れられていることがあります。かんばんは、物事を整理するのに十分に対応できます。

実装の利点

今日では、アジャイルという言葉への関心が穏やかに言えば過熱しているとき、それは最初から想定されていないかもしれません。それでも、割り当てを達成する目的で開始された場合でも、実装の恩恵を受けることは可能です。

1） かんばんは、組織内のプロセスの透明性を高めるために作成されます。

会社のどの部分でプロセスがどのように配置されているかを理解していない人が、どのくらいの頻度で対話しなければならないのでしょうか？たとえば、マーケティング担当者はプログラマーの仕事についてどれだけ知っていますか？マーケティング担当者の仕事についてプログラマーはどうですか？

他の部隊のプロセスの構造を知らないことは、しばしば他者の仕事に対する幻想と軽miss的な態度を引き起こし、そのような状況では接触を確立することがより難しくなり、部門は戦争状態にさえなる可能性があります。

2） かんばんは、最悪の症状で「マルチタスク」と戦うのに役立ちます

コースのどこかで、「効果的なマネージャー」が教えられます。その後、自分でそれを行い、タスクが5分を超えない場合は他の人にアドバイスします。、しかし、最も独創的な顧客は、各タスクを非常に小さく、そのような優先アプローチを必要とするように見せ始めます。

3） かんばんにより、特定のタスクのタイミングを評価する必要がなくなります

代わりに、統計的手法が提案されています。特定のドロップが（青い染料でマークされている場合でも）ポイントAからポイントBにパイプを飛ぶ速度を予測するのではなく、水道管の断面の直径と流量を測定していると想像してください。

かんばんを効果的にする便利なツール

導入には多くの儀式が含まれるスクラムとは異なり、かんばんの導入ははるかにスムーズで目に見えません。しかし、かんばんは、たとえどんなに美しいものであっても、まだ実装されていないため、最初は経済的効果が低くなります。

かんばんボード

全体としての組織のかんばん委員会およびそれに関連するユニットの下位委員会。 これは重要な属性ですが、その存在は柔軟な思考の存在と組織管理の方法論の存在を保証するものではありません。ロシアの多くの実装はこの段階で終了しますが、スプリントだけが獲得できたスクラムの多くの実装も見ることができます。

実装手順：

進行中の作業数の制限。（仕掛品制限）

この慣行はかんばんの重要な部分であり、それがなければ経済的効果ははるかに低い確率で達成可能です。著者の慣例では、各ステータスのタスクの制限は労働者の権利と自由の制限として直感的に認識されるため、制限の導入は常に深刻な抵抗を伴います。

実装方法：

1）未完了のタスク（ある場合）の瓦について話し合い、それらに対処することを決定します。

2）最も散らかった列にのみ制限を入力します。

3）プロセスの一部に特別な注意を払い、この場所の「閉塞」を解消するとすぐに、他の生産エリアがボトルネックになり、新しいボトルネックを見つけて、この列にも制限を設定します

（このために、隣接するユニットにかんばんボードも取得するように説得する必要がある場合でも、そうではありません） ;

4）必要なプロセスに関連するボードの列の制限を一貫して実装および強化しますが、単に導入されたルールのために人々が仕事なしで座っている限りではなく、あらゆるステータスの仕事の小さな合理的な供給が残っているべきです。

このプラクティスを実装するためのイニシアチブは、パフォーマー自身から得られるのが最適です。「上から」実装することはほとんど不可能ですが、価値があります。コーチが人を使うように説得するのは簡単で、カンバンシミュレーションゲームでの優位性を示しています。

SLA-サービスレベル契約、またはサービスレベル契約

名前は合意として翻訳されているという事実にもかかわらず、実際には、タスクが平均的に早く完了したことを示す統計の要素であり、この点で現実的な期待を構築することを可能にします。

ただし、統計とは異なり、このレベルには内部または外部の顧客に伝える際にわずかなマージンが含まれる場合があります。

実装

1）顧客（内部または外部）がキューにタスクを設定してから平均してどれくらいの時間が経過するかを統計的方法で計算します。また、どの時間間隔で最速の10％フィット（Xと呼びましょう）、90％のみフィット（Yと呼びましょう）します。また、「長期建設」の時間Z、最も長いタスクにかかった時間を計算します。

2）Xを取り、それにYを追加すると、顧客が指定された時間を待つことができず、タスクを延期する緊急の注文で「実行」された場合でも、タスクの90％を完了するための現実的な期限を取得します。おそらく緊急のタスクがあり、特別な順序で行われているという秘密を教えてください。著者は、優先順位の違反によりコーヒーやチョコレートが消費される「内部腐敗」の事例を認識しています。

3）通常の状況ではタスクがX + Yの時間で処理され、何らかの理由でZ時間まで極端に長く実行できるタスクは10％だけであることに顧客（内部または外部を問わない）に同意します。

サービスクラス

実際、サービスクラスについて上記のいくつかのパラグラフについて説明することで少しごまかしましたが、名前は付けませんでした。この名前は場所によっては複雑すぎて恐ろしいものに聞こえますが、アプローチ自体は、内外の顧客との連携に柔軟性を提供するためのかんばんの実装に不可欠な部分です。

実装方法

この機会について話し合い、公式の手紙を書き、ボードに行区切りを追加します。通常、Swimlinesと呼ばれます。Jiraで古いバージョンでこれに問題がなければ、Asanaでは追加のスクリプトなしでは不可能と思われます。

リクエストマネージャーロール（SRM）

かんばん資料では、著者は時々、スクラムから切り替えるときにプロダクトオーナーを解任しないために、この役割が必要であると正直に言っていますが、顧客からタスクを受け取ることに問題がない場合、このポジション（SRM）は特に必要ありません。この役割は、食品会社に「単一のエントリポイント」が不足しているチームに役立ちます。その後、この人は正式なポリシーを確立し、着信キューを処理できますが、これはフルタイムの仕事を意図したものではありません。または、複数のチームに1人のリクエストマネージャーを配置し、元のプロジェクトマネージャーまたは開発グループの責任者（一般に、新しいプロセスで余分な作業を行わずに残された人）にすることができます。

Delivery Manager Role（SDM）

サービスデリバリーマネージャーは非常に強力な役割であり、ほとんどの場合、最初に必要とされるプロジェクトマネージャーを任命し、物事を終わらせるようにします。マネージャーの配信が存在する場合、ほとんどの場合、リクエストマネージャーの役割は実質的に不要です。ただし、正式にはデュアルパワーを提供しますが、リクエストマネージャーはまだ実行するかどうかがまだ決定されていないタスクを処理し、配信マネージャーはすでに実行されて必要なタスクを処理します終わり。

ケイデンス。さまざまなプロセス頻度の会議

かんばんには、このような会議が多数ありますが、多すぎます。毎日から供給計画や待ち行列を埋める計画の会議まで、さまざまな会議（スクラムのスプリント計画と同様）。

デイリーフライングスタンドアップ

スタンドアップでは、スクラムとは異なり、パフォーマーにとってより楽しい質問が議論されます。昨日やったことを痛々しいほど覚えておく必要はありません。全員と一緒にボードを見て、各タスクが右から左へ右に移動するのを妨げるものと、それを防ぐことができるものを判断するだけで十分です。

運用レビュー

フォーマリズムに進まないで、製品の不利益をもたらす仕事中のルールに従うのはどうですか？

同じ制限理論に従って、ローカル最適化は有害である可能性が高いため、各チームのレトロスペクティブの会議でローカル最適化に関与しないように組織全体のプロセスを調査するという点で、アジャイルレトロスペクティブとは異なるオペレーションレビュー会議を開催するのに非常に役立ちます彼女を助けるよりも組織。

技術サポートエンジニアが、スタッフやその他の問題の兆候を増やすことなく、不満を抱くユーザーの数にますます効率的かつ迅速に対応しますが、迅速に対応する必要があるため、受け取った情報を開発チームに渡さないことを想像してください。これを想像することは難しくありません。これは、膨大な数のロシアおよび外国企業の技術サポートで発生します。どれほど効率的、迅速、美しく応答しなかったとしても、問題の原因を知らせなければ、問題の検出と修正はより難しくなり、増加する負荷に対処することはより困難になります。

配送計画

この会議では、2週間に1回だけ発生する必要はありませんが、供給の問題や不確実性がある場合（マーケティングなど）に発生する場合、発生する準備ができているもののレビューを行い、それらのタスクを選択できます次の配信ではより優先されます。

バックログ充填

正直なところ、作者の病棟にはこの会議に対する特別な必要性はありませんでしたが、多数の顧客による過密の問題がありましたが、それでも、この会議の必要性は、製品をゼロから作り、覚えている人にとって簡単に理解できますたとえば、Jiraで新たに構築されたプロジェクト。このような会議では、製品または組織規模で最も優先度の高いタスクを一緒に作成できます。技術レベルへの分解により、エンジニアはすでに完全に対処できるようになります。

指標

製品メトリクスの標準セットがあります：収益、利益、ARPPU（有料ユーザーごとの平均レート）、もう少し愛されていないARPU（ユーザーごとの平均レート、支払いだけでなく、すべてのユーザーの観点から収益を考慮します）など。これらのメトリックは、製品会社のプロセスにとって非常に有用であり、わずかに異なりますが、非常に類似しています-アウトソーシングのために。しかし、これはもちろん戦略レベルに関係します。

機能単位のレベルでは、プロセスを実際に正しい方向に導くメトリックスまたはそれらの間接的な予測を導入することが重要です。また、これは常に1日あたりに実行されるタスクの平均数、またはタスクが平均して実行される時間とは限りません。これらのメトリックはかんばんではデフォルトで提供されますが、プロセスは特定の内部および外部顧客のニーズに合わせて事前に調整する必要があります。このようにして初めて、企業はエンドカスタマーにサービスを提供するために、相互に相互接続されたサービスのセットになります。

製品管理の相互作用

プロダクトマネージャーの職業はスタートアップの仕事に似ており、唯一の違いはプロダクトマネージャーが給与のみを持ち、幸運な場合は利益の一定の割合を持っているが、スタートアップは給与を持たないが、潜在的な利益は完全に彼に属している（またはパートナーと共有している）ことです。

製品マネージャーは、個々の製品を開発し、収益性を高め、原則として、CEOの次のアイデアを実装するのではなく、実在の人々の実際の問題を解決することで顧客に利益をもたらすために存在します。ファンタジーは長い間終わっているか、この特定の方向に特定のビジョンはありませんでした。

プロダクトマネージャーは予算の所有者であり、クライアントに提供されるサービスの種類や計画の実施のための給与予算などの戦略を策定します。製品マネージャーは、製品が達成しなければならない主要な指標を定義します。ユニットはプロダクトマネージャーに直接従属することができ、従来のマトリックス構造も可能です。これは管理性が非常に悪く、個人（手動制御をしようとする部門長）の通信の負荷が増大します。

製品マネージャーは、必要なプロセスを設計し、必要なメトリックを設定できます。 最終的には、どの方法論も目標を達成するための単なる方法であるため、彼はプロセスのさまざまな部分でスクラムまたはかんばん、あるいは高速の滝を選択的に使用できます。

機能横断コマンド

スクラムで機能横断的なコマンドを使用できます。組織の全体的なかんばん構造のセルとして、機能横断的なスクラムコマンドを使用することもできます。

ただし、かんばんをスクラムに急いで急いで交換することには直接反対しないでください。かんばんは、それぞれがマーケティングから技術サポートまで何でもできるクロスファンクショナルな「戦闘」チームではなく、サービスユニットに最適です。

職域を超えたチームでは、作業を異なるタイプに分割せず、「このタスクはまだ私のコラムに含まれていません」という精神で対立を起こさない方が良いです。

そして、再びかんばんについて、かんばん自体の多くの間違い

プログラマー、テスター、または他のエンジニアが「いつ準備ができますか？」という質問でマネージャーや関連部門の代表者を引き出さないようにする方法。

人々にボードを読み、ボード上のタスクを設定するように教えるだけで十分です。確かに、多くのかんばん= boardの観点では、これは実際にはそうではありません。

通常、内部顧客は喜んでおり、上記のすべての方法を使用するチームを見せれば、一部の顧客は結果に満足したら、上記の要件を待たずにカンバンを実装し、ウイルスとしてカンバンを起動できるようにします。中規模組織内の管理方法。

著者の実務では、専門家によるより詳細な調査を開始した部隊によってかんばんが「強化」され、CEOが手動プロセス制御から削除されたため、顧客の損失の事例さえありました。

参照：

マネージャーだけでなくプログラマーの便利な仕事にかんばんを使用する方法