自分でプロセスを偽造する方法。 2GISの経験

ミハイル・ビザンキン（ mihey911 ）

オーバーロードしたチームについての話をします。



開発チーム、テスター、DevOpsといった20人の優秀な専門家からなるチームがありました。 この過負荷のチームには、ほとんどが国内の顧客が12人いました。 この十数人の顧客は常に優先事項を求めて戦っていました。 チームにとって、これは多くのストレス、緊張であり、チームは次に何が起こるかを理解していません-毎日新しいビジネスタスクが飛ぶことができます。 このような状況下で、彼らのために2年間働いていて慣れ親しんでいたスクラムは、誰かが非常に重要で何かを望んでいたので、彼らがやることができなかったコミットメント（スプリントのために約束したこと）を打ち破り始めましたとても価値があります。 そして、貴重なものはお金です、彼らは作られる必要があります。



そして、チームはそれにうんざりしており、 変更する準備ができていました 。 これは重要な条件です。



最初は、プロセスを整理するための一連の推奨事項とレシピを提供するつもりでしたが、レシピを例で説明する方が簡単です。そのため、私たちが何を、なぜ、自宅でそれを行うことができるかについて少し気を散らす話があります。



私自身について。 私は11歳でプログラミングを始めました。 私はプロのIT分野で6年以上働いており、そのうち3年間マネージャーを務めています。 彼はいくつかの会社で働いており、小規模から大規模、最大規模のプロジェクトを管理していました。チームで約40人です。 近年、私はアジャイルの方法論が好きで、これをすべて復活させる方法、これから何ができるか、さまざまな研究、実験に積極的に興味を持っています。



多くのチームとこのチームの主な違いは、この方法ですべてを行ったことです。これについては、意識的に説明します。 彼らは私たちがやっていることを非常によく理解しており、私たちは常にこれらすべてを伝えました。



変更を開始するには、自分自身の目標を設定し、質問に答える必要がありました：最終的に何を達成したいのか、このチームで何をしたいのか、このプロセス、チームの生活をどのように単純化したいのか？







第一に、私たちはモチベーションを失わないようにする必要がありました。なぜなら、それは困難で、強烈で、人々が疲れ始めていたからです。 彼らが高く、働くことができるように、彼らがそれを単純で簡単にすることが必要でした。 当然、明確な優先順位が必要でした。



明確な優先順位が最も苦痛な部分です。 結局のところ、優先順位を明確にする方法を知っている人はほとんどいません。



これから、次の目標-予測可能性が必要です。



私たちの期待：私たちにはやる気のあるチームがあり、理解可能な優先順位があり、プロセスを設定し、それを予測可能にすることができました。 結果を絶えず繰り返すことができ、あるタスクなどにどれだけ時間がかかるかがわかります。 そして便利なボーナス-すべてを意識的に行う独立したチーム、つまり 外からの人々の介入なしに、一部のコーチやマネージャーがプロセスをさらに開発し、自分自身を改善し、ほとんどの場合、上記の状況に陥ることはほとんどありません。



到達したい地平線を理解するために目標を決定した後、それがどのようになり、これらの目標を達成するために正確に何をするかをより詳細に理解する必要がありましたか？ つまり 達成したいある種の条件付きインジケータと、特定のアクションのオプションがありました。







スクラムを修正できました。 たとえば、彼らは義務を順守しませんでした-優先順位のために彼らが約束したことをしませんでした。 多くのエネルギーと神経を費やし、外的条件は変わらず、男たちは窒息して苦しむでしょう...私たちはこのコミットメントを遵守するように彼らに教えて始めることができます...



レンガから新しいもの、つまり スクラムを投げて言ってください：「みんな、私たちの頭から私たち自身のプロセスを考えてみましょう。」 それから、彼らはSEMAT研究所のエッセンスのような興味深いものに夢中になりました。 私たちはこの研究所がそれを使用したかった方法でそれを使用しませんでしたが、むしろ、ITプロセスのすべての要素を集め、それらの長所、短所、互換性を説明した参考書として見ました。 私たちは見て、それを好きではなかった。



かんばんを宣言するオプションがありました。 宣言的に。 マネージャーが来て言った：「明日はかんばんがあります。」 このオプションの長所と短所を比較検討しましたが、この場合、チームはほとんど決して独立を達成しないように思われました。



私たちは非常に奇妙な方法で行くことにしました-私たちはチームを少し進化させることにしました。 私は今でも何よりもこのオプションが好きです。これは有望なオプションだと思います。 しかし、少し先を見て、私たちはまだかんばんを手に入れたと言いますが、一方で、私たちは意識的にこの方法で行きました。



プロジェクトを開始する前に、変更を恐れないようにする必要がありました。プロジェクトはビジネスにとって重要です。そこで何かを壊し、すでに持っているものを失っても、ビジネスはフラッシュし、どのビジネスにも対応できなくなります。重要なこと。







私たちの利害関係が高いという事実を受け入れる必要がありました。 問題のあるプロジェクトでは、これが常に当てはまります。本当に重要なビジネスプロジェクトがある場合は、デフォルトで利害関係が高くなります。それを我慢して、それに対して何をすべきかを慎重に考える必要があります。



チームが最高の結果を望んでいるセットアップがありました。 ほとんどのチームは最高の結果を求め、結果をもたらすように作業をクールにしたいと考えています。 多くの専門家だけが来て、給料を受け取り、退職するわけではありません。 そして、チームが最善を尽くすのを支援することにしました。 これは、私たちが唯一のものではなく、問題を理解しただけでなく、それを解決するだけではないことを知っていたため、恐れることなく私たちを助けました。 チームがお手伝いします。



また、小さなステップで進む必要があることも理解するようになりました。 このような素晴らしいコンセプトがあります-カイゼン、かんばんと共通点があります-ポイントストロークで非常にゆっくりと、プロセス全体をどこか「良い」に移動するとき。 Kaizenを使用すると、適用された変更をロールバックできるときにクールなボーナスを取得できます。 彼らは何かを変えた-彼らは塗抹標本を作り、それが愚かであることに気づき、あたかも何も起こらなかったかのように、すぐにそれを取り除いた。



そして最も重要なことは、このすべてから学んだことです。小さなステップで行動する場合、間違いを恐れないことが重要です。 間違いを犯し、自分でそれを認めることを恐れていない場合は、それを受け取って修正してください。 エラーがあったとしても、他のことを試してください。そうすれば、すでに教えられているので、すぐに修正できます。



繰り返しますが、私たちは目標を愛し、ポイントを変更する前に、私たちの進化がどのように起こるかを理解したかったのです。 つまり 目標が何であるか、どのようなチームを獲得したいかを理解しました。次に、このチームでどのようなプロセスが必要かを理解する必要があります。







プロセスは次のように単純でなければなりません チームは複雑なプロセスを嫌い、物事が複雑なとき、多くの官僚機構などのことを嫌います。 当然、効率が必要であり、ビジネスに不可欠なタスクを数倍速く消化する必要がありました。 ビジネスは予測可能性を愛し、予測可能性を愛するため、予測可能性も必要でした。数日、数週間、数か月後に何が起こるかが明確な場合、私たちははるかに簡単に生活できます。



このロードマップをまとめました。







壊れたスクラムがあり、そこからスプリントを取り出して投げ出し、「これでカンバンの作業を始めました」と言いました。



誰も知らない場合、かんばんの主な目標は、タスクの設定から実稼働中の既製のソリューションまで、タスクが最適にすばやく流れるようにストリームを構築することです。



そして、私たちはさらに進んだ、またはむしろ、さらに進んでいくつもりでしたが、システムの評価が機能しないことに気付きました。 見積もりに固執する必要はありません。何かに置き換えることができます。予測可能性を得ることが重要です。 タスクを非常に透過的にすることで、予測可能性を取得しましょう。 つまり 高い確率で問題や痛みが発生する可能性があると言えるときに、タスクを非常に明確にすることにしました。 私たちは多くの時間を費やし、コミュニケーションに投資しましたが、チーム、顧客、ビジネスの両方でタスクをよりシンプルで理解しやすいものに分解する方法を学びました。



その後、少しずつ制限が導入され始めました。システムをより効率的にするために、最初にそれを緩め、次にフローを最適化するために必要に応じて締める必要があります。



制限の導入後、結果の測定を開始することができました。 私たちが何を達成し、最終的にどのような数字を獲得したかはすでに明らかになっています。 繰り返しますが、私たちはかんばんを得ました-制限、測定基準、通信-これらはすべてかんばんにとって馴染みのあるものであり、これは特定のものに関するかんばんのほとんどです。



実際、これはどのように起こったのですか、チームはこれをどのように経験しましたか？



一般に、このプロセスは非常に長く、約6か月から8か月で、男と私はこれをすべて経験し、馬を運転しないようにし、私たちが持っているものを壊さないようにしようとしました。 私たちは認識に多くの時間を費やし、回顧などのツールを通じて認識がもたらされました。







通常ではなく、2〜4週間に1回、振り返りを行いました。 問題が発生したとき、私たちは振り返ってこの問題について議論し、マネージャーは問題を解決する方法についてアイデアを投げかけました。 チームはアイデアを受け入れるか、拒否するか、対策を提案しましたが、そのメカニズムの一部を知っていたため、桁違いに優れていました。 したがって、回顧は最も効果的なツールであり、おそらく、これは後でアジャイルでどこかにしたいようなチームに影響を与える最適なポイントです。 回顧はストレートゴールドです。



かんばん用具、アジャイル特有の物に夢中にならないようにします。 重要ではありませんでした。 たとえば、物理的なボードのようなものを試してみました-ボードにステッカーを柱に掛けます。 しかし、物理的なボードが気に入らないITチームがあり、チームリーダーが毎日これらのステッカーをすばらしい隔離状態で圧倒し、タスクトラッカーのどこかで繰り返しました。 私たちはそれを2回試しました。2回目は、全員が得点したため、最後にボード全体が崩れました。 必要はありません。 これをすべてクールな自動化されたボードに置き換え、大画面に表示しました。効果は同じですが、一般的に物理的なボードは必要ありませんでした。



もう一つの興味深い点。 私が言ったように、私たちは小さなステップで歩きましたが、そのプロセスでは、たとえば「Jiraでボタンを作成する」ように見えました。 ボタンを作成するだけです。 大きなプロセスの観点から、ビジネスの観点から、ボタンを作成するように思えます-いくつかのゴミ。 しかし、彼女は私たちにたくさんのテスターの神経を救いました。 開発者は、かんばんに対する不信感をやめました。 このことのおかげで、誰もがストリームとは何かを理解し、この「不幸な」ボタンから非常に多くのボーナスを得たので、ボタンを作成する努力は受け取ったボーナスとは比べ物になりません。 したがって、小さな変更を提示された場合、拒否しないでください。試してみる価値があります。 気に入らなければ簡単にロールバックできます。



この進化の開始から2か月後、CycleTymeについて話をしました。 CycleTymeは、タスクを「タスクの脱穀機」に入れてから出てくるまでの平均時間です。 通常、入り口では、「希望」と言ったのは顧客、製品マネージャー、または他の誰かでしたが、生産のどこかで終わります。 戦闘サーバー上。 そのため、2か月後、人々がすでにフローに慣れていたときに、このCycleTymeを自分用に測定しました。 つまり 彼らはフローを持つことに慣れており、それがどのように機能するかを理解しています。



次の変更は約3〜4か月で、制限を導入し始めました。 制限は、実行される作業の種類に対する物理的な実際の制限です。 たとえば、開発者が2人いる場合、12のタスクを同時に物理的に実行できる可能性は低いでしょう。 そして、私たちは、知的な人々として、「彼らに2つの仕事をさせましょう」と言います。 そして、ここには、それ自体で何らかの制限が迫っています-4つのタスク。 最適なのは、開発者が時間を費やさず、作業中にタスクを切り替えない場合です。 そして、かんばんは、これらの制限を1に近づけることが望ましいと言っています。 最適-仕事に従事している人々の数に応じて。



私たちが導入した2番目の重要な制限は、チーム全体が現在実行しているタスクの数です。 着信ストリームを大幅にカットします。 私たちには膨大な数の顧客がいましたが、これらの顧客には次のように同意しました：すべての顧客に、他の顧客がどのタスクを設定するか、つまり すべての顧客は、私たちに多くのタスクがあることを知っていました。 また、優先順位が必要な場合は、「隣人」に同意して同意することができ、同時にビジネスにとってより重要なタスクを見つけることができます。 顧客とPMの両方に多くの苦痛と苦痛をもたらしましたが、チームを過負荷にすることなく、重要なタスクに集中することができました。 私たちはタスクをより速く実行し始めました。



振り返りについてもう一度。 私がそれがどのようなものであるかを語ったことすべて、すべてが回顧を通して紹介され、私たちはこれらすべてを回顧的にチームと議論しました。 実際、チームが何らかのアイデアを植え付けるためにチームが簡単に実装できる唯一のツールです。 他のすべて、彼らがあなたの話を聞く準備ができていない場合、彼らはあなたの耳を単に通し、あなたはただ部屋を去り、彼らは忘れます。 片方の耳に飛んだ-もう片方の耳に飛んだ。



最後に、このチームは何をし、どのような成功を収めましたか？







すべての顧客がすべてを知っているとき、私たちはまさにタスクプールを得ました-それはオープンで理解可能です。 優先順位をめぐる戦いは数ヶ月で自然に止まり、優先順位が明確で予測可能になり、ビジネス上の問題を非常に迅速に解決することができました。 速さ たとえば、タスク-広告会社はプロモーションページをすばやく作成する必要があります。 実装を2週間から2営業日に短縮しました。



私はこのチームと仕事をしていないので、半年以上が経過しており、彼らはまだチーム自身でプロセスを開発しています。 振り返りでいくつかの変更を行い、自分自身が理解していることを行い、これらの最新のブロックボタンを作成します。



たとえば、彼らには「ポストマスター」というクールな投稿があります。 これは、チームに着信するすべてのメールを数日間担当し、タスクを分散する人です。 ポジションは選択的かつ移行的です。 一般的に、郵便局の開発者は一般的に答えたがらず、いらいらしますが、数日中に誰かにそれを渡すことに気づいたら、このように暮らしやすくなります。 彼らは定期的にメールを解析し始め、すぐにそれに応答し、誰もが正常になりました。 そして、ボーナスとして、このチームの私たちは継続的デリバリーのような素晴らしいものを得ました。 これは朝にタスクを完了したときであり、夕方にはすでに「戦闘中」です。 彼らは自動化を実行し、タスクの重大度に応じて、数時間、場合によっては数分間、すべてのサーバーに到達できました。 これが私たちの経験です。



チームで作業する場合、この経験をどのように自分自身に投影できますか。どのチームを適用したいかは関係なく、チームに何かを教えますか？







まず、目標が必要です。 繰り返しますが、出力チームから得たいもの、彼らが抱えている苦痛や問題、問題を解決したい変更を検討する必要があります。



あなたが持っているオプション、痛みを伴うオプション、痛みのないオプションを確認する必要があります。 多かれ少なかれ受け入れられるオプションを選択したら、それをどのように実装するかのステップを熟考する必要があります。 チームに目を向けて実装する場合でも、いくつかのサポートポイントを用意し、現在、現時点で成功しているかどうかを把握する必要があります。



最も重要なこと：変更を行うことを恐れないでください。 最も難しいのは、始めることです。 最初のステップが完了しました。後で簡単になります。 そして、間違いを犯す権利、自分の決定を迅速にロールバックすること、間違いを認識すること、小さなステップを踏むことを学んでください。 小さな後方ステップは、大きなジャンプよりもはるかに簡単です。



そして、プロジェクトの革命、つまり あなたが来て「今日はかんばんがあります」とあなたが言ったときに最初に言ったこと、そしてあなたはそれであったすべてを捨てます。 彼らが突然来て、「今日は赤い壁紙をぶら下げて、古いものを捨てる」と言ったら-例えば、私はとても怒っています。 したがって、そのような提案をしてチームに来た場合、それは同じように動揺します。

連絡先

» Mihey911

» Twitter

» 2GIS会社ブログ

このレポートは、 WhaleRider Management and Entrepreneurship Conferenceでの最高のスピーチの1つの転写です。



会議のウェブサイトでは、メーリングリストに登録できます。メーリングリストでは、最近のいくつかのWhale Riderからの最高のレポートの解読が公開されています。 同じリストから、新しい会議の準備に従うことができます。



さて、主なニュースは、 WhaleRiderを含む8つのカンファレンスを含む春祭り「 ロシアのインターネットテクノロジー 」の準備を開始したことです 。