Bagaimana kami membuat aplikasi seluler untuk kurir VkusVill dalam 9 hari

Hai, nama saya Alexey Kaftanov, saya kepala FullStack (bagian dari Grup Perusahaan Avtomakon). Kami sedang mengembangkan aplikasi seluler dan web.



Di awal tahun, kami mendapat kasus yang menarik. Dalam dua minggu kami membuat aplikasi kurir dasar dengan pembaruan fungsional tanpa perlu mengunggah build ke toko.







Proyek ini ternyata adalah MVP klasik, model implementasinya cocok untuk proyek b2c kecil dan hampir semua proyek b2b. Jika Anda membutuhkan aplikasi yang berfungsi dengan jadwal yang ketat, saya menyarankan Anda untuk memperhatikan pendekatan ini. Teks tersebut akan menarik bagi manajer proyek dan, kemungkinan besar, tidak akan berisi apa pun yang sebelumnya tidak diketahui oleh pemrogram.



Sedikit sejarah



VkusVill mulai bereksperimen dengan pengiriman online tahun lalu. Untuk ini, strategi bisnis logis dipilih dan disetujui: pengembangan dua aplikasi berbeda, untuk klien dan kolektor / kurir.



Nyaman, hanya ada sedikit pelanggan, beban aplikasi kecil: sekitar 100 pesanan per hari, dalam proses pengembangan - hingga 1000.



Kemudian pandemi dimulai, ritel mulai mengatur ulang pengiriman ke mana-mana. Alur klien meningkat secara signifikan, ada waktu minimum untuk perubahan dan persetujuan - semua orang menyadari bahwa implementasi yang ada buruk dan perlu segera diubah.



Masalah implementasi kami



  1. Aplikasinya hanya Android. Tetapi pandemi mengguncang semua bidang, dan kurir dengan iOS mulai datang ke layanan pengiriman.
  2. Aplikasi membutuhkan waktu yang sangat lama untuk diperbarui, misalnya, setelah kami mendapat ulasan tujuh hari dari Google. Tidak mungkin mengoptimalkan produk dalam kondisi ini.


Seluruh jaringan bergantung pada layanan pengiriman selama periode isolasi, jadi pertanyaan utama yang dihadapi tim adalah: "Apa yang harus dilakukan dengan kurir?" Kemudian kami memutuskan untuk membuat bot telegram. Karena kami pandai bot .



Peningkatan jumlah pesanan menegaskan keberhasilan model bisnis yang dipilih. Namun kemudian kami mulai mengalami keterbatasan bot sebagai platform. Secara khusus, pengembangan memiliki beberapa tugas:



  • Lihat rute dan semua pesanan di peta yang nyaman
  • Diikat ke beberapa tempat penjualan sekaligus
  • Dapatkan informasi terkini tentang status pesanan
  • , . , , , .
  • . telegram : 8 .
  • “” - , .


Kami diliputi dengan kilas balik tentang masalah dengan ulasan tersebut. Selain itu, dengan pendekatan standar untuk pengembangan, kami harus melalui semua tahapan desain, desain, analisis oleh editor UX, tata letak, dan perakitan. Kami memperkirakan ini akan memakan waktu satu hingga tiga bulan dan menghabiskan sumber daya dari aplikasi utama.



Fakta menarik: di FullStack, empat pahlawan terlibat di front VkusVilla: 2 untuk iOS dan 2 untuk Android. Jika Anda ingin menemani mereka, kirimkan surat kepada saya - kafa@automacon.ru.



Pengembangan dimulai



Pada saat itu kami beruntung: kami menemukan orang-orang yang memberi tahu kami tentang platform tanpa kode Bubble.io. Menurut mereka, pengajuan permohonan kami bisa dilakukan di sana dalam seminggu. Selain itu, mereka menunjukkan dengan tepat bagaimana itu bisa berfungsi dan bahkan lulus tes untuk melihat apakah itu bisa bekerja dengan backend kami yang agak rumit.



Sejujurnya, Bubble tampak seperti teknologi yang agak kasar bagi saya, dalam hal antarmuka pengguna ini adalah sistem yang agak aneh dan tidak responsif.



Namun saat memahaminya, sebuah ide muncul: menggunakan prinsip platform untuk membuat aplikasi Anda sendiri dengan cepat. Karena jika Bubble bisa mengatasi tugas ini, lalu mengapa tidak bisa SPA, misalnya?



Kami memutuskan untuk menulis antarmuka pengguna di ReactJS menggunakan kerangka Capacitor . Proyek ini dirangkai menjadi satu set file yang dioptimalkan dan dikompresi yang diunggah ke server jarak jauh. Kapasitor memiliki akses ke fungsi asli, aplikasi diluncurkan melalui WebView, di mana URL dengan proyek yang dirakit di ReactJS ditentukan. Menurut logika ini, proyek harus dibuka sebagai situs biasa dengan kemampuan untuk memanggil fungsi asli. Anehnya, Apple tidak masalah membiarkan teknologi seperti ini masuk ke app store-nya.



Kami menulisnya, yang kami sampaikan kepada orang-orang dengan kompetensi Bubble dan salah satu programmer React kami. Itu terlihat agak primitif: kami mengambil panduan desain, memikirkan UI sederhana dan menyusun bagian depan yang akan menjalankan semua fungsionalitas bot.



Setiap tim (jika kami menghitung programmer kami sebagai satu tim) memiliki waktu 2 minggu untuk menyelesaikan tugas: berdasarkan pedoman, secara mandiri membuat aplikasi yang paling sederhana dan nyaman. Pengembang harus berkonsultasi langsung dengan project leader dari sisi bisnis.



Izinkan saya menekankan bahwa kami sengaja meninggalkan desain, desain, dan keterlibatan seorang analis.



Mengapa ada dua tim?



Dalam hal ini, fakta bahwa kami bekerja dengan VkusVill berperan. Dalam budaya mereka, metode menduplikasi pemasok digunakan secara aktif. Saya penasaran untuk melihat bagaimana tim Bubble pihak ketiga akan mengerjakan proyek tersebut. Mungkin kita bisa mengadopsi dari mereka beberapa trik, teknik manajemen dan fitur komunikasi.



Pada saat yang sama, saya tidak memiliki keyakinan tanpa syarat pada keberhasilan aplikasi berdasarkan konstruktor, jadi saya tidak ingin menghabiskan 2 minggu untuk membuat satu solusi.



Apa yang terjadi



Pertama-tama, gagasan untuk memparalelkan perintah ternyata sangat logis: solusi antarmuka tanpa kode entah bagaimana tidak langsung bekerja.







Karena tugas melakukan sesuai dengan pedoman itu sekaligus, penerapannya entah bagaimana sedikit menurunkan motivasi saya. Dari sudut pandang respons, Bubble memiliki masalah yang jelas: semuanya ditekan dengan canggung, seringkali dua kali. Dalam prosesnya, satu tarian lagi dengan rebana ditemukan: tim membutuhkan lebih dari 2 hari untuk mengganti peta Google "asli" untuk Bubble dengan Yandex. 1 hari lagi - untuk membuat fungsionalitas pembukaan rute melalui 2Gis. Pada saat yang sama, solusinya ternyata kruk: jika 2Gis tidak diinstal pada perangkat, itu masih ditawarkan. Dalam hal biaya tenaga kerja, tim tanpa kode mendapat sedikit lebih dari 80 jam (awalnya ini adalah batasnya) sementara aplikasi ternyata mentah. Ini adalah akhir kerja sama dengan mereka.



Solusi di ReactJS ternyata jauh lebih optimal: pertama, fungsionalitas penuh diselesaikan dalam 67 jam, dan kedua, dari sudut pandang pedoman dan logika, semuanya ternyata cukup berfungsi:







Publikasi di iOS berhasil : tidak ada pertanyaan untuk peninjauan, keesokan harinya aplikasi sudah disimpan. Kami tidak mengunggah Android ke Play Market, kami hanya menempatkan .apk di penyimpanan awan.



Setelah peluncuran, semua keuntungan dari perakitan semacam itu menjadi nyata. Aplikasi belum siap untuk pengujian penuh, dan pembaruan serta peningkatan lebih mudah dilakukan tanpa perlu publikasi.



Sekarang aplikasi telah bekerja selama beberapa bulan, kami telah menambahkan fungsionalitas yang cukup banyak, membuat Kazdev yang bagus dengan kurir. Semua orang bahagia.



Sedikit kesimpulan



Anehnya, pengembangan bubble.io memakan waktu lebih lama, dan produk akhirnya lebih mentah. Batasan konstruktor memainkan peran penting di sini.



Pada awalnya, ketika mengatur tugas teknis, saya menarik perhatian tim tentang pentingnya menggunakan pedoman dengan elemen visual yang sudah jadi: font, ikon, gaya umum, dll. Meskipun demikian, orang-orang dari Bubble memiliki antarmuka yang sangat primitif. Tidak mungkin bahwa dangkal "tidak punya waktu" dapat memainkan peran yang menentukan; sebaliknya, faktanya adalah bahwa platform tidak dapat disesuaikan dengan baik. Jika seseorang bisa menjelaskan alasannya, tulis di komentar.



Mungkin mengejutkan banyak orang bahwa kita tidak tahu tentang metodologi seperti itu dan sudah digunakan secara luas. Namun demikian, itu adalah wahyu bagi saya dan saya pikir ini adalah solusi yang sangat bagus untuk aplikasi perusahaan dengan jumlah Pengguna yang sedikit. Aplikasi ini ternyata berkali-kali lebih nyaman dan secara fundamental berbeda dari versi adaptif situs, waktu implementasinya lebih pendek daripada saat bekerja dengan ReactNative atau Flutter, perbedaannya tidak terlihat secara visual.



Untuk meringkas: proyek tampak seperti tantangan yang baik bagi tim, dan bagi saya pribadi, mengelolanya adalah cara yang bagus untuk melepaskan diri dari rutinitas tugas-tugas "besar" yang panjang, hati-hati dan sangat bijaksana.



All Articles