Web Sitesi, Mobil Uygulama ve Özel Yazılım Yaptırma Maliyeti Nasıl Belirlenir?

Bir dijital proje için teklif isteyen hemen herkes aynı yerden başlar: "Bir web sitesi yaptırmak istiyorum, ne kadara mal olur?" Sorunun karşılığında genellikle bir rakam değil, bir dizi soru gelir. Bu, kaçamak bir cevap gibi görünebilir.

Oysa sebebi basit: aynı cümleyle tarif edilen iki proje, birbirinden kat kat farklı işler olabilir. "Web sitesi" dendiğinde biri sekiz sayfalık bir tanıtım sitesini, bir diğeri bayilerinin sipariş verdiği, stok gördüğü, fatura kestiği bir platformu kastediyor olabilir. İkisi de doğru biçimde "web sitesi" diye adlandırılıyor.

Bu yazı bir fiyat listesi değil. Amacı, teklif almadan önce maliyeti gerçekte neyin belirlediğini anlaşılır biçimde açıklamak — böylece ilk görüşmeye geldiğinizde neyin konuşulacağını önceden biliyor olursunuz.

Maliyeti belirleyen üç temel

Proje türü ne olursa olsun bütçeyi üç şey belirler. Geri kalan her şey bunların ayrıntısıdır.

1. Kapsam: ürün ne yapıyor?

Kapsam, "kaç sayfa" ya da "kaç ekran" sorusundan ibaret değildir. Asıl belirleyici olan ürünün kaç farklı iş yaptığıdır. Bilgi gösteren bir sayfa ile form alan, kayıt tutan, başka bir sisteme veri yazan bir sayfa aynı büyüklükte değildir — görsel olarak ikisi de tek sayfadır.

2. Belirsizlik: neyi henüz bilmiyoruz?

Maliyeti şişiren şey çoğu zaman işin zorluğu değil, netleşmemiş kararlardır. "Entegre olacak" denen sistemin dokümantasyonu var mı, verisi nasıl geliyor, erişim izni kimde? Bunlar cevapsızken verilen her rakam bir tahmindir ve tahminler payla korunur. Kapsam analizinin asıl işi budur: belirsizliği erken azaltmak.

3. Yayın sonrası: proje bittiğinde ne oluyor?

Yazılım, teslim edildiği gün donan bir nesne değildir. Tarayıcılar, işletim sistemleri, ödeme sağlayıcıları ve entegre olduğunuz sistemler değişmeye devam eder. Bakım, güncelleme ve destek kapsamının baştan konuşulup konuşulmaması, toplam maliyetin en çok yanılınan kalemidir.

Web sitesi ve web platformu

Web tarafında maliyet farkı genellikle tek bir eşikte oluşur: site bilgi mi veriyor, yoksa iş mi yapıyor?

Bilgi veren tarafta maliyeti belirleyenler:

• İçerik yapısı. Yirmi sayfayı elle yazmak ile "hizmet", "referans", "ekip üyesi" gibi içerik türleri tanımlayıp bunları kendi alanlarıyla yönetmek farklı işlerdir. İkincisi başta daha pahalı, üç yıl sonra çok daha ucuzdur.
• Tasarımın özgünlüğü. Hazır bir tema uyarlamak ile markanın kendi arayüzünü kurmak arasında hem maliyet hem sonuç farkı vardır.
• İçerik yönetimi ihtiyacı. Siteyi kimin, hangi sıklıkla, hangi teknik bilgiyle güncelleyeceği doğrudan bir kapsam sorusudur.
• Çok dillilik. Yalnızca çeviri değil; adres yapısı, arama motoru sinyalleri ve içerik yönetiminin dil başına nasıl çalışacağı da işin parçasıdır.

Sitenin bir platforma dönüştüğü yerde maliyeti belirleyenler değişir:

• Üyelik ve yetkilendirme. Kimin giriş yaptığı, kimin neyi görebildiği.
• Entegrasyonlar. Muhasebe, kargo, ödeme, CRM ya da kurum içi bir sistemle konuşmak.
• Özel işlevler. Hesaplama, başvuru akışı, randevu, teklif formu gibi kuralları size özgü olan parçalar.
• Veri. Eski sitede birikmiş içeriğin ve kayıtların taşınması çoğu projede ayrı bir kalemdir.

Bu iki uç arasında keskin bir sınır yok; çoğu proje arada bir yerde duruyor. Kapsam görüşmesinin işi, projenizin bu çizgide nerede durduğunu netleştirmek. Ne tür işlerin bu kapsama girdiğini web platformu ve web sitesi hizmetimizde bulabilirsiniz.

Mobil uygulama

Mobilde en sık yaşanan yanılgı, uygulamanın gördüğünüz ekranlardan ibaret sanılmasıdır. Ekranlar işin görünen yüzü; maliyetin önemli bir kısmı arkada durur.

• Ekran ve akış sayısı. Beklendiği gibi bir etken, ama tek başına belirleyici değil.
• Backend ve veri senkronizasyonu. Veri yalnızca cihazda mı duruyor, yoksa bir sunucuda tutulup birden fazla cihazla eşitleniyor mu? Bu tek soru projenin boyutunu değiştirir.
• Kullanıcı hesabı, abonelik ve lisans. Üyelik, ücretli sürüm, deneme süresi ya da cihaz değiştirince lisansın taşınması gibi ihtiyaçlar kendi başlarına birer kapsamdır.
• Cihaz özellikleri. Konum, bildirim, arka planda çalışma, kamera, sensörler. Bunlar işletim sistemi izinleriyle iç içe geçtiği için hem geliştirme hem test yükü getirir.
• Yönetim paneli. İçeriği, kullanıcıları veya bildirimleri birinin yönetmesi gerekiyorsa uygulamanın yanında ikinci bir ürün var demektir.
• Test ve mağaza yayını. Uygulama mağazalarının kendi gereksinimleri, inceleme süreçleri ve test aşamaları vardır. Bu, kod yazıldıktan sonra biten bir iş değildir.
• Bakım. İşletim sistemi sürümleri ilerledikçe uygulamanın güncel kalması gerekir.

Bunu kendi ürünümüzde de yaşadık: Refakatçi'nin arka planda çalışan hatırlatıcıları ve konum işlevleri, ekran tasarımından belirgin biçimde daha fazla zaman istedi — çünkü asıl zorluk ekranı çizmek değil, işlevin telefon uykudayken de güvenilir çalıştığını doğrulamaktı. Mağaza tarafı da benzer: kendi Android ürünümüzü yayına hazırlarken kapalı test sürecinin kendi takvimi olduğunu birinci elden gördük.

Hangi kapsamın hangi projede gerçekten gerektiği, mobil uygulama geliştirme tarafında kapsam analiziyle birlikte belirleniyor.

Özel yazılım ve otomasyon

Özel yazılımda maliyet sorusu diğerlerinden bir adım önce başlar: geliştirilecek şey aslında bir yazılım değil, bir iş akışıdır. Bu yüzden ilk maliyet kalemi çoğu zaman kod değil, mevcut sürecin doğru anlaşılmasıdır.

• İş akışının karmaşıklığı. Kaç adım, kaç istisna, kaç onay noktası var? İstisnalar genellikle asıl işten daha fazla zaman alır.
• Rol ve yetki yapısı. Kaç farklı kullanıcı tipi var ve her biri neyi görüp neyi değiştirebiliyor?
• Mevcut sistemler. Yeni yazılım tek başına mı çalışacak, yoksa hâlihazırda kullandığınız programlarla konuşacak mı? Konuşacaksa o sistemin ne kadar açık olduğu sizin projenizin maliyetini belirler.
• Veri taşıma. Yıllardır bir tabloda veya eski bir programda biriken verinin temizlenip aktarılması sık sık hafife alınan bir kalemdir.
• Otomasyonun sınırı. Bir sürecin tamamını otomatikleştirmek ile en çok zaman kaybettiren üç adımını otomatikleştirmek çok farklı bütçelerdir — ve ikincisi çoğu zaman daha akıllıcadır.

Bu başlıkların projelerde nasıl ele alındığını otomasyon ve özel yazılım sayfasında bulabilirsiniz.

Her ihtiyaç özel geliştirme gerektirmez

Maliyet konuşurken en dürüst cümle bazen şudur: bu iş için özel yazılıma ihtiyacınız yok.

Standart bir kurumsal tanıtım sitesi, sıradan bir blog ya da piyasadaki hazır çözümlerin zaten iyi karşıladığı bir ihtiyaç için sıfırdan geliştirme yapmak; hem başlangıç maliyetini hem de sonraki yılların bakım yükünü gereksiz yere artırır.

Özel geliştirme, ihtiyaç hazır çözümlerin kalıbına sığmadığında anlamlı olur: kendinize özgü içerik türleri, standart dışı bir iş akışı, hazır ürünlerin desteklemediği bir entegrasyon ya da veriniz üzerinde tam kontrol ihtiyacı. Bu ayrımı hazır CMS ile özel CMS arasındaki seçimi anlattığımız yazıda daha ayrıntılı ele aldık.

Kapsamı olması gerekenden büyük tutmak kimsenin işine yaramaz. Doğru yanıtın "daha küçük bir proje" olduğu durumlar vardır ve bunu söylemek, satış yapmaktan daha değerlidir.

Teklif nasıl hazırlanıyor?

Yaklaşımımız paket satmak değil, kapsamı netleştirip projeye özel teklif hazırlamak. Akış genellikle şöyle işliyor:

• İhtiyacın anlaşılması. Ne yapmak istediğiniz değil, hangi sorunu çözmek istediğiniz. Bu ikisi çoğu zaman aynı şey değildir.
• Keşif. Mevcut durumun, kullandığınız sistemlerin ve gerçek kısıtların çıkarılması.
• Kapsamın yazıya dökülmesi. Neyin dahil olduğu kadar neyin dahil olmadığı da netleşir. Sonradan çıkan tartışmaların büyük kısmı bu adımın atlanmasından doğar.
• Belirsizliklerin azaltılması. Cevabı bilinmeyen sorular ya cevaplanır ya da ayrı bir aşamaya alınır.
• Proje bazlı teklif. Kapsam netleştikten sonra, o kapsama karşılık gelen teklif paylaşılır.

Kapsam büyükse projeyi aşamalara bölmek çoğu zaman daha sağlıklıdır: önce gerçekten çalışan bir ilk sürüm, sonra ölçüme ve geri bildirime göre devamı. Bu hem bütçeyi öngörülebilir kılar hem de yanlış yatırımı erken fark etmeyi sağlar.

Süre ile maliyet neden birlikte hareket eder?

Yazılımda süre ve maliyet aynı değişkene bağlıdır: kapsam. Bu yüzden kapsam netleşmeden verilen takvim de, verilen rakam da aynı ölçüde tahminidir.

Kapsam büyüdüğünde artan şey yalnızca geliştirme değildir. Her yeni işlev; test edilecek bir durum, kontrol edilecek bir hata senaryosu ve yayın sırasında dikkat edilecek bir adım daha getirir. Özellikle entegrasyonlar ve izin gerektiren işlevler, geliştirme süresine oranla belirgin biçimde daha fazla test süresi ister.

Bu yüzden "kaç haftada biter?" sorusunun dürüst cevabı da kapsamdan sonra verilir. Sabit bir takvim vaat etmek kolaydır; tutmayan takvim ise projenin kendisine zarar verir.

Görüşmeye gelirken elinizde ne olsun?

Teklif sürecini hem hızlandıran hem de daha isabetli kılan birkaç şey var. Hepsinin hazır olması gerekmiyor — ama ne kadarı netse teklif o kadar gerçekçi olur:

• Çözmek istediğiniz sorunun bir cümlelik tarifi.
• Bu ürünü kimin kullanacağı ve kaç farklı kullanıcı tipi olduğu.
• Hâlihazırda kullandığınız sistemler ve bağlanması gerekenler.
• Taşınması gereken mevcut içerik veya veri olup olmadığı.
• Varsa takvim kısıtınız ve düşündüğünüz bütçe aralığı.

Bütçe aralığını paylaşmak pazarlık gücünüzü azaltmaz; tam tersine kapsamın o aralığa göre doğru kurgulanmasını sağlar. Çoğu projede asıl soru "yapılır mı" değil, "bu bütçeyle en doğru kapsam hangisi" sorusudur.

Projenizi anlatmak isterseniz proje başlatma formundan ulaşabilirsiniz: kapsamı birlikte netleştirip projeye özel teklifi oradan paylaşıyoruz.