チームの立ち上げは、機能の開発速度の向上を保証しますか?
公開: 2020-03-28リリース速度を上げるためにチームを強化する際の重要な要素の 1 つは、製品チームからスプリント チームに明確さを伝えることです。
スムーズなスプリントの実行は、製品チームとスプリント チームの両方からの顕著な貢献の結果です
「最初から正しい (FTR)」の哲学は、すべてのチーム メンバーが共通の目標に向けて調整するのに役立ちます。
スタートアップが初期段階から成長段階に移行すると、優先順位が大幅に変化します。 とりわけ、機能の速度は優先事項として際立っており、成長を追求する上で重要な役割を果たしています。
私が一緒に働いていた、最近シリーズ A ラウンドで調達したシード資金によるスタートアップの創設者から、6 か月で新しい機能をリリースするためにエンジニアリング チームを 2 倍にするように依頼されました。 しかし、それだけがサイクル タイムの短縮に関係する要因なのでしょうか? 答えるために、私はこの一般的な「誤解」の背後にある無視された側面に対処することにしました。
リソース キャパシティは、本番環境への頻繁なリリースを促進する重要な要素の 1 つですが、これだけではサイクル タイムの短縮を保証することはできません。 16 以上のスタートアップ向けの製品を開発する中で、私はアーリー ステージからグロース ステージへの移行を何度も目の当たりにしてきました。 この経験から、スタートアップの創業者が考慮すべき重要な要素をいくつか紹介します。
明確さを伝える: トップダウンの本質
リリース速度を上げるためにチームを強化する際の重要な要素の 1 つは、製品チームからスプリント チームに明確さを伝えることです。 スプリントがあいまいな状態で開始されたり、開始するのに十分なストーリーがない場合、スプリント配信率は悪影響を受けます。 あいまいに定義されたストーリーやスプリントの途中にタスクを含めると、ペースが遅くなり、その結果、スプリント チームは計画どおりに成果をあげることができなくなります。
スムーズなスプリントの実行は、製品チームとスプリント チームの両方からの顕著な貢献の結果です。 製品チームは、チームがそれに応じて成果物を計画できるように、少なくとも四半期のロードマップを準備してスプリント チームと共有することで、その役割を果たすことができます。
一方、スプリントチームは、製品チームに製品のバックログを取得し、毎週または隔週でそれを整理して、集中的な配信を確実にするように働きかけ続ける必要があります。
「バグのない」リリースを自動化する
「効率とは、物事を正しく行うことです。 有効性とは、正しいことを行うことです。」 – ピーター・ドラッカー
自動化を考えるとき、それは後者のカテゴリーの例です。 機能開発がスピードを上げた瞬間、適切なプロセスが整っていないと、生産が機能しなくなる可能性が非常に高くなります。 製品が新機能の開発に対応できるほど安定していない場合、チームは新機能の構築よりも問題の修正に多くの時間を費やします。 その結果、エンジニアリングの速度が低下します。
ここで、CI/CD (継続的インテグレーションと継続的デプロイ) の出番です。 ここでは、徹底的なユニット、統合、および自動化テストのカバレッジにより、出荷されたものは何でもシステムを壊さないことが保証されます。
あなたにおすすめ:
RBI のアカウント アグリゲーター フレームワークがインドのフィンテックを変革するためにどのように設定されているか
起業家は、「Jugaad」を通じて持続可能でスケーラブルなスタートアップを作成することはできません: Cit...
メタバースがインドの自動車産業をどのように変革するか
反営利条項はインドのスタートアップ企業にとって何を意味するのか?
Edtech スタートアップがインドの労働力のスキルアップと将来への準備をどのように支援しているか...
今週の新時代のテック株：Zomatoのトラブルは続き、EaseMyTripはスト...
より多くを構築するだけではなく、より多くを破壊する
手直しは生産性を大きく損なう要因であり、あいまいに定義されたストーリー、開発テストの欠如、テスト カバレッジの欠如など、さまざまな要因の結果である可能性があります。 やり直しは、テストと回帰に QA エンジニア、デバッグに開発者、再リリースにリリース マネージャーの時間と労力を消費するため、生産性を損なう可能性があります。
少し速度を落とすことで、チームはより速く成果を上げ、付加価値を得ることができます。効果的な速度は、速度だけでなく常に非常にやりがいがあるからです。
'first-time-right (FTR)' の哲学は、すべてのチーム メンバーが、最初から堅牢で安定したコードを提供するという共通の目標に合わせるのに役立ちます。 急いでやり直しに行き詰まるよりも、コードの品質を判断するために余分な時間を費やすことは常に健全です。
FTR 率を改善するための実証済みの方法には、定期的なバックログ グルーミング、ストーリーの繰り返し、プロダクト マネージャーへの定期的なデモなどがあります。 スプリント チームは、要件を収集するだけでなく、FTR 率を改善するためにそれらを解明することにもっと集中する必要があります。
並行スプリント用にチームを構成する
スタートアップの製品チームが小さい場合、ほとんどの場合、全員が同時に 1 つまたは 2 つの機能に取り組んでいます (通常、4 ～ 6 人のメンバーのチームに当てはまります)。 ただし、複数の機能を提供することが期待されるため、明確な重点分野を持つ複数のサブチームを編成することを強くお勧めします。 このようにして、すべてのサブチームがスプリントを実行し、ロードマップを定義します。
1 つの大きなチームと比較して、「論理的な分離」フレームワークから生まれた小さなチームは、より効果的で、より良い結果をもたらします。 マイクロサービス、さまざまな製品ライン、およびさまざまなコンポーネントの個々のチームは、「論理的分離」アプローチのいくつかの例です。
再構築中は、DNA を維持するために、これらの各サブチームに以前のコア チームから少なくとも 1 人のメンバーを含めることが常に不可欠です。 配送のためのチーム間の調整には追加のオーバーヘッドが伴いますが、それは正当なトレードオフです。
速度とともに機能の使用状況を追跡する
ユーザー エクスペリエンスは、新機能のリリースの成功を測る最も重要な指標です。 複数の機能を迅速に提供し始めると、ユーザー エクスペリエンスが後回しになることがよくあります。 製品の機能が制限されている場合でも、ユーザー インタラクションは滑らかで途切れのない曲線のままです。
ただし、新機能のリリースを開始すると、ユーザーが圧倒され、エクスペリエンスが影響を受ける可能性が高くなります。
より良いユーザー採用を達成するには、機能の速度とともにユーザー エンゲージメントを追跡することが、今後も最善の方法です。 徹底的なユーザー調査は実証済みの方法の 1 つですが、新しいリリースのたびに機能フラグ、AB テスト、およびユーザー ジャーニーの追跡 (振幅または同様の分析ツールを使用) を介して、選択したユーザーに最初にロールアウトする重要な方法もあります。
コアメンバーを失うな
これは非常に一般的に無視されている側面かもしれませんが、非常に重要な側面としてしっかりと立っています. 小さなチームは必ずしもプロセスを必要とせず、機敏な構造を持ち、全員の声が聞こえます。 これらのチームがプロセスが設定され、新しいエンジニアリングおよび機能メンバーが追加された状態に移行すると、健全な管理が混乱を回避する唯一の方法になります。
エンジニアリング チームのスケールアップが成功するにつれて、エンジニアリング チームを継続的に養うには、有能な製品チームが不可欠です。 チームメンバーが重要な仕事をしていない場合、離職は避けられませんが、コアメンバーを失いたくないスタートアップはありません。 この場合、上級管理職は、人々との良好な関係を確保し、ダイナミクスをよく理解するための鍵を握っています。
私がここで共有した教訓は、長年にわたる複数のスタートアップとの経験から得られたものです。 すでに多くのことを抱えているスタートアップの創業者にとって、車輪の再発明に終わらない方法で役立つことを期待しています。