Maliyeti kullanıcı ve iş kuralı üzerinden tanımlayın
Bir CRM ve e-ticaret entegrasyonu uygulamasında “siparişleri gönder” ifadesi yeterli kapsam değildir. Sipariş hangi durumda aktarılacak, iptal ve iade nasıl işlenecek, hangi sistemdeki bilgi esas alınacak? İşlemi başlatan kullanıcının rolünü, çalışma sıklığını ve gecikmenin operasyon üzerindeki etkisini yazın. Aynı ekran, farklı kurallarda çok farklı iş yükü yaratabilir.
Örneğin bayi siparişini onaylayan görevli, fiyat değişmişken eski tutarı göndermemeli; bağlantı kesildiğinde aynı siparişin iki kez oluşturulması da önlenmelidir. Bu bir tasarım senaryosudur, yaşanmış müşteri sonucu değildir. Başarılı akışın yanında eksik ürün eşleştirmesi, yetkisiz kullanıcı ve tekrarlanan istek örneklerini hazırlayın. Her örnekte beklenen sonuç, görülecek hata ve işlem sahibinin yapacağı düzeltme tanımlansın. Ekran listesi bu davranışların ardından anlamlı hale gelir.
Özel geliştirmeden önce daha küçük çözümü araştırın
Bir Shopify iş ortağı ile keşif yaparken önce mağazanın mevcut özelliğini, hazır uygulamayı ve sınırlı bağlantı seçeneğini aynı senaryoyla değerlendirin. Özel geliştirme özgün iş kuralı için gerekebilir; ancak yalnızca bir abonelikten kurtulmak, yeni bir uygulamanın bakım sorumluluğunu haklı çıkarmaz. Hazır araç ile küçük bir özel bağlantı birlikte de çalışabilir.
Karşılaştırmada uygulamanın listelediği özelliği sizin akışınızın tamamını karşıladığı varsayımıyla eşitlemeyin. Kısmi iade, çoklu depo, farklı para birimi veya eski kayıtlar açısından eksik kalan noktayı gösterin. Eksik, işiniz için zorunlu değilse ilk kapsamdan çıkarılabilir. Kritikse uyarlama, başka araç veya özel geliştirme maliyetini ayrıca isteyin. Küçük bir deneme sonucunda “bu işlem desteklenmiyor” kanıtı almak, bütün uygulamayı geliştirdikten sonra aynı sınırı öğrenmekten daha yararlıdır.
Mevcut özellik
İş zaten platform içinde yapılabiliyorsa işlem sırasını ve sorumlusunu netleştirin. Yeni uygulamanın gerçekten hangi ek davranışı sağlayacağını yazın.
Hazır uygulama
Lisans, kullanım ücreti, veri koşulu ve destek kapsamını karşılaştırın. Kritik senaryoyu gerçekçi örnek veriyle gösteren bir deneme isteyin.
Sınırlı özel bağlantı
Hazır aracın karşılamadığı tek akışı ayırın. İki sistem arasındaki veri ve hata sorumluluğu açık değilse küçük bağlantı da sürekli destek gerektirebilir.
OKUMADAN SONRAKİ ADIMA
Uygulama kapsamını fiyatlanabilir hale getirin
Mevcut iş akışınızı, sistemlerinizi ve zorunlu davranışı inceleyerek geliştirme ile işletim sınırlarını tanımlayalım.
API erişimini teklif varsayımı olarak bırakmayın
ERP ve mağaza entegrasyonu kontrolü için alan eşlemesini API izinleriyle birlikte hazırlayın. Shopify’ın güncel kurulum rehberi, yeni özel uygulamalarda Dev Dashboard, sürüm ve kapsam düzenini açıklıyor. Mağaza sahibinin erişim vermesi, istenen her işlemin platformda otomatik olarak mümkün olduğu anlamına gelmez.
Geliştiriciden gerekli okuma ve yazma izinlerini, kullanılan API’yi, mevcut plan veya onay bağımlılıklarını belirtmesini isteyin. Hassas veriyi örnek dosyaya gereksiz yere eklemeyin. Test için maskelenmiş kayıt veya sentetik senaryo kullanılabilir. Harici sağlayıcının dokümantasyonu, deneme erişimi ve veri kalitesi yoksa keşif sonucunda hangi belirsizliğin açık kalacağını yazın. Sabit fiyat, doğrulanmamış erişimi görünmez kılarak verilmemeli; bağımlılık çözüldüğünde kapsamı güncelleyecek kişi ve karar noktası belirlenmelidir.
Teklif kalemlerini ve kabul kanıtını ayırın
Mağaza operasyonunun uygulamayı hangi görevde kullanacağını belirledikten sonra keşif, arayüz, backend, veri modeli, bağlantılar, test ve yayın kalemlerini ayrı görün. Geçmiş veri aktarımı, yönetim ekranı ve birden fazla mağaza desteği aynı temel geliştirme kalemine gizlenmemeli. Teklifte her işin hangi varsayımla tahmin edildiği anlaşılmalıdır.
Kabul için yalnızca “ekran çalışıyor” demeyin. Doğru siparişin hedefte bir kez oluşması, hatalı kaydın görünür olması ve sorumlu tarafından yeniden işlenebilmesi gibi sonuçlar seçin. İptal veya düzeltmenin etkisini de kontrol edin. Teknik ekip düzeltmeyi yapar; operasyon sahibi günlük işi denediğinde kabul kaydı kapanır. Kapsam dışı değişiklik hangi onayla fiyatlanacak, veri geç gelirse takvim nasıl güncellenecek ve hangi bağımlılık yayın kararını durduracak soruları sözleşme öncesinde cevaplanmalıdır.
Hosting, izleme ve bakım bütçesini ekleyin
CI/CD ve DevOps kurulumu uygulamanın yayın, izleme ve geri alma düzenini işletim kapsamına bağlar. Hosting, veri saklama, dış servis kullanımı ve hata bildirimi geliştirme sonrası devam edebilir. Uygulamanın küçük olması, bir kesintide sorumlunun kim olduğunun önemsiz olduğu anlamına gelmez. Mağaza ekibinin görebileceği durum bilgisi ayrıca tasarlanmalıdır.
Bütçede sabit gider ile hacme göre artan gideri ayırın. Sipariş sayısı, veri tutma süresi veya harici API kullanımı büyürse hangi maliyet etkilenir? Normal kullanım ve yoğun dönem için kendi varsayımlarınızı yazın; evrensel fiyat aralığı kullanmayın. API değişikliği, güvenlik düzeltmesi ve yeni iş talebi aynı bakım işi değildir. Dahil kapasite, ilk yanıt hedefi, sağlayıcı kesintisindeki iletişim rolü ve güncelleme sonrası tekrar test kapsamı belirlenmelidir. Kod, barındırma hesabı ve erişimlerin sahipliği de işletim planında yer alsın.
Fiyat istemeden önce belirsizlik dosyasını hazırlayın
Bir Shopify geliştirme partnerine mevcut akış, örnek veri, zorunlu davranış ve kabul senaryosu göndererek karşılaştırılabilir teklif isteyebilirsiniz. Kimden hangi erişimin beklendiğini ve hangi kararın henüz verilmediğini belirtin. Veri hacmi veya geçmiş aktarım kapsamı bilinmiyorsa bunu sıfır maliyet kabul etmek yerine keşif görevi olarak kaydedin.
Teklifleri aynı dönem ve aynı hizmet kapsamıyla karşılaştırın. Bir teklif bakım içerirken diğeri yalnızca yayına çıkışı kapsayabilir. İlk aşamayı sınırlı bir iş akışıyla kabul etmek, açık bağımlılıklar çözülmeden bütün projeyi taahhüt etmek zorunluluğunu azaltır. Teslim dosyasında kaynak kod, yapılandırma açıklaması, hata inceleme yöntemi ve açık işler bulunmalı. Devir sırasında yeni sorumlu kontrollü bir hatayı bulup tekrar işlemeyi deneyebiliyorsa, bakım bağımlılığı daha görünür hale gelir.
| Kalem | Teklifte aranacak açıklama | Kabul veya tekrar inceleme |
|---|---|---|
| Keşif | İş kuralı, erişim ve açık varsayım | Karar sahibinin onaylı kapsamı |
| Geliştirme | Veri yönü, arayüz ve hata kurtarma | Başarılı ve başarısız senaryo kanıtı |
| Yayın | Ortam, yapılandırma ve geri alma | Yetkili kontrollü yayın testi |
| İşletim | Hosting, kullanım ve izleme sahibi | Olay kaydı ve yeniden işleme denemesi |
| Bakım | Dahil iş, API değişikliği ve devir | Güncelleme sonrası kritik akış testi |
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Sabit fiyatlı teklif alınabilir mi?
İş kuralı, veri ve erişim belirsizlikleri yeterince azaltılmışsa alınabilir. Açık bağımlılıklar varsa önce sınırlı keşif veya aşamalı teslim daha değerlendirilebilir bir kapsam sağlar. Sabit fiyatın hangi değişikliklerde güncelleneceğini yazın.
Özel uygulama aylık ücretsiz çalışır mı?
Hazır uygulama aboneliği kalksa bile hosting, izleme, harici servis ve bakım giderleri olabilir. Hangi hesabın kime ait olduğunu ve hacme bağlı faturanın nasıl izlendiğini teklifte ayrı görün.
Ekran sayısı fiyatı karşılaştırmak için yeterli mi?
Hayır. Veri aktarımı, iş kuralı, yetki ve hata senaryosu görünür ekranlardan daha fazla iş gerektirebilir. Aynı ekran listesine dayanarak farklı teklifleri eşit kapsam saymayın; davranış ve kabul örneklerini karşılaştırın.
Geçmiş sipariş aktarımı neden ayrı kalemdir?
Alan eşleştirmesi, eksik kayıt, tarih ve eski durumların yorumlanması ek çalışma gerektirebilir. Erişim ve veri kalitesi doğrulanmadan bütün geçmişin sorunsuz taşınacağı varsayılmamalıdır. Aktarımın kontrol ve düzeltme sahibini belirleyin.
Geliştirici değişirse uygulama sürdürülebilir mi?
Kod, hesap erişimi, veri modeli, yayın yöntemi ve açık işler devredilebiliyorsa yeni ekip değerlendirebilir. Sadece kod deposu paylaşmak yeterli olmayabilir; kontrollü bir bakım göreviyle devir açıklamalarını doğrulayın.
KAPSAMI BİRLİKTE BELİRLEYELİM
Uygulama kapsamını fiyatlanabilir hale getirin
Mevcut iş akışınızı, sistemlerinizi ve zorunlu davranışı inceleyerek geliştirme ile işletim sınırlarını tanımlayalım.
Kapsamı görüşelim