Shopify'da özel uygulama ne zaman gerekir?
App Store'da on binlerce uygulama varken kendi uygulamanızı geliştirmek ne zaman mantıklı? Karar ölçütlerini, maliyet kalemlerini ve hazır çözümün nerede yetmediğini yazdık.
“Bunun için bir uygulama vardır” cümlesi Shopify'da çoğu zaman doğru. Ekosistemin en güçlü tarafı bu: ihtiyaçların büyük kısmı aylık birkaç dolarlık hazır çözümlerle karşılanıyor ve bunu görmezden gelip her şeyi geliştirmek pahalı bir hata olur.
Ama bir sınır var. Bu yazı o sınırın nerede olduğu, sınırın ötesine geçildiğinde ne yapıldığı ve özel geliştirmenin gerçek maliyet kalemleriyle ilgili.
Önce ayrım: özel uygulama tam olarak nedir?
Terim karışıyor, o yüzden baştan ayıralım. Shopify'da bir ihtiyacı çözmenin dört yolu var ve sadece biri “uygulama geliştirmek”:
Gelen taleplerin önemli bir kısmı aslında ilk iki gruba giriyor. “Uygulama geliştirilsin” diye başlayan görüşmelerin bir bölümü, tema tarafında yarım günlük bir düzenlemeyle ya da bir otomasyon kuralıyla kapanıyor. Bunu söylemek işimize gelmez ama söylüyoruz.
Otomasyon akışları ve karar kurallarıyla nelerin çözülebildiğini, hangisinin hangi pakette olduğunu ayrı bir yazıda anlattık.
Functions ve FlowÖzel uygulamanın gerçekten gerektiği durumlar
Projelerde özel geliştirmeye giden yolu açan beş durum var. Biri bile yoksa, hazır çözümlerle devam etmenizi öneriyoruz.
Beşinci madde en çok gözden kaçan. Sekiz uygulamayla kurulmuş bir mağazada aylık toplam abonelik, çoğu zaman bir yıllık geliştirme bütçesinin küçümsenmeyecek bir kısmını ediyor — üstüne sayfa hızındaki bedeli de ekleniyor.
Sayfaya eklenen her betiğin gerçek maliyetini ve denetimi nasıl yürüttüğümüzü ayrı bir yazıda anlattık.
Hız denetimiHazır uygulamayı seçmenin doğru olduğu durumlar
Tersini de net yazalım. Şu durumlarda özel geliştirme önermiyoruz:
Üçüncü madde en sağlam kural: bir işi hazır bir uygulamayla bir süre yapmadan, o iş için doğru yazılımı tarif edemezsiniz. Erken geliştirme, yanlış şeyin iyi yapılması demek.
Özel uygulamanın maliyet kalemleri
Geliştirme teklifleri çoğu zaman tek rakamla veriliyor ve karar bu rakama bakılarak alınıyor. Oysa maliyet dört kalemden oluşuyor:
Üçüncü kalem tekliflerde en sık atlanan yer. API sürümü geçtiğinde güncellenmeyen uygulamalar bir gün sessizce çalışmayı bırakıyor ve bu genellikle en kötü anda fark ediliyor.
İhtiyacın gerçekten geliştirme gerektirip gerektirmediğini önce yazılı olarak değerlendiriyor, kapsamı ve bakım planını birlikte çıkarıyoruz.
Özel uygulama geliştirmeNasıl planlıyoruz?
Bir özel uygulama projesine başlamadan önce üç belge çıkarıyoruz. Bunlar olmadan geliştirmeye başlamıyoruz.
Üçüncüsü kulağa tuhaf gelebilir ama en çok işe yarayan belge o. Projelerin uzamasının en yaygın sebebi, geliştirme sırasında ortaya çıkan “bir de şunu yapsın” istekleri.
Geliştirme sırasında dikkat ettiklerimiz
Beşinci madde entegrasyon projelerinin en pahalı arıza biçimi. Uygulama hata vermeden durduğunda kimse fark etmiyor; fark edildiğinde arada kalan siparişler çoktan sorun olmuş oluyor.
Kod kimde durur?
Özel geliştirmede en önemli sözleşme maddesi bu ve konuşulmadan geçilmemeli.
Bunu ajans tarafında olarak yazıyoruz: geliştirdiğimiz kodun bizde kilitli kalması müşteri için risk, bizim için de sağlıksız bir bağ. Çalışmaya devam etmenin sebebi bağımlılık değil, işin iyi yapılması olmalı.
Sık yapılan hatalar
Özet
Özel uygulama, hazır çözümlerin yetmediği yerde başlayan bir araç; bir statü ya da varsayılan tercih değil. Kendine özgü iş kuralı, kurum içi sistem bağlantısı, veri sahipliği, ölçek ve uygulama yığınının kendisi — bu beş başlıktan biri yoksa hazır çözümle devam etmek doğru karar.
İhtiyacınızı ve şu an hangi uygulamalarla çözdüğünüzü paylaşın; geliştirme gerektirip gerektirmediğini önce yazılı olarak değerlendirelim. Hazır bir uygulamayla çözülebiliyorsa, hangisiyle çözüleceğini de söyleriz.