Özel Yazılım Şartnamesi Nasıl Hazırlanır? Kontrol Listesi

Üç firmadan teklif istediniz. Biri sekiz sayfalık doküman ve altı haftalık takvimle döndü, ikincisi tek satırlık bir rakam yazdı, üçüncüsü "analiz sonrası netleşir" dedi. Yan yana koyduğunuzda karşılaştırdığınız şey yazılım olmuyor; firmaların tahmin cesareti oluyor. Kabahat tekliflerde değil. Üçü de aynı belirsiz metne bakıyor. Yazılım şartnamesi nasıl hazırlanır sorusunun sahadaki karşılığı şu: şartname ne istediğinizi anlatan bir tanıtım metni değil, teklif verenin neyi varsayabileceğini daraltan bir belgedir. Varsayım alanı daraldıkça fiyatlar birbirine yaklaşır.

İlk sayfa: bu iş bugün nasıl yapılıyor?

Çoğu şartname doğrudan "istenen özellikler" başlığıyla açılır. Mevcut durumu görmeyen firma ölçeği tahmin eder, tahmin ettiği yere de risk payı koyar. O payı siz ödersiniz. Yazılım analiz dokümanının ilk bölümü bu yüzden bugünü anlatır.

• Hangi süreç: "Stok yönetimi" yetmez. "Tedarikçiden gelen malın kabulü, raf yerleşimi ve e-ticarete stok bildirimi" tarif eder.
• Kaç kullanıcı: Toplam kullanıcı değil, aynı anda çalışan kullanıcı sayısı. Rol dağılımıyla birlikte yazılır.
• Aylık kaç işlem: Sipariş, iade, irsaliye, mal kabul satırı. Yoğun sezonun pik günü ayrıca yazılır.
• Bugün nasıl yapılıyor: Hangi Excel dosyası, hangi ekran, hangi WhatsApp grubu. Adım adım, kişi kişi.
• Nerede tıkanıyor: Hata en çok hangi adımda çıkıyor, kim fark ediyor, nasıl düzeltiliyor.

Ölçek bilgisi fiyatın yarısını belirler. Aylık 300 iade işleyen bir ekiple aylık 6.000 iade işleyen bir ekip aynı yazılımı kullanmaz; ikincisinde toplu işlem, kuyruk ve hata ekranı zorunlu hale gelir. Hazır bir paketin işi görüp görmeyeceğine de genelde burada karar veriliyor; özel yazılım mı hazır paket mi ayrımını şartnameden önce netleştirmek gerekiyor.

Kapsam listesinden çok, kapsam dışı listesi işe yarar

Anlaşmazlıkların büyük kısmı yazılanlardan değil, yazılmayanlardan doğuyor. Kapsam listesini iki taraf da okur. Kapsam dışı listesi ise kimsenin yazmak istemediği ama tartışmayı bitiren bölüm. İlk sürümde neyin olmayacağını yazılı hale getirmek, ne olacağını yazmaktan daha çok iş görüyor.

Proje kapsamı belirleme aşamasında şu maddeleri açıkça dışarıda bırakmak yaygın: mobil uygulama, çoklu dil, eski verinin tamamının taşınması, muhasebeye otomatik fiş atma, müşteriye açık self servis ekran. Hiçbiri "asla yapılmayacak" demek değil; ikinci faz başlığında toplanır, tarihi sonra konur.

Şartnamenin amacı yazılımı tarif etmek değil, iki tarafın aynı şeyi hayal ettiğini kanıtlamaktır. Kapsam dışı listesi bu kanıtın en ucuz yoludur.

Gereksinimi özellik olarak değil, senaryo olarak yazın

"İade modülü olacak" bir gereksinim değil, başlıktır. Yerine rol, adım ve beklenen sonucu içeren bir cümle yazılır: Depo sorumlusu iade kargosunu açar, barkodu okutur; sistem ilgili siparişi ve müşterinin belirttiği iade sebebini ekranda gösterir, ürünü "kontrol bekliyor" durumuna alır. Bu cümle hem fiyatlanabilir hem test edilebilir. Yanına hata durumları da yazılır: barkod eşleşmezse ne olur, sipariş kapanmışsa ne olur, aynı barkod iki kez okutulursa ne olur.

Aşağıdaki tablo, teklif hazırlayan tarafın belirsiz maddeleri nasıl okuduğunu gösteriyor.

Tablodaki son satır aslında kolay çözülüyor: hız gibi maddeler ölçüye bağlanabilir. "Hızlı çalışacak" yerine "200.000 hareket satırı olan bir tabloda tarih filtresi iki saniyede döner" yazıldığında madde hem fiyatlanabilir hem test edilebilir hale geliyor. Aynısı yük için de geçerli: kampanya gününde saatte kaç sipariş işlenecek, kaç kullanıcı aynı anda ekranda olacak. Bu iki satır yazılmazsa performans işi ya tamamen atlanıyor ya da tahmini bir tamponla fiyatlanıyor.

Kapsamı otuz maddeye çıkarmak zorunda değilsiniz; sekiz on ana akış, geri kalanın çerçevesini zaten çiziyor. Özel yazılım geliştirme işlerinde analiz toplantısının ilk yarısı zaten bu akışları süreç sahibinin ağzından çıkarmakla geçiyor.

Entegrasyonlar: teklifi en çok şişiren belirsizlik

Bir maddede "Ticimax ve muhasebe programıyla entegre olacak" yazıyorsa, o madde tek başına projenin yarısıdır. Karşı sistemin ne verdiğini bilmeden verilen süre tahmini tahmin bile sayılmaz. Şartnamede her entegrasyon için şu beş sorunun cevabı bulunmalı.

1. Hangi sistem, hangi sürüm: Bulut mu, kendi sunucunuzda mı, sürüm ve modül bilgisi ne.
2. API dokümanı var mı: Varsa şartname ekinde paylaşılır. Yoksa "dokümantasyon çıkarma" ayrı bir kalem olarak fiyatlanır.
3. Test ortamı verilecek mi: Canlıda deneme yapılmayacaksa test ortamını kim, ne zaman açacak.
4. Yetki ve anahtarları kim veriyor: API kullanıcısı işletmenin kendi sözleşmesinden mi çıkacak, bunu talep etmek kimin işi, ortalama ne kadar sürüyor.
5. Veri hangi yöne akıyor: Tek yönlü mü, çift yönlü mü. Çakışma olduğunda hangi sistem haklı sayılıyor.

Son madde en sık atlananı. İki sistemde de değişebilen bir alan varsa (fiyat, stok, sipariş durumu) hangi tarafın kazanacağı yazılmazsa, o alan canlıda sürekli birbirinin üzerine yazar. Bunun pratikte nasıl göründüğünü REST API entegrasyonu hataları yazısında örnekledik. İade Yönetim Paneli projesinde iade tutarının hangi kanaldan döneceği baştan tanımlıydı; tanımlı olmasaydı her iade ayrı bir karar konusuna dönerdi.

Kabul kriterleri: "çalışıyor" tam olarak ne demek?

Yazılım kabul kriterleri yazılmadığında teslim, ekran gösterme toplantısına dönüşür. Herkes memnun görünür, iki hafta sonra "bu böyle olmayacaktı" cümlesi gelir. Kabul kriteri her gereksinimin altına iki cümleyle yazılabilir: hangi girdiyle çalıştırılacak, hangi çıktı beklenecek.

Test verisini kim sağlayacak sorusu da netleşmeli. Gerçek veriden alınmış, kişisel bilgileri maskelenmiş birkaç yüz satır, hayali veriden kat kat değerli. Kataloğunuz kaç bin kalem olursa olsun, doğru seçilmiş 50 ürünlük gerçek bir örneklem çoğu hatayı yakalıyor: uzun isimli ürün, çok varyantlı model, barkodu olmayan kalem, negatif bakiyeye düşmüş stok.

• Kim onaylıyor: Her modül için tek bir isim. Komite onayı pratikte hiç kimsenin onayı demek.
• Kaç günde onaylanıyor: Teslimden sonra kaç iş günü içinde test edilip yazılı dönüş yapılacağı yazılır. Süre geçerse ne olacağı da yazılır.
• Hata mı, yeni istek mi: Kabul sırasında çıkan her madde ikiye ayrılır. Şartnamede yazan bir şey çalışmıyorsa hatadır ve bedelsiz düzeltilir. Şartnamede yoksa değişiklik talebidir.
• Kaç revizyon turu var: Arayüz için "iki tur revizyon, sonrası ayrı fiyat" gibi bir sınır, iki tarafı da rahatlatıyor.
• Gecikme iki taraflı yazılır: Test ortamı, API anahtarı, test verisi ve onay işletmeden geç gelirse takvimin nasıl kayacağı da maddeleşir. Projelerin çoğu koddan değil bekleyen bu kalemlerden gecikiyor.

Yazılım geliştirme sözleşmesi maddeleri arasına genelde bir de sessiz kabul hükmü giriyor: belirlenen süre içinde yazılı itiraz gelmezse teslim kabul edilmiş sayılır. Geliştiriciyi korur, işletmeyi de test etmeye zorlar.

Veri, kaynak kod ve ortamlar kimde kalıyor?

Bu bölüm şartnamenin en kısa, sözleşmenin en uzun kısmıdır. Bir yıl sonra firma değiştirmek isterseniz elinizde ne kalacağını belirleyen maddeler burada.

• Veri sahipliği: Verinin işletmeye ait olduğu ve talep hâlinde standart bir formatta (SQL yedeği, CSV) teslim edileceği yazılır. Kişisel veri içeren alanların nerede tutulacağı, test ve geliştirme ortamına maskelenmeden kopyalanıp kopyalanmayacağı ayrıca maddeleşir.
• Kaynak kod: Kod teslim edilecek mi, edilecekse hangi depoya. Kullanılan üçüncü parti lisanslar ayrıca listelenir.
• Sunucu ve ortamlar: Hosting kimin adına alınıyor, alan adı ve SSL sertifikası kimin hesabında, sunucu şifreleri nerede duruyor.
• Erişim yönetimi: Geliştiricinin canlı sunucuya erişimi proje sonrası devam edecek mi, devam edecekse hangi kapsamda.

Yedekleme kimin sorumluluğunda

"Yedek alınıyor" tek başına bir taahhüt değil. Yedeğin sıklığı, nerede tutulduğu, kaç gün saklandığı ve geri yükleme denemesini kimin yapacağı yazılmalı. Sunucu sizin hosting sağlayıcınızdaysa sorumluluk büyük ihtimalle sizde; yazılım firmasının uygulama içi yedeği ayrı konu. Bu ikisi karıştığı için veri kaybı yaşayan işletme az değil.

Teslim sonrası bakım ve değişiklik talebi

Garanti süresinin kapsamı net olmalı: yalnızca hata düzeltme mi, yeni geliştirme de dahil mi. Hata müdahale süresi için tek bir rakam yerine seviye tanımlamak daha gerçekçi. Sipariş akışını durduran bir hatayla rapordaki hizalama sorunu aynı aciliyette değil. Değişiklik talebi süreci de aynı yerde tanımlanır: talep nasıl iletilir, kim tahmin verir, onay olmadan iş başlar mı. Onay adımı yoksa küçük istekler faturasız birikir, sonra ilişki bozulur.

Teklifleri karşılaştırılabilir kılmak

Yazılım projesi teklif alma sürecinin son adımı, herkesten aynı formatta cevap istemek. Şartnamenin sonuna bir kalem listesi ekleyip "fiyatınızı bu satırlara dağıtın" demek yeterli. Toplamlar farklı çıksa bile satır bazında nerede ayrıştıkları görünür.

Adam-gün üzerinden kırılım isteme alışkanlığı yaygın ama karşılaştırma için zayıf. Bir firmanın 40 adam-günü diğerinin 25 adam-günüyle aynı işi çıkarabilir. Çıktı bazlı kırılım daha dürüst bir tablo veriyor.

Ödeme planını da bu satırlara bağlamak işe yarıyor. Takvime bağlanan ödeme, gecikmenin kimden kaynaklandığı tartışmasını her ay yeniden açıyor; kabul edilmiş çıktıya bağlanan ödeme o tartışmayı bir kez yapıp kapatıyor.

Yazılım şartnamesi örneği ararken, bu listenin hazır bir Word şablonundan çıkmasını beklemeyin. Şablonlar başlık verir, içeriği vermez; operasyonunuzu bilen tek taraf sizsiniz. En verimli yol, taslağı kendiniz yazdıktan sonra teklif isteyeceğiniz firmalarla kısa bir keşif görüşmesi yapmak. Biz de iletişim sayfasından gelen taleplerde önce bu turu yapıyoruz. Şartname bu turdan sonra genelde kısalıyor, çünkü ihtiyaç sanılan maddelerin bir kısmı mevcut sistemde zaten var oluyor.

Şartname yazmanın maliyeti birkaç gün. Yazmamanın maliyeti duruma göre değişir, ama hiçbir zaman birkaç gün değildir.

Bu konuda nasıl yardımcı oluyoruz?

Yuog Dev olarak e-ticaret işletmelerinin ERP, entegrasyon ve otomasyon altyapısını kuruyoruz. İhtiyaç analiziyle başlıyor, ölçülebilir hedefler koyuyor ve teslim sonrasında da destek veriyoruz. Süreçlerinizi konuşmak isterseniz iletişim sayfasından bize ulaşabilirsiniz.