Native ve Cross-Platform Uygulamalar: İş Kararı Rehberi

Native ve cross-platform tartışması genellikle soyut yürütülür ve odadaki ilk geliştiricinin tercih ettiği çerçeveyle sonuçlanır. Oysa bu, dört girdisi olan bir iş kararıdır ve üçünün performansla ilgisi yoktur.

Bu rehber seçimi gerçekte neyin sınırladığını anlatıyor: kullanıcının fark edeceği etkileşim, bağımlı olduğunuz donanım, ne sıklıkla yayın yapacağınız ve üç yıl sonra bunu kimin sürdüreceği.

Kısa cevap

• Zorlu etkileşimi adlandırın: Takıldığında yanlış hissettirecek bir ekran yoksa native lehine deneyim gerekçesi zaten kapanmıştır.
• Zor ekranı iki kez yapın: Eski bir cihazda iki haftalık gerçek karşılaştırma, çerçeve yazılarının açık bıraktığını kapatır.
• Sürüm ritmi bir kısıttır: Aynı değişikliğin iki platforma aynı gün gitmesi gerekip gerekmediği, kararı performanstan çok etkiler.
• Üçüncü yılı sahiplik belirler: İçeride kimsenin sürdüremeyeceği teknik olarak ideal seçim, ürün kazanmaya başlarken yeniden yazıma döner.

İş sonucu ve kullanıcı, her şeyden önce

Platform kararının hedefi, üç yıl sonra da savunulabilir bir seçim yapmaktır. Ürünün gerçekten zorlandığı etkileşimi, bağımlı olduğu donanımı ve bunu kimin sürdüreceğini yazın. Bu üç yanıtı yazmadan yapılan karşılaştırma, çerçeve tercihinin gerekçelendirilmesine dönüşür.

Kullanıcının pürüzü fark edeceği ekranı somut olarak adlandırın. Böyle bir ekran yoksa deneyim gerekçesi kapanmıştır ve karar ekip, sürüm ritmi ve maliyet üzerinden verilir. Ekranı adlandırabiliyorsanız prototipleyin; adlandıramıyorsanız tartışmayı kapatın ve maliyete bakın.

Sürüm ritmini de bu aşamada yazın. İki platforma aynı gün çıkma zorunluluğu, çoğu ekibin beklediğinden fazla kısıt yaratır ve teknik tercihten önce bir çalışma biçimi taahhüdüdür. Mağaza inceleme sürelerini de hesaba katın; aynı gün yayın hedefi bazı platformlarda baştan gerçekçi değildir.

Native ve cross-platform uygulama karşılaştırması için dört karar alanı

Deneyim

Biraz yanlış hissettirdiğinde kullanıcıların fark edeceği etkileşimi adlandırın: kamera, harita, uzun bir liste, parmağı takip etmesi gereken bir animasyon. Böyle bir şey adlandıramıyorsanız native lehine deneyim gerekçesi zaten kapanmıştır.

Cihaz erişimi

Ürünün bağımlı olduğu donanım ve işletim sistemi özelliklerini, bir de yeni platform sürümlerinin ne kadar hızlı desteklenmesi gerektiğini listeleyin. Lansman günü en yeni yeteneğe ihtiyaç duyan bir ürünün yanıtı, barkod okuyan bir üründen farklıdır.

Sürüm modeli

Ne sıklıkla yayın yapmayı planladığınıza ve aynı değişikliğin iki platforma aynı gün gitmesi gerekip gerekmediğine karar verin. Sürüm ritmi seçimi çoğu ekibin beklediğinden fazla kısıtlar ve teknik bir tercihten çok bir çalışma biçimine bağlanmaktır.

Sahiplik

Üç yıl sonra bunu kimin sürdüreceğini, hangi dilleri zaten bildiğini ve bu becerinin bulunduğunuz yerde ne kadar kolay bulunduğunu çıkarın. Projelerin kaderini performanstan çok bu satır belirler ve karşılaştırmadan en sık çıkarılan satır da budur.

Riskler geliştirmeden önce masada olsun

• Zor etkileşim geç fark edilir: En zorlu ekranı iki yaklaşımla da prototipleyin ve ikisini eski bir cihazda yan yana çalıştırın. Prototipleri ekip dışından birine kullandırın.
• Platform özelliği desteklenmeden gelir: Her iki yaklaşımın son iki işletim sistemi sürümünü ne kadar sürede desteklediğine bakın. Destek gecikmesi varsa bunu yol haritasına risk olarak yazın.
• Sürümler birbirinden ayrışır: Aynı değişikliğin iki platforma aynı gün gitmesi gerekip gerekmediğine karar verin ve bunun maliyetini fiyata yazın. Maliyeti yalnızca geliştirme değil yayın süreci olarak da hesaplayın.
• Binada sürdürecek kimse yoktur: Üç yıl sonra bunu kimin sürdüreceğini ve hangi dilleri bildiğini şimdi yazın. Yanıt yoksa seçim üç yıl sonra yeniden yazım olarak geri döner.

Gerçekçi bir yol haritası çıkarın

1. Zorlu etkileşimleri listeleyin. Takıldığında kullanıcının fark edeceği ekranları ve bağımlı olunan donanımı yazın.
2. En zor ekranı iki kez yapın. İki yaklaşıma aynı süreyi verin ve ikisini eski bir cihazda yan yana çalıştırın.
3. Sürüm ritmini kararlaştırın. Aynı değişikliğin iki platforma aynı gün gitmesi gerekip gerekmediğini yazın.
4. Üç yılı fiyatlayın. Mağaza süreçleri, sürüm yükseltmeleri ve işe alım dahil toplamı karşılaştırın.

Pilot yönetişimi ve yatırım kararları

Native ve cross-platform uygulama karşılaştırması pilotunun amacı ürünün bütün gelecek kapsamını kanıtlamak değildir. En önemli kullanıcı veya işletme varsayımını gerçek koşullarda sınamalıdır. Pilot grubu, başlangıç seviyesi, gözlem süresi, destek modeli ve devam kararı baştan yazılırsa sonuçlar yalnızca olumlu örnek seçerek yorumlanmaz.

Haftalık karar ritmi kurun. Kullanıcı değeri, operasyon akışı, veri ve sistem sınırları ve başarı ölçümü başlıklarında toplanan kanıtı aynı masada değerlendirin; ürün kullanımı ile iş sonucunu ayırın. Karar seçenekleri “devam et” ile sınırlı olmasın: kapsamı düzeltme, veriyi iyileştirme, operasyonu değiştirme, belirli kullanıcı grubunu erteleme veya yatırımı durdurma da meşru sonuçlardır.

Pilot sonunda hangi yeteneğin işletmeye devredileceğini netleştirin. Ürün erişimleri, veri görünürlüğü, izleme, destek bilgisi, karar geçmişi ve sonraki yol haritası yalnızca geliştirme ekibinde kalmamalıdır. Bu sahiplik, native ve cross-platform uygulama karşılaştırması yatırımının kontrollü biçimde büyümesini sağlar.

Sonraki adım

Native ve cross-platform kararını çerçeve tartışmasından çıkarıp iki soruya indirin: hangi etkileşim yanlış hissettirir ve üç yıl sonra bunu kim sürdürecek. İkisinin yanıtı genellikle kararı tek başına verir.

Ayrıntıya girmek isterseniz: Seyahat Uygulaması: Aksaklık ve Bağlam Odaklı Planlama.

30 günlük doğrulama planı: Native ve cross-platform uygulama karşılaştırması

1-5. günler: doğru hissetmesi gereken etkileşimleri listeleyin. Bir gecikmenin ya da pürüzlü bir animasyonun müşteri tarafından fark edileceği ekranları ve ürünün bağımlı olduğu donanımı yazın. Listeyi kısa ve somut tutun. Çoğu üründe böyle bir iki yer vardır; sizinkinde hiç yoksa native lehine deneyim gerekçesi zaten kapanmıştır. Liste on maddeyi buluyorsa ürün muhtemelen üç ayrı üründür ve önce sorulması gereken soru platform sorusu değildir.

6-15. günler: o ekranı iki kez yapın. En zor etkileşimi her iki yaklaşımla da prototipleyin ve her birine aynı geliştirici süresini ayırın. İkisini ofisteki en yeni cihazda değil, eski bir cihazda yan yana çalıştırın. İki haftalık gerçek bir karşılaştırma, çerçeve yazılarının süresiz açık tutacağı tartışmayı kapatır; çünkü ölçülen bir kıyaslama testi değil sizin etkileşiminizdir. Aynı iki prototipi ekip dışından birine kullandırın; geliştiriciler kendi yaptıkları şeydeki pürüzleri bir süre sonra fark etmez olur.

16-30. günler: üç yılın maliyetini çıkarın. Mağaza süreçlerini, işletim sistemi yükseltmelerini ve her yol için gereken işe alımı ekleyin. Kurucu ekip ayrıldığında bunu kimin sürdüreceğini sorun. Kararı toplam üzerinden verin ve varsayımlarıyla birlikte yazın; böylece seçim, o odada bulunmamış birine sonradan açıklanabilir. Yanılmanın maliyetini de ekleyin; gerçekçi en kötü durum üçüncü yılda yeniden yazımdır ve bunu kaldıramayan bir plan, plan değildir.

Pratik çalışma sayfası: Native ve cross-platform uygulama karşılaştırması

Native ile cross-platform arasındaki karar dört kısıt tarafından belirlenir ve çoğu ekip bağlayıcı olanı geç fark eder. Her satırı ürününüzün ihtiyacına göre doldurun; çerçeve karşılaştırması yazılarına göre değil.

Projelerin kaderini performans satırından çok sahiplik satırı belirler. Teknik olarak ideal ama binada kimsenin sürdüremeyeceği bir seçim, üçüncü yılda pahalı bir yeniden yazıma dönüşür; genellikle tam da ürün kendini ödemeye başladığı noktada.

İlgili rehberler

• Aynı soruna daha geniş bir bakış için: Mobil Uygulama Yönetim Paneli: Özellikler, Roller ve Akışlar.
• Pratikteki bir sonraki adım şurada anlatılıyor: Uygulama Lansman Kontrol Listesi: Yayın Öncesi ve Sonrası.

Native ve Cross-Platform Uygulamalar: İş Kararı Rehberi yazısındaki mobil çalışmanın arkasına bütçe konduğunda Mobil Ürününüzü Konuşalım.