Yazılım teklifi nasıl okunur? Kapsam, kaynak kod ve NDA

Bir yazılım teklifini okurken önce fiyata değil, kapsama bakın: neyin yapılacağı, neyin yapılmayacağı ve işin ne zaman “bitti” sayılacağı açıkça yazılı olmalı. Ardından kaynak kodun kime ait olacağını, gizlilik sözleşmesini (NDA), bakımı ve kapsam dışı taleplerin nasıl ele alınacağını kontrol edin. İki teklifi karşılaştırmanın doğru yolu, toplam rakamları değil, bu maddelerin ne kadar net olduğunu karşılaştırmaktır.

Biz fiyat listesiyle çalışmıyoruz. Her projede ilk görüşmeden sonra yazılı bir teklif veriyoruz. Bu yazıda, kendi tekliflerimizi hazırlarken de dikkat ettiğimiz maddeleri tek tek açıyoruz.

Neden aynı iş için çok farklı teklifler gelir?

Aynı brifle üç yazılım ekibinden teklif aldığınızda, rakamlar arasında büyük farklar görmek olağandır. Bunun nedeni çoğu zaman fiyatlandırma değil, anlaşılan iştir. Bir ekip “kullanıcı girişi” maddesini e-posta ve şifreyle sınırlı okur. Bir başkası şifre sıfırlama, iki adımlı doğrulama ve yönetici paneliyle birlikte. Teklif ne kadar belirsizse, bu farklar o kadar geç ortaya çıkar — genellikle de projenin ortasında.

Somut bir örnek verelim. Bir şirket, bayilerinin sipariş girebileceği bir panel için üç teklif alıyor. Birinci teklif tek satırlık bir özellik listesi ve toplam bir rakamdan oluşuyor. İkincisi ekranları sayıyor ama bayi yetkilerinden hiç söz etmiyor. Üçüncüsü ise her bayinin yalnızca kendi siparişlerini göreceğini, yöneticinin tümünü raporlayabileceğini, muhasebe aktarımının ikinci aşamada yapılacağını ve mevcut tablolardan veri aktarımının kapsam dışı olduğunu yazıyor. Üçüncü teklif en pahalısı gibi görünebilir. Ama aslında karşılaştırılabilir tek teklif odur; diğer ikisinin gerçek maliyeti, proje başladıktan sonra ortaya çıkacaktır.

Bu yüzden iyi bir teklif, rakamdan önce bir anlaşma belgesidir.

Kapsam: teklifin kalbi

Kapsam bölümü, teklifin en uzun ve en dikkatli okunması gereken kısmıdır.

Ne yapılacak?

Özellikler genel başlıklarla değil, kullanıcının ne yapabileceğiyle tarif edilmeli. “Raporlama modülü” yerine “Yönetici, seçtiği tarih aralığında satışları müşteri ve ürün bazında görüp Excel olarak indirebilir” gibi.

Ne yapılmayacak?

İyi teklifler kapsam dışını da yazar. Örneğin: “İkinci dil desteği bu teklife dahil değildir” ya da “Mevcut eski sistemden veri aktarımı ayrıca değerlendirilecektir.” Bu satırlar, ileride yaşanacak “bunun da dahil olduğunu düşünmüştük” tartışmalarını önler.

Ne zaman “bitti” sayılır?

Her teslimat için bir kabul ölçütü olmalı. İş tamamlandığında neyin test edileceği ve kimin onaylayacağı belli olmalı. Ölçüt yoksa, iş hiçbir zaman tam anlamıyla bitmez.

Belirsiz ifade	Netleştirilmiş ifade
”Mobil uyumlu"	"Telefon ve tablet ekranlarında, belirtilen tarayıcılarda test edilir"
"Admin paneli"	"Kayıt ekleme, düzenleme, silme ve rol bazlı erişim içerir"
"Entegrasyonlar"	"Belirtilen muhasebe sistemine sipariş aktarımı"
"Hızlı"	"Belirlenen performans hedefleri, belirtilen araçla ölçülür”

Teslimatlar ve aşamalar

Büyük bir projeyi tek bir teslim tarihine bağlamak risklidir. Teklifte işin aşamalara bölünüp bölünmediğine bakın. Biz işe en çok yükü kaldıracak parçadan başlıyoruz; her teslimde elinizde çalışan bir parça oluyor. Böylece hem ilerlemeyi somut olarak görürsünüz hem de yön değiştirmek gerekirse bunu erkenden yapabilirsiniz.

Teklifte şunları arayın:

• Aşamalar ve her aşamada teslim edilecekler
• Her aşamanın nasıl gösterileceği (test sürümü, canlı önizleme, demo)
• Ödemelerin bu aşamalara nasıl bağlandığı
• Sizden beklenenler: içerik, görsel, erişim bilgileri, onay süreleri

Son madde sık atlanır. Projeler yalnızca geliştirici yüzünden değil, müşteri tarafında bekleyen kararlar yüzünden de uzar. İyi bir teklif bunu da yazar.

Kaynak kod ve fikri mülkiyet

Bu madde, imzadan önce mutlaka netleşmesi gerekenlerin başında gelir.

Kaynak kod kime ait olacak?

Bazı ekipler yazılımı yalnızca kullanım hakkıyla verir; kod onlarda kalır. Bazıları teslimde kodu tümüyle devreder. İkisi de meşru modellerdir, ama farklı sonuçları vardır. Kod sizde değilse, ileride başka bir ekiple çalışmak ya da yazılımı büyütmek zorlaşabilir.

Biz, istenirse kaynak kodu teslimde müşteriye devrediyoruz. Teklifte bunun açıkça yazılmasını öneririz.

Devirde neler teslim edilir?

“Kaynak kod devri” bir dosya klasörü göndermekten ibaret olmamalı. Şunları sorun:

• Kod, sizin erişebildiğiniz bir sürüm kontrol deposunda mı?
• Kurulum ve yayın adımları yazılı mı?
• Sunucu, alan adı, mağaza hesapları gibi erişimler kimin adına?
• Kullanılan üçüncü taraf hizmetler ve lisanslar listelenmiş mi?

Mobil uygulamalarda mağaza hesaplarının sizin adınıza açılması, web projelerinde alan adının sizin adınıza kayıtlı olması da aynı sorunun parçasıdır. Mobil tarafı App Store’a uygulama yükleme yazımızda ayrıca anlattık.

Gizlilik sözleşmesi (NDA)

Fikrinizi, iş verilerinizi ya da müşteri bilgilerinizi bir yazılım ekibiyle paylaşmadan önce bir gizlilik sözleşmesi istemek son derece olağandır. NDA’nın kapsamına bakarken şunlara dikkat edin:

• Hangi bilgilerin gizli sayıldığı
• Gizlilik yükümlülüğünün süresi
• Proje bittiğinde verilerin iade ya da imha edilmesi
• Ekibin, işi kendi portfolyosunda gösterip gösteremeyeceği

Son madde iki taraf için de önemlidir. Bazı projeler portfolyoda isim vermeden, bazıları hiç gösterilmez. Bunu baştan konuşmak, sonradan doğabilecek rahatsızlığı önler. Biz istenirse NDA imzalıyoruz ve bu konuşmayı ilk görüşmede yapıyoruz.

Bakım, destek ve değişiklik talepleri

Yazılım teslim edildiği gün bitmez. İşletim sistemleri, tarayıcılar ve bağlı olunan platformlar sürekli değişir. Teklifte şunlar yer almalı:

• Teslim sonrası hata düzeltme dönemi. Teslimden sonra ortaya çıkan hatalar hangi süre içinde, hangi koşullarla düzeltilecek?
• Bakım modeli. Aylık bakım var mı, neleri kapsıyor? Güvenlik güncellemeleri, uyum çalışmaları, küçük geliştirmeler?
• Yanıt süresi. Bir sorun bildirildiğinde ne kadar sürede dönüş yapılıyor? Biz en geç iki iş günü içinde yanıt veriyoruz.

“Hata” ile “yeni istek” arasındaki ayrımın tanımlanması da önemlidir. Kapsamda yazan bir özelliğin çalışmaması hatadır. Kapsamda olmayan bir özelliğin istenmesi ise yeni bir taleptir.

Değişiklik talepleri

Hiçbir proje, başladığı gibi bitmez. Kullanıcıları gördükçe yeni ihtiyaçlar çıkar. Bu doğaldır. Önemli olan, değişikliğin nasıl ele alınacağının baştan belli olmasıdır:

1. Talep yazılı olarak iletilir.
2. Ekip, talebin kapsama, takvime ve maliyete etkisini yazılı olarak bildirir.
3. Siz onay verdikten sonra iş planına eklenir.

Bu süreç tanımlı değilse, küçük talepler birikir ve proje sessizce büyür. Kimse bunu fark etmez — ta ki takvim kayana kadar.

Teklifi okurken sorulacak sorular

İmzadan önce kendinize ve ekibe şu soruları sorun:

• Kapsamda olmayan ama benim dahil sandığım bir şey var mı?
• Her aşamanın sonunda elimde ne olacak?
• Kaynak kod ve tüm erişimler kimde kalacak?
• Proje bittikten sonra bir sorun çıkarsa kime, nasıl ulaşacağım?
• Yeni bir istek geldiğinde süreç nasıl işleyecek?

Bu sorulara teklifin içinde cevap bulamıyorsanız, sormaktan çekinmeyin. Cevapları yazılı olarak almak, herkesi korur. Teklif aşamasına gelmeden önce hazır bir ürünün işinizi görüp görmeyeceğini düşünmek isterseniz, hazır yazılım mı, özel yazılım mı yazımız iyi bir başlangıç olabilir.

Sık sorulan sorular

En ucuz teklifi seçmek mantıklı mı?

Ancak kapsamlar gerçekten eşitse. Çoğu zaman düşük teklif, daha dar bir kapsamı, belirsiz kabul ölçütlerini ya da bakımın hariç tutulmasını yansıtır. Teklifleri karşılaştırırken önce kapsamları yan yana koyun.

Kaynak kod devri neden önemli?

Kod sizdeyse, yazılımı istediğiniz ekiple geliştirmeye devam edebilir, başka bir sunucuya taşıyabilir ya da şirketinizin bir varlığı olarak değerlendirebilirsiniz. Kod sizde değilse, her değişiklik için ilk ekibe bağlı kalırsınız.

NDA’yı ilk görüşmeden önce mi imzalamalıyız?

Paylaşacağınız bilgi hassassa, evet. Genel bir fikri konuşmak için çoğu zaman gerekmez; ama iş verilerinizi, müşteri listelerinizi ya da henüz duyurulmamış bir ürünü paylaşacaksanız, NDA’yı önce imzalamak iyi bir alışkanlıktır.

Teklifte süre garantisi olmalı mı?

Teklifte aşamalar ve tahmini bir takvim olmalı. Ancak takvimin iki tarafın da sorumluluklarına bağlı olduğu açıkça yazılmalı: onayların, içeriklerin ve erişimlerin zamanında gelmesi de takvimin parçasıdır.

Bir yazılım projesi için teklif almayı düşünüyorsanız, nasıl çalıştığımızı özel yazılım ve SaaS sayfamızda bulabilir ya da bize yazabilirsiniz. İlk görüşmeden sonra kapsamı yazılı bir teklifle netleştiriyoruz.