小規模なプログラムがどのようにして小規模オフィスを月収 100 億ルーブル以上の連邦企業に変えたのか

2008 年 XNUMX 月末、私は既存のビジネス プロセスを自動化することを目的としたペルミのタクシー サービスの XNUMX つに招待されました。 一般に、私には XNUMX つの基本的なタスクが与えられました。


• タクシー運転手向けのモバイル アプリケーションを備えたコールセンター用のソフトウェア パッケージを開発し、社内のビジネス プロセスを自動化します。
• すべてを可能な限り短時間で完了する必要がありました。
• サードパーティの開発者から購入するのではなく、独自のソフトウェアを所有します。将来的には、ビジネスの発展に応じて、絶えず変化する市場状況に合わせてソフトウェアを独自に拡張できます。

当時、私はこの市場がどのように機能するのか、そのニュアンスを理解していませんでしたが、それでも、XNUMX つのことが私にとって明らかでした。 コールセンターは、オープンソースのアスタリスク ソフトウェア PBX に基づいて構築する必要があります。 コールセンターとモバイル アプリケーション間の情報交換は、基本的に、将来のプロジェクトのアーキテクチャとそのプログラミングを設計するための対応するすべてのパターンを備えたクライアント/サーバー ソリューションです。

プロジェクトのタスク、期限、コストを事前に評価し、タクシー サービスのオーナーと必要なすべての問題について合意した後、2009 年 XNUMX 月に仕事を開始しました。

先を見据えて、すぐに言います。 その結果、ロシアの 60 都市とカザフスタンの 12 都市にある 2 以上のサーバーで実行されるスケーラブルなプラットフォームが実現しました。 会社の総利益は月あたり 100 億ルーブル以上でした。

ステージXNUMX。 プロトタイプ

当時、私は IP 電話の実務経験がなく、「家庭」での実験の一環としてアスタリスクについて表面的にしか知らなかったので、モバイル アプリケーションとサーバー部分の開発に取り組むことになりました。 同時に、他のタスクに関する知識のギャップを埋めます。

モバイル アプリケーションを使用すれば、すべてが多かれ少なかれ明確になります。 当時は、単純なプッシュボタン式電話機用に Java でしか記述できませんでしたが、モバイル クライアントにサービスを提供するサーバーを記述するのはもう少し複雑でした。

• どのようなサーバー OS が使用されるか。
• タスクに対してプログラミング言語が選択されるのではなく、タスクに対してプログラミング言語が選択されるというロジックに基づき、ポイント 1 を考慮して、どのプログラミング言語が問題解決に最適であるかを考慮します。
• 設計時には、サービスに将来予想される高負荷を考慮する必要がありました。
• 高負荷下でフォールト トレランスを保証できるデータベースはどれか、またデータベースへのリクエスト数が増加したときにデータベースの高速応答時間を維持するにはどうすればよいか。
• 決め手となったのは、開発速度とコードを迅速に拡張できる能力でした。
• 将来の機器とそのメンテナンスのコスト (顧客の条件の XNUMX つは、サーバーが顧客の管理下にある地域に配置されている必要があることです)。
• プラットフォーム上の作業の次の段階で必要となる開発者のコ​​スト。

設計と開発に関連する他の多くの問題も同様です。

プロジェクトの作業を開始する前に、私はビジネス オーナーに次の戦略的決定を提案しました。プロジェクトは非常に複雑なので、実装にはかなりの時間がかかるため、最初に MVP バージョンを作成します。これにはそれほど時間はかかりません。しかし、それによって彼の会社はすでに「今ここ」の市場で競争上の優位性を得ることができ、タクシーサービスとしての能力も拡大することになるだろう。 その結果、このような中間ソリューションにより、最終ソリューションをより慎重に設計するための時間と、技術的な実験のための時間を得ることができます。 同時に、実装されたソフトウェア ソリューションは正しく設計されているとは保証されず、将来的に根本的に再設計または置き換えられる可能性がありますが、「競合他社からの脱却」に必要な最小限の機能は確実に実行します。 タクシーの創始者はこのアイデアを気に入ったので、最終的にはそれを実現しました。

最初のXNUMX週間は社内の業務プロセスを勉強したり、タクシーの仕事を内側から勉強したりしました。 どこで、何を、どのように自動化できるのか、また自動化がそもそも必要なのかどうかについてビジネス分析を実施しました。 会社員はどのような困難や問題に直面しているのでしょうか？ それらはどのように解決されるのか。 会社の従業員の勤務日がどのように編成されるか。 彼らはどんなツールを使っているのでしょうか？

XNUMX週目の終わりまでに、仕事を始めてインターネットで関心のある問題を勉強した後、経営者の希望とその時点での私自身の知識と能力を考慮して、次のスタックを適用することが決定されました。 :

• データベース サーバー: MsSQL (データベース ファイルの制限が 2 GB までの無料バージョン)。
• Windows 上の Delphi でモバイル クライアントにサービスを提供するサーバーの開発。データベースがインストールされる Windows サーバーがすでに存在し、開発環境自体も迅速な開発を促進します。
• 2009 年当時の携帯電話のインターネット速度が低かったことを考慮すると、クライアントとサーバー間の交換プロトコルはバイナリでなければなりません。 これにより、送信されるデータ パケットのサイズが小さくなり、その結果、サーバーとクライアントの作業の安定性が向上します。

さらに 12 週間がプロトコルとデータベースの設計に費やされました。 その結果、モバイル クライアントとサーバー間で必要なすべてのデータとデータベース内の約 20 のテーブルを確実に交換する XNUMX 個のパッケージが完成しました。 この部分の作業は、たとえ技術スタックを完全に変更する必要があるとしても、パッケージとデータベースの構造は変更しない必要があるという将来を考慮して実行しました。

準備作業の後、アイデアの実際の実装を開始することができました。 プロセスを少しスピードアップして他のタスクに時間を割くために、私はモバイル アプリケーションのドラフト バージョンを作成し、UI (一部 UX) をスケッチし、プロジェクトに馴染みの Java プログラマーを巻き込みました。 そして、サーバーサイドの開発、設計、テストに重点を置きました。

MVP の作業の XNUMX か月目の終わりまでに、サーバーとクライアントのプロトタイプの最初のバージョンが完成しました。

そして、合成テストとフィールド テスト、バグ修正、プロトコルとデータベースの小規模な改善を経て、XNUMX か月目の終わりまでに、アプリケーションは運用準備が整いました。 それが行われたのです。

この瞬間から、プロジェクトの最も興味深く、最も難しい部分が始まります。

ドライバーが新しいソフトウェアに移行する間、XNUMX 時間勤務が組織されました。 日中の勤務時間中に誰もが来られるわけではないので。 また、管理上は、創業者の強い意志により、ログイン・パスワードはタクシーサービスの管理者が入力し、運転手には伝わらない仕組みになっていた。 私の側では、障害や予期せぬ事態が発生した場合に備えて、ユーザーへの技術サポートが必要でした。

マーフィーの法則は、「うまくいかない可能性のあるものは、必ずうまくいかない」と教えています。 そして、それがまさに事態がうまくいかなかった理由です...私と数人のタクシー運転手が数十のテスト注文でアプリケーションをテストしたときのことです。 そして、ライン上で 500 人以上のドライバーが実際の人々からの実際の注文にリアルタイムで取り組んでいる場合は、まったく別の問題になります。

モバイル アプリケーションのアーキテクチャはシンプルで、サーバーに比べてバグが大幅に少なくなっています。 したがって、作業の主な焦点はサーバー側でした。 アプリケーションの最も重大な問題は、電話機のインターネットが失われ、セッションが再び復元されたときにサーバーから切断されるという問題でした。 そして、インターネットは頻繁に消えました。 まず、当時は携帯電話のインターネット自体が十分に安定していませんでした。 第二に、インターネットが機能しない盲点がたくさんありました。 私たちはこの問題をほぼ即座に特定し、XNUMX 時間以内に以前にインストールされたすべてのアプリケーションを修正および更新しました。

サーバーには主に、注文分散アルゴリズムにエラーがあり、クライアントからの一部のリクエストが正しく処理されませんでした。 不具合を特定したので、サーバーを修正して更新しました。

実際、この段階では技術的な問題はそれほど多くありませんでした。 大変だったのは、私がほぼ 4 か月間オフィスで勤務し、たまにしか家に帰らなかったことです。 たぶん5～XNUMX回くらい。 当時、私は一人でプロジェクトに取り組んでいて、私以外に何も修正できる人がいなかったため、私は行き当たりばったりで寝ていました。

XNUMX か月間、これは、XNUMX か月間すべてに常に不具合があり、停止することなく何かをコーディングしていたという意味ではありません。 私たちはそう決めただけです。 結局のところ、ビジネスはすでに運営されており、利益を上げていました。 今すぐ顧客や利益を失うよりは、安全策を講じて後で休んだ方が良いでしょう。 私たち全員がこのことをよく理解していたため、チーム全体がタクシー システムに新しいソフトウェアを導入することに最大限の注意と時間を費やしました。 現在の注文の混雑状況を考慮すると、間違いなく XNUMX か月以内にすべての欠点を解消します。 確かに、隠れたバグが残っている可能性があっても、ビジネス プロセスに重大な影響を与えることはなく、必要に応じて定期的に修正できます。

ここで注目すべきは、ドライバーを新しいソフトウェアに移行する状況の複雑さを最大限に理解し、XNUMX時間体制でドライバーと協力したタクシーサービスのディレクターや職長からの貴重な支援である。 実際、電話機への新しいプログラムのインストールが完了した後、ドライバーを XNUMX つも失うことはありませんでした。 また、クライアントの不削除率はそれほど大きくは増加しませんでしたが、すぐに通常のレベルに戻りました。

これでプロジェクトの第 XNUMX 段階の作業が完了しました。 そして、結果が出るまでに長くはかからなかったことに注意する必要があります。 人間の介入なしにドライバーへの注文の配信を自動化することで、顧客のタクシーの平均待ち時間が一桁短縮され、当然のことながらサービスに対する顧客ロイヤルティが向上しました。 これにより受注件数が増加しました。 これを受けてタクシー運転手の数も増加した。 その結果、受注件数も順調に増加しました。 そしてその結果、会社の利益は増加しました。 もちろん、このプロセス全体が即座に行われたわけではないので、ここでは少し先を進んでいます。 経営陣が喜んでいたと言っても過言ではありません。 私はプロジェクトへのさらなる資金調達に無制限にアクセスできるようになりました。

続ける..

出所： habr.com