Özel Yazılım Ne Kadar Sürede Tamamlanır? Proje Süresini Belirleyen 8 Faktör

Kısa cevap

Özel yazılım projelerinde tek bir standart süre yoktur. Kapsamı net ve entegrasyonu sınırlı bir MVP birkaç haftada kullanılabilir hale gelebilirken; birden fazla kullanıcı rolü, yönetim paneli, mobil uygulama, mevcut sistem entegrasyonları, veri aktarımı ve gelişmiş güvenlik gereksinimleri bulunan bir B2B platform birkaç ay sürebilir. InoviqLab açısından ilk yaklaşık planlama için şu aralıklar kullanılabilir: Proje tipi Yaklaşık ilk yayın süresi Basit şirket içi araç / küçük MVP 4–8 hafta Orta ölçekli web uygulaması / yönetim sistemi 8–16 hafta Kapsamlı B2B / SaaS platformu 3–6 ay Çok entegrasyonlu, mobil + web veya kurumsal sistem 6–12+ ay Bunlar genel planlama aralıklarıdır; sektör standardı veya proje teklifi değildir. Projeyi en çok uzatan unsur da çoğu zaman yazılım ekibinin kod yazma hızı değildir. Asıl belirleyiciler: kapsam + karar süreci + entegrasyon + veri + güvenlik + test + ekip + değişiklik yönetimidir.

“Bu yazılım kaç ayda biter?” sorusuna neden ilk görüşmede kesin cevap vermek zordur?

Çünkü:

“Bir CRM istiyoruz.” veya: “Bize operasyon sistemi lazım.” ifadeleri henüz proje kapsamı değildir. Örneğin iki şirket de “CRM” isteyebilir. Şirket A İhtiyaç:

• müşteri kaydı,
• not ekleme,
• durum takibi,

basit raporlama. Şirket B İhtiyaç:

• müşteri yönetimi,
• 6 kullanıcı rolü,
• satış pipeline’ı,
• e-posta entegrasyonu,
• ERP entegrasyonu,
• otomatik teklif oluşturma,
• dosya yönetimi,
• mobil uygulama,
• raporlama,
• onay akışları,
• yapay zekâ özeti,

geçmiş verilerin aktarılması. İkisinin proje adı aynı olabilir. Ama proje büyüklüğü aynı değildir. PMI’ın proje kapsamı rehberleri de gereksinimlerin ve proje parametrelerinin tanımlanıp onaylanmasını, sonraki planlama ve değişiklik kararları için temel kabul eder. (Proje Yönetimi Enstitüsü) Bu nedenle profesyonel bir yazılım firması: “Kesin 2 ay sürer.” demeden önce ne geliştirileceğini anlamaya çalışmalıdır.

Süre tahmini ne zaman güvenilir hale gelir?

Genellikle şu bilgiler ortaya çıktıktan sonra:

İş problemi ↓ Kullanıcılar ↓ Ana süreçler ↓ Modüller ↓ Roller ↓ Entegrasyonlar ↓ Veri ↓ Kabul kriterleri ↓ MVP kapsamı süre tahmini daha anlamlı hale gelir. Gereksinimin proje boyunca hiç değişmeyeceğini varsaymak da gerçekçi değildir. Agile yaklaşımın temel avantajlarından biri ürünü gerçek kullanıcıların önüne erken çıkarıp öğrenilenlere göre iterasyon yapabilmektir; GOV.UK Service Standard da dijital hizmetlerde iteratif ve kullanıcı merkezli yaklaşımı bu nedenle öneriyor. (GOV.UK) Dolayısıyla iyi proje planı: değişmeyecek bir kehanet değil, yeni bilgiler geldikçe güncellenen kontrollü bir tahmindir.

Proje süresini belirleyen 8 temel faktör

1. Kapsam ne kadar büyük ve ne kadar net?

En büyük faktör budur. Şu proje: Login + Müşteri listesi + Müşteri detay + Basit yönetim paneli ile şu proje: Web + Mobil + CRM + Operasyon + Muhasebe + Raporlama + Bildirim + AI + API aynı sürede tamamlanamaz. Ancak yalnızca özellik sayısı değil, kapsamın netliği de önemlidir.

Belirsiz gereksinim süreyi nasıl etkiler?

Örneğin: “Bir raporlama ekranı olsun.” denebilir.

Ama geliştirmeye geçince şu sorular ortaya çıkar:

• Hangi veriler?

Hangi filtreler?

Tarih aralığı?

Excel export?

PDF?

Kullanıcıya göre veri sınırı?

Grafik?

Para birimi?

Canlı mı, günlük mı güncellenecek?

Kim indirebilir?

Bir ekran:

1 task gibi görünürken altında onlarca karar olabilir. Bu nedenle proje başında bütün detayları %100 çözmeye çalışmak gerekmese de iş hedefi, kullanıcı akışları ve MVP kapsamı yeterince açık olmalıdır.

MVP süreyi nasıl kısaltır?

İlk versiyona:

Her şeyi koymak yerine: İlk gerçek değeri oluşturan minimum sistem seçilir. Örneğin kapsam: İlk sürüm

• kullanıcı girişi,
• müşteri kaydı,
• görev atama,
• durum takibi,

raporlama. Faz 2

• mobil uygulama,
• yapay zekâ,
• gelişmiş dashboard,
• ERP entegrasyonu,

otomasyon. olabilir. Bu: Özelliklerden vazgeçmek değildir. Önceliklendirmedir. GOV.UK agile rehberi de büyük user story veya epic’lerin mümkün olduğunda daha küçük, iterasyon içinde tamamlanabilecek parçalara bölünmesini öneriyor. (GOV.UK)

2. Kullanıcı rolleri ve iş akışları ne kadar karmaşık?

Bir sistemde yalnızca:

Admin User olabilir. Başka bir sistemde: Super Admin Company Admin Finance Operations Sales Customer Supplier Viewer bulunabilir. Her yeni rol yalnızca yeni kullanıcı tipi değildir.

Şunları da getirir:

• hangi ekranı görebilir?

hangi kaydı değiştirebilir?

hangi şirketin verisini görebilir?

onay verebilir mi?

silebilir mi?

export yapabilir mi?

fiyat görebilir mi?

Bir onay süreci düşündüğünüzden daha fazla iş olabilir

Örneğin: Personel oluşturur ↓ Manager onaylar ↓ Finance kontrol eder ↓ Director final approval verir Bu akışta ayrıca:

• reddetme,
• geri gönderme,
• düzenleme,
• bildirim,
• geçmiş kayıt,
• kim ne zaman onayladı,

onay sonrası değişiklik gibi durumlar bulunur. Dolayısıyla: “Bir onay butonu ekleyelim.” bazen küçük bir özellik değil, ayrı bir workflow’dur.

3. Başka sistemlerle entegrasyon var mı?

Entegrasyon proje sürelerinde sık gözden kaçan faktörlerden biridir. Örneğin özel yazılım:

• ERP,
• muhasebe,
• ödeme sistemi,
• banka,
• CRM,
• Google Workspace,
• Microsoft 365,
• kargo sistemi,
• liman sistemi,
• e-fatura,

yapay zekâ API’si ile konuşabilir. Her entegrasyon dışarıdan: API'ye bağlan gibi görünür. Gerçekte ise: Authentication + API araştırması + Data mapping + Error handling + Rate limit + Retry + Test environment + Monitoring gerektirir.

Üçüncü taraf API proje süresini neden belirsizleştirebilir?

Çünkü yazılım ekibiniz kendi sistemini kontrol eder. Ama üçüncü tarafı kontrol etmez. Örneğin: API dokümantasyonu eksik olabilir. Sandbox hesabı geç gelebilir. API belirli veriyi sunmayabilir. Sağlayıcının teknik ekibinden cevap beklenebilir. Rate limit çıkabilir. Security approval gerekebilir. GOV.UK teknoloji rehberi de third-party API’ye bağımlılığın servisin availability’sini dış sağlayıcıya bağlayabileceğini ve bu bağımlılık için yedek plan düşünülmesi gerektiğini vurguluyor. (GOV.UK) Bu nedenle: 5 entegrasyon = 5 basit API çağrısı olarak hesaplanmamalıdır. Entegrasyonu hazır olan müşteri projeyi hızlandırabilir Örneğin proje başlangıcında şunlar mevcutsa:

• API dokümantasyonu,
• test hesabı,
• authentication bilgisi,
• sağlayıcı teknik kişisi,
• örnek request/response,

entegrasyon belirsizliği ciddi biçimde azalır.

4. Mevcut veri taşınacak mı?

Yeni sistem sıfırdan başlayabilir. Ya da şirketin: 7 yıllık Excel dosyaları + eski CRM + müşteri kayıtları + fatura geçmişi + dosyalar yeni sisteme taşınabilir. İkinci senaryo ayrı bir proje kalemidir.

Veri migration neden zaman alır?

Çünkü eski veri çoğu zaman temiz değildir. Örneğin: Müşteri A.Ş. Müşteri AS Müşteri AŞ. Müşteri A.Ş aynı şirket olabilir. Telefonlar farklı formatta olabilir. Eksik alanlar bulunabilir. Eski sistem:

customer_type = 4

tutarken yeni sistem:

customer_type = SHIPPING_AGENT

bekleyebilir. Bu durumda yalnızca:

export → import

yapılmaz. Ayrıca: Mapping Cleaning Validation Deduplication Migration Verification gerekir. Excel'den yazılıma geçiş projelerinde özellikle dikkat Şirketler bazen: “Dosyaları size veririz, sisteme aktarılır.” diye düşünebilir. Ancak 15 farklı çalışanın 15 farklı Excel formatı varsa: yazılım geliştirmeden önce veri standardizasyonu gerekebilir. Bu yüzden veri örneklerinin proje başında görülmesi süre tahminini iyileştirir.

5. Güvenlik ve yasal gereksinimler ne kadar yüksek?

Bir tanıtım sitesiyle:

müşteri finans verisi tutan platform aynı güvenlik sürecine ihtiyaç duymaz. Örneğin sistem:

• kişisel veri,
• sağlık verisi,
• ödeme verisi,
• ticari hassas veri,

şirketler arası gizli veri tutuyorsa ek çalışmalar gerekebilir. Bunlar:

• role-based access,
• audit trail,
• encryption,
• MFA,
• data retention,
• backup,
• vulnerability testing,

privacy/onam akışları olabilir. GOV.UK Service Standard’ın güvenlik rehberi de güvenlik risklerinin, yasal sorumlulukların, üçüncü taraf risklerinin ve veri korumasının geliştirme yaşam döngüsü boyunca ele alınması gerektiğini belirtiyor. (GOV.UK) Güvenliği sona bırakmak projeyi hızlandırmaz Şu model: Önce sistemi bitirelim ↓ Sonra güvenlik ekleriz ilk aşamada hızlı görünebilir. Ama mimari kararları sonradan değiştirmek gerektiğinde proje süresi uzayabilir. Örneğin baştan: her kullanıcı her şirket verisini görebiliyor tasarlanmış bir sistemi daha sonra tam multi-tenant authorization modeline çevirmek ciddi değişiklik olabilir. Daha doğru yaklaşım: Temel güvenlik gereksinimlerini projenin başında belirlemek.

6. Test ve kalite beklentisi ne kadar yüksek?

“Ekran çalışıyor” ile:

“Production’a hazır sistem.” aynı şey değildir. Bir özellik için: Development tamamlandıktan sonra:

• functional test,
• farklı roller,
• edge case,
• mobile/browser,
• integration,
• authorization,
• error handling,

regression testleri gerekebilir.

Test neden zaman çizelgesinin gerçek parçasıdır?

Örneğin geliştirici:

“Rezervasyon ekranı tamam.” dedi. Ama testte: Kullanıcı aynı rezervasyona iki kez basıyor. Ödeme başarısız oluyor. Tarayıcı kapanıyor. Admin rezervasyonu değiştiriyor. Bildirim servisi cevap vermiyor. senaryoları ortaya çıkabilir. Kaliteli sistem yalnızca ideal senaryoda çalışan sistem değildir. GOV.UK Service Standard’ın 2026’da güncellenen güvenilir servis rehberi de kalite testinin düzenli yapılmasını, yalnızca otomasyon araçlarına bırakılmamasını ve live ortama benzer ortamlarda doğrulama yapılmasını istiyor. (GOV.UK)

“Test süresini kaldırırsak daha erken yayınlarız” mantıklı mı?

Takvim üzerinde evet. Business açısından her zaman değil. Test edilmemiş sistem daha erken yayınlanıp:

• müşteri kaybedebilir,
• operasyonu durdurabilir,
• hatalı hesaplama yapabilir,

veri kaybına neden olabilir. Dolayısıyla proje süresi konuşulurken: Kodlama süresi ile: Production'a hazır olma süresi ayrılmalıdır.

7. Müşterinin karar ve geri bildirim hızı nasıl?

Bu faktör yazılım tekliflerinde çoğu zaman görünmez. Ama çok önemlidir. Örneğin yazılım ekibi tasarım gönderdi: Pazartesi Müşteri onayı: 3 hafta sonra geldi. Bu üç hafta: geliştirme ekibinin kod yazma süresi değildir. Ama proje takvimine eklenir.

Hangi kararlar bekleme yaratır?

Örneğin:

• tasarım onayı,
• kullanıcı rolleri,
• fiyatlama kuralı,
• iş akışı,
• metin/içerik,
• entegrasyon hesabı,
• domain erişimi,
• şirket politikası,

sözleşme/onam metni. Bu nedenle müşteri tarafında: tek bir karar sahibi veya net karar mekanizması olması projeyi önemli ölçüde hızlandırabilir. GOV.UK’un güncel multidisipliner ekip rehberi de karar alma sürecindeki kişilerin ekibin içinde veya ekibe yakın olmasının, kullanıcı ihtiyaçlarından öğrenilenlere hızlı tepki verilmesini kolaylaştırdığını belirtiyor. (GOV.UK)

“Tasarımı herkese soralım” neden proje uzatabilir?

Şu yapı:

CEO Sales Operations Finance HR Marketing IT her ekranı ayrı ayrı onaylarsa karar döngüsü büyüyebilir. İdeal model: İlgili departman görüşü ↓ Product owner / proje sorumlusu ↓ Final karar şeklindedir. Bu geri bildirimi azaltmaz. Karar mekanizmasını netleştirir.

8. Proje başladıktan sonra ne kadar değişiklik yapılıyor?

Yazılım projesinin başladığı gün bütün ihtiyaçların sabit kalması beklenmez. Hatta kullanıcılarla çalıştıkça daha iyi fikirler çıkması normaldir. Sorun değişiklik değildir. Sorun: Her yeni fikrin otomatik olarak mevcut teslim tarihine eklenmesi dir. Basit örnek İlk kapsam: CRM + Teklif + Raporlama Proje devam ederken: Mobil uygulama da olsun. WhatsApp bağlayalım. AI teklif yazsın. E-fatura da ekleyelim. deniyor. Bu özelliklerin her biri değerli olabilir. Ama proje kapsamı artık aynı değildir. PMI kaynakları da scope değişikliğinin süre, kaynak, teslimat ve kalite üzerindeki etkisinin değerlendirilerek kontrollü biçimde yönetilmesini öneriyor. (Proje Yönetimi Enstitüsü) Change request kötü bir şey değildir Aksine gerçek projelerde gereklidir. Sağlıklı süreç: Yeni ihtiyaç ↓ Analiz ↓ Süre etkisi ↓ Maliyet etkisi ↓ Öncelik

↓

Faz 1 mi Faz 2 mi?

↓

Karar olmalıdır. Böylece müşteri: “Neden proje gecikti?” yerine: “Bu iki yeni modülü eklediğimiz için takvim üç hafta genişledi.” diyebilir.

Peki ekip büyürse proje yarı sürede biter mi?

Genellikle hayır. 2 geliştirici: 4 ay çalışıyorsa 4 geliştirici ekleyip otomatik olarak: 2 ay sonucu alınmaz. Çünkü bazı işler paralel çalışabilirken bazıları birbirine bağımlıdır. Örneğin: Database tasarımı ↓ Backend ↓ API ↓ Frontend ↓ Test gibi bağımlılıklar bulunabilir. Ayrıca ekip büyüdükçe:

• koordinasyon,
• code review,

iletişim ihtiyacı da büyür. Bu nedenle doğru soru: “Kaç kişi koyacağız?”

• değil,

“Hangi işler gerçekten paralel yürütülebilir?” olmalıdır. Güncel GOV.UK Service Standard da dijital ürünlerin ihtiyaca uygun multidisipliner ekiplerle geliştirilmesini öneriyor; gerekli uzmanlık projenin aşamasına göre değişebilir. (GOV.UK)

Özel yazılım projesinin tipik aşamaları nelerdir?

Pratikte süreç şöyle olabilir:

1. Discovery

↓

2. Kapsam / Roadmap

↓

3. UX/UI

↓

4. Teknik mimari

↓

5. Development

↓

6. Entegrasyon

↓

7. QA / UAT

↓

8. Pilot / Staging

↓

9. Canlıya alma

↓

10. İyileştirme

Bu aşamaların tamamı her projede aynı uzunlukta değildir. Bazıları paralel yürütülebilir.

Discovery ne kadar önemli?

Discovery’nin amacı haftalarca toplantı yapmak değildir.

Şu soruları erken çözmektir:

• Kimin problemini çözüyoruz?

Bugünkü süreç nasıl?

Nerede zaman kaybediliyor?

İlk sürümde ne olmalı?

Hangi sistemlere bağlanacağız?

Veri nereden gelecek?

Başarılı olduğumuzu nasıl anlayacağız?

Kullanıcının gerçek problemini erken anlamak, yanlış ürün geliştirme riskini azaltır; GOV.UK kullanıcı ihtiyaçları rehberi de varsayımların erken test edilmesini bu nedenle öneriyor. (GOV.UK)

Tasarım bitmeden kodlama başlanabilir mi?

Çoğu projede evet. Ama: Hiç tasarım yok ↓ Her ekran geliştirme sırasında düşünülüyor yaklaşımı sürekli rework oluşturabilir. Daha iyi: Ana kullanıcı akışı + Temel design system + Öncelikli ekranlar netleşirken geliştirme başlayabilir; sonraki ekranların tasarımı paralel ilerleyebilir.

İlk versiyonun tamamı bitmeden kullanıcıya gösterilmeli mi?

Genellikle hayır, beklememek daha iyidir. Örneğin: 12 haftalık proje varsa müşteri ilk kez:

1. hafta

ürünü görmemelidir. Daha sağlıklı: Hafta 2 → prototip Hafta 4 → ilk akış Hafta 6 → çalışan modül Hafta 8 → genişletilmiş demo gibi iteratif görünürlük sağlanabilir.

Agile yöntemlerin temel mantığı da ürünü kullanıcıya erken gösterip öğrenilenlere göre geliştirmektir. (GOV.UK)

“Proje tamamlandı” ne anlama geliyor?

Bu da başta tanımlanmalıdır. Bir şirkete göre: Tüm kod yazıldı. Başka şirkete göre: App Store ve Google Play’de yayınlandı. Başka projede: Eski sistem verileri aktarıldı, çalışanlar eğitildi ve eski sistem kapatıldı. Dolayısıyla Definition of Done benzeri kabul kriteri baştan belirlenmelidir. InoviqLab için örnek proje süreleri Aşağıdaki süreler teknik teklif değil, planlama amacıyla InoviqLab tarafından oluşturulmuş örnek aralıklardır.

1. Basit operasyon / yönetim paneli

Örnek:

• login,
• 2–3 rol,
• kayıt yönetimi,
• dashboard,

export.

Yaklaşık: 4–8 hafta

2. Orta ölçekli B2B web uygulaması

Örnek:

• 4–6 kullanıcı rolü,
• operasyon akışları,
• dashboard,
• dosya yönetimi,
• bildirim,

bir veya iki entegrasyon.

Yaklaşık: 8–16 hafta

3. SaaS platformu

Örnek:

• multi-tenant yapı,
• üyelik/paketler,
• gelişmiş yetkilendirme,
• raporlama,
• API,
• admin panel,

automation.

Yaklaşık: 3–6 ay

4. Kapsamlı kurumsal sistem

Örnek:

• web,
• mobil,
• ERP/API entegrasyonları,
• legacy migration,
• gelişmiş workflow,
• audit,

yüksek güvenlik. Yaklaşık: 6–12+ ay Burada önemli olan toplam proje süresi değil, ilk değer süresidir Bir proje: 9 ay sürebilir. Ama şirket:

1. ayda

ilk modülü kullanmaya başlayabilir. Bu nedenle iki farklı tarih konuşulmalıdır.

Time to First Value

İlk çalışan ve fayda sağlayan bölüm ne zaman kullanılabilir?

Full Scope

Planlanan bütün modüller ne zaman tamamlanır?

Bu ayrım müşteri açısından çok daha değerlidir. “6 aylık proje” 6 ay boyunca hiçbir şey görememek anlamına gelmemeli Örneğin: Ay 1 Core + kullanıcılar Ay 2 Operasyon Ay 3 Raporlama Ay 4 Entegrasyon Ay 5 Mobil Ay 6 Optimization şeklinde aşamalı teslim olabilir. Bu model business’ın daha erken değer elde etmesini sağlayabilir.

Proje süresini gerçekten kısaltmak isteyen şirket ne yapabilir?

Proje başlamadan önce hazır olması gerekenler

1. Tek bir proje sorumlusu belirleyin

Kim final karar verecek?

1. “Ne istiyoruz?” yerine problemi açıklayın

Örneğin: “CRM istiyoruz.” yerine: “Satış ekibi tekliflerin hangi aşamada olduğunu takip edemiyor.” daha değerlidir.

3. Mevcut süreci gösterin

• Excel,
• form,
• e-posta,
• mevcut yazılım,

örnek rapor.

4. Kullanıcı rollerini belirleyin

Kim kullanacak?

5. Entegrasyonları baştan söyleyin

ERP, muhasebe, banka, API vb.

6. Veri örneklerini hazır edin

Gerçek veya anonimleştirilmiş örnek.

7. İlk sürüm önceliğini belirleyin

“Olmazsa olmaz” ile “iyi olur” ayrılmalı.

8. Geri bildirim süresini kısaltın

3 haftalık approval döngüsü yazılım ekibi tarafından telafi edilemez. Kırmızı bayrak: Analiz yapmadan kesin tarih veren teklifler Şu teklif dikkatle değerlendirilmelidir: “Ne istediğinizi tam konuşmadık ama 45 günde kesin biter.” Bazı çok standart projelerde bu mümkün olabilir. Ancak gerçek özel yazılımda:

• kapsam,
• integration,
• user role,
• migration,

security bilinmeden kesin süre vermek yüksek belirsizlik taşır. Daha güvenilir yaklaşım: İlk tahmin ↓ Discovery ↓ Kapsam ↓ Daha güçlü tahmin ↓ Sprint/iteration bazında güncelleme modelidir. Bir başka kırmızı bayrak: “Sınırsız revizyon” Özel yazılım: Sınırsız değişiklik + Sabit tarih + Sabit bütçe olarak yönetilirse üç değişkenden biri sonunda zarar görür:

• kapsam,
• kalite,

süre. Yeni ihtiyaç çıktığında etkisi görünür hale getirilmelidir.

Proje gecikmesi her zaman kötü yönetim anlamına mı gelir?

Hayır. Örneğin proje sırasında:

• kritik kullanıcı ihtiyacı keşfedilebilir,
• third-party API değişebilir,

güvenlik problemi bulunabilir. Bazen doğru karar teslim tarihini değiştirmektir. Sorun: Takvimin değişmesi

• değil;

neden değiştiğinin görünür olmaması dır.

Sağlıklı proje yönetiminde tarih nasıl konuşulmalı?

Tek tarih:

30 Kasım yerine: MVP hedefi + confidence level + kritik bağımlılıklar + sonraki fazlar ile konuşulması daha anlamlıdır. Örneğin: MVP hedefimiz 10–12 hafta. Bu tahmin üçüncü taraf ERP sandbox erişiminin ilk hafta sağlanması ve kapsamın mevcut MVP ile korunması varsayımına dayanıyor. Bu çok daha şeffaftır. Proje süresini belirleyen 8 faktör — özet Faktör

Süreye etkisi

1. Kapsam ve gereksinim netliği

Özellik ve belirsizlik arttıkça süre artar

2. Rol ve workflow karmaşıklığı

Yetki/onay senaryoları geliştirme ve testi büyütür

3. Entegrasyonlar

Dış sistem bağımlılıkları belirsizlik yaratır

4. Veri migration

Temizleme ve doğrulama ek çalışma oluşturur

5. Güvenlik / uyumluluk

Ek mimari ve test gerektirir

6. Test / kalite seviyesi

Production hazırlığını doğrudan etkiler

7. Müşteri karar hızı

Bekleme süresi takvime eklenir

8. Kapsam değişiklikleri

Yeni iş süre ve maliyeti değiştirir

Özel Yazılım Projesi Öncesi Süre Kontrol Listesi Ana business problemi tanımlı. Kullanıcı grupları belli. MVP özellikleri belli. “Faz 2” özellikleri ayrılmış. Kullanıcı rolleri tanımlı. Onay akışları açıklanmış. Entegrasyonlar listelenmiş. API erişimleri kontrol edilmiş. Mevcut veri örnekleri hazır. Veri migration gereksinimi belli. Güvenlik hassasiyeti tanımlı. Mobil uygulama gerekip gerekmediği belli. Web ve admin panel kapsamı belli. Test/kabul sürecini kimin yapacağı belli. Müşteri tarafında proje sorumlusu atanmış. Karar/onay süreci net. Canlıya alma kriteri tanımlanmış. Bu maddelerin büyük bölümü netse süre tahmini de daha güvenilir hale gelir.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın proje yaklaşımıdır. Özel yazılım projelerinde bizim için en önemli hedef: “Projeyi mümkün olduğunca kısa göstermek” değil, kullanılabilir ilk değeri mümkün olduğunca erken ortaya çıkarmaktır. Çünkü: 6 ay sonra dev sistem yerine bazı projelerde: 8 hafta sonra çalışan çekirdek sistem ↓ sonraki modüller iteratif daha değerli olabilir. Birinci prensip: Önce ürünün çekirdeğini bulun Her istenen özellik aynı önemde değildir. Şunları ayırın: Olmazsa olmaz ↓ Önemli ↓ Sonraki faz ↓ Opsiyonel Bu ayrım süreyi en hızlı kontrol eden yöntemlerden biridir. İkinci prensip: Belirsizliği kod yazarak çözmeye çalışmayın Bir ekranın business kuralı bilinmiyorsa geliştiricinin tahmin ederek yapması: Geliştir ↓ Müşteri görür ↓ Yanlış ↓ Yeniden geliştir döngüsü yaratır. Bazen 30 dakikalık doğru süreç toplantısı birkaç günlük yeniden geliştirmeyi önleyebilir. Üçüncü prensip: Müşterinin zamanı da proje kaynağıdır Özel yazılım tamamen dışarıya bırakılan bir iş değildir. Yazılım şirketi: teknolojiyi bilir. Müşteri: iş sürecini bilir. İkisinin birlikte çalışması gerekir. GOV.UK’un güncel multidisipliner ekip yaklaşımı da teknik ekip ile hizmeti/işi bilen kişilerin aynı delivery sürecinde çalışmasının önemini vurguluyor. (GOV.UK) Dördüncü prensip: Kapsam değişebilir; hedef kontrolsüz değişmemesidir Agile proje: “Başta hiçbir şeyi planlamayalım.” demek değildir. Aksine: Roadmap + Priority + Iteration + Feedback ile değişimi yönetmektir. GOV.UK Service Standard da kullanıcı geri bildirimiyle iterasyon yapmanın yanlış ürünü geliştirme riskini azalttığını belirtiyor. (GOV.UK) Beşinci prensip: Süre tahmininin yanında varsayımları da yazın Örneğin: Tahmini süre 12–14 hafta. tek başına eksiktir. Daha güçlü: 12–14 hafta; ERP API erişiminin proje başlangıcında hazır olduğu, müşteri geri bildirimlerinin maksimum iki iş günü içinde geldiği ve MVP kapsamına yeni modül eklenmediği varsayımıyla. Böylece hem müşteri hem yazılım ekibi hangi faktörlerin tarihi değiştireceğini bilir.

Sonuç

“Özel yazılım ne kadar sürer?” sorusunun doğru cevabı:

Projenin büyüklüğüne göre değişir. deyip bırakmak değildir. Süreyi belirleyen somut faktörler vardır: Kapsam + Workflow + Entegrasyon + Veri + Güvenlik + Test + Karar Hızı + Kapsam Değişiklikleri Bu değişkenler erken görünür hale getirildiğinde proje tahmini de çok daha güvenilir hale gelir. Küçük bir MVP 4–8 hafta, orta ölçekli bir özel yazılım 8–16 hafta, kapsamlı SaaS/B2B platformları ise birkaç aydan başlayıp 6 ay veya daha uzun süreye uzanabilir. Bu aralıklar InoviqLab’ın planlama örnekleridir; gerçek proje süresi discovery ve kapsam analizinden sonra belirlenmelidir. İşletme açısından ise belki daha önemli soru şudur: “Bütün sistem ne zaman biter?” yerine: “İlk kullanılabilir ve işimize değer sağlayan sürümü ne zaman kullanmaya başlayabiliriz?” Bu soru, özel yazılım yatırımını çok daha doğru planlamayı sağlar.