28 Nisan 2026 · 12 dk okuma
Teknik Şartname (RFP) Nasıl Hazırlanır? Yazılım Projesi İhale Rehberi 2026
Makrops Mühendislik Ekibi
Yazılım, 3D ve yapay zeka mühendisliği · İstanbul / Berlin / New York
Bir yazılım projesini doğru almanın ilk koşulu, doğru sormaktır. Türkiye'de kurumsal yazılım firması seçim sürecinin %70'i, henüz teknik şartname yazılmadan yola çıkar; sonra teklifler dağılır, alıcı kafası karışır, satıcı projeyi yarı yolda yeniden yazar.
Bu yazıyı, kendi RFP'sini yazacak kurumsal alıcı için (CFO, CIO, CDO, satın alma müdürü) hazırladık. Ne kamu ihale dili gibi 90 sayfalık ne de iki paragraflık brief; pratik orta yol.
1. Teknik şartname (RFP) nedir, niye gerekli?
RFP (Request for Proposal) / Teknik Şartname — bir alıcının, ihtiyacını ve kabul kriterlerini belgeleyerek satıcılardan tutarlı teklif istediği dokümandır.Niye gerekli?
- Aynı işe 3 firma teklif etsin diye değil; aynı işin tarif edildiğinden emin olmak için.
- İyi yazılmış şartname, teklif farkını ortalama %50 daraltır. Çünkü "ben buna ne anladım"ı eler.
- Sonradan "bu kapsam dışıydı" tartışmalarını %80 azaltır.
- Kurumsal yönetişim (compliance, denetim) için kanıt belgesidir.
- Tek başına proje başarısı sağlamaz; uygulamada karar mercii ve hız o kadar önemli.
- Aşırı detay, fırsat alanını kapatır; çok az detay, riski açar.
- 6 aydan eski şartname genelde geçersizdir (teknoloji ve gereksinim değişimi).
2. Bir RFP'nin 12 zorunlu bölümü
Sektörden bağımsız 2026 standardı 12 bölüm:
1. Yönetici özeti (1 sayfa) — proje 30 saniyede ne anlatır? 2. Şirket ve bağlam — biz kimiz, niye bu yola çıktık? 3. Mevcut durum analizi — nasıl çalışıyor, ne çalışmıyor? 4. Hedefler ve başarı metrikleri — sayısal hedef 5. Kapsam (in-scope / out-of-scope) — net liste 6. Fonksiyonel gereksinimler — kullanıcı senaryoları 7. Fonksiyonel olmayan gereksinimler — performans, ölçek, güvenlik, uyum 8. Mimari ve entegrasyon kısıtları — eski sistem, AD, tek sign-on, ERP 9. Veri ve KVKK / ISO — özel nitelikli veri var mı, saklama süresi? 10. Süreç ve teslim modeli — Agile / Waterfall / Sprint sabit 11. Tedarikçi soruları (RFP yanıt formatı) — nasıl cevap istiyoruz? 12. Değerlendirme kriterleri ve takvim — fiyat % kaçı, kalite % kaçı?
Bu yapı yokken yazılan RFP'ler genelde "biz ne istediğimizi bilmiyoruz" sinyali verir. Ciddi bir B2B yazılım şirketi bu sinyalden uzak durur.
3. "Fonksiyonel olmayan" gereksinimlerin gizli gücü
Çoğu RFP'nin zayıf halkası, fonksiyonel olmayan (NFR) bölümüdür. Bu bölüm aslında projenin mühendislik bütçesini belirler.
Mutlaka tanımlanmalı:
- Performans: zirve trafikte sayfa yanıtı < 1 sn, INP < 200ms
- Ölçek: 12 ay sonra 100K aktif kullanıcı
- Erişilebilirlik (a11y): WCAG 2.2 AA
- SLA: %99.9 uptime, RTO 1 saat, RPO 15 dakika
- Güvenlik: OWASP Top 10, ISO 27001, KVKK
- Veri kalıcılığı: 7 yıl saklanmalı (e-fatura uyumu)
- Uluslararasılaştırma: TR + EN + AR, RTL desteği
- Tarayıcı / cihaz: son 2 sürüm Chrome / Safari / Edge / Firefox; iOS 16+ / Android 11+
- Erişilebilirlik kanalı: 7/24, 4 saat içinde kritik müdahale
4. Kapsam tarifi — yazmadığınız her şey kapsam dışıdır
Açık olmayan kapsam, yazılım projelerinin %1 numaralı katilidir. Bizim önerdiğimiz pratik:
Aşama 1: Temel kullanıcı senaryosu listesi- Aktör + ne yapıyor + hangi sonuca ulaşıyor
- Örnek: "Saha satış temsilcisi, müşteri ziyaretinde mobil uygulamadan teklif oluşturup PDF olarak müşteriye e-posta yollayabilir."
- En kritik 3 senaryoyu adım adım çizin
- Her adımda hangi sistemle konuşuluyor (CRM, ERP, ödeme)?
- "Bu fazda kapsam dışı: AI öneri motoru, çok dil, offline mode."
5. Tedarikçi soru seti (RFP yanıt formatı)
Tedarikçinin cevabını standardize etmek, karşılaştırmayı kolaylaştırır. 2026'da kullanılan asgari soru seti:
Şirket
- Kuruluş, çalışan sayısı, finansal istikrar
- Bizim sektörde 5+ referans
- Ödüller, sertifikasyonlar (ISO 27001, ISO 9001, sektörel)
Ekip
- Bu projeye atanacak gerçek isimler ve CV'ler
- Sözleşme süresince ekip değişme kuralları
- Saatlik / günlük ücret bandı
Süreç
- Discovery yaklaşımı
- Sprint uzunluğu, ceremonileri
- Kabul kriterleri ve sign-off prosedürü
- Risk yönetimi (top 5 risk + mitigation)
Teknik
- Önerilen mimari (yüksek seviyeli diyagram)
- Stack seçimi gerekçesi
- 3rd party araçlar listesi
- Veri yedekleme + geri yükleme prosedürü
- Felaket kurtarma planı
Sözleşme
- IP transfer modeli
- Kaynak kod erişimi day-1
- Sözleşme süresi ve çıkış klozları
- Garanti süresi (genelde 6 ay) ve kapsamı
- Bakım sözleşmesi opsiyonu
Fiyat
- Kalem bazlı (NSI: discovery, UI/UX, backend, frontend, mobile, QA, DevOps, PM)
- Sprint başına maliyet
- 1 yıl bakım fiyatı
- Üçüncü parti maliyet beklentisi
6. Değerlendirme matrisi — kim seçilecek?
Şeffaf değerlendirme matrisi yoksa, satın alma genelde "müdürün hissi" olur. 2026 standart matris:
| Kriter | Ağırlık | Notlama |
| Sektörel deneyim | %15 | 0-10 |
| Önerilen ekip kalitesi | %15 | 0-10 |
| Teknik mimari kalitesi | %15 | 0-10 |
| Süreç olgunluğu | %10 | 0-10 |
| Süre / takvim gerçekçiliği | %10 | 0-10 |
| Fiyat | %20 | 0-10 |
| Risk yönetimi yaklaşımı | %5 | 0-10 |
| Sözleşme + IP modeli | %5 | 0-10 |
| Müşteri referansı + saha ziyareti | %5 | 0-10 |
7. Sektörel zorunluluklar — RFP'ye eklenecek özel bölümler
Finans / fintech
- BDDK / SPK uyum
- KVKK + KKVKK + GDPR
- ISO 27001 + PCI-DSS
- Sızma testi (yıllık + kritik değişiklik sonrası)
- Veri ikametgâhı (Türkiye, AB)
Sağlık
- Sağlık Bakanlığı + e-Nabız + MEDULA
- KVKK özel nitelikli veri
- ISO 27799
- HL7 / FHIR uyumu
Kamu / savunma
- TS 13638 (yerli yazılım)
- TÜBİTAK BİLGEM
- AQAP, MIL-STD
- Kaynak kod escrow
E-ticaret / perakende
- E-fatura, e-arşiv, e-irsaliye
- Banka POS sertifikasyonu
- Pazaryeri entegrasyonları (Trendyol, Hepsiburada vb.)
Üretim
- ISA-95 katmanı
- IATF 16949 (otomotiv)
- ISO 22000 (gıda)
8. RFP süreç takvimi — gerçekçi 2026
| Adım | Süre |
| RFP yazımı | 2-4 hafta |
| Tedarikçi long-list (8-12 firma) | 1 hafta |
| Tedarikçilere RFP dağıtımı + Q&A | 1 hafta |
| Tedarikçi cevap süresi | 3-4 hafta |
| Cevap analizi + short-list (3-4 firma) | 1 hafta |
| Demo + saha ziyareti + referans çağrısı | 2 hafta |
| Final değerlendirme + müzakere | 2 hafta |
| Sözleşme + Hukuk | 2-3 hafta |
| Toplam | 14-18 hafta |
9. RFP'de en sık yapılan 10 hata
1. Çözümü dikte etmek ("React + AWS yapacaksınız") — satıcının yaratıcılığını kapatır. 2. Mevcut sistemi tarif etmemek — entegrasyon sürpriz olur. 3. Başarı metriği yok — "iyi olsun" projesi. 4. NFR yok — performans/ölçek belirsiz. 5. Out-of-scope yok — sürpriz fatura. 6. Veri tarifi eksik — KVKK + göç riski. 7. Ekip beklentisi yok — junior ekip atanır. 8. Cevap formatı standardize değil — karşılaştırılamaz. 9. Süreç modeli net değil — Agile / Waterfall karması. 10. Bakım / SLA atlanır — 1. yıl sonu kriz.
10. Mini RFP şablonu — küçük projeler için
15 sayfalık RFP yazamayanlar için 2 sayfalık mini şablon:
``` 1. KISA TANIM (3 cümle) 2. MEVCUT DURUM (1 paragraf) 3. NEYİ BAŞARMAK İSTİYORUZ (3 hedef + 3 metrik) 4. KAPSAM (5 madde in-scope, 5 madde out) 5. NFR (performans, ölçek, güvenlik, uyum) 6. ENTEGRASYON (3 mevcut sistem + format) 7. EKİP BEKLENTİSİ (rol + senior/mid sayısı) 8. SÜRE + BÜTÇE BANDI (3-6 ay, X-Y TL) 9. TEDARİKÇİ CEVABI (8 standart başlık) 10. DEĞERLENDİRME (5 kriter + ağırlık) ```
Bu şablon, KOBİ-orta ölçek özel yazılım geliştirme projelerinde teklif aralığını ciddi daraltır.
11. Kapanış
Teknik şartname yazmak, satın alma değil; liderlik disiplinidir. İhtiyacı baştan çerçeveleyen, satıcıya cevap verme alanı bırakan, kabul kriterlerini sayısallaştıran her RFP, sonraki 12 ayın projesini daha az krizle götürür. Şartname yazmaya 2-4 hafta yatırım yapmak; 12 aylık projede 3-4 ayın bütçe + zaman yangınını söndürür.
İyi RFP, iyi projeyi getirmez; iyi projenin önündeki en büyük engeli (yanlış anlama) kaldırır.
*Makrops, B2B yazılım şirketi olarak kurumsal alıcılara RFP danışmanlığı, teknik şartname yazımı ve kurumsal yazılım çözümleri özel yazılım geliştirme süreçlerinde uçtan uca destek veriyor. API geliştirme hizmetleri, DevOps hizmetleri ve mimari danışmanlığı ihtiyacınız için ücretsiz keşif: iletişim.*