Yazılım Projesi Ne Kadar Sürer? Proje Tipine Göre Gerçekçi Süre Rehberi

Hazır şablonla basit bir site birkaç günde açılabilir; ancak özgün tasarımlı, yönetim panelli ve SEO altyapılı bir kurumsal site için gerçekçi süre 2-4 haftadır. Bunun ilk haftası tasarım ve onay, sonraki 1-2 haftası geliştirme, son günleri test ve yayındır. Logo, metin ve görseller hazır teslim edilirse alt sınıra, çok dillilik ve özel modüller eklenirse üst sınıra yaklaşılır.

Sanal POS ve kargo entegrasyonlu, özgün tasarımlı bir e-ticaret sitesi için gerçekçi aralık 4-8 haftadır. Süreyi en çok etkileyen kalem yazılım değil ürün verisidir: fotoğraflar, açıklamalar ve varyantlar hazır değilse site bitse bile açılamaz. Muhasebe, pazaryeri ve ERP entegrasyonlarının her biri takvime 1-2 hafta ekler; ilk açılışı çekirdek entegrasyonlarla yapmak en hızlı yoldur.

Orta kapsamlı bir mobil uygulama için gerçekçi süre 2-4 aydır: 2-3 hafta tasarım, 6-10 hafta geliştirme, 2-3 hafta test, artı mağaza onayları. App Store ve Google Play onayı genellikle birkaç gün sürer ama ret-düzeltme turları 3-7 gün ekleyebilir. Üyelik, bildirim ve ödeme gibi sunucu tarafı işler sürenin yarısını tüketir; teklif alırken bu kalemin dahil olduğunu doğrulayın.

Çünkü işin büyük kısmı kod değil, işletmenizin kurallarını doğru anlamaktır. İlk 2-4 hafta analiz aşamasıdır: mevcut akışlar, Excel dosyaları ve istisna durumlar çıkarılır. Ardından modüller sırayla geliştirilir, eski veriler taşınır ve ekip eğitilir. Tek modüllü bir başlangıç 2-3 ayda canlıya alınabilir; çok modüllü tam kapsam 5-6 aya uzar. Analizi atlayan projeler kullanımda patlar ve toplamda daha uzun sürer.

Teknik olarak mümkün, ama genellikle hazır bir şablonun logo ve renklerinin değiştirilmesi anlamına gelir. Özgün tasarım, mobil uyum testi, SEO temel kurulumu ve içerik girişi 3 güne fiziksel olarak sığmaz. Bu tür vaatlerde neyin teslim edileceğini yazılı sorun: tasarım kaç revizyonlu, panel var mı, site kime ait? Şüpheli derecede kısa süre, genellikle şüpheli derecede dar bir kapsamın işaretidir.

İki numaralı şüpheli tekniktir; bir numaralı şüpheli süreçtir. En yaygın uzatıcılar: kapsam kayması (projeye sonradan eklenen 'küçük' istekler), geç içerik teslimi (yazılmayan metinler, çekilmeyen fotoğraflar, ayıklanmayan veriler) ve onay gecikmeleri. Üçü de sözleşmeyle yönetilebilir: kapsam kilitlenir, içerik teslim tarihleri takvime yazılır, geri bildirim için süre kuralı konur.

Proje ilerlerken kapsama tek tek eklenen küçük isteklerin birikerek takvimi ve bütçeyi şişirmesidir. Her ekleme yalnızca kendi geliştirme süresini değil, bitmiş parçaların yeniden test edilmesini de getirir; birkaç 'ufak rica' bir aylık gecikmeye dönüşebilir. Çözüm, kapsamı başta yazılı kilitlemek ve yeni fikirleri faz 2 listesine almaktır; ayrıntıları kapsam kilitlemesi rehberinde bulabilirsiniz.

Toplam süreyi biraz, faydaya erişme sürenizi ciddi biçimde kısaltır. Proje 3-5 teslim noktasına bölündüğünde ilk çalışan modülü haftalar içinde kullanmaya başlarsınız; yanlış anlaşılmalar erken yakalandığı için pahalı düzeltme turları da azalır. Ödemeyi aşamalara bağlamak firmayı takvime kilitler. Modelin kurgusunu aşamalı ödeme rehberimizde anlattık.

Kapsama bağlı olarak pazara çıkışı yarıya indirebilir: 4 aylık bir projenin işe yarayan çekirdeği çoğu zaman 6-8 haftada canlıya alınabilir. MVP kalite kısmak değil, özellik sayısını kısmaktır; çekirdek eksiksiz ve sağlam çıkar, kalan özellikler gerçek kullanıcı geri bildirimine göre sıralanır. Bu sıralama, hiç kullanılmayacak özelliklere hiç zaman harcanmamasını da sağlar.

Her dış entegrasyon kendi başvuru, test ve onay süreciyle gelir ve tipik olarak takvime 1-2 hafta ekler. Kritik nokta şudur: sürenin bir kısmı karşı tarafın (banka, kargo firması, operatör) onay döngüsüdür ve yazılım ekibinin elinde değildir. Deneyimli firmalar bu başvuruları projenin ilk günü başlatır ki onay beklemesi geliştirmeyle paralel erisin; sıralı yürütülürse aynı işlem projeyi haftalarca bekletir.

Üç şey sürenin yarısından fazlasını sizin elinize verir: içeriği (metin, görsel, ürün verisi) proje başlamadan hazırlamak, geri bildirimleri toplu ve hızlı vermek (dağınık on e-posta yerine tek liste, 2-3 iş günü içinde) ve karar vericiyi tekilleştirmek. Ortakların sırayla fikir değiştirdiği projeler en çok uzayanlardır. Bir de yeni fikirleri faz 2 listesine yazma disiplini eklerseniz takvim korunur.

Bu riskin panzehiri sözleşmedir: teslim tarihleri aşama aşama yazılmalı, makul gecikmeler için tazminat veya cayma koşulu tanımlanmalı, ödeme aşamalara bağlanmalıdır. Ödemesi teslimata bağlı bir firma gecikmenin maliyetini kendisi taşır. Teklifleri kıyaslarken süre taahhüdünün sözleşmede nasıl yer aldığına mutlaka bakın; sözlü 'iki aya biter' hiçbir şey ifade etmez.

Olmalıdır ve teklifte açıkça yazmalıdır. Sağlıklı bir planda sürenin kabaca %15-20'si test, hata düzeltme ve yayın hazırlığına ayrılır; mobilde buna mağaza onay süreci eklenir. 'Geliştirme bitti' ile 'canlıya alındı' arasında tipik olarak 1-2 hafta vardır. Teslim sonrası dönem için de garanti süresi sorun: yayın sonrası ilk haftalarda çıkan hataların ücretsiz giderileceği yazılı olmalıdır.

Hayır; canlıya alma bir başlangıçtır. İlk haftalarda gerçek kullanımda küçük hatalar ve iyileştirme ihtiyaçları çıkması normaldir ve bunların nasıl karşılanacağı baştan netleşmelidir. 60 gün ücretsiz garanti gibi yazılı bir taahhüt, bu dönemin ek fatura sürprizine dönüşmesini engeller. Uzun vadede güncelleme ve bakım için ayrı bir destek anlaşması düşünülür.

Süreyi neye dayandırdığını açıklayabilene. Kapsamı maddelere bölmüş, her aşamaya tarih vermiş ve varsayımlarını (içerik teslimi, onay süreleri, entegrasyon sayısı) yazmış bir teklif güvenilirdir; havadan verilmiş kısa süre genellikle ya dar bir kapsamın ya da sonradan gelecek ek faturaların habercisidir. İki firmaya da aynı yazılı kapsam listesini verip süreleri o liste üzerinden karşılaştırmak en sağlıklı yöntemdir.