ビジネスと DevOps を結び付ける優れた方法をどのように見つけたか

開発がソフトウェアのメンテナンスと組み合わされるとき、DevOps の哲学は誰も驚かないでしょう。 DevOps 2.0 または BizDevOps という新しいトレンドが勢いを増しています。 ビジネス、開発、サポートという XNUMX つのコンポーネントを XNUMX つの全体に結合します。 そして、DevOps と同様に、エンジニアリングの実践が開発とサポートの間の接続の基礎を形成し、ビジネス開発においては、分析が開発とビジネスを結び付ける「接着剤」の役割を果たします。

すぐに認めたいのですが、私たちは賢明な本を読んだ後で、初めて実際にビジネスを展開していることを知りました。 従業員の自発性と改善への抑えられない情熱のおかげで、何とかこのプロジェクトが実現しました。 分析は開発生産プロセスの一部となり、フィードバック ループを大幅に削減し、定期的に洞察を提供します。 すべてがどのように機能するかを詳しく説明します。

クラシック DevOps の欠点

新しい顧客製品が考案されると、企業は顧客の行動の理想的なモデルを作成し、良好なコンバージョンを期待し、それに基づいてビジネス目標と結果を構築します。 開発チームは、非常に優れた高品質のコードを作成するよう努めています。 サポートは、プロセスの完全な自動化、新製品の保守の容易さと利便性を期待しています。

現実は、クライアントがかなり複雑なプロセスを受け取り、ビジネスは低いコンバージョンに行き詰まり、開発チームは次から次へと修正をリリースし、サポートはクライアントからのリクエストの流れに埋もれるという形で発展することがほとんどです。 おなじみですね？

ここでの悪の根源は、プロセスに組み込まれた長くて貧弱なフィードバック ループにあります。 企業や開発者は、スプリント中に要件を収集しフィードバックを受け取る際、製品の運命に大きな影響を与える限られた数の顧客とコミュニケーションをとります。 多くの場合、ある人にとって重要なことは、対象者全体にとってはまったく一般的ではありません。
製品が正しい方向に進んでいるかどうかは、発売から数か月後の財務レポートや市場調査の結果によってわかります。 また、サンプルサイズが限られているため、多数のクライアントに対して仮説を検証する機会がありません。 一般に、それは長く、不正確で、非効果的であることがわかります。

トロフィーツール

私たちはこれを回避する良い方法を見つけました。 以前はマーケティング担当者のみを支援するツールであったが、現在では企業や開発者の手に渡るようになりました。 私たちは、プロセスをリアルタイムで確認し、今ここで何が起こっているのかを理解するために、Web 分析を積極的に使用し始めました。 これをもとにプロダクト自体を企画し、多くのクライアントに展開していきます。
何らかの製品改善を計画している場合、それがどのような指標に関連付けられているか、またそれらの指標が売上やビジネスにとって重要な特性にどのような影響を与えるかをすぐに確認できます。 こうすることで、効果の低い仮説をすぐに取り除くことができます。 あるいは、たとえば、統計的に有意な数のユーザーに新機能を展開し、メトリクスをリアルタイムで監視して、すべてが意図したとおりに機能しているかどうかを把握します。 リクエストやレポートの形でのフィードバックを待つのではなく、すぐに自分自身で製品作成プロセスを監視し、迅速に調整してください。 新しい機能を展開し、XNUMX 日で統計的に正しいデータを収集し、さらに XNUMX 日で変更を加え、XNUMX 週間で素晴らしい新製品が完成します。

ファネル全体、つまり新製品に接触したすべての顧客を追跡し、ファネルが急激に狭くなったポイントを検出し、その理由を理解することができます。 現在、開発者と企業の両方が日常業務の一環としてこれを監視しています。 彼らは同じカスタマー ジャーニーを見て、改善のためのアイデアや仮説を一緒に生み出すことができます。

ビジネスと開発を分析と統合することで、製品の継続的な作成、継続的な最適化、ボトルネックの検索と確認、およびプロセス全体の全体的な実行が可能になります。

すべては複雑さの問題です

新しい製品を作成するときは、最初から始めるのではなく、既存のサービス Web にそれを統合します。 新製品を試すとき、クライアントは多くの場合、複数の部門に問い合わせます。 彼は、コンタクト センターの従業員、オフィスのマネージャー、サポートに連絡したり、オンライン チャットで連絡したりできます。 メトリクスを使用すると、たとえば、コンタクト センターにかかる負荷や、受信したリクエストを処理する最適な方法などがわかります。 私たちはオフィスに何人の人が来ているかを把握し、クライアントにさらにアドバイスする方法を提案します。

情報システムも全く同じです。 私たちの銀行は 20 年以上存続しており、その間に異種システムの大規模な層が作成され、現在も機能しています。 バックエンド システム間の相互作用は、予測できない場合があります。 たとえば、一部の古いシステムでは、特定のフィールドの文字数に制限があり、これにより新しいサービスがクラッシュすることがあります。 標準的な方法を使用してバグを追跡するのは非常に困難ですが、Web 分析を使用すると簡単です。

私たちは、関連するすべてのシステムからクライアントに表示されるエラー テキストを収集して分析し始める段階に達しました。 それらの多くは時代遅れであることが判明し、それらが何らかの形で私たちのプロセスに関与しているとは想像することさえできませんでした。

分析の操作

当社の Web アナリストと SCRUM 開発チームは同じ部屋にいます。 彼らは常に相互作用します。 必要に応じて、スペシャリストがメトリクスの設定やデータのダウンロードを支援しますが、ほとんどの場合、チーム メンバー自身が分析サービスを使用して作業するため、複雑なことは何もありません。

たとえば、限られた種類のクライアントまたはソースに対して依存関係や追加のフィルターが必要な場合には、ヘルプが必要です。 しかし、現在のアーキテクチャではこれに遭遇することはほとんどありません。

興味深いことに、分析の実装には新しい IT システムのインストールは必要ありませんでした。 私たちは、マーケティング担当者が以前に使用していたものと同じソフトウェアを使用しています。 必要なのは、その使用に同意し、ビジネスおよび開発に実装することだけでした。 もちろん、マーケティングが持っていたものをそのまま取り入れることはできず、すべてを新たに再構成し、マーケティングが私たちと同じ情報フィールドに入れるように新しい環境へのアクセスを提供する必要がありました。

将来的には、処理されるセッション量の増加に対応できるように、Web 解析ソフトウェアの改良版を購入する予定です。

また、Web 分析と CRM および会計システムからの内部データベースの統合プロセスにも積極的に取り組んでいます。 データを組み合わせることで、ソース、クライアントの種類、製品ごとなど、必要なすべての側面でクライアントの全体像を把握できます。 データの視覚化を支援する BI サービスは、間もなくすべての部門で利用できるようになるでしょう。

結局私たちはどうなったのでしょうか？ 実際、私たちは生産プロセスの一部として分析と意思決定を組み込み、目に見える効果をもたらしました。

分析: 熊手を踏まないでください

最後に、事業開発ビジネスを構築する過程でトラブルに巻き込まれないようにするためのヒントをいくつか紹介したいと思います。

1. 分析をすぐに実行できない場合は、間違った分析を行っていることになります。 XNUMX つの製品からシンプルなパスをたどってから、スケールアップする必要があります。
2. 将来の分析アーキテクチャをよく理解しているチームまたは担当者が必要です。 分析をどのように拡張し、他のシステムに統合し、データを再利用するかを陸上で決定する必要があります。
3. 不要なデータを生成しないでください。 ウェブ統計は、有用な情報であるだけでなく、低品質で不要なデータを含む巨大なゴミ捨て場でもあります。 そして、明確な目標がないと、このゴミが意思決定や評価の邪魔をすることになります。
4. 分析のための分析を行わないでください。 まず、目標、ツールの選択、そしてそれが効果を発揮する箇所のみの分析です。

この資料は Chebotar Olga と共同で作成されました (オルガ・セボタリ).

出所： habr.com