ブレイズ製品チームの再編

公開: 2019-03-27

ソフトウェア製品の背後にある最も重要な原動力は、それを構築する人々のグループと、それらの相互関係です。したがって、チームが可能な限り多くのレバレッジと影響力を持つことができるようにチームを配置することが重要です。

Brazeでは、製品とエンジニアリングの組織がどのように設計されているかを幅広く考えており、機能の優先順位付け、チームの専門知識の開発、製品のより効率的な構築の方法を大幅に改善するのに役立った主要な部門再編成からの学習を共有したいと考えています。

初期の構造：製品/市場の適合性とそれ以降

製品/市場の適合性を見つけ、それを活用してビジネスを成長させることは、すべてのスタートアップが通過しなければならないるつぼです。スタートアップの開発のこの段階を通して、実験のスピードと機会を迅速に活用する能力が重要です。そのために、元の製品チームの構造は次のようになりました。

機能的な専門分野に基づいてチームを分割したこの構造は、いくつかの理由でうまく機能しました。

まず、製品/市場に適合させるまでの過程で、製品の変革に効率的に取り組むことができました。専門家は、コードベースの膨大な範囲を所有し、最も快適な言語、フレームワーク、および設計上の決定を使用できました。大量のカフェインに支えられて、1つの軍隊のプロジェクト「チーム」は定期的に巨大な努力に取り組みました。これには、顧客向けのパブリックAPIの構築や、メッセージ送信インフラストラクチャ全体のオーバーホールが含まれ、多くの場合、唯一のエンジニア、プロダクトマネージャー、デザイナーの役割を果たします。これらのタイプの極端な対策は、大企業では狂気になりますが、初期の成長の間は必要であり、ほとんど日常的です。

さらに、この構造は、10〜15人のチームだけで特定の技術分野を深く習得するのに役立ちました。フロントエンドのモデルビューコントローラーレイヤー、API、高スループットのメッセージ送信コードなど、コア製品の多くの要素は、ほんの数人の個人に完全に理解されていました。

当時、それは単純で、必要なものはすべてありました。スピードがすべてである場合、単純なガイドラインに基づいて整理することで、認知のオーバーヘッドを減らし、最も効果的な場所に注意を向けることができました。

後の構造：成長とスケーリング

しかし、私たちのチームが30または40を超えると、この構造は崩壊し始めました。最終的に、製品チームの再編成を、いくつかの最大の課題に対する解決策として特定しました。戦略的プロジェクトのチームを構成するために、スキルセットとタイムラインを調整するために持続不可能な努力を費やしていました。また、優先順位付けに膨大な時間を費やし、テクノロジーベースのチーム構造が最も重要な製品のニーズに直接対応していなかったため、ビジネス全体ですべての製品の優先順位を強制的にランク付けすることがよくありました。そして最後に、チームメンバーが特定の顧客のユースケースで深い経験を積む機会はほとんどありませんでした。

最終的に、Spotifyで普及したSquad/Tribeモデルに似たアジャイルのクロスファンクショナルチームを中心に構成された組織に切り替えました。新しい組織構造は次のようになります。

私たちのチームの大部分は、私たちの製品またはビジネスの重要な領域に対応する「製品分野」内で働いています。例えば：

私たちのEメール＆エンタープライズチームは、Eメールを上から下まで実行し、許可管理など、多くの最大の顧客にとって重要な特定の製品分野を実行します。
当社のMessaging＆Automationチームは、ユーザーセグメンテーション、メッセージング、および当社の主力オーケストレーション製品であるCanvasに関連するいくつかの製品領域を所有しています。

各業種は特定の顧客ニーズに対応しているため、業種内では、優先順位付けは（比較的）簡単であると予想されます。 Visual Design、DevOps、インフラストラクチャエンジニアリンググループなどの特定のチームは、プラットフォーム全体にまたがり、主要な領域で一貫性を構築しています。

影響

再編成により、チーム間の依存関係が大幅に減少しました。以前は、特定のプロジェクトに特定の時間に専門的なスキルセット（エンジニアリング、設計、製品管理など）の適切なバランスを割り当てるという数独のようなスケジューリングの問題に苦労していました。また、短期的なインセンティブも調整しました。移行前は、チームは、無関係な目標を目指していたカウンターパーティに依存していることがよくありました。新しい構造により、製品チームは独立し、タイムラインをはるかに細かく制御でき、目標に完全に対応し、生産性と士気を向上させます。

新しい組織の設計により、優先順位も改善されました。たとえば、Eメールおよびエンタープライズチームは、Eメールインフラストラクチャのアップグレード、コアEメール機能の構築、またはエンタープライズユーザビリティの問題の修正のいずれかを決定する必要がある場合があります。3つすべてが同様の方法でお客様のニーズに関連しているため、簡単で定量化可能な決定です。。

あまりにも多くの優先度の高いニーズに苦しんでいるチームは、その製品領域がより多くのリソースを必要としていることの指標でもあります。これにより、困難な優先順位付けの問題を人員配置のニーズとして再構成することができます。これは依然として困難ですが、概念的には簡単に対処できます。

最後に、ほとんどのチームを特定の製品分野に集中させることで、個人は時間の経過とともに深い専門知識と生産性の高い仕事上の関係を築くことができました。当初、構築の最初の数年間で、個人は基本的に製品全体とコードベースを頭の中に持つことができましたが、私たちが成長するにつれて、これは不可能になりました。製品の問題はフラクタルです。よく見るたびに、ニュアンスと深みが増します。その結果、製品またはコードベースの特定の領域で何時間も費やし、そのビジネスニーズを深く理解することは、実際の製品のブレークスルーを達成するための最良の方法の1つです。さらに、焦点を絞った長期的なチームを作成することで、所有権と信頼関係が構築され、一貫した一連の協力者間の暗黙の協力関係が固まります。

もちろん、完璧なシステムはありません。製品指向の柱に焦点を当て、全体的な優先順位を犠牲にして、チームがローカライズされたニーズに合わせて最適化する可能性を高めました。たとえば、グローバルな問題（「フロントエンドフレームワークを変更すると全体的なエンジニアリングの速度が上がる」）ではなく、ローカライズされた技術的負債（「このコントローラーは面倒」）に焦点を当てることができます。このニーズを見越して、上記の分野横断的なチームを設立するための措置を講じ、フロントエンドコンポーネントとデザインパターンの総合的な製品/設計システムを構築する委員会など、他の幅広いプロジェクトに専用の委員会を使用しました。。

私たちの新しい構造はまた、全体的で変革的な製品の変化のためにより高い活性化エネルギーをもたらします。バックエンドAPIなど、製品の一部の領域は、複数のチームによって共同所有されています。コードベースの幅広い横断的な領域に抜本的な変更を加えるためのしきい値が高いため、このタイプの構造は、製品のスケルトンが大部分形成された後に最適に機能します。

要点

全体として、再設計された製品組織構造に満足しています。チームの依存関係、優先順位付け、および長期的な製品の専門知識の構築に関する課題を解決または大幅に改善し、拡張方法に関する有用なロードマップも用意しています。特に、次のことを学びました。

依存関係を取り除き、インセンティブを調整することで、効率が大幅に向上します。
リンゴからリンゴへの優先順位付けは、より単純でより効果的です。
特定の顧客またはビジネスニーズに関する深い専門知識は、より良い製品の成果につながります。
同じチームメンバーと長期間にわたって協力することは、優れた協力関係を築くために重要です。

特定の重要な特性を共有するチームには、この構造をお勧めします。製品マネージャー、設計者、エンジニアなどの機能の専門家が同等の利害関係者である部門横断的な組織。統合された製品開発チームの約15〜20人以上。そして、最も重要なのは、製品と市場の適合性です。そして、このタイプのチーム構造があなたにとって魅力的に聞こえるなら、私たちは採用しています！