冷酷な自動化。 ディレクターズカット

プログラマーのチームで自動化を加速した経験と、私たちがどのテクニックを実践し、何が実現したかについてお話したいと思います。

初期条件

次の条件でプログラマーの作業を加速するために実験を実施しました。

• 地理的に分散した製造企業でした。
• 4人のプログラマ1Cと私、彼らのリーダーが実験に参加しました。
• 複雑な構成をサポートするフルタイムのプログラマーです。
• 私たちは退屈になり、開発することにしました。

まず第一に、私たちがスクラムに関するジェフ・サザーランドの本に出会った後、開発したいという欲求が生じました。 おそらく、この手法についてはすでによくご存知でしょうので、ここでは詳しく説明しません。 この記事の主要部分はスクラムに関するものではありません。

そのため、この本を読んだときに、ジレンマがあることがわかりました。これは、本のタイトルの誤った翻訳です。 英語の名前は、スクラムが作業を4倍高速化することを示唆しています。「半分の時間で2倍の作業を行う技術」。

ロシア語の翻訳では、スクラムはプロジェクト管理の革新的な方法であると述べられています。 ITマネージャーが面接の準備をするとき、彼らはしばしば言われます-その人が集中していることに注意してください-プロセスまたは結果。 ロシア語翻訳はプロセスに焦点を合わせています 。

なぜこれについて自信を持って話しているのですか？ 私はスクラムをライブで使用した何十人もの人々を見ました。 彼らのほとんどは、スクラムプロセスを開始したばかりであり、「何が変わったのか」と尋ねると、「透明になり、面白く、楽しくなった」と言います。 しかし、結果がどのように変化したか、開発速度が向上したかどうか、プロジェクトをより速く引き渡し始めたかどうかに興味がある場合、彼らは効果を測定しなかったため、これを知らないことがわかります。

そのため、この本を読んで、ビジネスプロセスのすべての主要な段階を備えた古典的なスクラムを開始しました（写真に示しています）。

測定方法について説明します（レポート全体に表示されます）。 スクラムで測定する従来の方法は、 ポーカープランニングです。 以下から構成されます。各タスクについて、チーム（またはこのタスクで何かを理解している参加者のチーム）には、1、2、3、5、8、最大34（フィボナッチシリーズの数字）のスコアが与えられます。 推定の全体に従って、平均が取られます。 タスクは、顧客に受け入れられたときに完了したと見なされます。

最初の結果

古典的なスクラムの導入は何をもたらしましたか？ 彼の前では、一人当たりの平均日産量は4.2ポイントでしたが、その導入により、 指標は7.73ポイントに上昇しました 。 生産性が2倍になりました。

みんなが気に入って、他の部署の同僚にそれについて話し、会社全体が興味を持ち、誰もが自宅でスクラムを実装し始めました。

しかし、誰もがフェチに夢中になったので、何も起こりませんでした-彼らはコルク板を買って、それらにステッカーを貼り付けて、これに限定しました。 スクラムにも興味を持っていたオーナーでさえ、従業員をしました。彼はコルクボードに行って写真を撮り、1週間後に戻ってきて再び写真を撮りました。ボードは変わりませんでした。

もっと欲しかった

2倍のパフォーマンスの改善は退屈に思えました。 したがって、私は再び本を読み始めました。 54〜55ページで、いくつかのshuhariが気づきました。 これは合気道の原則であると書かれています - 最初にルールに従ってすべてを実行し（syu）、次に即興を開始し（ha）、その後のみ分離して独自のテクニックを実行します（ri） 。

興味深いことに、広く知られているスクラムガイドでは、この原則は捨てられ、「shuhari」から「syu」だけが残っていました。

そして、私たちはずっと行くことにしました。

Jeff Sutherlandの本で推奨されている基本的な加速アルゴリズムは、Demingサイクルです。 簡単に言えば、それは次のように定式化できます：あなたはあなたの人々がどのように働いているかを見て、彼らが愚かであることに気付き、どこに遅れがあるのか​​、何らかの種類の変化を思いつき、それを実装し、何が起こったのかを見てください。 それが良くなり、速くなったら-変更を残します。 それが悪化した場合-変更を削除します。 主なことは、それを迅速に行うことです。

ちなみに、Goldratt Systemsの制約の理論は同じことを言っており、他に集中しているだけです。 彼女は言う-あなたのシステムで最も狭いリンクを見つけて、それを広げるか、それを削除する。 その後、もう一度繰り返します。

一方と他方の両方の目標は、生産サイクル全体でできるだけ早く結果を得ることができるようにすることです。 偶然にも、同じ考えがトヨタ生産システムの開発者によって表現されました-生産システムの目的は、クライアントのお金をできるだけ早く到着させることです。

ワークフローのオブザーバーの役割は、スクラムマスターによって実行されます。 これはコーチだと言えます。 スクラムの同僚の経験を読むと、彼らはスクラムマスターをディフェンダーとして認識し、スクラムマスターは障害を取り除き 、一部の人々を追い払い、何かを助けなければならないと言います。

しかし、 スクラムマスターはオブザーバー兼トレーナーであり、より速く働くことを人々に教え、愚かなところを見て、助け、プロンプトを出し、新しいものを探し、さまざまな組み合わせを試します。 サッカーのコーチのように。

実験チーム。

実験が行われた背景を理解するには、チームを導入する必要があります。 OlegとIgorの2つのStasがあったと言っても、誰もこれらの人々を知らないので、これは何も伝えません。 あなたは、プラスまたはマイナス、私だけを知っています。

したがって、2人のスタソフ、オレグとイゴールの代わりに、キャラクターは誰もが知っているチームとして提示され、それは実際の人々に可能な限り似ています：

• ウサギは賢く、静かで、静かです。
• ピグレットは最年少、最速、最も好奇心urious盛です。
• ロバは最も落ち込んでおり、彼は人生のようです。
• そして、フクロウ...実際、元の本はフクロウではなく、ワシミミズク、男性的でした。 そのため、チームにはワシミミズクがいました。

次のステップは即興です。

最初の日に、すべてを変更することにしたとき、私たちは：

• スクラムボードとステッカーを捨てました。 スクラムボードは、1Cに基づく情報システムに置き換えられました。ドキュメント管理。
• ステッカーは、この情報システムのタスクに置き換えられました。
• 左のポーカーと速度の測定。
• 毎日の会議、回顧、プロジェクト（一般的にはエンティティとして）を削除しました-トピックごとのタスクの分類のようなものを残しました。
• ダウンタイム、損失の常時監視を追加。
• そして、彼らは絶え間ないプロセス変更を加えました。

合計で、約1年間続いたこの実験中に、約40個の加速器が見つかりました 。 これらの40個のアクセラレータをグループ化しようとしましたが、これらの各アクセラレータがワークフローにどのように影響したかを簡単に説明します。

念のため、これらのアクセラレータがどこから来たのかを説明します。 ここには新しいものは何もありません。 私は自分でいくつかの原則を思いついた、私の仲間の何人かは何かを思いついた、我々は本から何かを読んだ。 たとえば、本の中にそのような問題を解決するためにこれを行うことが推奨されている場合、あなたはそれを試してみる必要があります。 判明した場合は、そのままにしておきます。 意味がない場合は、破棄します。

ゼロチェンジ

そのため、このプロセスの再考を始めた最初のことは、 本「Code of Samurai」です。 みんなで読んで購入し、家で保管することをお勧めします。 500年前とすでに500年前に書かれたため、人々は管理方法、従う方法、開発する方法、改善する方法を知っていました。

サムライコードでピグレットと呼ぶキャラクターの注目は、これらの2つのフレーズを引き付けました。 彼はそれを見ました：

• 決定は非常に迅速に行わなければなりません-7回の呼吸で。
• そして、あなたがすぐに決定を下さないと、結果は悲惨なものになります。

ピグレットはこの考えにあまりにも夢中になり、7回の呼吸で決定を下せなかった場合は拒否しました。 楽しい酒を見逃したことさえありました。

興味をそそられました。この本をもう一度読み直し、約10ページごとに次のように書かれていることに気付きました。

どのように見えますか？

あなたが決定をするための規則を持っているときの戦略のようです。
私たちの国で最も一般的な戦略は何ですか？ 「あなたの会社の戦略は何ですか？」と尋ねると、彼らはあなたに長い「足取り」を見せます。それは今年何をするかを示しています-会社の計画、予算、タスク、売り上げの成長など.d。

この定義は私の近くではなく、私の目的には適していません。

そのため、2番目の定義のみを残し、 決定を下すための一連のルールとしてのみ戦略を認識し始めました。

したがって、スクラムプロセスで導入したゼロの変更は、チームで新しい加速技術を試し、それらの原則を策定し 、名前を付け（覚えやすく、議論しやすくするため）、作業でさらに使用することでした。 。 これらの原則は、他のすべてのキャリアです。

改善の主な秘密

次の基本原則は、 「改善の主な秘密」です。

あなたはそれを望み、信じ、あなたはそれを望みます-いいえ、しかし、私たちは「改善の主な秘密」を考え出しました。

次のように定式化できます。 変化の問題の75％は、人々が言われたとおりに働かないという事実のために起こります。

なぜこれが起こっているのですか？ 事実、変更を実装しようとしている人々（たとえば、スクラム）が来て、部下に次のように伝えます。「あなたは今、新しい方法で働いています。」 そして、彼らはただ去ります。 そして、1、2週間後に戻ってくると、結果がないことがわかります。 そして最終的に、これらの「詐欺師」はスクラムが機能していないと判断し、スクラムをメモリとツールセットから永久に削除します。 他のすべての方法でも同じことが起こります。 私は会社でこれを非常識な回数見ましたが、彼らは何か（何らかの変化）が機能していないことを常に説得しようとしました。

したがって、変更の基本原則を作成しました。変更を適用するには、変更を適用する必要があります 。 今日、テクニカルサポートがないと判断した場合-テクニカルサポートなしで何が起こるかを確認したい場合-テクニカルサポートはありません。

これはおそらく、私たちの成功の基礎となった最も重要なことです-私と一緒に働いた人たちがこれらのルールを受け入れたという事実に。 彼らは注文、指示、人員配置の変更、順列を私に尋ねませんでした。 私たちはちょうど同意し、一緒にやった。 その結果、ある日、いくつかの方法、実践などの動作を確認することができました。

周りにはいつもクールなマネージャーがたくさんいました。 私自身もかつて一つになりたかった。

クールなマネージャーは誰ですか？ これは、タスクを設定し、期限に名前を付ける必要があり、期限が過ぎてタスクが完了していない場合、エグゼクティブが責任を負う必要があると考えている人です。 これは私のものではなく、彼らの表現です。 彼らはそう言っています：スクラムはすべてがらくたです、彼らが期限に間に合わなかったとき、あなたは仕事と乾燥を設定しなければなりません。

しかし、 締め切りは悪いと自分自身で決めました。 なんで？

• まず、タスクプール（150など）があり、それぞれに期限を設定する場合、これらの日付は常に「浮かんでいる」ため、毎日再計算する必要があります。 その結果、管理に多大な時間が費やされます。
• 第二に、日付は常に 「浮いている」という事実のため、日付は常に正しくありません 。
• さらに、人が時間に陥る程度は何も意味しません 。 ある期間、ある人が1つのタスクを持つことができるということです。
• そして、何のために彼らは必要ですか？ 大騒ぎするが、実際にはタイミングが常に間違っている場合は？ タイミングは単なるフェチです。
• 私たちは、タイミング管理は管理における「女性的なアプローチ」であると判断しました。

最後の点は別途明確にする必要があります。 特にこのアプローチは男性でさらに一般的になっているため、私はすぐに女性を怒らせないでください。 この比phorは、一部のマネージャーの行動を何らかの形で説明するために考案されました。

人生からのアナロジー：女性が男性にタップを修正するように頼み、それを行うために5日間を与えると想像してください。 この5日間はどうなりますか？ 男性は自分のビジネスの一部を行い、女性は思い出させますか？ いいえ、できません。 彼女は毎日来て、静かに見ます-修理されたか修理されません。 そしてここに5日目が来ます、女性が現れます、見える-それを修正しませんでした。 朝待って、朝に......

そして最も重要なことは、女性にとってこれは肯定的な結果です。 なんで？ その後、次のようにできるため：

ここで、 タスクを設定したタフなマネージャーとの類似性を引き出して、 その人が時間通りに完了しないようにします。 これはある種のサディズムのようです。 彼らはとても楽しまれ、これが仕事であると信じており、それのためにあなたは月に30万から50万ルーブルを支払わなければなりません。

私たちはそのようなものではないので、 用語は 、 後に何もする必要がない場合にのみ必要であるという原則を自分で定式化しています。 たとえば、レポートの期限。 その後、タスクを実行できなくなります。これは、レポートの遅延に対するペナルティが収益の約20％であるように見えるためです。

目標

確かに誰もがたまたまこの状態で部下を見ることがありました。

あなたは仕事に来ます-そしてあなたの従業員はこのように座っています。

またはそのように。

それをどうしますか？ 私はこれを行うために使用します：

その結果、彼は率直に数回送られ、一度人を失神させましたが、これは男性と女性の両方の小屋の涙を数えていません。 嫌な、まだ恥ずかしい。

絶えず叫んでいる人はたわごとに変わります。 嫌いな人が彼をそのようにした人だと言う方が正しいですが。

なぜこの状態が悪いのですか？ あなたが絶えず人に叫ぶなら、あなたはもう彼の涙を見ないでしょう、それはあなたが彼が座っていて何もしないことを知らないことを意味します。 うつ病の人は何もしないからです。 効率のために、これは大きな損失です。 朝落ち込んだ人は、一日中インターネットを閲覧し、コンフィギュレータを開いてすばやく切り替えます。 それでも、プログラマはドアからモニターのそばに座っていますよね？

したがって、人に怒鳴らない方が良いです。 状況を分析する必要があり、 その人にはありふれた動機がないことが判明するかもしれません 。 しかし、人には目標がないのでやる気がありません 。 彼は仕事に来て、理由を知りません。 また、たとえば自宅で目標を達成しなかったために（妻が休暇でモルディブに行きたいが、これを提供できないため）自宅で何らかの否定性を受け取った場合、彼はただ座って仕事に来ます。 目標を達成する方法のため、彼は知りません 。 または多分彼には目的がありません。

したがって、私たちは目標について話し合う必要があるという原則を自分たちで策定しました。 最初に、私たちは一度に1人ずつ座って話し、それから集まって話し合いました。

その結果、 特定の「平均」目標（すべての目標）を導き出すことができました 。

この「平均目標」はこのようなものでした- 将来の雇用主のために働くことです 。 この言葉遣いには多くの意味があります（そうですね）。 私は2つだけ言及します：

• 第一に、プログラマーの目標は、現在の組織の現在の仕事とは関係ありません。 なぜなら、現在の組織を離れるときに現在の組織に執着する人は、その重要性に非常に大きな打撃を受けるからです。 結局のところ、 ここで重要なことは、誰も必要としません 。
• 第二に、「将来の雇用主のために働く」とはどういう意味ですか？ これは、ほとんどの将来の雇用主にとって有用な、最も抽象的な経験を得ることを意味します。

これは私たちが子供たちのために策定した目標であり、これは子供たちに非常に前向きな効果をもたらしました。

「オンザフライでのカスタマイズ」に関するいくつかの言葉は、作業をスピードアップするための純粋に技術的な方法です。

写真は、そのようなアクセラレータの不完全なリストを示しています。 これらは、 特定のクラスの問題を非常に迅速に解決する抽象的なソリューションです 。 最も一般的な例は、データ検証です。 ユーザーがドキュメントの実行中に何かを禁止するたびに30分間コードを記述する代わりに、コンフィギュレーターを起動せずに3分でチェックを行います。 それだけです

「平均目標」と「その場でカスタマイズ」を追加すると、「レイオフキット」が得られます。 これは何ですか これは、会社を去る人が彼と一緒に取る知識、経験、アイデアのセットです 。

チームのメンバーごとに、勉強する必要があるもの、試してみる必要があるもの、理解する必要があるもののかなり大きなリストを作成しました。これにより、退職後に新しい仕事に適用できるようになりました。

優先順位は非常に重要なものです。

私の人生では、経済学の博士論文から企業の革新的なベクター開発のモデルを使用する限り、タスクに優先順位を割り当てるためのさまざまなオプションを試してきました。

しかし、効率性はシンプルであることを実践が示しています。 したがって、最終的に、 優先順位を設定するために、 通常のアイゼンハワー行列を選択しました 。 すべてのタスクが4つの正方形に分割されている場合、誰もがこのツールについて知っています。

チームの原則では、これは次のように反映されました。

• マネージャーが課した緊急度/重要度。
• 従業員は実行順序を選択できません。
• Nefigの場合。

従業員が実行順序を選択できないのはなぜですか？ プログラマーのタスクを選択する能力は効率にとって驚くべき悪だからです。 彼は一日中タスクを選択できます。 日は何ですか？ これは週の20％です。 それだけです、その日は過ぎました。 彼はタスクを選択するだけでなく、コンフィギュレーターに入り、それがどのように解決されるか、落とし穴は何かを見ることができます。 そして、それは一日中、そしておそらくそれ以上になります。

そして、効率にとって2つの最大の悪は、人が怖がっているときと彼が理解していないときです。

怖い-これは人が座っているときです：

• 怖い質問;
• 間違えるのはひどいです。
• 同僚に気を散らして何かを尋ねることは恐ろしいことです。
• 彼らが彼をscるので、最適にしないことはひどいです。

そして、選択がそうであるように、恐怖は麻痺します。 男はやり始めた、彼は尋ねることを恐れていた-そして彼はあなたが彼に来て尋ねるまで麻痺して座っている-何がありますか？
この実験全体を行ったとき、これがどれほど重要であるかはわかりませんでした。 これは、別の会社に引っ越して初めて理解できました。 今、私の恐怖はこのように見えます。 この人を知っていますか？

または、誰かが認識しなかった場合。

これは、metadata.jsプラットフォームの作成者であるEvgeny Malyarovです。

彼は私のものの20倍の知識を持っているので、私はこの男を恐れています。 そして、私は彼に尋ねるのが怖いです、なぜなら私は最高であることに慣れていて、ここで私はばかです。 そして私は怖いです。

人は一日中踏みつけることができるとすでに言った。 今、私は一日の終わりを待って逃げるために、一日中歩くことができます。

怖いときは、ユーモアの助けを借りて状況から抜け出すことができます 。 この方法は直感的にわかりました。 人が間違っているとき、私たちは彼を笑います。 そして、彼らは私の上を含め、すべての上で、そしてすべての上で笑っているので、誰も傷つけません。

そして、それが明確でない場合はどうすればよいですか？ プログラマーが座ってタスクを受け取り、それを行う方法を理解していないと想像してください。

友人を助けるために人々にコンピューターから立ち上がることを強制し、それが明確でないことを彼に説明する必要があります。 なぜ強制する必要があるのですか？ 「互いに助け合いなさい」と言うことができます。 しかし、プログラマーはモニターを見るのが好きなので、彼らは助けにはなりません。 彼らにとって、モニターから立ち上がることは問題です。 時々あなたは言う：「みんな、私に聞いてください、私は今あなたにクールなことを話します。」 しかし、彼らは座って、モニターを見ながら、彼らが聞いていると言っているが、実際には彼らは自分の問題で忙しい。 その結果、モニターを見ないようにモニターをオフにしなければならないこともあります。

そして、誰も理解しておらず、誰もお互いを助けられないとき、どうしますか？ 5人が座っています。これを行う方法は誰も知りません。 この場合、以下を手配する必要があります。

• ブレーンストーミング。
• または、Devil's Advocateというメソッドを使用します。 これは、あるプログラマーが1つのソリューションを提供し、別のプログラマーが別のソリューションを提供する場合です。 そしてその結果、最初のものが2番目のアイデアを守り、2番目のアイデアが最初のものを守るように、それらを交換する必要があります。 これは非常に興味深い-あなたが誠実に問題にアプローチし、あなた自身がそれを信じているかのように他人のアイデアを守りたい場合。
• 触媒の人々は何か良いものを思い付く別の方法です。 たとえば、クールな建築ソリューションを思い付く場合、黙って考えないでください-大声で考えてください 。 あなたの周りの人を集めて、「みんな、私が言うことを聞いて、同意する、またはその逆は同意しない」と言ってください。 その結果、2日間ではなく30分間で意思決定がはるかに速くなります。
• ジンギスカンは、問題を解決する別の興味深い方法です。 ジンギスカンは、このような都市を取るのが好きでした：彼は都市に近づき、それを襲撃し始め、そしてあきらめて撤退するふりをしました。 人々は街から逃げ出し、待ち伏せされました。 同様の方法を適用することもできます。 ある人が解決策を思いついたとき、彼はそれに固執し、別のものを発明したくありません 。 しかし、リーダーが「それを忘れて、この決定は良くない、それは根本的に間違っている」と言った場合-その人は何か他のものを思いつき始めます。 その結果、5回目または6回目の反復のどこかで、クールなソリューションが生まれます。

私は、開発をコンベアベルトに変え、人々の能力の拡大を妨げていると非難されることがよくあります。 チームも例外ではありませんでした-ロバは私にこの質問をしました-彼は泣き、痛み、より難しいタスクを求めました。 彼は最も経験が浅く、給料が不足しており、認定を受けていませんでした。

私が言う-pf、なぜですか？ バランスを取りましょう。 プラットフォームを研究するために雇用者に代わって奨学金を支払うことはできませんが、一方で、交換できない従業員のコンベヤーも必要ありません。

取ってバランスが取れていた。 平均して、時間の30％を割り当てて、人間にとって新しい問題を解決することが判明しました。 原則は次のとおりです。

• 私たちは少なくとも2つの方向で開発します -速度と視野。
• 地平線だけを開発することはできません-私たちは大学ではありません（そのような奨学金、ブハハ）。
• 速度だけを開発することはできません-私たちはコンベアではありません。
• したがって、バランスを維持します。

ちなみに、私はロバに言及したので...彼は結局、最も効果的な従業員であることが判明しました。 彼は最低ポイントを与えましたが、ポイントのコストを計算すると、それは最低でした。 大まかに言って、彼の仕事の結果は会社に最も安い費用をかけた。 ロバはそれを非常に誇りに思っていました。

– .

, , . . , — , . , , – , . – . , . , . など-無限に。 , , , .

, , .

… , « ». .

, ? . :

• , ;
• , , ;
• , – ;
• .

, , , . , - , .

, , .. , – . – , , , . « », .

, . . , – , - . , , , , – , , , , – -, .

, , , , . , – , , , -, , , . , . , .

. , , , . , . , . , , . .

, , . – , ? . , .. – , , ( — ).

– , . , – 3% . – , , , .. . - , .

, , , . . , . – - – , ?

- – , , . , .

. , .

, 1? . – , , . , – , – , , , , , .

, . , . , .

, . , , , . , , , !

- , , , . – , ! , ? , . ! , … — .

: . , , , , , – . . , .

. . Scrum – , .

. , , , , 15-00, . . – , , ., -, – .

, , «». , , « ». – . , , . , .

– .

Scrum – , . . ? . つまり Scrum .

, , , , , 20 % .

.

• – ;
• – ;
• – ;
• 5 – 5 ;
• – .

, , -. « », , , . – , , .

- , , – . , . , – . , , - .

:

• ;
• ;
• ;
• 1: , scrum-.

. , , . !
.

.

, «» , .

• , Scrum 4,2 .
• Scrum 7,73 .
• «» Scrum 17 .

そしてこのすべての後、私はこの会社を辞め、「タフなマネージャー」が私の代わりに来ました。スクラムが「スクラム」と呼んでおり、これは新しい手法であると言っている真のクールなマネージャー。私の仲間は会社に残っていたので、彼らは彼らの有効性を測定し続け、彼らが今どのように働いているかの指標をくれました。現在、その有効性は2.5ポイントに低下しています。

最終測定値と非常に最初の測定値の商を計算すると、適用されたすべての方法と原理により、効率が4倍向上したことがわかります。

：PSのビデオ版があり、時間と二人は。