エンジニアリングチームと製品チームの間で効果的な相互作用を構築します

@innubis



現実には、成功する製品は、オーディエンスの新しいニーズを理解し、予測し、敏感にならなければなりません。 さらに-新しいトレンドを設定します。 これは必然的に製品開発に関わるエンジニアリングチームに義務を課します。エンジニアは常に製品プロセスに没頭し、あらゆる種類の実験を行い、同時に効率を高いレベルで維持する必要があります。



Badooの私たちは比較的小さな力（私のチームでは30人）で、品質、計画、サポートを失うことなく、毎月約100の新機能を展開しています。 この記事では、「馬に乗って」いる方法と、エンジニアリングチームと食料品の相互作用をどのように構築したかについて説明します。



私たちの経験は他の企業にとっても興味深いものになると確信しています。 そして、試行錯誤と継続的な改善を通じて開発したアプローチが、誰かを本当に助けることを願っています（そして理想的には、プロセスを構築する時間と労力を節約し、望ましい結果をもたらすでしょう）。



私の名前はDmitry Semenikhinです。Badoo機能のチームリーダーです。 私はここでほぼ6年間働いており、私の目の前のこの時期に、チームとそのプロセスの両方の急速な進化（製品開発のコンテキスト）がありました。



この記事のプロセスとは、エンジニアリングチームと製品チーム間の相互作用のシステム、この相互作用を改善および簡素化するために設計された特定のルールと推奨事項のセットを意味します。 しかし、何かを改善し始める前に、解決したいタスクを決める必要があります。 それらをキー値と呼びます。 私たち自身のために以下を開発しました：

• 透明性 プロセスのすべての参加者は、自分と関連するチームが何をしているかを理解し、それが何のためにどのように行われているかを理解する必要があります。
• スピード 。 私たちは、多くの承認、空の議論、些細なことの「研磨」に多くの時間を費やす余裕はありません。 アイデアから生産のプロトタイプまでのパスは、必要な品質が許す限り最小限である必要があります。
• 柔軟性 。 市場の変化に可能な限り迅速に適応し、迅速に変革し、あらゆる課題に迅速に対応する必要があります。

スキーム1（スタートアップ）

2012年に当時の革新的なモバイルの方向でチームに参加しました。 5人のバックエンド開発者と1人のプロダクトマネージャーがいました（彼は顧客でもあります）。 3つのクライアントチーム（iOS、Android、およびモバイルWeb）もありましたが、主にバックエンドチームの仕事についてお話します。



タスクと計画の設定は簡単でした。 プロダクトマネージャーはビジネスから要件を収集し、それらを単純な技術要件にまとめ、優先順位を付けて、チームのタスクのリストを作成しました。 さらに、タスクは、他のチームの開発者とのコミュニケーションを確立し、それらのタスクを実稼働にもたらした開発者に渡されました。 当時それが機能した理由：

• 優先順位の単一リスト （リソースが解放されるとすぐにリストから一番上のタスクを取得します）。 どの開発者もどんなタスクにも取り組むことができることを心に留めておくべきです。 （透明性と柔軟性）
• 簡単なコミュニケーション。 プロダクトマネージャーとビジネスは、エンジニアリングチームが何をしているかを確認できます。各タスクの進捗状況を追跡するのは簡単です。 不明な点がある場合は、1回の電話またはチャットメッセージで問題が解決します。 （透明性と速度）
• 頭の周りのティムリッド。 Lidaがチームがリードするすべてのプロジェクトを覚えておくのは簡単です。注文、期限などについて他のリードと同意するのは簡単です（透明性と速度）
• 明確で便利なプロセス。 Jiraでフィルターとダッシュボードを簡単にカスタマイズします。 リストは1つで、タスクはほとんどありません。 （透明性、速度、柔軟性）

そして、私たちはかなり長い間そのようなスキームで生きてきました。 結局のところ、彼女はスタートアップスタイルに可能な限り近いです！ 誰もがすべてを知っており、誰もがすべてに参加しています。 このプロセスは、可能な限りシンプルで簡単でした。 「私たちは若かった…」:)

しかし、何かがうまくいかなかった

時間が経つにつれて、サーバーチームが成長し、自然に数人のグループに分かれました。 各グループは特定の領域（メッセンジャー、検索、通知など）、またはJiraに関してはコンポーネントを担当していました。 一方、製品チームも成長し、より多くの顧客を獲得しています。 この時点で、私たちはスキームの欠点のいくつかを認識しましたが、慣性によって問題を正確に解決し続けました。 そして彼らは...



最初の問題：リスト内の分布は、チームが分割された方向と相関していなかったため、優先リストからタスクを抽出する順序を保証できなくなりました。 したがって、一部のグループは非常に忙しく、他のグループは食料品の仕事で過負荷になる可能性があります。 このため、プロダクトマネージャーは、私たちがランダムに作業しているか、フル稼働していないと感じていました。



2番目の問題：不整合と不透明度。 プロセスには多くの参加者がいたため、さまざまなチームの作業に非同期があり、同意することがより困難になりました。 その結果、チームとディスカッション（誰が何をいつ開始するか）の作業を同期させて、会議に多くの時間を費やしました。



一般的に、私たちのコアバリューはすべてすぐに苦しみました。

スキーム2（頭の周りの計画）

特定された問題に包括的な方法で対処しました。



まず、各プロジェクトを段階に分けたインターフェイスを開発しました（たとえば、「プロトコル-請求-サーバーAPI-Android-iOS」）。その後、進行状況と依存関係を簡単に確認できました。 これはJiraの一種のアドオンで、Jiraの組み込みツールよりも便利な形式でプロジェクトの全体像を見ることができました。 透明性が向上しました。



次に、サーバーチームは、クライアントチームの計画を個別に慎重に監視し、当面の計画にリストされているプロジェクトのみを開発に取り入れました。 これを行うために、クライアントチームごとに、サーバーチームの責任者が任命され、週に1回「彼の」クライアントチームの計画を更新し、残りのチームに通知しました。 私たち自身の経験から見てきたように、サーバー側を事前に開発することは非常に危険です-両方の優先順位が変更される可能性があり、機能の要件も非常に危険です。 透明性と速度が向上しました。



第三に、クライアントチームの計画を知っていれば、たとえば、一部のグループが過負荷であり、他のグループが過負荷でないことを確認して、作業をより有能に整理できます。 この場合、製品マネージャーに優先順位の変更を依頼するか、mejuの作業を再配布しました。 たとえば、ある開発グループが別のオーバーロードされたグループのタスクに参加して、優先順位リストの正しい順序を確保できます。 柔軟性がより柔軟になりました。 :)

スキーム3（垂直）

時間が経っても、私たちのチームは成長を続けました。 また、エンジニアの方向（コンポーネント）による分割により、非常に簡単にスケーリングできるようになった場合、製品チームはモノリスとして存在できなくなるため、方向（垂直）にも分割されました。 たとえば、Comms、Revenue、Core、Next genアプリケーションがありました。 つまり、製品チームは会社のビジネス目標に従って分割されました。これは論理的です。 その結果、1つの優先順位リストではなく、条件付きで4つの独立した結果が得られました。 各製品ライン内で、タスクの優先順位リストが作成され、「降順」されました。





図 1 4つの独立した製品バーティカル（ストリーム）は、エンジニアリング部門全体のタスクリストを形成します。 その後、タスクは、仕様に従って適切な開発グループに分類されます。



さらに、各業種には、承認されたエンジニアリングリソースの割り当てがありました。 相対的に言えば、垂直Aは今月の時間の30％、B-20％、C-40％、D-10％を受け取ります。 次に、進行中の製品タスクのJiraでスライスを撮影し、垂直に分割してプロットした最も単純な統計を作成しました。 これらのグラフを見て、どの垂直に注目する必要があるかを決定しました。





図 2各部門の開発リソースの実際のコストを追跡して、正しい割合を維持します。



このスキームは非常に機能しており、エンジニアリングリソースの不足をほとんど常に経験している（そして経験し続けている）という事実がない限り、全体として私たちのすべての価値に対応しています（ちなみに、 才能を探しています！ ）。 これにより、製品チームは、特定の業種の特定のプロジェクトがどの時点で開発に取り入れられるかを理解していませんでした。



垂直に割り当てられた割り当て、およびコンポーネントごとの社内エンジニアリング部門を考慮すると、垂直の3番目の場所にあるタスクが非常に長い間そこにハングアップしたり、このプロジェクトを担当するグループが完了しなかったりすることがあります過負荷でした。



説明します。 このスキームでは、製品チームは、私たちの部門を30人以上のモノリシックリソースとして認識しました。たとえば、ある部門が10個の新しいタスクを「落とし」ます。 しかし、実際には、これらの10個のタスクはすべて、このグループが担当する同じ技術分野に属しているため、1つの開発グループに分類できます。 このグループには5人しかいないとします。 この場合、チームが合理的な時間内にそのようなタスクのストリームに対処できなかったことは明らかですが、製品チームにとってこれは決して明白ではありませんでした。



この状況下で、悪いことが起こり始めました。 プロダクトマネージャーは、エンジニアリングリーダーに「ハング」プロジェクトを押し付け、リストをランダムに並べ替え、個々のタスクをリストの先頭に移動し、他のタスクを「プッシュ」し始めました。 リードは常にストレスにさらされ、全員を満足させようとすると同時に、サポートや技術プロジェクトのために何らかの形でリソースを残そうとしました。 その結果、多くの製品プロジェクトが実装されましたが、何らかの理由でこれは満足をもたらしませんでした。



そのように生きることは不可能でした！ 要約すると、私たちがその時に抱えていた問題をもう一度概説します。

• 計画の複雑さ。 プール内の多数のタスクについては、いつタスクを実行するかを言うことは不可能でした。
• その結果、 開発プロセスの不透明度。 他のチームは、それが依存するタスクがいつ完了するかが不明確だったため、プロジェクトの各部でいつ作業を開始できるかを理解できませんでした。
• チーム内のやや緊張した状況 （エンジニアリングチームと食料品の両方）。 誰もがみんな不満でした。
• 製品チームの要求に応えようとする試みの結果として、製品開発へのフォーカスがサポートおよび技術的負債を損なうようにシフトする 。

そして、行動を起こしました。

スキーム4（現在）

まず、内部構造を製品チームに開放することにより、透明性を向上させることにしました。 これで、5人がアプリケーションの1つの機能を担当し、3人だけが他の機能を担当していることがわかります。 このようなオープンなプロセスには素晴らしいボーナスがあります。同僚のリソースを尊重することです。 製品チームのメンバーは、誰が何で忙しく、どれくらいの時間忙しいかを確認し、タスクを計画するときにこれを考慮します。



次に、開発チームの個別のバックログの形成に基づいて、より明確な週次計画を導入しました。 製品チーム（すべての業種）が毎週、特定のグループのメンバーシップに従ってタスクのリストを作成し、優先順位を付けます。 さらに、どちらのタスクがより重要であるかは互いに合意しており、エンジニアリングリーダーはすべての製品分野に対応するためのバランスをとる必要がなくなりました。 さらに、グループのリーダーは、チームの能力と提案されたタスクの複雑さを考慮して、グループが今週解決し始めることができるのと同じ数のタスクをリストの先頭から取得します。 その後、すべてのグループに対して実行されたタスクの単一リストが製品チームに表示され、必要に応じて調整が行われます（何かが追加され、何かが置き換えられます）。 その後、計画は承認されたと見なされます。





図 3製品チームは、各開発グループのバックログを独立して形成します。 エンジニアリングリードは、1週間で解決できるタスクのみを受け入れます。



この場合、1週間の計画は、1週間で解決するために着手するタスクのリストであることに注意してください。 タスクの作業を完了するための期限は期日フィールドに表示され、開発者がタスクの作業を開始した時点で設定されます（以下で期日についてもう少し説明します）。



結果として得られたもの：

• 透明性 誰もがどのタスクが計画されているかを見て、現在の状況とタイミングを評価できます。 これらはすべて、すべての人にとって便利な形式で提示されます。
• 柔軟で簡単な計画。 「週」の期間は、理由のために選択されました。 私たちの条件では、これはあなたが本当に重要なことに集中し続けることができる最適な期間です。
• 落ち着いた雰囲気。 承認済みの計画があり、現在取り組んでいます。 予期しない予定外のタスクを待つ必要はありません（少しcでした：もちろん、それらは予想される必要がありますが、以前と同じ量ではありません）。
• 操縦の自由。 リードは、以前のスキームを使用したときのプレッシャーを免れ、技術プロジェクトを計画し、バグ修正と技術的負債のためにリソースを静かに確保できます。

欠点はありますか？ もちろん。 たとえば、今では、製品チームは彼女にとって珍しいことをしなければなりません。別のチームのリソースの計画に参加することです。 これからは、エンジニアはチームメンバーが新しいタスクを削除して完了するまで待つための「ブラックボックス」ではありません。タスクバックログを作成するときは、エンジニアリングチームの機能の断片化を考慮して重要なタスクをグループに均等に分散する必要があります。 幸いなことに、Jiraの組み込みツールはこれを比較的簡単にします。



また、製品チームにとって、10人のグループに提案された10人のうち1週間にリードが3つのタスクしかとらなかった理由がまだ明確ではありません。 ここで、そのようなソリューションの核心にあるものを口頭で説明するだけですが、それを単純化して視覚化したいと思います。 たとえば、すべての新しいタスクのサイズを暫定的に推定できます。 これにより、開発者のリソースをより効率的に使用できます。 プロダクトマネージャーが特定のタスクの開発に非常に時間がかかることを知っていた場合、それを提案することはできませんでしたが、いくつかの単純なタスクを優先して選択していましたが、全体としてビジネスに大きな影響を与える可能性があります。



これらすべてにもかかわらず、私の意見では、このスキームの利点はマイナス以上のものです。 したがって、今ではそれを使用しますが、すぐに相互作用メカニズムを完成させるために問題のある領域を分析することを止めません。

重要な追加

エンジニアリングチームと製品チームの間の相互作用スキームの説明の邪魔にならないように、言及するのに非常に重要ないくつかのポイントを別の章に入れることにしました。

期日

すべての製品タスクの期日を設定し、このパラメーターのコンプライアンスを監視します。 新しいタスクを受け取った開発者は、まずそれを詳細に分析し、自分の仕事、関連チームの仕事、リスクと依存関係を評価する必要があります。 はい、これは間違いではありません。 彼がコードの作成を終了した日付ではなく、QAでタスクを与えた日付ではなく、タスクが実動で表示された日付ではありません。



イリヤ・アジェフは、なぜそれが重要であり、どうやってこれに至ったのかを彼の記事で説明しました。 簡単に言うと、私たちにはすべての開発者がいます-これは最初から最後までタスクを実行する小さなプロジェクトマネージャーです。 そして、彼は結果と期限に責任があります。 期日が守られない場合は、理由を分析し、これが将来発生しないことを確認するか、システムのボトルネックを見つけて修正します。 また、開発者は、プロジェクトの進捗状況、プロセスで発生する問題、状況チケットの特別なフィールドでどのように誰によってブロックされるかについて、関心のあるすべての人に簡単に通知します。

プロジェクトチーム

チームの機能分離に基づいた標準的なタスク開発プロセスの計画と存在にもかかわらず（各部門は製品の一部を担当します）、多くの場合、このメカニズムは柔軟性と効率が十分ではありません。 最も顕著な例は実験的なタスクです。特定の機能を開発する必要がある場合、そのタイプとロジックは完全には理解されていません。 初期プロトタイプを迅速に作成し、その後多くの編集を行って製品を改善する必要がある場合（および複数のチームが同時に作業する必要があります）。



そのような場合、プロジェクト期間中、必要なすべての部門からのリソースがあるクロスファンクショナルプロジェクトチームを作成します。 そして、多くの場合、標準プロセスをバイパスして機能します。 必要に応じて、このようなチームに個別の計画プロセスと開発プロセスが導入され、製品チームとやり取りするためのスキームが導入されます。

あとがき

誰もがすべてを知っていて、誰もがすべてを知っている小さなチームがある場合、特別な相互作用メカニズムは必要ありません。 すべてがそのように動作します！



しかし、成長し始めるとすぐに、プロセスの参加者の仕事をよりよく調整する必要があり、コミュニケーションのためのオーバーヘッドがあります。 この時点で、毎週の集会、スタンドアップ、シンクなどのようなプロセスを導入する必要があります。



プロジェクトが成長して、1つの部署内でも従業員は何も置き換えることができないようになると、基本的な変更が必要になります。これは、構造と内部の詳細を考慮したプロセスです。



そのため、スクラムやかんばんなどの既成の方法論を採用せず、独自の機能とアドオンを備えた特定の中間オプションを使用しています。 そして、私たちはプロセスを改善し続け、停止するつもりはありません。お気づきかもしれませんが、まだ十分な問題があります。



そして、示された問題をどのように解決し、解決しましたか？ コメントで共有してください。



ご清聴ありがとうございました！



PS 今週の土曜日、 Techleads MeetupがBadooのモスクワ事務所で開催されます。 空席はもうありませんが、 YouTubeチャンネルで放送を見ることができます 。 社内でプロセスを構築し、ITを管理するトピックに興味がある場合は、ぜひご参加ください！