Kapsam ve sınırlar: Teklifin omurgası
Özel yazılım teklifi ilk sayfada işin sınırlarını açıkça yazmalı. “Neyi yapıyoruz?” sorusuna teknik kalemlerle cevap verin: modüller, veri kaynakları, raporlama, yönetim paneli, doğrulama kuralları ve çıktı formatları. Benzer kelimeler yerine somut liste kullanın: örn. kullanıcı kayıt/izin, sipariş oluşturma, fatura indirme, doküman yükleme gibi. Sınır maddesi de şart: Teklif kapsamına girmeyen işler (ör. üçüncü parti lisanslar, özel bir mobil uygulama, veri temizliği) net belirtilemiyorsa ileride ek ücret çıkar. Teklifte kabul kriteri olarak “hangi veriler hangi formatta üretiliyor” maddelerini görün.
Ekran listesi: Sayfa değil, ekran tanımı istenmeli
Teklifte ekranler sadece başlık halinde değil, ekran tanımıyla verilmelidir. Her ekran için amaç, ana alanlar ve kritik kontroller belirtilmeli. Örnek şablon: “Kullanıcı Yönetimi ekranı: rol atama, yetki kontrolü, kullanıcı durumları (aktif/askıda/kapalı), ekran filtreleri (tarih aralığı, rol, e-posta), dışa aktarım (CSV)”. Yönetim ekranları, kullanıcı ekranları, onboarding adımları, hata ekranları ve doğrulama ekranları da ayrı yazılmalı. En azından rol bazlı görüntüleme farkları tek tek listelenmelidir. Ayrıca ekranlerde kullanılacak veri alanlarının kaynağı (DB tablosu, entegrasyon cevabı, kullanıcı girdisi) belirtilirse “beklenmeyen alan” sorunları azalır.
Kullanıcı rolleri ve yetkilendirme matrisi: Kim neyi yapacak?
Teklifin kritik parçası kullanıcı rolleri ve yetkilendirme yaklaşımıdır. En azından yönetici, operasyon yetkilisi, standart kullanıcı ve yalnızca görüntüleyen kullanıcı gibi roller tanımlanmalı. Her rol için “oluşturma, düzenleme, silme, onay, dışa aktarım” gibi aksiyonlar net yazılmalı. Yetki matrisi teklif ekine alınabilir; metinle bile olsa tablolaştırın. Ayrıca alan düzeyi yetki (ör. bazı alanlar sadece admin tarafından düzenlenir) gerekiyor mu yazılmalı. Oturum yönetimi için kimlik doğrulama yöntemi (e-posta şifresi, SSO, token tabanlı erişim) belirtilmeli. Yetkisiz erişim denemelerinde kullanıcıya gösterilecek mesajlar ve loglama şartları da eklenmeli.
Entegrasyonlar: Hangi sistem, hangi veri, hangi yöntem?
Teklifte entegrasyonlar tek satır “entegrasyon yapılacak” şeklinde geçmemeli. Her entegrasyon için kaynak sistem, hedef sistem, veri akışı yönü (al/ver), tetikleyici (manuel, zamanlayıcı, webhook), veri formatı (JSON/CSV/XML) ve doğrulama mantığı yazılmalı. Örnek: “ERP’den sipariş verisi alımı: günlük 02:00 çalışır, sipariş statüsü güncellenir, benzersiz anahtar siparişNo’dur”. API erişim modeli (REST/SOAP), kimlik bilgisi saklama (örn. secrets vault), rate limit ve hata senaryoları belirtilmeli. Ayrıca veri eşleşme ve tekrar kayıtların önlenmesi için idempotency yaklaşımı yazmak gerekir. “Ekip gerekli dokümanları sağlar” demek tek başına yeterli değildir; hangi endpoint’lerin teslim alınacağı listelenmelidir.
Teslim süresi ve plan: Takvim değil, kilometre taşları
Teslim süresi “X hafta” gibi tek sayıyla kalmamalı; kilometre taşları eklenmeli. Teklifte en az: analiz, ekran prototipleri, teknik tasarım, geliştirme, test (fonksiyonel ve entegrasyon), UAT, devre alma ve eğitim adımları yer almalı. Her aşamada teslim edilecek çıktı dosyaları belirtilmelidir: örn. ekran taslakları, yetki matrisi, API dokümantasyonu, test senaryo listesi, devreye alma kontrol listesi. Kritik olan, bağımlılıkların kimde olduğudur: ödeme/SSO ayarları, API anahtarları, sandbox erişimleri gibi öğeler için tarih ve sorumluluk yazılmalı. Böylece gecikme olursa nedeni tartışılmaz. Neptün Medya bu planı teklif içine “kontrol kapıları” şeklinde koyar; onay alınmayan noktada sonraki adımın başlamaması hedeflenir.
Bakım ve destek: Hizmet seviyesi nasıl tarif ediliyor?
Teklifte bakım başlığı net olmalı: destek saatleri, yanıt süresi, hata sınıfları ve önceliklendirme kuralı tanımlanır. Örn. kritik hata: aynı gün aksiyon, yüksek öncelik: 48 saat içinde çözüm planı, düşük öncelik: bir sonraki bakım sprint’i. Destek kapsamına nelerin dahil olduğu açıkça yazılmalı: bug fix, küçük iyileştirmeler, mevzuat kaynaklı alan değişiklikleri gibi. Ayrıca bakım kapsamında “sürüm güncelleme” ve test edilerek geri dönüş sağlama yaklaşımı belirtilmeli. Logların tutulacağı, izleme metrikleri ve performans kontrolleri için beklenti yazın. Entegre sistemlerde API değişirse nasıl davranılacağı (ön bildirim, uyarlama süresi) da bakım şartlarının parçası olmalıdır.
Değişiklik yönetimi: Yeni istek hangi süreçle fiyatlanır?
Özel yazılım projelerinde değişiklik kaçınılmazdır. Teklif, değişiklik yönetimini operasyonel bir prosedür gibi tarif etmelidir. Yazılı şekilde: istek alma kanalı (ticket sistemi/e-posta), etki analizi (hangi modül/ekran/veri akışı), süre ve maliyetin nasıl hesaplandığı, onay adımı ve plan güncelleme yöntemi belirtilmelidir. “Scope change” durumunda hangi ölçütler değişiklik sayılır: yeni ekran eklemek, mevcut ekranın alanlarını değiştirmek, entegrasyon endpoint’i değiştirmek gibi. Ayrıca acil istek kanalı olmalı; normal süreci beklemeden hangi koşullarda devreye alındığı yazılmalıdır. Sık hata: sözlü talepleri aynı sprint’e dahil etmek, sonradan “tamamlanmamış iş” tartışması doğurur.
Kabul testleri ve dokümantasyon: Doğru bitti nasıl anlaşılır?
Teklifin sonunda kabul testleri ve dokümantasyon maddeleri olmalı. Fonksiyonel kabul için test senaryoları (kullanıcı rolleri, form validasyonları, işlem adımları), entegrasyon kabulü için veri örnekleri (örn. siparişNo eşleşmesi), performans için temel hedefler (örn. sayfa yükleme süresi, sorgu limitleri) belirtilir. Ayrıca “tamamlandı” tanımına eğitim ve işletim devri dahil edilmelidir: admin kullanım kılavuzu, operasyon kontrol listesi, hata loglarına erişim adımları. Kaynak kodun teslimi/erişim yöntemi ve proje dosya yapısı da yazılabilir. Neptün Medya benzer projelerde dokümantasyonu sadece PDF olarak bırakmaz; teklif içinde test ve devreye alma kontrol listesini de talep eder.
Uygulama sonrası kontrol listesi
- Mobil görünüm, form ve WhatsApp yönlendirmeleri test edilir.
- Title, description, canonical ve sitemap kayıtları kontrol edilir.
- Kırık link, hatalı görsel ve boş CTA alanı bırakılmaz.
- İçerikler gerçek hizmet kapsamıyla uyumlu kalır.