今年の初めに、興味深い事例がありました。2週間で、ビルドをストアにアップロードすることなく、機能を更新した基本的な宅配便アプリケーションを作成しました。
プロジェクトは古典的なMVPであることが判明し、実装モデルは小規模なb2cおよびほとんどすべてのb2bプロジェクトに適しています。タイトなスケジュールで動作するアプリケーションが必要な場合は、このアプローチに注意を払うことをお勧めします。このテキストはプロジェクトマネージャーにとって興味深いものであり、おそらく、これまでプログラマーが知らなかったものは何も含まれていません。
ちょっとした歴史
VkusVillは、昨年オンライン配信の実験を開始しました。このために、論理的なビジネス戦略が選択され、承認されました。クライアントとコレクター/宅配便業者向けの2つの異なるアプリケーションの開発です。
便利で、顧客が少なく、アプリケーションの負荷が小さく、開発の過程で1日あたり約100件の注文（最大1000件）が発生しました。
その後、パンデミックが始まり、小売店はあらゆる場所への配送に向けて再編成を開始しました。クライアントフローが大幅に増加し、変更と承認のための最小限の時間がありました-誰もが既存の実装が悪く、緊急に変更する必要があることに気づきました。
私たちの実装の問題
- アプリはAndroidのみでした。しかし、パンデミックはすべての領域を揺るがし、iOSの宅配便業者が配達サービスに来始めました。
- たとえば、Googleから7日間のレビューを受けた後、アプリケーションの更新には非常に長い時間がかかりました。これらの条件下で製品を最適化することは不可能でした。
ネットワーク全体が隔離期間中は配達サービスに依存していたため、チームが直面した主な質問は「宅配便業者をどうするか」でした。次に、テレグラムボットを作成することにしました。ボットが得意だから です。
注文数の増加により、選択したビジネスモデルの成功が確認されました。しかし、その後、プラットフォームとしてのボットの限界にぶつかり始めました。特に、開発にはいくつかのタスクがありました。
- 便利な地図でルートとすべての注文を確認してください
- 一度に複数のPOSに結び付けられる
- 注文のステータスに関する最新情報を受け取ります
- , . , , , .
- . telegram : 8 .
- “” - , .
レビューの問題についてのフラッシュバックで覆われていました。さらに、開発への標準的なアプローチでは、設計、設計、UXエディターによる分析、レイアウト、および組み立てのすべての段階を経る必要があります。これには1〜3か月かかり、メインアプリケーションからリソースを消費すると見積もっています。
興味深い事実：FullStackでは、4人のヒーローがVkusVillaフロントに関与しています。iOS用に2人、Android用に2人です。彼らと一緒にいたいのなら、私に書いてください--kafa@automacon.ru。
開発開始
その瞬間、私たちは幸運でした。ノーコードプラットフォームBubble.ioについて教えてくれた人たちを見つけました。彼らによると、私たちの要求に応じた申請は、1週間でそこで行うことができます。さらに、彼らはそれがどのように機能するかを正確に示し、それが私たちのかなりトリッキーなバックエンドで機能するかどうかを確認するためのテストに合格しました。
正直なところ、Bubbleは私にはかなり粗雑なテクノロジーのように見えました。ユーザーインターフェイスの観点からは、Bubbleはやや奇妙で、応答性の低いシステムです。
しかし、それを理解しているうちに、プラットフォームの原理を使用して独自のアプリケーションをすばやく作成するというアイデアが浮かびました。バブルがこのタスクに対処できるのなら、たとえば、なぜSPAができないのでしょうか。
Capacitorフレームワークを使用してReactJSでユーザーインターフェイスを作成することにしました 。プロジェクトは、リモートサーバーにアップロードされる最適化および圧縮されたファイルのセットにアセンブルされます。 Capacitorはネイティブ関数にアクセスできます。アプリケーションはWebViewを介して起動され、ReactJSでアセンブルされたプロジェクトのURLが指定されます。このロジックによれば、プロジェクトは、ネイティブ関数を呼び出す機能を備えた通常のサイトとして開く必要がありました。驚いたことに、Appleはこのようなテクノロジーをアプリストアに導入することに問題はありません。
私たちはそれを書き、Bubbleコンピテンシーを持つ人とReactプログラマーの1人に渡しました。それはかなり原始的に見えました。私たちはデザインガイドを取り、シンプルなUIを考え、ボットのすべての機能を実行するフロントをまとめました。
各チーム（プログラマーをチームとして数える場合）は、タスクを完了するのに2週間かかりました。ガイドラインに基づいて、最もシンプルで便利なアプリケーションを個別に作成します。開発者は、ビジネス側からプロジェクトリーダーに直接相談する必要がありました。
アナリストの設計、設計、関与を故意に放棄したことを強調しておきます。
なぜ2つのチームがあったのですか？
この場合、私たちがVkusVillと協力しているという事実が役割を果たしました。彼らの文化では、サプライヤーを複製する方法が積極的に使用されています。サードパーティのBubbleチームがこのプロジェクトでどのように機能するのか興味がありました。おそらく、それらからいくつかのトリック、管理手法、および通信機能を採用することができたはずです。
同時に、コンストラクターに基づくアプリケーションの成功を無条件に信じていなかったので、1つのソリューションを作成するのに2週間を費やしたくありませんでした。
何が起こった
まず第一に、コマンドを並列化するというアイデアは非常に論理的であることが判明しました：ノーコードインターフェイスソリューションはどういうわけかすぐには機能しませんでした。
ガイドラインに従った作業が一気に行われたので、実装はどういうわけか私を少しやる気にさせました。応答の観点から、Bubbleには明らかな問題があります。すべてが不器用に、多くの場合2回押されます。その過程で、タンバリンを使ったダンスがもう1つ発見されました。チームは、Bubbleの「ネイティブ」GoogleマップをYandexに置き換えるのに2日以上かかりました。さらに1日-2Gisを介してルーティングを開く機能を作成します。同時に、解決策は松葉杖であることが判明しました。2Gisがデバイスにインストールされていない場合でも、それは提供されていました。人件費に関しては、アプリケーションが未加工であることが判明したときに、ノーコードチームは80時間強（当初はこれが制限でした）を取得しました。これで彼らとの協力は終わりました。
ReactJSのソリューションは、はるかに最適であることが判明しました。まず、すべての機能が67時間で完了し、次に、ガイドラインとロジックの観点から、すべてが非常に機能していることが判明しまし
た。iOSでの 公開は成功しました。 ：レビューのための質問はありませんでした。翌日、アプリケーションが保管されました。AndroidをPlayマーケットにアップロードせず、.apkをクラウドストレージに配置しただけです。
発売後、そのようなアセンブリのすべての利点が具体的になりました。アプリケーションは本格的なテストの準備ができていなかったため、更新や改善は公開せずに行う方が便利です。
現在、アプリケーションは数か月間機能しており、かなり多くの機能を追加し、宅配便で優れたKazdevを作成しました。みんな幸せです。
いくつかの結論
驚いたことに、bubble.ioでの開発には時間がかかり、最終製品はより粗雑でした。ここでは、コンストラクター制約が重要な役割を果たしました。
最初に、技術的な割り当てを設定するときに、フォント、アイコン、一般的なスタイルなどの既製の視覚要素でガイドラインを使用することの重要性にチームの注意を向けました。それにもかかわらず、Bubbleの人たちは非常に原始的なインターフェースを手に入れました。平凡な「時間がなかった」ことが決定的な役割を果たす可能性は低いです。むしろ、プラットフォームのカスタマイズが不十分であるというのが事実です。誰かが理由を説明できるなら、コメントに書いてください。
私たちがそのような方法論について知らず、すでに広く使用されていることに多くの人を驚かせるかもしれません。それでも、それは私にとっては啓示であり、ユーザー数が少ない企業アプリケーションにとっては非常に優れたソリューションだと思います。アプリケーションは何倍も便利で、サイトのアダプティブバージョンとは根本的に異なり、ReactNativeやFlutterを使用する場合よりも実装時間が短く、視覚的に違いは目立ちません。
要約すると、プロジェクトはチームにとって良い挑戦のように見えました。個人的には、プロジェクトを管理することは、「大きな」タスクの長く、注意深く、非常に思慮深い設計のルーチンから抜け出すための素晴らしい方法でした。