デリバリークラブで不確実性を克服する方法

友達、みなさん、こんにちは！私の名前はKolyaArkhipovです。DeliveryClubの研究開発を担当しています。



私たちのチームは、FoodTechプラットフォーム内で科学を多用するタスクを解決します。DCプラットフォームには多くのアルゴリズムとデータに基づいてコンポーネントを開発します。解決の過程で、私たちはビジネス側と開発側の両方から多くの不確実性に直面しています。



資料はボリュームがあり、あなたの役に立つことを願っています。ですから、ティーポットを入れて美味しいコーヒーを淹れることをお勧めします。この記事を書いているときに自分でやったのです。



今日は、私たちのチームが過去1年間に通過したレースについてお話します。類推はそれ自体で生じました-私たちは非常にダイナミックな会社、ロシアのマーケットリーダーFoodTechで働いています。私たちはさまざまな事業分野を急速に発展させており、それは本当に推進力です！フィニッシュラインにたどり着いただけでなく、レースで多くの洞察を得ることができました。これが私があなたと共有したいことです。

この記事は、RIT ++ 2020カンファレンスでのレポートの後に掲載されました。ビデオが好きな人は、記事の最後でそれを探してください。

ケトルはもう沸騰していますか？素晴らしい！それで、今日議論されること：

1. R＆Dと不確実性。私たちが直面したこと。
2. 実験。どのようにそしてなぜ私たちは戦いでそれらを行うのですか？
3. 測定可能性。指標の選択について話し合い、リスクに取り組みましょう。
4. 自律性。DCTechでGISTフレームワークと内部ソースアプローチをどのように適応させたか。

緑色のライト、クラッチ、最初に-行きましょう。

R＆Dと不確実性

一部の企業では、R＆Dチームが新技術の基礎研究に従事しています。このような研究の目的は、現在のプロセスの開発と、ビジネスにおけるまったく新しい分野の両方である可能性があります。たとえば、ブロックチェーンは数年前はそのようなテクノロジーでした。



すぐに、私たちは何か他のことについて話している。 Delivery ClubのR＆Dは、適用される問題を解決することです。私たちのビジネスは急速に成長しており、注文も増えており、内部プロセスのほとんどはデータとアルゴリズムに基づいています。入力データの量が増えると、一部のアルゴリズムは効果がなくなり、昨日は完全に適合したコンポーネントが、今日では動作不能になることがよくあります。



ご想像のとおり、このような問題は決定論的ではないことが多く、その結果、あらゆる側面から多くの不確実性が伴います。重要なものを強調しましょう：





私たちが直面していること、そしてこれらが本当に困難であるかどうかを詳しく見てみましょう。



目標



を達成する方法私たちは常にビジネス目標を明確に理解しています。つまり、どの方向に進むか、どこに行かなければならないかです。しかし、研究課題に関して、この目標にどのように取り組むかが常にすぐに明らかになるとは限りません。どの戦略を採用するか：実験または機能の大規模な展開を通じて？戦闘でのシミュレーションまたは実験で環境を構築しますか？選択肢は大きいです-目が上がります。



正確に何をする価値があるか



さて、私たちはビジネス目標を理解し、どの戦略に従うかについて合意しました。作業に必要な特定の機能セットを決定するときが来ました。それらを選択する方法、バックログに含めるもの、順序：「正確に何をする価値があるか」だけでなく、誰が私たちの分野で最大の専門知識を持っているかを決定する必要があります。



目標を



達成できる時期は、ビジネスにとって確かに非常に重要です。研究はクールで面白いです。データの新機能や研究アルゴリズムを探したり、他の国の同僚からの興味深いメモを読んだりできます。しかし、間違ったタイミングで起動された機能は必要ないことが多いため、目標がいつ達成されるかをビジネスが理解することは重要です。FoodTech市場は現在非常にダイナミックです。



なぜ誰かが私のコードを必要とするのですか



最後の不確実性は、重要ではありませんが、開発者の動機付けの問題です。 R＆Dは主に実験的な開発であり、その結果、私たちのコードは必ずしも本番環境に定着するとは限りません。最初は、なぜこの機能を作成したのか理解できず、心を込めて非常に腹を立て、ビジネスはそれが機能せず、切り離す必要があると判断しました。質問-なぜ私はこれをしているのですか？なぜ誰かが私のコードを必要とするのですか？ -私たちと一緒に頻繁に登場しました。その過程で、私たちはこれをどのように扱うことができ、どのように取り組むべきかを理解しました。そして今、これは最初に克服する必要がある最も重大な不確実性の1つであると確信しています。



それで、そのようなまともなバンプの束を埋めた後、私たちはすべての問題を1つの場所に集め、幸福のためにこれらの不確実性の交差点に3つのプロセスが欠けていることに気づきました。

1. , , .
2. . , , . , - , , .
3. , , - . . IT- ( ), , , , 2-3 . — , .

下の図に概略的に示されています。



実験は、目標を達成する方法と正確に何をすべきかという質問に答えます。メトリックにより、このコードを実際に本番環境に残す必要があるかどうかという質問に、非常に明確かつ透過的に答えることができます。完全な自律性は、期限を評価して満たすのに役立ちます。



止まらない。クラッチ、セカンドギア、私たちは急速に勢いを増しています。

実験

カスタムの宅配便自動割り当てプラットフォームを検討してください。彼女の仕事はかなり単純です。パートナー、ロジスティクス担当者（つまり、宅配便業者）、顧客の3人の市場参加者を集めて、すべての参加者が満足できるようにすることです。つまり、注文が到着したら、レストランが料理の準備を終えたときに正確にレストランに来て、すぐにそれを受け取り、約束した時間に熱くておいしいクライアントに届ける宅配便を選択する必要があります。



非常に単純に見えます、そしてここであなたは言うかもしれません-十分な理論！それは実際の打ち上げに移る時です。



私はあなたに同意しますが、それでも実験のプロセスについて少し詳しく見ていきましょう。全体像を見てみましょう。

1. - — . — , , .
2. — . . — , .
3. — Just In Time. , : , , . , , , . , FoodTech- : , . , .

製品増分の内部でどのプロセスが行われているのかを詳しく見てみましょう。







3.1仮説。それは言葉で定式化するか、または概略的に示すことができます。主なことは、なぜそれがまったく機能するのかを明確に正当化することです。つまり、実験には理論的なトレーニングが必要です。



3.14開発。ここでは詳しく説明しません。開発の詳細については、この記事で説明します。 Scrumを使用し、必要なすべてのアクティビティを2週間繰り返します。



3.2準備。次に、実験を準備する必要があります。つまり、この実験中に通信するジオセグメントまたはオーディエンスを決定する必要があります。また、結果を比較するセグメントを選択します。



3.3実験。次に、実験自体を開始します。重要なポイント：開始前であっても、監視するビジネス指標に同意します。今日は、実験が開始され、技術的に安定していることを示す技術指標の説明を残しておきましょう。ビジネス指標について詳しく説明します。間違いなく危険信号を修正します-これらは、実験中に超えてはならないいくつかのしきい値です。



3.4分析。私たちだけが持っているクールでユニークなデータをたくさん蓄積してきました。それらから有用な情報を抽出しないこと、つまり、テストされている仮説の妥当性について合理的な結論を導き出すこと、および私たちのサービスの聴衆について新しいことを強調することは奇妙です。



3.5結論。おそらくこのプロセスで最も重要なポイントです。この場合、出力は常に3つのボタンを押しています。

• 実験をさらに展開して、次の地域または聴衆の次のセグメントに展開します。
• 何か問題が発生した場合はロールバックします。
• 継続する。考慮しなかった第三者要因の影響が見られる場合があり、その結果、明確な結論を出すことはできません。このような場合は、続行することにします。

実際の実験

最後に、これが実際の例でどのように機能するかを確認するときが来ました。もう疲れましたか？楽しみが始まります。



自動割り当てプラットフォームに戻ります。その前に、納期を短縮するためにジャストインタイムアプローチが非常にクールであることを提案しました。これを、貪欲なアルゴリズムとして示す現在の割り当て戦略と比較します。



まず、仮説を正当化します。

貪欲なアルゴリズム

その重要な特徴は、すぐに処方することです。注文がプラットフォームに到着するとすぐに、この注文に最適なパートナーの宅配便を探し、遅滞なく指定して、この注文について宅配便業者に通知します。その結果、宅配便を探す時間を最適化します。ただし、新しい注文が到着したり、別の宅配便がリリースされたりすると、状況がすぐに変わる可能性があるため、このアプローチは常に効果的であるとは限りません。アルゴリズムはこれに反応しなくなりました。以下はイラストです。





この例では、2つの注文を選択するのに合計45分かかります。もっとうまくやれるようです。

ちょうど間に合う

このアルゴリズムのタスクは、注文の準備ができたときにレストランに到着する宅配便業者を正確に選択することです。それは私たちに何を与えるでしょうか？次の事実により、最終的に納期が短縮されます。

• 宅配便業者はレストランで過ごす時間が少なくなります。
• 宅配便をより最適に選択します。

技術的には、これは実装が非常に簡単です。注文を受けた場合、すぐに宅配便を選択しますが、注文については伝えないため、「仮想予約」を行い、選択を変更する時間を確保します。そして、レストランへの道が注文を準備するための残りの時間と等しい場合にのみ、最終的に（注文を宅配便に転送するかどうか）決定します。概略的に-下の図で。







その結果、わずか30分で注文を選択できます。これは、前のケースの3分の1です。



私の意見では、仮説は正当化されており、私たちはそれを開発に取り入れています。合意したとおり、開発プロセスについては詳しく検討しません。

実験の準備に移りましょう

私たちの場合、何を準備する必要がありますか？それほど多くはありません。A/ Bテストの期間、実験の地理、および比較するものです。私たちは特定の都市に定住し、ある予約戦略が別の予約戦略に与える影響を最小限に抑えるように条件を選択しました。



私たちは間違いなく、危険信号とそれらに対する反応についてビジネスと交渉します。危険信号は、実験中に超えたくないビジネスメトリックのしきい値です。交差した場合、圧倒的な数の実験でこれはロールバックです。しかし、私たちのせいで交差点が発生したのではなく、他の要因の結果であることが確実にわかっている場合は例外があります。この場合、実験を続行することを決定できる場合があります。



他に何を準備する必要がありますか？コントロールルームの同僚に同意します。彼らは、注文に問題がないことをリアルタイムで観察します。彼らにとって、私たちの変化は目に見えるでしょう。なぜなら、私たちがすぐに宅配便の注文を割り当てる前に、今はこれを行わないので、私たちは自分の考えを変えるための時間を与えます。そのため、計画されている実験について同僚に警告する必要があります。



さて、次に進みましょう。実験を準備し、実施し、結果を得ました。そして、ここに楽しい部分があります-分析。

実験分析

総納期の改善に合意し、いきなり4つのスケジュールがありました。ここで説明する価値があります。実験を開始するときは、1つの主要な指標ではなく、ビジネスにとって重要ないくつかのビジネス指標を確認することが重要です。この場合、プラットフォームの実際のプロセスに影響を与える仮説の失敗のリスクを大幅に減らすことができます。正直に言うと、私たちは実験の開始時にそのような間違いを犯しました、そして時々それらは本当に不快な結果につながりました。しかし、間違いは良いことです。私たちはそれらから学びます。



結果を見てみましょう。この記事の目的はJustIn Timeアルゴリズムの効率の詳細な分析ではないため、特定の値なしでグラフを表示します。実験を行う際には、私たちのアプローチにもっと焦点を合わせたいと思います。同じ理由で、A / Bテストを実施し、結果の統計的有意性を判断する理論については詳しく説明しません。これは、次の出版物、そしておそらくサイクル全体にとっても大きなトピックです。

• « ». , , . , . , — , . , . , , . , . , , (/), — , , . -, .
• « ». . , , , . , . , .
• « » « ». : . .

その結果、主要な指標（1）が減少し、非常に重要な指標（2）が減少し、他の2つの主要な指標（3、4）の安定した値が得られ、赤いフラグは点灯しません。これにより、実験の成功とテストされている仮説の妥当性について結論を下すことができます。



クラス！次の仮説に走りましたか？それは素晴らしく面白くて、みんなの生活を改善するように設計されています！しかし、いいえ、それだけではありません。おそらく、忘れてはならない最も重要なステップの1つが残っています。これは、次の3つのボタンのいずれかを押すことです。

1. ロールアウトする
2. ロールバック
3. 継続する

実験の過程で、チームには、機能を完全に担当する役割を持つ同僚が必要です。同僚は、これら3つのボタンのいずれかを押します。当初、このステップを忘れてしまった場合があり、その結果、数十回の同時起動実験があり、それぞれの状況がわかりませんでした。それらは肯定的な結果をもたらしましたが、完全には展開されておらず、ビジネスには効果がありません。さらに、詳細を覚えて整理するためだけに、かなりのリソースを費やす必要がありました。しかし、繰り返しになりますが、私たちは間違いから学びます。

実世界の実験

なぜ戦闘ですぐに実験するのかについて簡単に説明しましょう。このアプローチは通常、履歴データに基づいて、そのような機能を実装した場合に「それがどうなるか」に一定の精度で答えることができる分析シミュレーション環境によって反対されます。



なぜ私たちは自分たちのために最初のアプローチを選んだのですか？ 2つの理由。

• -, .
  
  , , . , - , , . — .
  
  
  
  . .
  
  
  
  ? , , , — . , , , , , . , .
  
  
  
  これはかなり危険なアプローチであるということは、ここで正直に言う価値があります。聴衆、顧客、ビジネスを失望させるリスク。この記事では、このようなリスクを軽減する方法について主に説明します。メトリック（いくつか）を注意深く正確に選択し、それらをリアルタイムで監視します。何か問題が発生した場合は、すぐに実験をオフにします。

• 2つ目は、もちろん速度です。戦闘条件での実験は、結果をはるかに正確かつ迅速に示します。

先に進む前に、いくつかの小さな勝利を修正しましょう。





透明性のある実験プロセスは、目標を達成する方法の質問に対する答えを私たちに与えます。そして、実際の状況ですぐにテストを実施することで、私たちは聴衆をよりよく理解し始めます。その結果、開発チームは、ビジネス上の問題を解決する特定の機能を提案するのに十分な専門知識を持っています。



悪くはありませんが、それだけではありません。今こそ、測定可能性についてもっと話す時です。そして、その間、3番目のガスを床に向けると、風が鳴り響きます。

測定可能性

なぜメトリックが必要なのですか？主に仮説を確認するか、失敗した仮定の影響を減らすため。理論的には十分に根拠のある仮説でさえ、常に成功するとは限りません。そして、彼らが撃つとき、時には膝で。

• -, FoodTech, : , , , .
• -, , , . , , , . ! , , , . , , -.

私たちの経験によると、良いレシピはいくつかの指標がある場合です。1つのターゲットメトリック-それを改善します。そしてさらにいくつかの重要なもの-私たちはそれらを落としてはいけません。



ビジネスと開発の両方が見られる統一された監視スペースを導入します。1つのツールである必要はなく、MetabaseとGrafanaの2つを使用しますが、将来的にはどちらかを選択する予定です。最も重要なことは、ビジネスと開発の両方の同僚が見える単一のスペースが必要です。そして、必ず危険信号を特定してください。

赤い旗

はい、これらは、実験中に超えてはならないメトリックのいくつかのしきい値です。反応が交差した場合は、反応についてビジネスに同意し、アラートを投稿することは価値があります。



そしてもう1つの小さな勝利：「なぜ誰かが私のコードを必要とするのか」という質問に答えました。彼女のことを忘れないでください！





開発側のこの不確実性は、コードが本番環境に留まらない理由を常に理解しているとは限らないことを思い出させてください。率直に言って、これについては悲しかったです。開発からビジネスメトリクスまでピアツーピアのイマージョンアプローチを採用することで、お客様のソリューションに対する理解を深めるだけでなく、最終結果に焦点を当てることでビジネス上の問題を解決するための意欲を高めることができました。



さて、私たちは実験と透明なプロセス、測定基準と測定可能性を理解しました。前方がフィニッシュラインで、4番目をオンにし、勝利するまで最高速度でオンにします。

自律性

上記のすべては、私たちがビジネス側と開発側の両方から自律的になったときにのみ、可能な限りうまく機能します。

要旨

ここで、自律性とは、決定を下す際の最小の依存関係を意味します。承認プロセスに溺れることなく迅速に決定を下すために、ビジネス側で何をしましたか？ GISTフレームワークを実装しました。





このアプローチは、目標、アイデア、ステッププロジェクト、タスクです。同社には、経営陣がすべての従業員に透過的に伝達するという明確なビジネス目標があります。これらの目標を達成するために、従業員はアイデアを投げかけます。1ダースまたは1つのアイデアがあります。アイデアはまだプロジェクトではないことが重要です。これらは私が実装したいアプローチのいくつかです。ステッププロジェクト-これらはすでにプロジェクトです：これらのアイデアを実装する非常に大きな機能。Just In Timeの例では、宛先はまさにステッププロジェクトです。最後のレベルは、私たちが慣れているタスクです。これはすでに分解されたステッププロジェクトであり、人件費で見積もられています。



では、このアプローチはどのように自律性を達成するのに役立ちますか？この機能を作成することを提案すると（Just In Time）、ビジネスは次のことを透過的に認識します。

1. 機能を実装するサイズとコスト。
2. 彼はどのような考えを実行していますか。
3. 会社の具体的な目標は何ですか（影響）。

次に、同じ基準（コスト、影響）に従って、隣接するステッププロジェクトと比較する必要があります。私たちは会議を開き（彼らは私たちと定期的に）、話し合い、優先順位を付け、決定を下します。



とてもシンプルでわかりやすいように見えます。私たちの場合はそうです、そしてそれは機能します：ビジネスは迅速に決定を下します、私たちは幸せです。しかし、これは自律性への第一歩にすぎません。開発側からもブロックされるべきではないからです。

内部ソース

社内のみのオープンソースのようなものです。Delivery Clubのアーキテクチャはマイクロサービスであり、現在では100を超えています。多くの場合、機能を作成するには、チームが担当するコンポーネントだけでなく、隣接するサービスも変更する必要があります。そしてここに2つの方法があります：

1. 他のチームのバックログに改善を加え、みんながそれらを作ることに同意します。
2. 自分でやれ。

私たちの適応では、プロセスは次のように機能します。ジャストインタイムの大きな機能があり、3つのサービスグル​​ープに影響します。

• R＆Dが担当する自動割り当てプラットフォーム、
• ロジスティクスプラットフォーム、
• パートナー（レストランやショップ）とのやり取りのコンポーネント。

私たちはこれを行います：

1. すべてのタスクをR＆Dチームのバックログに収集します。
2. チーム内で優先順位を付けて配布し、どの人がどのコンポーネントを改良するかを決定します。
3. 実装の微妙な違いについて、ロジスティクスチームおよびパートナー領域の技術リーダーに同意します。
4. 私たちは自分自身を成長させ、同僚はレビューを行います。
5. 次に、自分でテストします。
6. 私たちはすでにサービスオーナーに本番環境への移行を提供しています。

本番環境に移行した後も、これらの改善は、これらのサービスを所有するチームの責任の領域に残ります。



正直なところ、このアプローチは完璧ではなく、リスクがあります。主なものはタイミングです。ほとんどの場合、サービス所有者が行うよりも2〜2.5倍長くコンポーネントを変更します。



しかし、その利点も明らかであり、実装のわずかな遅延をはるかに上回ります。それは予測可能性です。ここで重要なのは、他のチームには独自のバックログと優先順位があり、ほとんどの場合、「緊急に」タスクを実行できないことです。したがって、私たちのビジネスの締め切りは現実的であり、他のチームの優先順位が変更される可能性の影響を受けません。



だから、おめでとうございます-終了、勝利！





迅速で透過的な意思決定のためのGISTフレームワークと、開発における自律性のための内部ソースアプローチを実装しました。これで、パズルのすべてのピースが組み立てられました。締めくくりの時間です、それは面白いレースでした、あなたの参加に感謝します！まとめましょう。

結論

• 実験は、目標を達成するための透過的で効果的なツールです。
• 実際の環境で実行することで、オーディエンスを調査します。これにより、毎回変更を加えることができ、すべての機能を本番環境に残しておく必要がない理由も理解できます。
• しかし、混乱を避けるためには、明確なプロセス、役割の分配、責任者の任命が必要です。
• 実験のアクティブフェーズと分析中に、いくつかの主要なメトリックを一度に監視し、結論を出すことを忘れないでください（この場合、3つのボタンのいずれかを押してください）。
• 開発において迅速な決定と自律性を行うことは、結果を達成し、チームの意欲を維持するのに役立ちます。

RIT ++ 2020会議からのレポートのビデオ録画。





以上です、このレースに一緒にいてくれてありがとう。私たちはまだ始まったばかりであり、大きな課題がまだ先にあると確信しています。喜んで共有します、またね！