Delivery ClubTechでの製品変革

こんにちは、Habr！前回の投稿でお約束したように、引き続きデリバリークラブテックをご紹介します。今日は製品の変革についてお話します。



偶然にも、2018年10月にDCに到着したことで、チーム内のすべてのプロセスが完全に再構築されました。その瞬間、IT部門、そして実際には会社全体が新たな課題に直面しました。古いプロセスが新しい要件を満たしていないことは明らかでした。彼らは主に市場投入までの時間の減少に関心を持っていました。



これらの変更、新しい課題、新しいチーム構造、プロジェクトマネージャーやテクニカルアナリストなしでの作業方法、そして本日お伝えしたい製品開発へのアプローチについてです。



2018年10月、私は消費者責任者に就任しました。これがデリバリークラブへの旅の始まりでした。方向性の範囲内で製品チームを編成し、プロセスを説明し、形式化し、他のすべての領域に拡張する必要がありました。さらに、タスクはチームのパフォーマンスメトリックを導き出し、採用フレームワークをゼロから開発することでした。

チームの特徴

最も重要な課題は、開発プロセスから予測可能性と透明性を実現することでした。当時、パフォーマンス指標がなかったため、状況は複雑になりました。しかし、確かなことは、リリースは定期的に行われず、その構成はリリース自体の時点でのみ明確でした。



もう1つの問題は、製品を中心にチームが形成されていないことでした。同じ開発者がまったく異なるプロジェクトに参加できるため、ビジネスとのこの複雑なコミュニケーションは、特定のタスクに明確に焦点を当てることができませんでした。そのため、当初はIT部門の構造を再構築し、プラットフォームチームから製品チームに移行することが決定されました。



プラットフォームアプローチでは、バックエンドの人々は別々に座っていて、フロントエンドは別々に座っていて、各チームにはタスクを分散するチームリーダーがいました。この構造の明らかな欠点：開発者はプロセスと製品に没頭しておらず、共通の目標に関心がなく、チームは異なる焦点を持っており、製品専用のリソースもありませんでした。その結果、開発者は焦点がぼけ、目標は達成できませんでした。なんらかの奇跡で目標を達成できたとしても、製品管理者と関係者とのコミュニケーション不足により、当初の予定とは異なることが多かった。







最初に決定されたのは、1つのチーム-1つの製品です。リソースが割り当てられます。つまり、チームはこの製品に対してのみタスクを実行し、他の製品に対してはタスクを実行しません。同様の製品に取り組んでいるチームが開発の方向性を形成します。最初の変換の結果、次の4つの方向になりました。

1. 消費者
2. ロジスティクス
3. ベンダー
4. 内部

2番目に決定されたのは、各チームに製品マネージャーを割り当てることです。彼はチームの1人でもあります。製品マネージャーは、製品変更の戦略を策定し、チームが焦点を当てる製品メトリックを作成し、スプリントの目標を設定します。



その結果、「Product Manager-Team Lead-Dev-QA」というセルが表示されました。開発者としてバックエンドとフロントエンドの開発者が含まれますが、フロントのないチームもあります。フロントエンダーは、Web AngularとJS、またはiOS / Androidのいずれかです。



現在、各チームの平均人数は5±2人です。何故ですか？私たちはすぐにこの公式にたどり着きませんでした。私たちの統計によると、最も予測可能な結果を​​達成できるのは、まさにこのチームの構成です。つまり、チームは製品に大幅な変更を加えるのに十分な機能を引き受けることができますが、同時に、計画の複雑さは、より多くの人がいる場合よりも低くなります。つまり、計画エラーが最小限になります。



しばらくの間、チーム内の役割を実験して、モバイル開発チームのリーダー（iOS / Android）とバックエンドチームのリーダーがいました。しかし、最終的にはマトリックス構造になりました。

• 1人のチームリーダー（原則として、バックエンドの誰か）は、QA、バックエンド、およびフロントエンドのマネージャーを直接監督しています。
• product- « — — QA».
• — . . , QA- , CI/CD, QA- .
• - , .
• .

私たちのもう1つの特徴は、プロジェクトマネージャーや技術アナリストがいないことです。これはもともとDeliveryClubの場合でしたが、変更しないことにしました。製品に焦点を合わせているチームに問題があったことを覚えていますか？では、なぜチームと製品マネージャーの間に仲介者を作るのでしょうか。チームはまず、Jiraでチケットを閉じるだけでなく、機能がエンドユーザーにどのように影響するかを気にすることが重要です。これを行うには、人々はコンテキスト、ドメイン、ビジネス、さらには製品メトリックや財務メトリックに没頭する必要があります。



その結果、開発チームと製品マネージャーの間の対話が進行中です。開発者は、製品マネージャーからタスクのリストを取得して、これらすべてを開発するために出発するだけでなく、数時間で彼のところに来て、たとえば、「ここのボタンをもう少し簡単にすることができますが、1週間速くすることができます」と言うことができます。数字で、製品マネージャーはOKと言います。



したがって、技術チームは、技術分析、評価、および分解のタスクを独立して実行し、製品マネージャーとのスプリントを計画します。これを機能させるために、スプリントを開始する1週間前にスプリントを開始します。これは次のセクションです。

スプリントの開発と計画

事前計画

スプリント開始の1週間前に、製品マネージャーはケースとデザインを持ち込み、「何をする必要があるか」という質問に答えます。技術チームは、それをどのように行うか、そしていつすべての準備が整うかを決定します。



これを行うために、チームには1週間あります。その間、チームリーダー、開発者、QAが集まり、技術的な詳細について話し合い、分解を実行し、評価のためにポーカーを計画してリセットします。この期間中に、QAはテストケースのリストを作成し、それがテストされます。

計画

チームが分解と評価を行うと、計画が始まります。すべてのタスクは8時間に分割されます。スプリント内のタスクの数を数えるために、従業員の数に2週間の反復の80時間を掛け、その結果にフォーカスファクター0.8を掛けます。



さらなるタスクはバケツで打ち負かされます、それらの3つだけがあります：

1. 製品60％
2. 技術債務20％
3. 20％をサポートします。

例を挙げましょう。3人のバックエンダーのチームがあります。これは80 * 3 * 0.8 = 192有効時間です。製品開発に116時間（60％）、技術債務に38時間（20％）、サポートに38時間（20％）を費やします。

グルーミング

月曜日にタスクをスケジュールし、スプリントの途中、つまり1週間後にグルーミングが行われます。最初の週の結果を分析し、スプリントの目標を達成する時間があるかどうかを判断するグルーミングを呼び出します。目標が達成されると、製品マネージャーは同じ会議で次のスプリントの計画を提示し、サイクル全体が繰り返されます。

デモ

スプリントの論理的な終わりはデモです。ここでは、すべての開発チーム、利害関係者、ビジネスの同僚、さらにはデリバリークラブの責任者を招待します。



リリースを担当する同僚がプレゼンテーションを準備し、スプリントの成果と克服された困難について話します。新機能がユーザーにどのように役立つかについて、製品ストーリーと洞察を共有します。



今日はチーム全体にとって重要な日です！

レトロ

私たちにとって、レトロは効率を向上させる方法です。まず、チームのパフォーマンスの指標、つまりスプリントをどれだけうまく閉じたかを確認します。反復の開始時に実行されたタスクに対する完了ステータスのタスクの比率を確認し、このデータをバケットごとに修正します。



たとえば、Productでは、20の問題を取り、17を終了しました。したがって、このバケットの成功率は85％です。私たちの製品開発の順調な進展は、90％以上の指標です。それが低い場合は、Retroでこのメトリックを改善する方法について話し合います。

スプリントワーク

コードレビューとテストの仕組みについてよく尋ねられます。ここではすべてがかなり標準的です。



一日はスタンドアップで始まります。チームは15分間、昨日何をしたか、今日何をするかについて話し合います。



JiraFlowとGitFlowを使用してタスクを処理し、Atlassianスタックを使用します。実行する列を備えたスクラムボードもあります-進行中-コードレビューの準備ができています-QAの準備ができています-人生の準備ができています-完了しました。



開発者がコードを準備すると、Jiraの現在の問題番号でブランチを作成します。これは機能ブランチです。彼はそれをBitbucketのプルリクエストにも送信します。開発者には少なくとも2つの承認が必要です。 Jenkinsとの統合もあります。ビルドがグリーンの場合は、マージできます。技術リーダーとチームリーダーは合併する権利を持っています。プルリクエストのユニットテストを準備する必要がある場合があります。また、これらが重要ではないビジネス領域、重要でないドメイン、または実験的な機能であることがわかっている場合は、意図的に記述しないことがあります。そうすれば、それを切り取ることができます。



すべてが滑らかになったら、テスト用に送信します。テストエンジニアは、自動テストを作成するか、テストケースを手動で実行します。ドメインの重要度によっても異なります。そして、展開します。



このプロセスは時計のように機能すると言えます。しかし実際には、現時点ではチーム内で絶え間ないコミュニケーションがあります。主な焦点は、スプリントの目標と時間通りのリリースです。目標を達成するために、製品の変更について話し合うか、技術的な実装を修正することができます。これはすべて、タスクの作業中に発生します。これは常に、開発者、チームリーダー、製品マネージャー、およびQAの間の対話です。

IT部門の開発の方向性と構造

変革の過程で、私たちは開発の方向性の新しい構造に到達しました。ご存知のように、最初に4つについて書きました。さらに、目標を高品質でタイムリーに実施するには、さらに2つの領域を特定する必要があることが明らかになりました。したがって、現在は6つあります。

• 消費者はすべてカスタム製品、つまりWebサイトとモバイルアプリです。
• ロジスティクス-ロジスティクス、宅配便業者、配達について。
• ベンダー-パートナー（レストラン/ショップ）との統合について。
• 内部-コールセンターとサポート。
• R＆D-科学集約的なタスクを解決します。
• プラットフォーム-アーキテクチャとプラットフォーム全体を改善します。

それぞれの方向には、独自の範囲のタスクと独自の困難があります。

消費者

この方向の優先順位は、ユーザーの幸せです。主な製品指標は次のとおりです。保持、注文コンバージョン率、消費者NPS。技術的な観点から、すべてのデータが迅速に送信されることが重要です。この方向では、エンドユーザーと直接連携するため、おそらく最大の高負荷になります。また、膨大な数のマイクロサービスもあり、そのほとんどがここにあります。



主な製品は、モバイル版を含むWebサイトと、iOSおよびAndroid用のアプリケーションです。2つの主な流れは、食料品の配達とレストランの配達です。他の場所と同様に、技術スタックのプラスまたはマイナス：キャッシュ用のPHP、Go、Postgres、Redis、Memcache、非同期通信用のKafka。

ロジスティクス

この方向性のタスクは、空腹のユーザーに注文を迅速に配信することを保証することです。さらに、必要に応じて宅配便業者の手動制御を支援するディスパッチャ用のインターフェイスを開発しています。



ロジスティクスの主な課題の1つは、注文数が増えるとシステムに負荷がかかるときに発生します。負荷に対処するには、アーキテクチャに品質の変更を加える必要があります。また、事務用品、洋服、本などの配達とは大きく異なります。ここではすべてが少し簡単です。ルートシートを作成し、計画して実行しました。



食品配達では、そのような数は機能しません。私たちはすべてオンデマンドであり、状況は5〜15分ごとに変化します。雨や雪が降り始めると、常に需要が高まります。また、外が晴れていて家にいたくないときは、需要が減ります。休日と週末では、需要プロファイルは平日とは異なります。交通状況と混雑も、特に自動車/オートバイの宅配便が普及している地域では、独自の調整を行います。朝、午後、夕方の時間には、異なる需要プロファイルがあります。



この需要の移行は、モニターによって追跡されます。需要が減少した場合は、検索結果を変更し、「プロモーション」セクションでより関連性の高いオファーを提供します。関連性を向上させるために、ユーザーと変化を観察しているロジスティックゾーンの両方に対してソートをパーソナライズするMLモデルを含めます。



ロジスティクスで取り組んでいる主なアプリケーションの1つは、ライダーアプリです。これは、宅配便業者が注文を受け取る場所と配達する場所を確認するAndroidアプリケーションです。

ベンダー

このエリアは、社内パートナーであるレストランやショップと連携しています。むしろ、個人アカウントを通じてメニューを管理し、検索結果の統計に反応するマネージャーと一緒に。



収集された注文に関するデータと統計のおかげで、私たちはターゲットオーディエンスとレストランの特徴をよく理解しています。私たちは彼らと協力して協力し、顧客が誰であるかをよりよく理解し、マーケティングメカニズムを可能にするのに役立つツールを提供します。また、レストランが価格最適化モデルを開発し、どの料理をいつ、どの順序で表示するのが最適かを理解するのを支援します。



ベンダーの方向で取り組んでいるもう1つの製品は、キッチンの注文が落ちるダッシュボードです。キッチンは注文を受け入れ、その構成を確認し、それを準備する方法を決定し、実際にそれを準備します。注文が準備されると、キッチンはアプリでこれを確認し、注文を宅配便業者に転送します。そして、宅配便業者はライダーアプリで動作します。

内部

この領域は、ユーザーサポートを提供するコールセンターのツールを担当します。実際、これは注文に関連するすべての「管理領域」です。オペレーターは、クライアントを支援し、注文の現在のステータスに関する追加情報を提供し、レストランに送信される前に注文を調整することができます。



この方向性の課題は、そのようなシステムを作成することです。これは、第一に、便利で、オペレーターのすべてのニーズをカバーし、第二に、クライアントができるだけ早く支援される必要があるため、高速です。重要なタスクに加えて、Internalのスタッフは、オペレーターによる1つの問題の処理時間の短縮と、呼び出しの数の削減に取り組んでいます。

R＆D

ビジネスプロセスを変更する必要があると同時に、これらの変更がプラットフォーム全体にどのように影響するかを理解する必要がある場合は、研究開発が関与します。彼らは実験を行い、モデルを構築し、数え、計量します。また、BI部門と最も緊密に連携し、ビッグデータ、MLモデルを操作し、ニューラルネットワークを設計し、需要を予測します。これに関連して、BIは研究とツールでR＆Dを支援します。



研究は主にデータの操作に関するものです。たとえば、何らかの要因を変更した場合のシステムの動作。この領域は最も高いレベルの不確実性を持っているため、R＆Dのほとんどのタスクは現在ロジスティクスから来ています。

プラットホーム

これは技術的な方向性です。まず第一に、彼らはシステムコアを改善し、注文処理をリファクタリングし、モノリスを分解することを目的としています。これは古典的な意味での製品開発ではありませんが、何らかの方法でのすべての改善は、ユーザーがDelivery Clubアプリケーションをより便利かつ簡単に操作できるようにすることを目的としています。応答時間を短縮してページをより速く開き、プラットフォームの容量を増やしてより多くのユーザーが作成できるようにします。注文と同時に、使用経験は彼らにとって可能な限り快適でした。

変革の結果と新たな課題

私たちの仕事は、成長する企業のすべての要件を満たす開発プロセスを構築することでした。チームはビジネスに関与し、互いに多くのコミュニケーションを取り、チーム自身が設定した期限に責任を持ち、彼らの仕事がエンドユーザーにどのように影響するかを理解します。プロセスは透過的で、測定可能で、そして最も重要なことに、スケーラブルでなければなりません。



製品の変革を行い、開発プロセスを最適化した後、各リリースが予測可能になったという結論に達しました。最初は、リリースがいつ、どのような構成でリリースされるかを80％の精度で知っていました。現在、部門内のすべてのチームの平均パフォーマンス指標は90％に成長しています。チームの関与、つまり男性のモチベーションは大幅に向上し、彼らは自分たちが何をしているのか、そしてなぜそれが重要なのかを理解しています。



このプロセスには、製品開発に悪影響を与えることなくできるだけ早くタスクに対応する機能が含まれ、人件費を柔軟に見積もり、製品マネージャーからの要件の変化にタイムリーに対応するための十分なコミュニケーションポイントがあります。実際には、プロセスがスケーラブルであることを確認しました。同じ開発プロセスで、パフォーマンスを損なうことなく、40人から170人に成長することができました。



同時に、私たちは製品の変革がまだ進行中であることを止めず、信じています。2019年の終わりに、チームがビジネスにさらに影響を与える方法について考え始めました。チームには多くの製品の専門知識があり、それを使用して、テクノロジーとビジネスの一種の共生を考え出すことができるようです。さらに、製品の仮説を検証するためのメカニズムを考案する必要がありました。つまり、開発に含まれるタスクの価値を制御することです。これを行うために、GISTプロセス（製品の仮説を検証するためのフレームワーク）について説明しました。これについては、次の記事のいずれかで説明します。



読んでくれてありがとう！