Web ve mobil uygulamalar için tek bir backend: pratik bir plan

İki uygulama neden ayrışır

İki uygulama aynı amaçla başlayabilir ama kısa sürede farklı sistemler gibi davranmaya başlar. Ofis ekibi net bir yönetim web uygulamasına ihtiyaç duyar. Saha ekibi hızlı bir mobil uygulamaya ihtiyaç duyar. Her iki ekip de aynı işler, müşteriler, formlar ve durum güncellemeleriyle çalışır, ama her uygulama günlük rutinler doğrultusunda farklılaşır.

İşte ayrışma burada başlar. Ofis personeli iş emirleri oluşturup planlarken saha personeli sahada onları günceller. Her iki ekip aynı kayıtlara dokunuyorsa ama her uygulama onları farklı şekilde ele alıyorsa, sorunlar çabuk ortaya çıkar. Webde "atanmış" olarak işaretlenen bir iş mobilde "hazır" sayılabilir. Bir uygulamada zorunlu olan bir not diğerinde isteğe bağlı olabilir. Kısa sürede kayıt tek bir net hikâye anlatmaz hale gelir.

Ana neden çoğaltılmış mantıktır. İş kuralları her iki uygulamaya da dağıtıldığında küçük farklılıklar gerçek çelişkilere dönüşür. Bir ekranda teknisyenin bir görevi fotoğraf olmadan kapatmasına izin verilirken, diğer tarafta faturalamayı engellemek için fotoğraf gerektirebilirler. Artık durum işin bittiğini söylüyor ama veri eksiktir.

İsimler de kayar. Bir ekip "ziyaret tamamlandı" der. Diğer ekip "iş bitti" der. Bir yönetici "kapandı" der. Bu terimler konuşmada yeterince yakın görünse de yazılımlarda ayrı adımlar, filtreler ve raporlar haline gelir. Zamanla kafa karışıklığı artar, özellikle yeni ekip üyeleri süreci önlerinde olan ekrandan öğrenmeye başladığında.

Küçük değişiklikler bile farkı genişletir. Yeni bir onay adımı, zorunlu bir imza veya ekstra bir müşteri alanı önemsiz görünür. Ama değişiklik iki yerde yeniden yapılmak zorundaysa genellikle bir uygulama önce güncellenir, diğeri sonra yetişir. Bu gecikme yeniden çalışmaya, destek sorunlarına ve bozuk verilere yol açar.

İşte bu yüzden paylaşılan bir backend önemlidir. Yönetim web uygulaması ile saha mobil uygulaması kayıtları paylaşıp kuralları paylaşmadığında sistem yavaşça ikiye bölünür.

Tek bir paylaşılan iş akışıyla başlayın

Ekranları düşünmeden önce, gerçek süreci baştan sona yazın. Bir isteğin oluşturulduğu andan işin kapatıldığı, onaylandığı veya faturalandırıldığı ana kadar ilerleyin. Bu, her iki uygulamaya da aynı omurgayı verir.

Yaygın bir hata, yönetim web uygulamasını ve saha mobil uygulamasını iki ayrı ürün olarak planlamaktır. Bu genellikle aynı sürecin iki versiyonunu, aynı durum için iki ayrı anlamı ve daha sonra fazladan manuel düzeltmeleri yaratır. İş akışı önce gelmelidir.

Açık bir dil kullanın. Örneğin: istek oluşturuldu, atandı, kabul edildi, ilerliyor, duraklatıldı, tamamlandı, gözden geçirildi. Ardından her adımı inceleyin ve kimlerin dokunduğunu sorun. Bazı adımlar her iki role aittir. Bir ofis çalışanı işi atayabilirken saha çalışanı mobilde kabul edebilir. Her ikisi de iki farklı iş akışı değil, tek bir iş akışının parçasıdır.

Önce paylaşılan adımları işaretleyin

Bunu planlamanın en kolay yolu paylaşılan eylemleri cihaza özgü eylemlerden ayırmaktır.

Paylaşılan eylemler: bir isteğin oluşturulması, bir çalışan atanması, durum güncellemesi, not ekleme ve işin kapatılması gibi şeylerdir. Web odaklı eylemler genellikle kuyrukları gözden geçirme, işi yeniden atama, tamamlamayı onaylama ve rapor çalıştırma gibi işlemleri içerir. Mobil odaklı eylemler genellikle görevi kabul etme, fotoğraf yükleme, imza alma ve varış işaretleme gibi işlemlerdir.

Bu, uygulamaların nerede farklı olması gerektiğini ve nerede olmaması gerektiğini görmenize yardımcı olur. Web uygulaması daha fazla filtre ve yönetim kontrolü gösterebilir. Mobil uygulama daha büyük butonlar ve daha az seçenek kullanabilir. Ancak durum mantığı, doğrulama ve iş kuralları tek bir yerde kalmalıdır.

Durum değişiklikleri için bir tek gerçek kaynağı erken seçin. Eğer bir görev sadece fotoğraflar ve müşteri imzası eklendikten sonra Tamamlandı durumuna geçebiliyorsa, bu kural backend'de yaşamalıdır. Yalnızca mobil ekranda veya sadece yönetim panelinde olmamalıdır.

Basit bir test yardımcı olur: aynı eylem her iki uygulamadan gerçekleştiğinde sonuç aynı mı olmalı? Cevap evet ise, iş akışınız ortaktır. Hayır ise, iş kuralları muhtemelen arayüzün içinde gizleniyordur.

Temel veri modelini tanımlayın

Ekranlarla başlamayın. Günlük olarak işletmenizin izlediği gerçek şeylerle başlayın: müşteriler, konumlar, işler, personel, envanter, faturalar veya denetimler. Hem yönetim web uygulaması hem de saha mobil uygulaması aynı iş ile uğraşıyorsa, o iş tek bir kayıt olarak tek bir paylaşılan veri modelinde var olmalıdır.

Yararlı bir test: "Bu iki uygulama gerçeğe dair farklı görüşlere sahip olabilir mi?" Eğer cevap evet ise, model yanlış yerde bölünmüştür. Backend tek gerçek kaynağı tutmalıdır.

Her temel kayıt için paylaşılan alanları birlikte tutun. Bir iş emri ID, durum, müşteri, konum, atanmış çalışan, planlanan tarih, tamamlanma tarihi, notlar, ekler ve fotoğrafları içerebilir.

Bu alanlar her iki deneyim için önemlidir, görüntülenme şekilleri farklı olsa bile. Yönetim ekibi programları düzenleyip web panosundan personele atama yapabilir. Saha ekibi programa sadece bakabilir, fotoğraf yükleyebilir ve işi tamamlandı olarak işaretleyebilir. Yine de aynı kayıt söz konusudur; sadece izinler farklıdır.

Rol-özel alanları yalnızca gerçek bir ihtiyaç olduğunda ekleyin. Eğer dağıtımcıların dahili bir öncelik puanına ihtiyacı varsa, bu aynı iş emrinin üzerinde durabilir ve saha kullanıcılarından gizlenebilir. Mobil çalışanların çevrimdışı eşleme bayrağına veya cihaz yakalama meta verilerine ihtiyacı varsa, ana iş kaydının anlamını değiştirmeden dikkatle ekleyin.

Uygulamaları gerçek işte kullanılabilir kılan destek alanlarını unutmayın. Sahiplik kimin kaydı oluşturduğunu, kime ait olduğunu veya kime atandığını gösterir. Zaman damgaları ne zaman oluşturulduğunu, güncellendiğini, başlatıldığını veya tamamlandığını gösterir. Dosyalar ve görüntüler yapılan işin kanıtını sağlar. Notlar, ana veriyi değiştirmeden istisnaları açıklamaya yardımcı olur.

AppMaster kullanıyorsanız, bu genellikle önce paylaşılan varlıkları modellemek ve sonra web ve mobil uygulamalarda farklı UI ve erişim kuralları uygulamak anlamına gelir. Bu, mantığın iki arayüze yayılmak yerine backend'de merkezlenmesini sağlar.

İş kurallarını ekranların dışında tutun

Eğer yönetim web uygulaması ve saha mobil uygulaması her birinin neye izin verileceğine ayrı ayrı karar verirse, neredeyse anında ayrışırlar. Bir ekran bir değeri kabul ederken diğeri reddedebilir veya bir uygulama bir işi "tamamlandı" olarak işaretlerken diğeri hâlâ "ilerliyor" sayabilir.

Çözüm basittir: iş kurallarını backend'de tutun ve her iki uygulamanın aynı mantığı çağırmasına izin verin.

Doğrulama kuralları tek bir yerde olmalıdır. Bir iş emri atanabilmesi için bir müşterinin, bir konumun ve en az bir görevin gerekliliği varsa, backend bunu her seferinde zorlamalıdır. Web uygulaması yardımcı bir mesaj gösterebilir, mobil uygulama da aynısını yapabilir, ama kural hiçbirinin tekelinde olmamalıdır.

Durum değişiklikleri için de aynı şey geçerlidir. Hem uygulamalar için Draft, Assigned, In Progress, Completed ve Closed gibi tek bir paylaşılan durum akışı kullanın. Bu akış backend'de yaşadığında her iki uygulama da aynı yolu izler. Yönetim ekibi web uygulamasından işi atayabilir, saha ekibi mobilden ilerlemeyi güncelleyebilir, ama backend izin vermedikçe hiçbir uygulama adımları atlayamaz.

Hesaplamalar ve kontroller de tek bir yerde çalıştırılmalıdır. Toplam maliyet saatlere, malzemelere, vergiye veya onay limitlerine bağlıysa, bunu backend'de yapın. Bir teknisyenin fotoğraf veya imza olmadan bir işi kapatamayacağı kuralı varsa, bunu yine backend'de kontrol edin.

Uygulamada nasıl görünür

Bir servis şirketi hayal edin. Ofis ekibi işleri oluşturmak için web uygulamasını kullanıyor, teknisyenler ise sahada mobil uygulamayı kullanıyor. Her iki uygulama da iş oluşturma, personel atama, durum değiştirme ve toplamları hesaplama için aynı backend mantığını çağırmalıdır.

Bu ayrım ekranları basit tutar. Her uygulama kullanıcıların görmesi ve yapması gerekenlere odaklanır, backend ise tutarlı kalması gereken kuralları korur.

Adım adım nasıl planlanır

Ekranlar değil, insanlarla başlayın. Sistemi kimlerin kullandığını, ne yaptıklarını ve hangi seçimleri yapmaya yetkili olduklarını yazın.

Bir yönetim web uygulaması ve bir saha mobil uygulaması için bu genellikle ofis personeli, yöneticiler ve saha çalışanları demektir. Ofis ekibi işleri oluşturabilir, kişileri atayabilir, değişiklikleri onaylayabilir ve çalışmaları kapatabilir. Saha ekibi yalnızca atanmış işleri görebilir, ilerlemeyi güncelleyebilir, not ekleyebilir ve kanıt yükleyebilir.

Bunlar netleşince, tek sayfada paylaşılan veri modelini çizin. Önce basit tutun: işler, müşteriler, personel, konumlar, fotoğraflar ve durum geçmişi. Her kaydın gerçekten ihtiyaç duyduğu alanları ekleyin.

Kayıtlar ve durum değişiklikleri etrafında tasarlayın, sayfalar etrafında değil. Her iki uygulama da aynı işle uğraşıyorsa, aynı durum değerlerini, aynı atama kurallarını ve aynı onay mantığını kullanmalıdır.

Basit bir planlama sırası

1. Her kullanıcı rolü için ana eylemleri listeleyin.
2. Her eylemin hangi verileri okuduğunu ve değiştirdiğini not edin.
3. Durum kurallarını net şekilde tanımlayın.
4. Her ekranı tam olarak hangi veriye ihtiyaç duyduğuna eşleyin.
5. Modeli birkaç gerçek görevle baştan sona test edin.

Bu son adım en önemlisidir. Gerçekçi bir vaka alın: ofiste oluşturulan bir tamir talebi, bir teknisyene atanması, sahada güncellenmesi ve ardından bir yönetici tarafından gözden geçirilmesi. Modeliniz bu akışı ekran-özel kurallar olmadan yönetiyorsa doğru yoldasınız demektir.

Her uygulamada ne farklı olmalı

Backend paylaşılan kalmalı ama deneyim farklı olmalıdır. Yönetim web uygulaması ve saha mobil uygulaması farklı işler için hizmet verdiğinden aynı kayıtları farklı şekillerde sunmalıdır.

Web tarafında insanlar genellikle daha geniş bir görünüm ister. Birçok kaydı karşılaştırır, sütunları sıralar, geçmişi tarar, filtreler çalıştırır ve toplu güncellemeler yapar. Bir dağıtımcı ya da operasyon yöneticisi on iş emrini aynı anda güncellemek, personele atamak ve durum değişikliklerini tablo halinde kontrol etmek isteyebilir.

Mobilde hız genel bakımdan daha önemlidir. Saha çalışanı genellikle bir net cevaba ihtiyaç duyar: sıradaki görevim nedir? Ana ekran sıradaki görevi, adresi, iletişim bilgilerini, teslim tarihini ve durum güncelleme butonunu öne çıkarmalıdır.

Aynı veri, farklı sunum

Ana fikir basittir: kayıtları aynı tutun, etraflarındaki düzeni değiştirin. Her iki uygulama aynı iş, müşteri, durum ve not nesnelerini kullanıyorsa iş kuralları tek yerde kalır.

Değişen sadece arayüzdür. Web yoğun tablolar, kaydedilmiş filtreler ve toplu düzenleme araçları gösterebilir. Mobil ise mevcut görevi ve sonraki eylemi öne çıkarmalıdır. Mobil fotoğraf, imza, barkod tarama veya konum toplayabilir. Web daha derin inceleme, raporlama ve istisna yönetimi destekleyebilir.

Çevrimdışı kullanım gerçek bir farktır. Saha uygulaması sinyali kaybedebilir; bu senaryo senkronizasyon tasarımını, çakışma yönetimini ve hangi verilerin cihazda öncelikle saklanması gerektiğini etkiler. Yönetim web uygulaması genellikle istikrarlı bir bağlantı varsayar ve canlı güncellemelere daha fazla güvenir.

Basit bir örnek denetim sürecidir. Ofis ekibi ziyaretleri atamak, sonuçları gözden geçirmek ve hatalı girişleri topluca düzeltmek için web uygulamasını kullanır. Denetçi mobil uygulamayı sıradaki ziyareti açmak, fotoğraf çekmek, varışı onaylamak ve raporu göndermek için kullanır. Farklı ekranlar, aynı denetim kaydı.

Basit bir örnek senaryo

Ekipman tamiri yapan bir servis şirketi hayal edin. Ofis ekibi dizüstü bilgisayardan çalışırken teknisyenler günün büyük kısmını yolda geçirir.

Bir dağıtımcı yönetim web uygulamasını kullanarak yeni bir iş emri oluşturur. Müşteri adı, adres, problem detayları, öncelik, planlanan zaman ve atanan teknisyen girilir. Bu tek bir paylaşılan kayıt oluşturur; web için ayrı bir versiyon değil.

Daha sonra teknisyen saha mobil uygulamasını açar ve aynı iş emrini görür. Ekran farklı görünür çünkü iş farklı bir bağlamda kullanılıyor, ancak temel veri aynıdır. Teknisyen adresi görebilir, müşteriyi arayabilir, görev detaylarını kontrol edebilir ve ilerlemeyi tekrar yazmadan güncelleyebilir.

Sahada teknisyen hasarlı parçanın fotoğraflarını ekler, birkaç not yazar ve müşterinin imzasını alır. Bunların hepsi aynı iş kaydına kaydedilir. Mobil uygulama fotoğraflar veya notlar için kendi yanında ayrı bir sistem oluşturmaz; yalnızca paylaşılan veri modeline bilgi ekler.

Ofiste yönetici güncellenmiş işi yönetim web uygulamasında açar. Sahayla eklenenleri görebilir, işi onaylayabilir ve faturaya veya takip işine gönderebilir. Kimsenin iki versiyon arasında karşılaştırma yapmasına gerek yoktur.

Durum geçmişi bunu kullanışlı kılar. Dağıtımcı işi Scheduled olarak ayarladıysa, teknisyen In Progress olarak işaretlediyse ve yönetici Completed olarak kapattıysa herkes aynı zaman çizelgesini görür. Bu, basit soruları cevaplamayı kolaylaştırır: durumu kim değiştirdi, ne zaman değiştirdi ve ziyaret öncesinde/sonrasında ne oldu?

Kaçınılması gereken yaygın hatalar

En büyük hata aynı kuralı iki yerde koymaktır. Eğer yönetim web uygulaması bir işin "Scheduled" durumundan "In Progress" durumuna geçebileceğini söylüyorsa ve mobil uygulama da bunu kontrol ediyorsa, bu kurallar ayrışacaktır. Durum değişikliklerini, izinleri ve zorunlu kontrolleri backend'de tutun, böylece her iki uygulama da aynı mantığı izler.

Başka bir yaygın problem, aslında aynı olan iş için ayrı kayıtlar oluşturmaktır. Ekipler ofis görünümünü saha görünümünden farklı hissettirmek istediklerinde bunu yaparlar. Sonra yönetim uygulamasında bir "randevu" olur, mobilde bir "ziyaret" olur ve bunları senkronize etmek birilerinin işi olur. Bu genellikle notların uyumsuzlaşmasına, tekrar eden güncellemelere ve hangi kaydın gerçek olduğuna dair karışıklığa yol açar.

Alanlar (fields) başka bir tuzaktır. Bir ekip sadece bir ekstra detay istediği için sütun eklemek kolaydır. Ama her alanın bir amacı olmalı. Neden önemli olduğunu, kim tarafından kullanıldığını ve bir kuralı, raporu veya kararı etkileyip etkilemediğini sorun. Cevap belirsizse, ihtiyaç gerçek olana kadar bırakın.

Zayıf bağlantı çoğu zaman sahada ilk gün göz ardı edilir. Bir teknisyen mobil uygulamayı bir bodrumda, kırsal bir yolda veya zayıf sinyalin olduğu bir depoda açabilir. Eğer uygulama her eylem için canlı bağlantı gerektiriyorsa işler durur. Hangi verinin çevrimdışı erişilebilir olması gerektiğini, hangi eylemlerin bekleyebileceğini ve cihaz yeniden bağlandığında çakışmaların nasıl ele alınacağını planlayın.

İsimler de paylaşılan sistemi bozabilir. Bir ekip bir adımı "Assigned" derken diğer ekip "Dispatched" ya da bir başkası "Ready" diyorsa, insanlar bunları farklı durumlar olarak görmeye başlar. Erken bir ortak sözlük üzerinde anlaşın ve her yerde bunu kullanın.

İyi bir sezgi kontrolü basittir: bir işin tek bir gerçek kaynağı olmalı, bir kural tek bir yerde yaşamalı ve bir durum net bir ada sahip olmalıdır.

İnşa etmeden önce hızlı kontroller

Herhangi bir şey inşa etmeden önce planı kağıt üzerinde test edin. Model birkaç dakikada açıklanabilecek kadar basitse, genellikle hem web hem mobil büyüdükçe istikrarlı kalması yeterince basittir.

İyi bir kontrol: her iki ekip aynı kayda işaret edip aynı şeyi mi kastediyor? Ofis ekibi bir işi, görevi, müşteriyi veya denetim raporunu saha ekibinden farklı görüyorsa ayrışma erken başlar.

Kısa bir kontrol listesi kullanın:

• Bir iş emri gibi tek bir temel kaydı seçin ve her iki uygulamanın da aynı sürümü okuduğunu doğrulayın.
• Doğrulama kurallarını bir kez backend'de yazın, her ekranın içinde değil.
• Her durum değişikliğini tek bir yol olarak test edin.
• Modeli basit bir diyagramda çizin.
• Mobil görünümü en gerekli olanla sadeleştirin.

Küçük bir senaryo yardımcı olur. Yönetim web uygulaması tamir ziyaretlerini planıyor ve mobil uygulama teknisyenler tarafından kullanılıyor. Yönetim ekibi filtrelere, raporlara ve tam müşteri geçmişine ihtiyaç duyabilir. Teknisyen ise sadece bugünün işleri, iletişim bilgileri, güvenlik notları ve durum güncellemesi yapmak isteyebilir. Farklı ekranlar sorun değil. Farklı iş kuralları sorun.

Bir pratik test daha: bir kuralı değiştirin ve kaç yerde dokunmanız gerektiğine bakın. "Tamamlamadan önce fotoğraf gereklidir" kuralını değiştirmek backend mantığına ek olarak birkaç ayrı ekranı düzenlemeyi gerektiriyorsa, tasarım zaten parçalanmaya başlamıştır.

Sonraki adımlar

Hem web hem mobil için tek bir backend istiyorsanız, her ekranı ya da her ekip isteğini eşleştirmekle başlamayın. Önce her gün önemli olan tek bir iş akışıyla başlayın: iş oluşturma, atama, durum güncelleme ve kapatma gibi. Küçük bir iş akışı testi yapmak daha kolaydır ve veri modelinin nerede net olduğunu, nerede boşluk olduğunu çabucak gösterir.

Ekranları cilalamadan önce backend kurallarını oluşturun. Hangi alanların zorunlu olduğunu, kimin durumu değiştirebileceğini, veri eksik olduğunda ne olacağını ve hangi eylemlerin uyarı veya takip görevleri tetikleyeceğini karar verin. Bu kurallar backend'de yaşadığında, yönetim web uygulaması ve saha mobil uygulaması yüzeyde farklı görünse bile aynı mantığı izler.

Pratik bir sıra basittir: ana kayıtları ve ilişkilerini tanımlayın, temel iş kurallarını ve durum değişikliklerini yazın, iş akışını örnek verilerle test edin, ofis işleri için web görünümünü ve saha işleri için mobil görünümü tasarlayın, sonra ilk versiyonu gerçek kullanıcılarla gözden geçirin.

Bu sıra, iki uyumsuz uygulama inşa etme hatasından kaçınmanıza yardımcı olur.

Daha hızlı ilerlemek isterseniz, AppMaster gibi bir no-code platformu yardımcı olabilir. Veri ve iş mantığını tek yerde tanımlamanıza, ardından aynı temele dayanarak bir web uygulaması ve native mobil uygulama oluşturmanıza izin verir.

İlk yayın küçük olsun. Bir yöneticiye web uygulamasını gerçek bir görev için kullanmasını, bir saha çalışanına da mobil uygulamayı gerçek bir vardiyada kullanmasını söyleyin. Nerede tereddüt ettiklerini, neleri atladıklarını ve neyin olmasını beklediklerini gözlemleyin. Önce o noktaları düzeltin, sonra daha fazla iş akışına genişletin.

Genellikle en güvenli yol budur: tek bir paylaşılan model, tek bir kural seti ve gerçek iş etrafında şekillendirilmiş iki deneyim.