持続不可能なSaaS製品を救う方法

[[355134]]

以前にもこの話題について簡単に触れましたが、今日は皆さんとさらに詳しく議論したいと思います。現在、中国のほとんどの SaaS 企業は販売主導型、顧客需要主導型です。カスタマイズ開発を拒否することは難しく、プロジェクトを完了することは容易です。強力な製品機能とビジネス洞察力を備えたチームがない限り、製品は数年の蓄積を経て徐々に肥大化していきます。

製品が肥大化すると、次のような多くの問題が発生します。

• メンテナンスコストが上昇している
• ユーザーエクスペリエンスは悪化している
• 蓄積された顧客は資源から綱となり、調整の難しさや作業量も増大しています。

この場合、いくつかの新しい市場プレーヤーからの競争に対処するのは非常に受動的です。さらに、エクスペリエンスが悪いと、顧客は徐々に離れてしまい、チームは何もできず、ジレンマに陥ってしまいます。これは、中国のほとんどのB面製品企業の現状でもあります。

既存の製品をリファクタリングするべきか、それともゼロから始めて新しい製品を開発するべきでしょうか?現時点では、当社は難しい決断に直面しています。基本的に、すべての R&D チームはゼロから始めることを提案します。 R&Dの観点から見ると、これはよりシンプルで効率的な方法です。元の汚いコードについて心配する必要がなくなり、チームの士気が高まります。ただし、企業の観点からは、いくつかの要素を考慮する必要があります。

新システムの開発コストと開発サイクル。

新しいシステムが開発から少数の顧客によるオンライン使用、そして成熟して安定するまでには、かなり長い時間がかかります。

旧顧客向けの移行コスト。

このコストには、移行プロセス中に投資された BD、実装、トレーニング、アフターセールスのコストと、顧客が投資したコストが含まれます。

並行期間中は、何らかのバグや要件が発生し、双方で開発コストが発生します。

異なる製品ラインに対応するには 2 つの人員チームが必要であり、開発、実装、トレーニング、アフターセールスには 2 つのチームが必要です。採用、育成、拡大の難易度が増します。さらに、2 つの製品ライン間の製品の結合度が高く、通信の負荷が大きくなります。

一般的に、B サイド製品の移行コストは非常に高く、顧客が使用習慣を変えるためのコストも非常に高くなります。また、移行を望まない顧客も常に存在し、必然的に 2 つのシステムを長期にわたって維持することになります。体験したことのない人にとっては、このような価格やコストを想像するのは難しいでしょう。古い顧客を移行すると、彼らは疲れてしまいます。古い顧客を移行しないと、彼らは無視され、ある程度傷つき、あなたの評判に影響を及ぼします。

顧客が非常に少ない場合、または移行全体が基本的に比較的低コストであることが保証されている場合を除き、新しいセットをゼロから開発しないことを強くお勧めします。コストが非常に高いです。すべてのコストを 2 倍にするだけでなく、移行コストと顧客コストもあります。各顧客の移行と実装は複雑なプロジェクトになる可能性があります。

したがって、新しいシステムを開発するコストは、既存の製品を再構築するコストよりも間違いなく指数関数的に高くなります。この選択を行った後、多くの企業は、新しい製品に満足できず、古い製品から移行できず、多くの時間とリソースを無駄にするというジレンマに陥ります。著者は成功した事例をほとんど見つけていない。

では、システムを非常に詳細に再構築する必要がある場合、どのようにすればよいのでしょうか?次のような考え方や原則を参考にできると思います。

1: 良い人になる準備をしなさい。

以前の記事で述べたように、何かの成功や失敗において最も重要な要素は人です。牛をうまく屠殺するには、データベース アーキテクト、ソリューション アーキテクト、機能アーキテクトなど、いくつかの役割が非常に重要です。すべての役割に人材が必要なわけではありませんが、対応する役割を担う人材は必要です。たとえば、データベースは B サイド製品の基礎となります。一度エラーが発生すると、調整コストが非常に高くなります。データベース アーキテクトには、データベース設計テクノロジを理解し、ビジネス開発とビジネスの詳細を深く理解し、将来を見据えたコラボレーション アプローチを持つ 1 人以上の人物が必要です。ソリューション アーキテクトには、実際にはビジネスを理解し、テクノロジーを理解している 1 人以上の人物が必要です。

B サイド製品は学際的なテーマであり、ビジネスとテクノロジーの両方を理解している人材を見つけるのは比較的簡単です。ビジネスとテクノロジーの両方を理解し、その2つを有機的に組み合わせることができる人材を見つけるのは困難です。そのような人材は現在、中国では希少な資源です。一般的に言えば、このような学際的な科目では、ビジネスマンがテクノロジーを学ぶよりも、技術者がビジネスを学ぶ方が簡単です。会社はこの方向で訓練するのに適した人材を選ぶべきです。

短期間で適切な人材を見つけるのが難しい場合は、外部のコンサルタントに依頼して、ある程度の検討を行ってもらうのがベストです。

2：理想的な製品形態を大まかに設計します。

製品再構築の道筋を決定するには、製品の最終的な全体アーキテクチャ、主に機能アーキテクチャとシステムアーキテクチャを設計する必要があります。さらに、より満足のいく答えを得るためには、いくつかの中核となるビジネス設計のアイデアと原則を決定し、繰り返し磨き上げる必要があります。最終目標がわかれば、最善の進路について慎重に考えることができます。

3: リファクタリングの優先順位を慎重に選択します。

製品の再構築では、パスと優先順位の選択が非常に重要です。最も合理的かつ労力を節約できる道を見つけることは、チームにとって大きな試練となります。ここで決まった答えを出すのは難しいですが、従うべき原則がいくつかあります。

基礎となるコア アーキテクチャの調整を優先します。

リファクタリングで最も重要なことは、データベース アーキテクチャ、製品機能アーキテクチャ、ページ アーキテクチャを正しくすることです。データベース、機能、ページ アーキテクチャのいずれであっても、実際には最も合理的な方法を見つけること、つまり、ユーザー エクスペリエンスと製品の成長のバランスを見つけることが重要なのです。一般的に言えば、最良のエクスペリエンスとは、十分なページ数を使用して、ユーザーが関心のあるコンテンツを十分に閲覧できるようにすることです。しかし、製品は増え続けており、アーキテクチャが適切に分類されていないと、機能やページが非常に混雑し、拡張できなくなります。したがって、経験と成長の最適なバランスを見つける必要があります。

いくつかのコア データベース テーブルとコア機能アーキテクチャを優先的に調整する必要があります。間違ったデータベースや間違った機能アーキテクチャで行われた作業は無駄になり、最初からやり直す必要があります。

コア機能や特に悪い機能の再構築を優先する

頻繁に使用されるコア モジュールや特に貧弱な機能は、最初にリファクタリングする必要があります。この種の再構築はユーザーにとって最大の価値があり、顧客は協力する十分な動機を持っています。

新規需要が高いモジュールの再構築を優先します。

製品は静的なものではありません。製品をリファクタリングする場合、大量の外部要求が絶えず押し寄せてくることに必ず直面することになります。多くの新しい要求がある機能モジュールの場合、間違った機能ベースで新しい要求を満たすために多くの時間を費やすのではなく、最初からやり直す方がよいでしょう。実際、いわゆるリファクタリングでは、モジュールや関数を 1 つずつ書き直し、アジャイルな肉屋のようなアプローチを使用して主要なリスクを分解することがよくあります。

4: 卓越性を追求し、同じ間違いを繰り返さない。再建の機会はすべて再生の機会です。

これは言うまでもありません。モジュールをリファクタリングするたびに、再生の機会が生まれます。一つの穴を使って別の穴を埋めることはできません。作業を開始する前に、少なくとも 85 点以上のデザイン スコアを達成する必要があります。盲目的にスピードだけを追い求めないでください。

5: 引き算を頑張りましょう。引き算がうまくいけば勝利です。

肥大化したシステムをリファクタリングするときは、リファクタリングと書き直しのプロセス中に、あらゆる可能な方法を試して削減を行う必要があります。モジュールの減算、関数の減算、さらにはフィールドの表示、検索条件を極端に削減すると、良好な再構築には大量の減算が伴わなければなりません。

顧客の観点から見ると、再構築後のすべてのアップグレードは、従来のシステムにすでに精通している人にとっては苦痛です。顧客は何度も苦しめられるとイライラしがちです。ユーザー エクスペリエンスと口コミの観点から、反復的な配置に関するいくつかの提案を以下に示します。

1: 各イテレーションとアップグレードにより、お客様は引き続き魅力的な特典をお楽しみいただけます。

アップグレードを繰り返すたびに、再構築された新しいバージョンのエクスペリエンスが元のバージョンよりもはるかに優れているか、顧客の悩みを解決できる新しい機能が備わっている必要があります。そうすることで、ユーザーはアップグレードする意欲を持つようになります。各反復計画を設計および調整する際には、ユーザーのアップグレードの動機を十分に考慮する必要があります。そうしないと、多くの抵抗に遭遇することになります。

2: 移行およびアップグレードのプロセス中は、お客様に意識させず、トレーニングも不要にすることで、投資コストを削減します。

各再構築後のアップグレードには、多くの場合、データの移行が伴います。この負担は顧客に負わせるべきではありません。実装チームが顧客による完了を支援します。また、各再構築後の機能は基本的にトレーニングを必要とせず、お客様は基本的に実装トレーニングコストを投資する必要がありません。

3: 完全リリースを開始する前に、グレースケール テストを実行して、新しい機能が実現可能であることを確認します。

各主要再構築には一定期間のグレースケールテストサイクルが必要であり、一部の典型的な顧客が再構築されたモジュールを最初に使用して、完全リリース前に問題がないことを確認することで、顧客のトラブルを最小限に抑えることができます。トラブルが発生するたびに不信感が募り、非協力的になり、製品の評判が悪くなります。

4: 新規顧客に対しては必要な機能のみを公開し、その後の移行コストを削減します。

これはちょっとしたヒントです。旧製品で十分に整備されていない一部の非必須機能については、再構築プロセス中に、許可処理を通じて増加する新規顧客に公開しないようにし、後で移行コストの増加を回避する必要があります。

復興は困難です。シンプルさは難しい。人生は難しい。しかし、ほとんどの人は十分な問題を経験した後に初めて心の平穏を見つけ、シンプルな生活を送ることができるのです。