Yazılım teklifi nasıl okunur? 12 kırmızı bayrak ve kopyalanabilir kapsam (SOW) şablonu

Teklif, kapsam belgesi (SOW) ve sözleşme: üçü aynı şey değil

Bir yazılım işinde üç belge sık sık tek bir PDF'in içinde birbirine karışır. Karşılaştırmadan önce ayırmak gerekir.

• Teklif, satıcının bir işi hangi fiyata ve hangi koşullarla yapmayı önerdiğini anlatan belgedir.
• Kapsam belgesi (SOW, Statement of Work) işin ne olduğunu, neyle teslim edileceğini, neyle kabul edileceğini ve ne zaman yapılacağını yazan belgedir. Proje yönetiminde SOW, bir projenin iş gereksiniminin anlatısal tarifi olarak tanımlanır; tipik bir SOW amaç, kapsam, teslimat takvimi, kabul ölçütleri ve ödeme planını içerir (Wikipedia).
• Sözleşme, tarafların haklarını ve yükümlülüklerini bağlayan hukuki metindir.

Tek sayfalık, altında bir fiyat olan bir PDF yalnızca tekliftir. Kapsamın yalnızca konuşmada kaldığı projelerde sorun çıkması kolaylaşır: herkes aynı cümleyi duyar ama farklı bir ürün hayal eder, fark ilk gösterimde ortaya çıkar. Özel yazılım geliştirme sayfamızda anlattığımız yaklaşım da buna dayanır: kapsam, takvim ve maliyet iş başlamadan yazıya dökülür. Bu yazı, bir yazılım teklifini okumayı anlatıyor: neye bakacağınızı, teklifleri nasıl karşılaştıracağınızı ve elinize geçen kapsam belgesinin nasıl görünmesi gerektiğini. Sonda kopyalanabilir bir şablon ve kapsam belgesine çevrilmiş tek satırlık bir yazılım fiyat teklifi örneği de var.

Teklifi hangi sırayla okumalı?

Çoğumuz bir teklifi fiyattan başlayarak okur. Tersini öneriyoruz: fiyat en sonda okunur, çünkü neyin fiyatı olduğunu bilmeden fiyat bir şey anlatmaz.

1. Önce kapsam dışını arayın. Yazılı bir "yapılmayacaklar" listesi, kapsamı düşünmüş bir teklifin en güvenilir işaretidir. Yoksa "dahil" sandığınız şeylerin bir kısmı ek fatura çıkabilir.
2. Kabul ölçütüne bakın. Her teslim için "tamam"ın nasıl anlaşılacağı yazılı mı?
3. Ödeme planını teslimlerle eşleştirin. Her ödemenin yanına hangi teslime bağlı olduğunu yazın; eşleşmeyen satırları işaretleyin.
4. Hesap ve mülkiyet maddelerini bulun. Teklifte yoksa "yok" diye not alın; yokluk da bir bilgidir.
5. Boşlukları soruya çevirin. Aşağıdaki kırmızı bayrak tablosunun son sütunu hazır bir soru listesidir. Yanıtları yazılı isteyin: telefonla ya da sohbette verilen bir yanıt teklifin yazılı metninde yer almaz ve ileride kanıtlamak zor olabilir; dayanmak istediğiniz her yanıtı yazılı alın.
6. En son fiyata bakın ve karşılaştırma tablosunu doldurun.

Okurken küçük bir alışkanlık da işe yarar: tekliflerdeki sayıları ve tarihleri ayrı bir yere çıkarın. Aynı tutarın bir yerde "tahmini", başka yerde "kesin" diye geçmesi, kalemlerin toplamının genel toplamla tutmaması ya da bir tarihin iki yerde farklı yazılması da yazılı sorulacak sorulardır; çoğu zaman kötü niyetin değil, aceleyle hazırlanmış bir belgenin işaretidir.

Yazılım teklifinde olması gereken on bölüm

Aşağıdaki tablo, bir yazılım teklifinin (ya da ekindeki kapsam belgesinin) yanıtlaması gereken on bölümü ve her birinin eksikliğinde ne olduğunu gösteriyor. Bölümlerin çoğu tipik bir SOW'un içeriğiyle örtüşür; "değişiklik yönetimi" ve "hesap sahipliği" gibi yazılıma özgü olanlar eklenmiştir.

Tablodaki on bölüm bir teklifi okurken, aşağıdaki şablonun on iki başlığı ise kapsam belgesini yazarken işe yarar. İlk dokuz bölüm şablonda aynı sırayla yer alır; tablodaki onuncu bölüm şablonda üç başlığa ayrılır: fikri mülkiyet ve kaynak kod devri, hata düzeltme ile destek ve bakım, gizlilik ile fesih ve devir yardımı.

Kabul ölçütüne dair bir not: yazılım dünyasında "yapıldı" ile "bitti" farklı şeylerdir. Scrum Kılavuzu'nun "Done tanımı", bir artışın gereken kalite ölçütlerini karşıladığı durumun biçimsel tarifidir (Scrum Kılavuzu 2020). Teklifte bunun karşılığı, her teslimat için önceden yazılmış, sınanabilir bir kabul ölçütüdür.

12 kırmızı bayrak

Kırmızı bayrak, teklif sahibinin kötü niyetli olduğunu göstermez; çoğu zaman yazılmamış bir varsayımın işaretidir. Tabloyu bir soru listesi olarak kullanın: her satırdaki soruyu teklif sahibine yazılı sorun ve yanıtı yazılı alın.

Referans konusunda bir ayrıntı: gizlilik sözleşmeleri nedeniyle bazı stüdyolar müşteri adı veremez. Bu durumda ad yerine canlı bir demo, ekran görüntüsü ya da kararların gerekçesini anlatan bir mühendislik notu istemek makul ve doğrulanabilir bir alternatiftir.

Daha önce bir ekip projeyi yarıda bıraktıysa, devralmadan önce yapılacak denetim için yarım kalmış yazılım projesi devralma yazısına bakın.

Teklifleri yan yana karşılaştırma

Üç teklifi yalnızca toplam fiyata göre karşılaştırmak, üç farklı işin fiyatını karşılaştırmaktır. Önce aynı kapsamı varsayın, sonra her teklifin aşağıdaki soruları nasıl yanıtladığına bakın. Her hücreye üç etiketten birini yazın: yazılı (tekliften alıntılayabiliyorsunuz), sözlü (söylendi ama yazılı değil) ya da yok. "Sözlü" ve "yok" sayısı, fiyat farkından daha çok şey söyler.

Fiyat satırının en altta olması bilerek yapılmıştır. Önce neyi satın aldığınızı, sonra ne kadara aldığınızı karşılaştırın. En düşük fiyatlı teklifin aynı zamanda en çok "yok" içeren teklif olup olmadığına bakın: fiyat farkı, kapsam farkından gelebilir.

Mobil uygulama teklifleri için kalem kalem bir model ve boş bir karşılaştırma tablosu mobil uygulama maliyeti yazısında.

Sabit fiyat, zaman-malzeme, hibrit: ne zaman hangisi?

Teklifin fiyatı üç biçimden birinde gelir. Üçünün de doğru olduğu durum vardır; sorun, modelin işin belirsizliğine uymamasıdır.

Belirsizliğin en çok olduğu yer işin başıdır; bu yüzden birçok proje önce kapsamı netleştiren küçük bir aşamayla başlar. Hangi modelle çalışırsanız çalışın, kapsam değiştiğinde ne olacağı teklifte yazılı olmalıdır.

Kapsam belgesi (SOW) şablonu

Aşağıdaki iskelet, bir yazılım fiyat teklifine ek olarak isteyebileceğiniz kapsam belgesinin örneğidir: kopyalayıp köşeli parantezleri doldurun ve teklif sahibine "bu başlıkların her birinin yanıtını teklifinizde görmek istiyorum" diyerek verin. Örnek maddeler fikir vermek içindir.

Aynı şablonu, her yanıt için yazma alanı bırakılmış yazdırılabilir PDF ve köşeli parantezleri vurgulanmış düzenlenebilir Word dosyası olarak da indirebilirsiniz.

1. Amaç ve başarı ölçütleri. "Bu proje [çözülecek sorun] için yapılır. Başarı, [ölçülebilir ölçüt] sağlandığında kabul edilir (örneğin: müşteri, sipariş formunu yardım almadan tamamlayabiliyor)."
2. Kapsam içi. "Aşağıdaki işlevler kapsamdadır: [işlev listesi, ekran listesi, entegrasyon adları]. Listede olmayan işlev kapsam dışıdır."
3. Kapsam dışı. "Şunlar açıkça kapsam dışıdır: [örneğin ikinci platform, çoklu dil, eski veriyi taşıma]. Bunlardan biri istenirse 7. madde işler."
4. Teslimatlar ve kabul ölçütleri. "Teslimatlar: [kaynak kod, çalışan sürüm, belge]. Her teslimat için kabul ölçütü yazılıdır: [ölçüt]. Alıcı, teslimden sonra [süre] içinde teslimatı yazılı olarak kabul eder ya da gerekçesiyle reddeder; yanıt verilmemesinin sonucu [taraflarca belirlenen sonuç]."
5. Takvim ve kilometre taşları. "İş [sayı] kilometre taşına bölünmüştür: [kilometre taşı adı ve tarihi]. Her kilometre taşında alıcı çalışan bir sürümü görür."
6. Fiyat ve kilometre taşına bağlı ödeme planı. "Toplam bedel [tutar] [KDV dahil ya da hariç]. Ödemeler kilometre taşlarına bağlıdır: [ödeme ve kilometre taşı eşlemesi]. Kapsam değişmedikçe bedel değişmez."
7. Değişiklik yönetimi. "Kapsam değişikliği yazılı bir değişiklik talebiyle istenir. Yüklenici talebin fiyat ve takvime etkisini [süre] içinde yazılı bildirir; iki taraf yazılı onay vermeden uygulanmaz."
8. Roller, iletişim ve karar süreleri. "Alıcı tarafında karar veren: [ad]. Yüklenici tarafında kodu yazan mühendis: [ad]. Sorulara yanıt süresi: [süre]. Süresinde verilmeyen karar takvime etki edebilir."
9. Altyapı, hesap ve erişim sahipliği. "Alan adı, barındırma, depolama, mağaza ve üçüncü taraf hesapları [alıcının ya da yüklenicinin] adına açılır. Yüklenici tarafından yönetilen her hesabın alıcıya devri [yöntem] ile yapılır."
10. Fikri mülkiyet ve kaynak kod devri. "Teslim edilen işe ilişkin [devredilen haklar, tek tek sayılarak], [koşul, örneğin bedelin tamamının ödenmesi] halinde alıcıya geçer. Yüklenicinin projeden önce var olan araç ve kütüphaneleri yüklenicide kalır; alıcıya bunlar için [kullanım hakkı] verilir."
11. Hata düzeltme, destek ve bakım. "Yayından sonra [süre] boyunca [hata türü] ücretsiz düzeltilir. Bunun ötesindeki destek [kapsam ve ücretlendirme] ile ayrı bir yazılı ek belgeyle belirlenir."
12. Gizlilik, fesih ve devir yardımı. "Taraflar paylaşılan bilgiyi gizli tutar. Sözleşme [koşul] halinde feshedilebilir; fesihte yüklenici, o güne kadar üretilen işi, kodu ve belgeleri [süre] içinde teslim eder ve devir için [kapsam] yardım sağlar."

Teslim edilecek şey yapay zekayla üretilmiş bir prototipin üretime taşınmasıysa, 4. maddedeki kabul ölçütleri için üretime hazırlık denetiminin "geçti" ölçütlerinden yararlanabilirsiniz.

Bu şablon hukuki bir metin değildir. Bağlayıcı bir sözleşme için bir avukata hazırlatın ya da okutun.

Yazılım fiyat teklifi örneği: tek satırlık kapsamı kapsam belgesine çevirmek

Kurgusal bir örnek (rakam ve müşteri adı yok): teklifte yalnızca şu satır ve altında tek bir toplam fiyat var: "Rezervasyon sistemi geliştirilecektir." Aynı satır kapsam belgesine çevrilince her biri yazılı yanıt isteyen sorular ortaya çıkar. Rezervasyon senaryosunun gerçek bir sistemdeki karşılığı için Rezervasyon Platformu vakamıza bakabilirsiniz.

Tek satırlık bir cümlenin dört satırlık bir tabloya dönüşmesi, kapsam belgesinin yaptığı işin kendisidir.

Teklif, sözleşme ve avukat

Teklif ve SOW, işin ne olduğunu ve nasıl kabul edileceğini anlatır; hukuki sonuçları ise sözleşme düzenler. İkisinin birbiriyle çelişmemesi gerekir; çelişirse hangisinin üstün olduğu sözleşmede yazmalıdır.

Bir avukata okutmanız gereken kısımlar şunlardır. Hak devri: 5846 sayılı Fikir ve Sanat Eserleri Kanunu'nun 52. maddesi, mali haklara dair sözleşme ve tasarrufların yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşuyor (mevzuat.gov.tr); "kaynak kod sizindir" tek cümlesinin bu şartı karşılayıp karşılamadığı bir hukuk sorusudur. Kişisel veri: 6698 sayılı Kanun'un 12. maddesine göre, veri sorumlusuysanız ve kişisel veriler sizin adınıza başka biri tarafından işleniyorsa, tedbirlerin alınmasında onunla birlikte sorumlusunuzdur (mevzuat.gov.tr); yazılım evi kullanıcı verinizi barındıracaksa bunun sözleşmede nasıl yazılacağı bir avukatla netleşmeli. Sorumluluk sınırı, fesih ve gizlilik de aynı gruptadır.

Bu yazı hukuki danışmanlık değildir.

Biz bunu nasıl yapıyoruz

Burada yalnızca sitemizde yazdığımızı tekrarlıyoruz:

• İşe başlamadan önce ne yapılacağı, hangi sırayla ve ne kadara olacağı yazıya dökülür; siz onaylamadan iş başlamaz ve kapsam yazılı olarak onaylandıktan sonra fiyat değişmez.
• Ödemeler teklifte belirlenen takvimle ilerler.
• Teslim edilen işin mülkiyeti, proje bedelinin tamamı ödendiğinde size geçer; projeden önce var olan kendi araçlarımız, kütüphanelerimiz ve altyapılarımız bizde kalır.
• Siz aksini tercih etmedikçe barındırma, alan adı, depolama ve dağıtım hattını biz kurar ve yönetiriz; kendi hesaplarınız varsa dağıtımı oraya yaparız. Bir gün taşımak isterseniz hesaplar, alan adları ve dokümantasyonla birlikte temiz bir devir için yanınızda oluruz.
• Kodunuzu yazan mühendisle doğrudan konuşursunuz.
• Geliştirme başladığında hesabınızda durumu, teklifleri ve ödemeleri gösteren canlı bir proje paneli açılır.

Ayrıntılar Süreç ve Kullanım Koşulları sayfalarında. Elinizde karşılaştırılacak bir teklif ya da başlatmak istediğiniz bir iş varsa özel yazılım geliştirme sayfamıza bakabilir ya da projenizi anlatabilirsiniz.

Yukarıdaki şablon bizim sözleşmemizin metni değildir; bağlayıcı olan, işiniz için imzalanan yazılı sözleşmedir.

Sık sorulan sorular

SOW nedir, tekliften farkı nedir?

SOW (Statement of Work, kapsam belgesi), işin ne olduğunu, neyle teslim edileceğini, neyle kabul edileceğini ve ne zaman yapılacağını anlatan belgedir. Teklif ise fiyatı ve koşulları önerir. Tek sayfalık bir teklif, SOW'un yerini tutmaz; iyi bir teklif ya SOW'u içerir ya da ona atıf yapar.

Sabit fiyatlı teklifte değişiklik istersem ne olur?

Bu, tekliften önce sorulması gereken sorudur. İyi kurgulanmış bir teklifte değişiklik yönetimi yazılıdır: değişiklik talebinin fiyat ve takvim etkisi yazılı bildirilir ve siz onaylamadan uygulanmaz. Bizde kapsam yazılı onaylandıktan sonra fiyat değişmez.

Kaynak kod ne zaman benim olur?

Sitemizde yazdığımız gibi, teslim edilen işin mülkiyeti proje bedelinin tamamı ödendiğinde size geçer; projeden önce var olan kendi araçlarımız, kütüphanelerimiz ve altyapılarımız bizde kalır. Bağlayıcı olan, imzalanan yazılı sözleşmedir. Başka bir yazılım evinden teklif alıyorsanız aynı soruyu yazılı sorun.

Ödeme planı nasıl olmalı?

Ödemeler, çalışan ve kabul edilebilir bir teslime ya da kilometre taşına bağlanmalıdır; hangi ödemenin hangi teslime bağlı olduğu yazılı olmalıdır. Uygun oranlar projeye göre değiştiği için bir yüzde önermiyoruz. Teslimle ilgisiz bir ödeme, tablodaki altıncı kırmızı bayraktır.

Teklifi kim hazırlıyor?

Bunu teklif sahibine sorun: teklifi hazırlayanla işi yapan aynı kişiler mi? Sitemizde yazdığımız ilke, kodunuzu yazan mühendisle doğrudan konuşmanızdır; araya talepleri aktaran bir hesap yöneticisi girmez.

Kaynaklar

Aşağıdaki sayfalar 24 Ekim 2026'da açılıp okundu.

• Statement of work, Wikipedia · Scrum Kılavuzu 2020
• 5846 sayılı Fikir ve Sanat Eserleri Kanunu, mevzuat.gov.tr · 6698 sayılı Kişisel Verilerin Korunması Kanunu, mevzuat.gov.tr

Bu yazı genel bilgi içindir; hukuki danışmanlık değildir.