Kısa cevap: özel yazılım yaptırmanın 5 adımı
Özel yazılım yaptırmak beş adımda ilerler: problemi tanımlayın, brief yazın, teklifleri aynı brief üzerinden isteyin, küçük bir keşif ya da prototip aşamasıyla başlayın, sonra geliştirmeye ve yayına geçin. Teklif istemeden önce en çok işe yarayan hazırlık, ne istediğinizi çözümle değil problemle anlatan yazılı bir brief'tir.
"Kaç haftada biter?" sorusunun ilk cevabı bir sayı değil, bir aralıktır. Construx'a göre proje çok erken aşamadayken yapılan tahmin hem yüksek hem düşük tarafta 4 kata kadar sapabiliyor (toplam aralık 16 kat) ve kuruluşlar ilk taahhüdü çok erken verdiğinde 2 ila 4 kat hata payıyla çalışıyor. Bu yüzden sağlam bir teklif, kesin bir tarih yerine aşamalara bölünmüş bir plan ve her aşama sonunda yeniden değerlendirme sunar.
| Adım | Ne yaparsınız? | Çıktı |
|---|---|---|
| 1 | Problemi ve kapsam dışını yazarsınız | Tek sayfalık problem tanımı |
| 2 | Brief hazırlarsınız | Kapsam, kullanıcılar, kısıtlar, bütçe aralığı |
| 3 | Aynı brief'i 2-3 firmaya verirsiniz | Karşılaştırılabilir teklifler |
| 4 | Keşif ya da prototip aşamasıyla başlarsınız | Kapsam ve plan netleşmiş olur |
| 5 | Geliştirme, test, yayın ve bakım | Çalışan yazılım ve destek sözleşmesi |
Yazının sonunda kopyalayıp kullanabileceğiniz bir brief şablonu var.
Brief nasıl yazılır?
Çözümü mü, problemi mi yazmalı?
İngiliz hükümetinin hizmet geliştirme kılavuzu (GOV.UK Service Manual, 21 Haziran 2021'de güncellenmiş) ilk aşamada, yani keşif sırasında hizmetin inşa edilmemesini, önce problemin çerçevelenmesini ve problemin parçası olmayan şeylerin açıkça kabul edilmesini öneriyor. Bu bir kamu hizmeti kılavuzu, ama mantığı her özel yazılım için geçerli: "şu ekranlar olsun" demek yerine "şu süreç aksıyor ve şu sonucu istiyoruz" yazın. Çözümü firmayla birlikte tasarlarsınız; baştan çizdiğiniz çözüm, daha iyi bir yolu kapatabilir.
Brief'te neler olmalı?
Bizim önerimiz olan asgari liste: problem ve hedef, yazılımı kimin kullanacağı, kapsam içi ve kapsam dışı, öncelikli özellikler, bağlanması gereken sistemler (ERP, muhasebe, e-ticaret), kısıtlar (mevzuat, KVKK, altyapı), başarı ölçütü ve kabul kriteri, bütçe aralığı ve takvim kısıtı. TÜBİTAK BİLGEM'in "Uygulama Yazılımı Geliştirme" rehberi de ihtiyaç analizinde sistemin ayrıntılı analizi, maliyet analizi ve proje planının yer almasını ister.
Hazır bir yazılım yetmez mi?
Bu soruyu brief'ten önce sorun. TÜBİTAK BİLGEM rehberi de paket yazılım ile özel yazılım ayrımının baştan değerlendirilmesini öneriyor. Karar için hazır yazılım mı özel yazılım mı karar matrisimize bakabilirsiniz; ERP gibi hazır ürünlerin seçiminde sorulacakları da İzmir'de ERP firması seçerken 12 soru yazısında topladık.
Teklif istemeden önce kendinize sormanız gereken 15 soru
Bunlar firmaya değil, önce kendinize soracağınız sorular: cevapları brief'e dönüşür. Hepsini yanıtlayamıyorsanız bu bir sorun değil, keşif aşamasının konusu olduğunun işareti.
Problem ve kapsam
- Hangi problemi çözüyoruz ve neden şimdi?
- Bu problem bize bugün neye mal oluyor (zaman, hata, kayıp satış)?
- Kapsam dışında ne kalıyor?
- Yazılımı kimler kullanacak, kimler onaylayacak?
- "Bitti" demek için hangi ölçütleri sağlamalı?
Teknik ve yasal
- Hazır bir ürün (paket yazılım) bu ihtiyacı karşılamıyor mu?
- Hangi sistemlerle bağlanmalı (ERP, muhasebe, e-ticaret, bankalar)?
- Hangi kısıtlar var (mevzuat, KVKK, mevcut altyapı)?
- Kaynak kod kimin olacak, devir ya da lisans olarak nasıl yazılacak?
- Yazılım firması kişisel verilere erişecek mi, güvenlik tedbirleri nasıl sağlanacak?
Ticari ve işletme
- Fiyat sabit mi olacak, saat esaslı mı, yoksa hibrit mi?
- Kapsam değişirse ek iş nasıl fiyatlanacak?
- Yayın sonrası bakım ve destek nasıl işleyecek (süre, yanıt süresi)?
- Çıkış koşulları nedir: firma ile yollar ayrılırsa kodu, veriyi ve dokümantasyonu nasıl alacağım?
- Güvenli geliştirme ve test nasıl yapılacak?
Proje aşamaları ve süre
Proje hangi aşamalardan geçer?
Genel bir özet: keşif ve analiz, tasarım ya da prototip, geliştirme, test, yayın, bakım ve destek. GOV.UK kılavuzu da işi keşif (discovery), prototip (alpha), geliştirme (beta) ve canlı (live) diye aşamalara ayırıyor; keşfin tipik süresini 4-8 hafta, prototip aşamasının tipik süresini 6-8 hafta olarak veriyor ve prototipte yazılan kodun atılmasını bekliyor. Bunlar kamu hizmetleri bağlamında yazılmış, Türkiye'deki özel yazılım projeleri için ölçülmüş süreler değil; yalnızca "ilk aşamalar tam yazılımın süresi değildir" mantığını göstermek için veriyoruz. Türkiye için güvenilir, yayımlanmış bir özel yazılım süre verisi bulamadık.
Sabit fiyat mı, saat esaslı mı?
Sabit fiyat net kapsam ister; kapsam değişirse ek iş ayrıca fiyatlanır. Saat esaslı model esnektir ama izleme ister; müşteri tarafında üst sınır (örneğin her aşama için bir bütçe tavanı) koymak yaygın bir önlemdir. Bizim önerimiz hibrit gitmek: keşif aşamasını saat ya da sabit küçük bir paket olarak yapın, sonuçta çıkan net kapsamla geliştirme için fiyat konuşun. Construx'un uyardığı gibi çok erken verilen taahhüt öngörülebilirliği zayıflatır ve riski artırır.
Süre neden bir aralıktır?
Çünkü proje ilerledikçe belirsizlik azalır. Construx, anlamlı taahhütlerin projenin erken-orta noktasında (yaklaşık yüzde 30'unda) mümkün olduğunu yazıyor. Teklifte tek bir bitiş tarihi görüyorsanız, nasıl hesaplandığını ve kapsam değişirse ne olacağını sorun.
Yerel firma avantajı ve dezavantajı
"Yerinde toplantı ve yakınlık proje başarısını artırır" iddiasını doğrulayan bir kaynak bulamadık; bu nedenle bunu kesin bir avantaj olarak yazmıyoruz. Pratikte aynı şehirde olmanın somut karşılığı şudur: toplantıyı sizin sahanızda yapabilirsiniz, iş akışını yerinde görebilirler, referans ziyareti kolaylaşır. Karşısında şu soru kalır: bu avantaj sözleşmede yazılı mı? Yerinde toplantı sayısını, hangi aşamada olacağını ve ek ücret doğup doğmadığını teklifte netleştirin. Karar kriteriniz şehir değil, referans, plan ve sözleşme olsun.
Kaynak kod ve sözleşme: hangi maddeler yazılı olmalı?
Bu bölüm hukuki danışmanlık değildir; sözleşme maddeleri için bir hukuk danışmanına başvurun. Bilinmesi gereken üç şey:
- Bilgisayar programları eserdir. 5846 sayılı Fikir ve Sanat Eserleri Kanunu (FSEK), her biçim altında ifade edilen bilgisayar programlarını eser kapsamında sayıyor (madde 2).
- Hak devri yazılı olmalı. FSEK madde 52'ye göre mali haklara dair sözleşmelerin yazılı olması ve konusu olan hakların ayrı ayrı gösterilmesi şarttır. Yani "kaynak kodu bize teslim edilecek" cümlesi tek başına yetmez: kaynak kod teslimi, kullanım lisansı ve hakların devri ayrı ayrı ve yazılı olarak belirtilmeli.
- Kişisel veri sorumluluğu sizde de kalır. KVKK madde 12'ye göre veri sorumlusu, verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek için gerekli her türlü teknik ve idari tedbiri almak zorundadır; kişisel veriler kendi adına başka bir kişi tarafından işleniyorsa, bu tedbirlerin alınmasında o kişilerle müştereken sorumludur. Yazılım firması verinize erişecekse bunu sözleşmede ve güvenlik tedbirlerinde yazılı hale getirin.
Güvenli geliştirme için firmaya referans alınabilecek çerçeveleri sorabilirsiniz: web uygulamaları için OWASP'ın uygulama güvenliği doğrulama standardı (ASVS 5.0.0, Mayıs 2025) ve NIST'in güvenli yazılım geliştirme çerçevesi (SSDF; NIST sayfası, yazılım üreticilerinin yanı sıra alıcıların da kullanabileceğini belirtiyor).
Brief şablonu
Aşağıdaki başlıkları doldurun ve aynı metni tüm firmalara verin:
| Başlık | Yazacağınız şey |
|---|---|
| Problem | Hangi süreç aksıyor, neye mal oluyor? |
| Hedef ve başarı ölçütü | Neyin değişmesini istiyorsunuz, nasıl ölçeceksiniz? |
| Kullanıcılar | Kim kullanacak, kaç kişi, hangi rollerle? |
| Kapsam içi | İlk sürümde olması gerekenler |
| Kapsam dışı | Şimdilik olmayacaklar |
| Bağlanacak sistemler | ERP, muhasebe, e-ticaret, bankalar, diğer |
| Kısıtlar | Mevzuat, KVKK, altyapı, mevcut yazılım |
| Bütçe aralığı | Rakam ya da aralık; teklifi gerçekçi tutar |
| Takvim kısıtı | Zorunlu bir tarih varsa nedeni |
| Sözleşme beklentileri | Kaynak kod, bakım, çıkış |
Sıkça Sorulan Sorular
Özel yazılım brief'i neleri içermeli?
Problem ve hedef, kullanıcılar, kapsam içi ve dışı, bağlanacak sistemler, kısıtlar, başarı ölçütü, bütçe aralığı ve takvim kısıtı. Çözümü değil problemi anlatın; çözüm tasarımını firmayla birlikte yapın.
İzmir'de yerinde toplantı gerekli mi?
Zorunlu olduğunu gösteren bir kaynak bulamadık. Süreci yerinde görmek, özellikle üretim, depo ya da saha gibi fiziksel işleri olan firmalar için işe yarayabilir; bunu teklifte yazılı bir madde yapın (kaç toplantı, hangi aşamada, ek ücret var mı).
Proje kaç hafta sürer?
Türkiye için güvenilir yayımlanmış bir süre verisi bulamadık. Kapsama, entegrasyonlara ve onay hızınıza bağlı. Erken aşamadaki her tahminin geniş bir hata payı vardır (Construx'a göre 4 kata kadar her iki yönde): bu yüzden aşamalara bölünmüş bir plan isteyin.
Kaynak kod kime ait olur?
Bu sözleşmede yazdığınıza bağlı. FSEK madde 52'ye göre mali haklara dair sözleşmelerin yazılı olması ve hakların ayrı ayrı gösterilmesi şarttır; kaynak kod teslimini, lisansı ve devri ayrı ayrı yazın. Kesin maddeler için bir hukuk danışmanına başvurun.
Brief'inizi birlikte değerlendirmek isterseniz özel yazılım geliştirme sayfamıza bakabilir ya da bize ulaşabilirsiniz.
Kaynaklar: How the discovery phase works (GOV.UK Service Manual, 21 Haziran 2021), How the alpha phase works (GOV.UK Service Manual, 8 Mayıs 2019), The Cone of Uncertainty (Construx), Uygulama Yazılımı Geliştirme rehberi (TÜBİTAK BİLGEM), 6698 sayılı Kişisel Verilerin Korunması Kanunu, madde 12 (Adalet Bakanlığı MGM), 5846 sayılı Fikir ve Sanat Eserleri Kanunu (orgTR), OWASP ASVS, NIST Secure Software Development Framework
Kapak fotoğrafı: Vitaly Gariev / Unsplash