BurnRate は Blazor による収益の成功を促進しています

.NET の経験豊富で経験豊富なスタートアップ企業家で、人々の成功を支援する情熱を持つ Robert McLaws に会いましょう。彼のキャリアを通じて、McLaws は、スタートアップ企業の成功率を大幅に向上させるために、スタートアップの資本家 (VC) とその数千億の投資がどのように失敗したかを目の当たりにしました。VC への投資が 50 年続いた後も、企業の少なくとも 70% が成長のあらゆる段階で失敗します。

その統計は McLaws を警告しました。そこで、彼は、創設者や収益リーダーが採用プロセスをシステム化し、スプレッドシートの数式を使わずに、成長のための独自のコースをグラフ化するのを支援することに着手しました。彼は、スケーラブルな成長の計画をより簡単かつ正確なものにする価値のある特定の計算をテクノロジーで行う機会を見ました。

人間のアルゴリズムを構築する

何年も前、Mc Wavs は、ASP.NET を使用して商業用不動産空間で財務分析製品を構築するアプリケーション フレームワークを構築していました。アパートメント の複合型のキャパシティ モデルを構築すると、SaaS の販売容量モデルを掘り下げるための道のりと、仕事の人間の能力が会社の収益を生み出す能力にどのように影響するかについて説明します。

そこで彼は、Go-to-Market チームの収益需要と人員の計画システムである BurnRate のアイデアを思い付きました。McLaws は、マーケティング、営業、顧客の成功などの主要な収益チームのスタッフレベルを決定するために直感と推測に頼ることは、成長への持続可能な道のりではないと感じました。

代わりに、彼は科学があると信じていました: つまり、会社が \「People Algorithm \」 を使用して、よりスマートに成長するのに役立つアルゴリズムです。\「これらの [顧客の成功、マーケティング、販売] チームは、最初の場所でコストを獲得する責任があるため、計算を正しく行い、収益チームが直感的に使用できるほど簡単にすることが不可欠でした。\」

適切な技術スタックの選択

金融数学の経験から、JavaScript などの浮動小数点演算を使用するプログラミング言語では、金融システムを構築するには十分ではない、と McLaws は教えました。このアルゴリズムの基盤は、一貫して検証できる信頼性の高い結果を提供するために C# にある必要があります。

前の会社を退職して BurnRate を立ち上げたとき、アプリケーション フレームワークを残してゼロから再開発する必要がありました。.NET Core の最初のリリースは公開されたばかりなので、最新の時代に向けてリビルドするのに最適なタイミングでした。

バックエンドは、プロジェクトのクエリ可能な API のニーズを処理できる以上に、Azure SQL と Microsoft Restier で十分にシンプルでした。.NET Core では、彼の急速な「People Algorithm」は非常に高速で、高度に構造化されたデータからの非常に複雑な計算をほんの一瞬で処理できました。

ただし、企業が複数のシナリオを作成し、それらを切り替える方法で会社の財務データを整理するには、予想していなかったアーキテクチャの深さが必要でした。

「シナリオ、親シナリオ、時間スケール、および計画された結果と実際の [結果] を 1 つのモデルにまとめると、頭を回転させるには十分でした。何か月もの作業が必要で、作業を繰り返し試みました」と彼は言います。McLaws は、BurnRate がアルゴリズムで使用する単体テストの数は、「おそらく他のほとんどの企業がアプリケーションを使用してビルドする場合よりも桁違いに高いでしょう。このプラットフォームを使用して、ビジネス全体の将来に関する意思決定を企業に求めています。間違える余裕はありません」と述べています。

BurnRate は、単体テストの生産性を向上させ、より短時間でより一貫性のあるテストを作成するために、Breakdance と呼ばれるオープンソース テスト フレームワーク全体を構築しました。

フロントエンドにはさまざまな課題が示されました。McLaws は、Webpack、TypeScript、および Knockout の組み合わせを使用して BurnRate UI のプロトタイプ作成を開始しましたが、多くの障害に直面しました。その時点では、ビルドの構成を容易にする TypeScript 定義は Webpack にありませんでした。

\「JavaScriptー何でもかまいませんが、実行時にすべてをスワップアウトできる言語ーでは、失敗は既定の設定です。成功は、通常は精神的な苦痛によって得られるものでなければならなりません。\」と McLaws は述べています。

最終的にすべてが機能し、最初の完全に機能するプロトタイプを作成したとき、特に何百人もの従業員を抱える企業の雇用計画を生成する際に、チームはスケーリングの問題に苦労しました。

\「UI の更新と再計算とサーバー側をスケーリングして処理する方法を見つけようとしたとき、私たちは前に戻っていました。\」 と彼は言いました。\「レンダリングを試みると、ブラウザーでますますぎくしゃくしてきました。\」

Blazor がスケーラビリティへの道のりをどのように照らしたか

Blazor はこの頃にマーケットプレースに入り、新しいフロントエンド テクノロジーでした。

\「最小限の JavaScript を使用したブラウザーでのエンドツーエンドの C# の約束は無視するには良すぎました。\」と McLaws は述べています。

クライアント側とサーバー側の間で C# を使用すると、アプリケーションの開発が非常に簡単になっただけでなく、McLaws によると「非常に簡単に」、また、BurnRate の UI を計算と同じくらい信頼性の高いものにする上で重要な役割を果たしました。

バックエンド コードを記述するのと同じ言語で単体テストを記述できますが、これは非常に大きいです! その方法でビルドしたくないのはなぜですか? それは、何千行ものコードを排除し、WPF の世界で 5 秒も費やした人にとっては直感的なことでした。"

Blazor を使用すると、BurnRate は \「非常に、非常に迅速に移動できました。\」 3 年ではなく、チームは数週間で動作する Blazor プロトタイプを構築し、1 年未満で数十万行のコードを完全に移植しました。

その時間の大部分は、新しいオープンソース ツールの構築に費やされたため、他の企業も Blazor アプリを迅速に構築できました。これは、McLaws の有益な精神に合致するアプローチです。

「人々は、BurnRate のようなプラットフォームを構築するときに、顧客向けのアプリが必要なだけはないことを忘れる傾向があります。また、データベースの変更とシステム管理のためにアプリの背後にあるアプリも必要です」と彼は言いました。

\「そこで、BlazorEssentials をビルドしました。これは、Blazor の XAML から Model-View-ViewModel (MVVM) アーキテクチャ スタイルを有効にするライブラリです。これにより、アプリ内のデータ表示からデータの取得を明確に分離できます。これは、アプリケーション アーキテクチャのシンプルさと一貫性のレベルをもたらします。コードベースの 100% が、予測可能なパターンを持つ 1 つの言語でテストできるようになりました。\」

Azure DevOps を活用して、高度に自動化された継続的インテグレーションと継続的デリバリー (CI/CD) を実現することで、BurnRate チームはさらに迅速に移行できます。

「新しいアプリでも、既存のアプリ用の新しいユーティリティでも、数時間以内に運用環境に出荷できます」と McLaws 氏は述べています。

BurnRate がスケーリングされるにつれて、顧客のコアな日常業務に組み込まれるように、製品の安定性を確保する必要がありました。McLaws は Microsoft を信頼しています。

セキュリティ侵害のないソリューションの提供

\「私はずっと前に Microsoft を選びましたが、Microsoft は私を一度も失望させなかった。\」 と彼は言いました。

McLaws は 23 年間の .NET のベテランであり、5 回の Microsoft MVP 受賞者であり、オープンソースの貢献は合計で 14 億ダウンロードを超えています。今日まで、彼は優れたものを一緒に構築するためのリソースとコミュニティがあることを知り、Microsoft と共に開発を続けています。Blazor を使用することで、BurnRate チームはアプリを構築し、McLaws のビジョンを侵害することなく提供できました。

「安定したスケーラビリティの [レベル] をサポートできる .NET 以外のプラットフォームは決してありませんでした。\」と彼は言いました。彼によると、Blazor は無駄のないチームを強化して、よりスマートかつ迅速に構築しました。