Mobil Uygulama Teklifi Nasıl Değerlendirilir? Yazılımcıya Sorulacak 15 Soru

Elinizde iki ya da üç teklif varsa, büyük ihtimalle aralarındaki fark sizi şaşırtmıştır. Biri diğerinin birkaç katı tutar, biri iki sayfa, öteki yirmi sayfadır. Ancak iki teklif genellikle aynı işi anlatmaz. Biri yalnız uygulamanın görünen yüzünü fiyatlarken, diğeri sunucuyu, yönetim panelini, mağaza sürecini ve bir yıllık bakımı da kapsar.

Talha Aslan ve ekibi olarak bu rehberde size bir kontrol listesi veriyoruz. Yazının sonunda şunları yapabileceksiniz:

• Bir teklifte hangi bölümlerin eksik olduğunu birkaç dakikada görmek.
• Yazılımcıya soracağınız 15 soruyu tek tabloda toplamak.
• Çok düşük bir teklifin nereden tasarruf ettiğini anlamak.
• İki teklifi aynı ölçütlerle puanlayıp karar vermek.

Maliyeti hangi etkenlerin belirlediğini ayrı bir yazıda anlattık; rakamların neden bu kadar değiştiğini merak ediyorsanız mobil uygulama geliştirme maliyetini neler belirler yazımıza bakabilirsiniz. Bu yazıda ise elinizdeki belgeyi birlikte okuyoruz.

Mobil uygulama teklifinde hangi bölümleri mutlaka görmelisiniz?

İyi bir teklif, iki tarafın aynı şeyi anladığını kanıtlayan bir sözleşme taslağı gibi çalışır. Bu nedenle aşağıdaki bölümlerden biri eksikse, eksik kalan kısım ileride ya ek fatura ya da anlaşmazlık olarak geri döner.

• Kapsam belgesi: uygulamanın ne yapıp ne yapmayacağının yazılı tanımı.
• Ekran listesi: her ekranın adı ve o ekranda kullanıcının yapabildiği işler.
• Platformlar: iOS, Android ya da ikisi; desteklenen en eski sürüm bilgisi.
• Yönetim paneli ve sunucu: içerik, kullanıcı ve sipariş yönetimini kimin, nasıl yapacağı.
• Mağaza yayını: App Store ve Google Play başvurusunu kimin yürüteceği.
• Test: hangi cihazlarda, hangi senaryolarla ve kaç tur test yapılacağı.
• Bakım: yayından sonraki hata düzeltme ve işletim sistemi uyumu.
• Kaynak kodu: kodun ve hesapların teslim biçimi.
• Ödeme planı: hangi aşamada ne kadar ödeneceği.

Örneğin bizim mobil uygulama geliştirme tekliflerimizde bu dokuz başlık ayrı ayrı yer alır, çünkü uygulamayı biz geliştirip mağazaya da biz çıkardığımızda sorumluluğun nerede başlayıp bittiği açık olmalıdır. Elinizdeki teklifte bu başlıkları tek tek işaretleyin; eksik olanlar, aşağıdaki sorularla yazılımcıya ilk soracağınız konulardır.

Yazılımcıya soracağınız 15 soru nelerdir?

Aşağıdaki tabloyu yazdırıp her teklif için ayrı ayrı doldurabilirsiniz. Böylece "evet", "hayır" ve "belirsiz" cevaplarını yan yana görürsünüz.

Şimdi bu soruları gruplar halinde açalım ve her birinde iyi bir cevabın neye benzediğini gösterelim.

Kapsam belgesi neden teklifin temelidir?

Kapsam belgesi, yani projenin yazılı iş tanımı, teklifteki rakamın neye karşılık geldiğini gösteren tek yerdir. "Üyelik sistemi, ürün listesi, sepet ve ödeme" gibi tek satırlık bir özet yeterli değildir. Üyelik e-posta ile mi, telefonla mı, sosyal hesapla mı olacak? Şifre sıfırlama, hesap silme ve profil düzenleme var mı? Her biri ayrı ekran ve ayrı iştir.

Soru 1: "Kapsamı madde madde yazılı olarak verir misiniz?" İyi bir cevap, özellik listesini ve her özelliğin kısa açıklamasını içerir. Ayrıca teklif sürecinde kapsamı birlikte netleştirmeyi önerir.

Soru 2: "Kapsam dışı olan işler nelerdir?" Bu soru çoğu zaman ilkinden daha değerlidir. Örneğin çoklu dil, karanlık tema, canlı destek ya da çevrim dışı çalışma kapsam dışıysa bunun yazılı olması, ileride "zaten dahil sanıyordum" tartışmasını önler.

Kapsamı netleştirmenin en kısa yolu ilk sürümü küçük tutmaktır. Bu konuda mobil uygulama MVP nedir ve ilk sürümde hangi özellikler olmalı rehberimiz, hangi özellikleri sonraya bırakabileceğinizi gösterir.

Ekran listesi ve kullanıcı akışı teklifte nasıl yer almalı?

Soru 3: "Ekran listesini ve kullanıcı akışını gösterebilir misiniz?" Ekran listesi, uygulamadaki her sayfanın adını ve işlevini sayar. Kullanıcı akışı ise bir kişinin uygulamayı açtığı andan siparişi tamamladığı ana kadar hangi ekranlardan geçtiğini gösteren basit bir çizimdir.

Bu iki belge, teklifler arasındaki farkı en hızlı açıklayan araçtır. Örnek senaryo: bir teklif 14 ekran sayarken diğeri 32 ekran sayıyor. İlk bakışta pahalı görünen teklif, aslında hata ekranlarını, boş durumları, bildirim ayarlarını ve hesap silme akışını da hesaba katmış olabilir.

Ekran listesinde şu ayrıntıları arayın:

• Giriş, kayıt, şifre sıfırlama ve hesap silme ekranları.
• Boş liste, bağlantı hatası ve bekleme durumları.
• Bildirim izni ve diğer izin istekleri.
• Ayarlar, gizlilik metni ve iletişim ekranları.

Tasarım dosyasının (Figma gibi bir tasarım aracında hazırlanan ekran çizimleri) teklife dahil olup olmadığını da sorun. Tasarımsız başlayan projede ekranlar yazılım sırasında değişir; dolayısıyla süre uzar.

iOS, Android ya da ikisi birden: platform sorusunu nasıl sormalısınız?

Soru 4: "Hangi platformlar için, hangi teknolojiyle geliştireceksiniz?" Bu sorunun cevabı maliyeti ve bakım yükünü doğrudan değiştirir. Native geliştirme, yani iOS ve Android için ayrı ayrı yazılan iki uygulama, her platformun kendi araçlarını kullanır. Cross-platform yaklaşım ise tek kod tabanından iki uygulama üretir.

İki yaklaşımın da yeri vardır. Ancak teklifte yalnız "iOS ve Android" yazıyorsa, bunun tek kod tabanı mı yoksa iki ayrı proje mi olduğunu öğrenmeden karşılaştırma yapamazsınız. Kararı nasıl vereceğinizi native mi cross-platform mu yazımızda, örnek bir teknolojiyi ise React Native nedir rehberimizde anlattık.

Bunun yanında uygulamanın destekleyeceği en eski işletim sistemi sürümünü ve tablet desteğini sorun. Eski cihaz desteği test yükünü artırır; tablet düzeni ise ayrı tasarım ister. Bu iki satır teklifte yoksa, genellikle kapsam dışıdır.

Yönetim paneli ve sunucu tarafı teklife dahil mi?

Soru 5: "Yönetim paneli teklife dahil mi?" Uygulamada gördüğünüz ürünleri, kampanyaları ya da randevuları birinin güncellemesi gerekir. Bunun için çoğu projede web tabanlı bir yönetim paneli gerekir. Bazı teklifler paneli hiç anmaz, çünkü verinin elle, doğrudan veritabanına girileceğini varsayar.

Soru 6: "Sunucu, veritabanı ve barındırma kimde olacak, aylık gideri kim ödeyecek?" Uygulama telefonda çalışır ama veriyi bir sunucudan alır. Bu bağlantıyı sağlayan yapıya API denir; kavramı API nedir yazımızda anlattık. Sunucu yazılımı, barındırma hizmeti ve bildirim, harita, e-posta gibi üçüncü taraf servisler, teklifte ayrı satır olarak görünmelidir.

Örnek senaryo: düşük görünen bir teklif yalnız telefon uygulamasını kapsıyor, sunucu tarafını ise "mevcut sisteminize bağlanır" diye geçiyor. Oysa işletmenin uygulamaya veri verecek hazır bir sistemi yok. Böyle bir durumda asıl işin yarısı teklifin dışında kalmış olur. Dolayısıyla panel ve sunucu satırlarını görmeden toplam rakamları kıyaslamayın.

Mobil uygulama teklifi mağaza yayınını kapsıyor mu?

Soru 7: "App Store ve Google Play yayınını kim yapacak, hesapları kimin adına açacaksınız?" Mobil uygulama teklifi çoğu zaman "uygulama teslim edilir" diye biter. Fakat teslim ile yayın aynı şey değildir. Mağazaya çıkış; geliştirici hesabı, mağaza metinleri, ekran görüntüleri, gizlilik bilgileri ve inceleme sürecini kapsar.

Geliştirici hesaplarının işletmeniz adına açılması uzun vadede sizi korur. Apple, kurum olarak kaydolan geliştiricilerden D-U-N-S numarası ister; bu şartı Apple Developer Program kayıt sayfasında görebilirsiniz. Google Play de kurum hesabı için D-U-N-S numarası ister ve finans, sağlık gibi bazı uygulama türlerinde kurum hesabını zorunlu tutar. Hesap türlerini Play Console Yardım'daki hesap türü sayfasında karşılaştırabilirsiniz.

Ayrıca Google Play, yeni kişisel geliştirici hesaplarından yayın erişimi istemeden önce belirli sayıda test kullanıcısıyla belirli bir süre kapalı test yapmasını ister. Güncel şartı Play Console Yardım'daki test şartları sayfasından kontrol edin. Süreci adım adım Google Play kapalı test şartı yazımızda anlattık. Teklif bu süreyi takvime koymuyorsa, yayın tarihi gerçekçi değildir.

Uygulama mağaza incelemesinden geçemezse ne olur?

Soru 8: "Mağaza uygulamayı reddederse düzeltmeyi kim, hangi bedelle yapacak?" Ret, mağaza sürecinin olağan bir parçasıdır. Önemli olan, teklifin bu durumu öngörüp öngörmediğidir.

App Store İnceleme Yönergeleri birkaç temel beklentiyi açıkça yazar. Giriş gerektiren uygulamalarda inceleme ekibine demo hesap bilgisi vermeniz ve sunucunun inceleme sırasında çalışır durumda olması gerekir. Hesap oluşturmaya izin veren uygulamalar, hesabı uygulama içinden silme imkânı da sunmalıdır. Üstelik yalnız bir web sitesini paketleyen, "uygulama gibi" davranmayan ürünler minimum işlevsellik gerekçesiyle reddedilebilir.

İyi bir cevap şöyledir: "Kapsamdaki özelliklerle ilgili ret gerekçelerini ek ücret almadan düzeltiriz; kapsam dışı bir özellik gerekirse ayrıca teklif veririz." Belirsiz bir cevap ise "o zaman bakarız" olur. Benzer bir ret türünü App Store 4.3 spam reddi yazımızda inceledik; şablon uygulamalarla çalışan tekliflerde bu riski özellikle sorun.

Test sürecini teklifte nasıl tanımlamalısınız?

Soru 9: "Uygulamayı hangi cihazlarda, nasıl test edeceksiniz ve ben ne zaman deneyebileceğim?" Test satırı teklifte tek kelimeyle geçiyorsa, büyük ihtimalle test yükünü size bırakan bir plan vardır.

İyi bir test planında şu unsurları görmek istersiniz:

1. Farklı ekran boyutlarında ve işletim sistemi sürümlerinde gerçek cihaz testi.
2. Ödeme, kayıt ve bildirim gibi kritik akışlar için yazılı test senaryoları.
3. Sizin yayın öncesinde uygulamayı kendi telefonunuzda deneyebileceğiniz bir beta dağıtımı.
4. Bulunan hataların kaydedildiği ve durumunun izlenebildiği bir liste.
5. Kabul testi, yani sizin "onaylıyorum" dediğiniz son kontrol aşaması.

iOS tarafında beta dağıtımının nasıl çalıştığını TestFlight nedir yazımızda anlattık. Ayrıca kabul testinin süresini ve bu sürede bulunan hataların ücretsiz düzeltilip düzeltilmeyeceğini teklifte yazılı olarak isteyin.

Gizlilik bilgileri ve mağaza formları teklifte yer alıyor mu?

Mağazaya çıkmadan önce uygulamanın hangi verileri topladığını, bu verileri ne için kullandığını ve kimlerle paylaştığını beyan etmeniz gerekir. Google Play bu bilgiyi Veri güvenliği bölümünde, Apple ise uygulama gizlilik bilgilerinde ister. Bu beyanlar uygulamanın gerçek davranışıyla örtüşmelidir; aksi halde ret ya da uyarı riski doğar.

Sorun şu ki bu formları doğru doldurmak için kodu bilen birinin desteği gerekir. Örneğin uygulamanıza eklenen bir analiz ya da bildirim kütüphanesi de veri toplayabilir. Yazılımcı bunu size söylemezse, formu eksik doldurursunuz.

Bu nedenle teklifte şu satırı arayın: "Mağaza gizlilik formlarının hazırlanmasında kullanılan kütüphanelerin veri listesini biz sağlarız." Formların ayrıntısını Google Play veri güvenliği formu ve App Store gizlilik etiketleri yazılarımızda anlattık. Kişisel veri konusunda hukuki sorumluluk sizde kalır; dolayısıyla aydınlatma metinleri için hukukçunuzdan destek alın.

Yayından sonra bakım ve güncelleme kimin işi?

Soru 10: "Yayından sonra bakım nasıl işleyecek, aylık ya da yıllık bir bakım planınız var mı?" Uygulama yayına çıktığında iş bitmez. iOS ve Android her yıl yeni sürümler çıkarır, mağazalar kurallarını günceller ve kullandığınız kütüphaneler eskir.

Örneğin Google Play, yeni uygulamaların ve güncellemelerin yakın tarihli bir Android API seviyesini hedeflemesini ister; şartı karşılamayan eski uygulamalara zamanla yeni cihazlardaki kullanıcılar ulaşamayabilir. Konuyu Google Play hedef API seviyesi şartı yazımızda ayrıntılı işledik. Bakım planı olmayan bir uygulama, bu tür uyarılara karşı savunmasız kalır.

Bakım teklifinde şunları ayrı ayrı görmelisiniz: hata düzeltme, işletim sistemi uyumu, güvenlik güncellemesi, sunucu izleme ve yeni özellik geliştirme. Son madde genellikle bakıma dahil değildir; bu yüzden aradaki çizginin yazılı olması gerekir.

Kaynak kodu ve hesaplar kimde kalacak?

Soru 11: "Proje bitince kaynak kodu, tasarım dosyaları ve tüm hesapları bana teslim edecek misiniz?" Bu soru, teklif aşamasında en çok atlanan ama en pahalıya patlayan sorudur.

Kaynak kodu teslim edilmeyen bir projede yazılımcıyı değiştirmek istediğinizde uygulamayı baştan yazdırmanız gerekebilir. Benzer şekilde geliştirici hesapları yazılımcının adına açılmışsa, uygulamanın mağazadaki sahibi siz olmazsınız. Sunucu, alan adı ve üçüncü taraf servis hesapları için de aynı soru geçerlidir.

Sözleşmede hangi maddelere bakmanız gerektiğini kardeş yazımız mobil uygulamanın kaynak kodu kime ait ayrıntılı anlatıyor. Teklif aşamasında ise kısaca şunu yazılı isteyin: kodun hangi biçimde, hangi depoda ve hangi aşamada size devredileceği. Not: bu yazı hukuki danışmanlık değildir; sözleşme metni için avukatınıza danışın.

Ödeme planını teslim aşamalarına nasıl bağlamalısınız?

Soru 12: "Ödemeler hangi teslimlere bağlı?" Sağlıklı bir ödeme planı, her ödemeyi somut ve kontrol edilebilir bir teslime bağlar. Böylece iki taraf da riski paylaşır.

Örnek senaryo olarak şu aşamalı yapıyı düşünebilirsiniz:

1. Sözleşme ve kapsam onayı ile başlangıç ödemesi.
2. Tasarım ekranlarının onayı ile ikinci ödeme.
3. Test sürümünün size teslimi ile üçüncü ödeme.
4. Mağaza yayını ve kaynak kodu devri ile son ödeme.

Oranları burada rakamla vermiyoruz, çünkü projenin büyüklüğüne göre değişir. Ancak iki işarete dikkat edin. Birincisi, toplamın büyük kısmını işin başında isteyen plan, riski tamamen size yükler. İkincisi, son ödemeyi mağaza yayınına değil yalnız "teslime" bağlayan plan, yayın sürecinin sorumluluğunu belirsiz bırakır.

Teklifteki teslim süresi gerçekçi mi?

Teslim süresi, teklifin en kolay yazılan ama en zor tutturulan satırıdır. Gerçekçi bir takvim, yazılım süresinin yanında sizin onay sürelerinizi, mağaza incelemesini ve test dönemini de içerir.

Takvimi okurken şu kalemleri ayrı ayrı arayın:

• Kapsam ve tasarım onayı için ayrılan süre.
• Geliştirme döngüleri ve her döngünün sonunda size gösterilecek parça.
• Beta testi ve kabul testi dönemi.
• Mağaza incelemesi ve olası ret sonrası düzeltme payı.
• Google Play kişisel hesaplarındaki kapalı test dönemi gibi zorunlu bekleme süreleri.

Örnek senaryo: bir teklif yalnız "8 hafta" diyor, diğeri ise aynı işi tasarım, geliştirme, test ve yayın olarak dört aşamaya bölüyor. İkinci teklif daha uzun görünse bile hangi aşamada gecikme olduğunu görmenizi sağlar. Üstelik tek rakamlı bir süre, onay gecikmelerinin kimin hanesine yazılacağını da belirsiz bırakır. Bu yüzden her aşamanın sonunu somut bir teslime bağlayın.

Değişiklik taleplerinin bedelini nasıl belirlemelisiniz?

Soru 13: "Proje sırasında yeni bir özellik istersem ya da bir ekranı değiştirmek istersem ne olur?" Her yazılım projesinde fikirler değişir. Bu normaldir; sorun, değişikliğin nasıl fiyatlanacağının önceden belirlenmemesidir.

İyi bir teklif, değişiklik talebi süreci tanımlar. Yani yeni talebi yazılı alır, süresini ve bedelini tahmin eder, siz onaylamadan işe başlamaz. Bazı ekipler bunun için saatlik ya da günlük bir birim ücret belirtir. Böylece küçük değişiklikler pazarlık konusu olmaz.

Ekibin projeyi kısa döngülerle ilerletip ilerletmediğini de sorun. İki haftalık döngülerle çalışan bir ekip, her döngü sonunda size çalışan bir parça gösterir ve değişiklikleri erken yakalar. Bu yöntemi yazılım proje yönetiminde Agile ve Scrum yazımızda anlattık.

Projede kimlerin çalışacağını nasıl anlarsınız?

Soru 14: "Projede kimler çalışacak ve sizinle nasıl iletişim kuracağım?" Bir mobil uygulama genellikle tasarım, mobil geliştirme, sunucu geliştirme ve test becerisi ister. Teklif bu rollerin kimde olduğunu göstermelidir.

Burada aradığınız şey büyük bir kadro değil, şeffaflıktır. İşin bir kısmı dışarıya veriliyorsa bunun açıkça söylenmesi gerekir. Ayrıca tek bir proje sorumlusunun olması ve haftalık durum raporu gibi düzenli bir iletişim biçimi, projenin gidişatını görmenizi kolaylaştırır.

Referans uygulamaları da isteyin. Ancak yalnız ekran görüntüsüne değil, mağazada yayında olan, düzenli güncelleme alan ve kullanıcı yorumu toplayan uygulamalara bakın. Yayındaki bir uygulama, ekibin mağaza sürecini de başarıyla yönettiğini gösterir.

Son olarak, projenin ortasında ekipten biri ayrılırsa işin nasıl devam edeceğini sorun. Kodun ortak bir depoda tutulması ve kısa teknik notlarla belgelenmesi, bu riski büyük ölçüde azaltır.

Garanti süresi ve hata tanımı neyi kapsıyor?

Soru 15: "Teslimden sonra garanti süresi ne kadar ve hangi hataları kapsıyor?" Garanti, kapsamdaki bir özelliğin yazıldığı gibi çalışmaması durumunda ücretsiz düzeltmeyi ifade eder. Yeni özellik, tasarım değişikliği ya da işletim sistemi güncellemesinden doğan uyum işi ise genellikle garantiye girmez.

Bu yüzden "hata" tanımının teklifte yazılı olmasını isteyin. Örneğin ödeme ekranının çökmesi açıkça bir hatadır; buna karşılık buton renginin değişmesi isteği bir değişiklik talebidir. Hataların öncelik seviyesine göre ne kadar sürede ele alınacağını da sorun. Kritik bir hatanın günlerce beklemesi, satış yapan bir uygulama için ciddi kayıp demektir.

Garanti süresinin ne zaman başladığını da netleştirin. Bazı teklifler süreyi test sürümünün tesliminden, bazıları ise mağaza yayınından başlatır. Yayın birkaç hafta gecikirse, ilk yöntemde garantinin bir kısmı uygulama henüz kullanıcıya ulaşmadan biter. Bu nedenle başlangıç noktası olarak gerçek kullanıcıların uygulamayı indirebildiği günü öneriyoruz.

Çok düşük bir mobil uygulama teklifi hangi riskleri taşır?

Çok düşük bir mobil uygulama teklifi her zaman kötü niyet anlamına gelmez. Çoğu zaman kapsamın bir kısmı sessizce dışarıda bırakılmıştır. Saha tecrübemize göre en sık karşılaşılan tasarruf noktaları şunlardır:

• Hazır bir şablonun az değişiklikle yeniden kullanılması ve mağaza reddi riski.
• Yönetim panelinin ya da sunucu tarafının teklife hiç girmemesi.
• Testin yalnız geliştiricinin kendi telefonunda yapılması.
• Mağaza yayınının, hesap kurulumunun ve gizlilik formlarının size bırakılması.
• Kaynak kodunun teslim edilmemesi ya da yazılımcının hesabında kalması.
• Bakım planının olmaması; dolayısıyla ilk işletim sistemi güncellemesinde sorun çıkması.

Kısacası düşük teklifi elemek için önce yukarıdaki 15 soruyu sorun. Cevaplar tatmin ediciyse düşük fiyat gerçekten verimli bir ekibin işareti olabilir. Cevaplar belirsizse, aradaki fark ileride ek fatura olarak geri gelir. Maliyet kalemlerinin ayrıntısını tekrar etmiyoruz; onlar için maliyet yazımıza dönebilirsiniz.

İki teklifi yan yana nasıl karşılaştırırsınız?

Teklifleri karşılaştırırken toplam rakamla başlamak, en sık yapılan hatadır. Bunun yerine önce kapsamı eşitleyin, sonra fiyata bakın. Şu sırayı öneriyoruz:

1. 15 soruluk tabloyu her teklif için doldurun.
2. Her "hayır" ya da "belirsiz" cevap için yazılımcıdan yazılı açıklama isteyin.
3. Eksik kalemleri ikinci tekliften fiyatlatın ya da ilk teklif sahibinden ek fiyat isteyin.
4. Kapsamı eşitledikten sonra toplamları yeniden karşılaştırın.
5. Son olarak süreyi, ödeme planını ve referansları puanlayın.

Örnek senaryo: A teklifi, B teklifinin belirgin biçimde altında kalıyor. Ancak A teklifinde panel, mağaza yayını ve bakım yok. Bu kalemleri A teklif sahibinden ayrıca istediğinizde iki rakam birbirine yaklaşıyor, hatta A geçebiliyor. Böylece kararı gerçek kapsam üzerinden verirsiniz.

Teklif istemeden önce sizin hazırlamanız gerekenler neler?

Yazılımcıdan net bir teklif almak, sizin net bir talep göndermenize bağlıdır. Ayrıca tüm firmalara aynı belgeyi göndermek, teklifleri karşılaştırılabilir kılar.

• Uygulamanın tek cümlelik amacı ve hedef kullanıcısı.
• İlk sürümde mutlaka olması gereken özelliklerin kısa listesi.
• Beğendiğiniz ve beğenmediğiniz örnek uygulamalar.
• Uygulamanın konuşacağı mevcut sistemler: web sitesi, stok, muhasebe ya da ödeme altyapısı.
• Hedeflediğiniz yayın dönemi ve bu tarihin neden önemli olduğu.
• Geliştirici hesaplarının kimin adına açılacağı ve şirket bilgileriniz.

Bu liste kusursuz olmak zorunda değildir. Ancak her teklif sahibinin aynı listeyi görmesi, "bizim anladığımız buydu" farkını en baştan küçültür.

Talebinizi gönderirken bir de cevap tarihi belirleyin. Tüm tekliflerin aynı hafta içinde gelmesi, karşılaştırmayı kolaylaştırır; üstelik soruları herkese aynı anda sorma imkânı verir.

Teklifte hangi ifadeler sizi uyarmalı?

Bazı ifadeler tek başına sorun değildir; fakat açıklanmadan bırakılırsa ileride tartışma doğurur. Şu kalıpları gördüğünüzde yazılımcıdan yazılı açıklama isteyin:

• "Standart özellikler dahildir" ama teklif bu özellikleri tek tek saymıyor.
• "Mağaza yayınında destek sağlarız" ama başvuruyu kimin yapacağı belirsiz.
• "Bakımı ihtiyaca göre fiyatlarız" ama birim ücret yok.
• "Kaynak kodunu talep halinde teslim ederiz" ama teklif koşulu açıklamıyor.
• "Teslim süresi yaklaşık" ama aşama tarihleri yok.

Bu ifadelerin her biri, teklifin bir kısmının konuşulmadan bırakıldığını gösterir. İyi niyetli bir ekip bunları seve seve yazıya döker; hatta bu soruları sormanız, onların da işini kolaylaştırır.

Talha Aslan ve ekibi mobil uygulama teklifini nasıl hazırlar?

Biz mobil uygulama teklifini, bu yazıdaki 15 sorunun cevabını önceden içeren bir belge olarak hazırlarız. Kapsam ve kapsam dışı maddeleri, ekran listesini, platform kararını, panel ve sunucuyu, mağaza yayınını, test planını, bakım seçeneklerini, kaynak kodu devrini ve aşamalı ödeme planını ayrı başlıklarda yazarız.

Uygulamanızı biz geliştirir, App Store ve Google Play'e de biz çıkarırız; geliştirici hesaplarının işletmeniz adına açılmasını ve kodun size devredilmesini baştan planlarız. Projenizin özetini mobil uygulama geliştirme hizmeti sayfamızdan iletirseniz, kapsamı net, karşılaştırılabilir bir teklifi size hazırlarız. Elinizde başka bir teklif varsa, aynı 15 soruyla yan yana koymanızı özellikle öneririz.