Teklif istemeden önce neyi netleştirmelisiniz?
Firmalarla konuşmadan önce ayıracağınız bir iki gün, gelen teklifleri karşılaştırılabilir kılar. Herkese aynı bilgiyi verirseniz farklar fiyattan değil, yaklaşımdan çıkar.
Teklif öncesi kontrol listesi
- Problem: bugün neyin, kimin için ve hangi maliyetle aksadığı bir paragrafta yazılı.
- Kullanıcılar: ürünü kullanacak roller ve her rolde kabaca kaç kişi olduğu belli.
- Sistemler: bağlanılması gereken ERP, muhasebe yazılımı ve tablolar listelendi.
- Başarı ölçütü: canlıya çıktıktan sonra neyin değişmesi gerektiği ölçülebilir biçimde yazıldı.
- Kısıtlar: değişmeyecek tarihler, KVKK ve güvenlik gereklilikleri, verinin nerede tutulacağı belli.
- Bütçe aralığı: üst sınır ve bütçe dönemi şirket içinde konuşuldu.
- Karar süreci: kararı kimin vereceği ve projeyi günlük olarak kimin yürüteceği belirlendi.
Bu bilgileri bir sayfalık bir proje briefinde toplayın ve her firmaya aynı metni gönderin; bunun için proje briefi aracımızı kullanabilirsiniz. Bütçe aralığını paylaşmak, firmaların bu bütçeye sığan gerçekçi bir kapsam önermesini kolaylaştırır.
Yazılım projesi ihtiyaç listesi nasıl hazırlanır?
İhtiyaç listesi ekran adlarından önce kullanıcıyı, işlemi ve kabul ölçütünü anlatmalıdır. Her maddeye bir öncelik ve karar verecek kişi ekleyin. Bilinmeyen bir entegrasyonu kesin gereksinim gibi yazmak yerine açık soru olarak işaretleyin.
Varsayımsal örnek: Bir distribütörün ilk sürüm için hazırladığı aşağıdaki liste teklifleri aynı kapsamda karşılaştırmayı sağlar. Rakamlar müşteri sonucu veya fiyat değildir; test koşuludur.
| İhtiyaç | Kabul ölçütü | Öncelik ve sorumlu |
|---|---|---|
| Bayi kendi fiyatını görsün | İki farklı bayi hesabıyla aynı ürün açıldığında her biri yalnız kendisine tanımlı fiyatı görür. | İlk sürüm · Satış yönetimi |
| Sipariş ERP’ye aktarılsın | Aynı iş kimliği ikinci kez gönderildiğinde tek sipariş oluşur; ERP kapalıysa kullanıcı bekleyen durumu görür. | İlk sürüm · BT ve operasyon |
| Cari özet gösterilsin | Toplam, veri tarihiyle birlikte gösterilir; muhasebe belirlenen örnek kayıtlarla ERP sonucunu karşılaştırır. | İlk sürüm · Muhasebe |
| Mağazadan uygulama indirilsin | Barkod veya çevrimdışı işlem ihtiyacı kanıtlanana kadar mobil uyumlu web kullanılır. | Sonraki aşama · Ürün sahibi |
Listeye ayrıca kaynak veri ve aktarım yönünü, mevcut erişimleri, taşınacak kayıtları, destek sorumlusunu, bütçe sınırını ve değişmeyecek tarihleri ekleyin. Hazırlığa proje briefi aracıyla başlayabilir; listeyi özel yazılım geliştirme görüşmesinde kapsam ve varsayım listesine dönüştürebilirsiniz.
Freelancer, ajans, stüdyo, entegratör ya da iç ekip?
“Yazılım firması” tek bir tür değildir. Doğru seçenek, işin büyüklüğüne ve yazılımın şirketiniz için ne kadar kalıcı bir yetkinlik olacağına bağlıdır.
| Seçenek | Ne zaman uygun? | Neye dikkat edin? |
|---|---|---|
| Serbest geliştirici | Kapsamı net, küçük ve tek uzmanlık isteyen işler | Tek kişiye bağımlılık; tasarım, test ve sürekliliği kimin üstleneceği |
| Dijital ajans | Web sitesi, kampanya ve tanıtım ağırlıklı işler | İş kuralı ve entegrasyon yoğun projelerde mühendislik derinliği |
| Ürün ve yazılım stüdyosu | Strateji, tasarım ve mühendisliğin birlikte gerektiği ürünler ve operasyon platformları | Kapasite; projeye gerçekte kimlerin ayrılacağı |
| Büyük entegratör | ERP kurulumu, çok ülkeli ve çok tedarikçili programlar | Satışta görüştüğünüz ekiple projede çalışan ekibin farkı |
| İç ekip | Yazılımın yıllarca geliştirilecek temel bir yetkinlik olduğu durumlar | İşe alım süresi; ilk sürümü dış destekle yapıp ekibi sonra kurmak da bir seçenek |
Bazen doğru cevap bir firma seçmek değil, hazır bir ürün kullanmaktır. Muhasebe, bordro ya da standart bir CRM ihtiyacını çoğu zaman hazır yazılım daha hızlı ve daha az riskle karşılar. Özel geliştirme, iş akışınız hazır ürünlere sığmadığında anlam kazanır.
Görüşmede sorulacak 24 soru
Her ölçütü sunumla değil, kanıtla doğrulayın: örnek bir belge, gerçek bir depo, ekipteki kişilerle bir görüşme. Sorular altı başlıkta toplanıyor; her başlığın altında iyi bir cevabın ve kırmızı bayrağın nasıl göründüğü var. Görüşmeye ürünü her gün kullanacak bir çalışanınızı da alın; firmanın onu nasıl dinlediği, keşif yaklaşımı hakkında çok şey söyler.
Keşif ve kapsam
- İlk sürümün kapsamını nasıl belirliyorsunuz?
- Süre ve fiyatı hangi bilgiye dayanarak veriyorsunuz?
- Teklifinizdeki varsayımlar ve kapsam dışı işler neler?
- Kapsam değişirse süre ve bedel nasıl güncellenir?
İyi cevap: kullanıcı görüşmesine ve süreç gözlemine dayanan kısa bir keşif sprinti önerir; tahmini aralık olarak verir ve aralığı neyin daraltacağını söyler.
Kırmızı bayrak: sistemlerinizi görmeden, ilk toplantının ardından verilen kesin süre ve kesin fiyat.
Ekip
- Projede kimler, haftada ne kadar zamanla çalışacak?
- Bu görüşmedeki kişilerden hangileri projede olacak?
- Ekipten biri ayrılırsa bilgi nasıl devredilir?
- Alt yüklenici kullanıyor musunuz, hangi işlerde?
İyi cevap: isim ve rol bazında bir ekip ve bu kişilerle görüşme imkânı.
Kırmızı bayrak: “İhtiyaca göre kaynak atarız.”
Çalışma ritmi
- Çalışan yazılımı ne sıklıkla göreceğiz?
- Önceliklere kim, hangi toplantıda karar veriyor?
- İlerlemeyi ve riskleri nasıl raporluyorsunuz?
- Bizim taraftan haftada ne kadar zaman bekliyorsunuz?
İyi cevap: kısa sprintler, her hafta ya da iki haftada bir canlı demo, herkesin görebildiği bir iş listesi.
Kırmızı bayrak: aylarca süren ve sonunda tek seferde yapılan bir teslim.
Kalite, güvenlik ve KVKK
- Hangi testleri yazıyorsunuz, kod incelemesi nasıl yapılıyor?
- Kişisel veriyi nasıl koruyorsunuz, veri nerede tutulacak?
- Yetkilendirme ve erişim kayıtları ilk sürümde var mı?
- Bir güvenlik açığı bulunursa süreç nasıl işliyor?
İyi cevap: test ve güvenlik işlerinin planda ve teklifte ayrı kalem olarak yer alması.
Kırmızı bayrak: “Testler en sonda yapılır.”
Kod, devir ve destek
- Kod deposu, alan adı ve bulut hesapları kimin adına açılacak?
- Depoya ilk günden erişimimiz olacak mı?
- Proje sonunda hangi belgeler teslim edilecek?
- Canlıya çıktıktan sonra destek hangi kapsamda ve hangi sürelerle verilecek?
İyi cevap: hesapların sizin adınıza açılması, depoya ilk günden erişim, kurulumu ve mimariyi anlatan belgeler, yazılı müdahale süreleri.
Kırmızı bayrak: kodun ancak son ödemeden sonra gösterilmesi.
Referans ve benzer iş
- Benzer bir problemi nasıl çözerdiniz?
- Görüşebileceğimiz eski müşterileriniz var mı?
- İnceleyebileceğimiz bir ürün, tasarım ya da kod örneğiniz var mı?
- Bu projedeki en büyük risk sizce ne?
İyi cevap: referans varsa doğrudan görüştürmek; yoksa bunu açıkça söyleyip riski sınırlayan bir başlangıç önermek.
Kırmızı bayrak: doğrulanamayan logo listeleri ve “Bu projede risk görmüyoruz.”
Teklifler nasıl karşılaştırılır?
Teklifleri yan yana koymadan önce aynı işi fiyatlayıp fiyatlamadıklarına bakın. Toplam bedel ancak kapsam ve varsayımlar eşitlendikten sonra anlam kazanır.
| Başlık | Neye bakın? |
|---|---|
| Kapsam | İlk sürümde hangi kullanıcı akışları ve modüller var; aynı ekranlar mı sayılmış? |
| Varsayımlar | Entegrasyon, veri kalitesi ve sizden beklenen katkı yazılı mı? |
| Kapsam dışı | Neyin yapılmayacağı açıkça listelenmiş mi? |
| Ekip | Roller, kıdem ve kişi başına ayrılan zaman belli mi? |
| Takvim | Kesin tarih mi, aralık mı; aralığı neyin daraltacağı söylenmiş mi? |
| Kabul ölçütü | Bir işin bittiğine hangi testle ve kim karar veriyor? |
| Fiyat modeli | Sabit bedel, aşamalı sabit bedel ya da zaman ve malzeme: kapsam değişince ne oluyor? |
| Teslim ve destek | Kod, belgeler, garanti süresi ve canlı sonrası destek fiyata dahil mi? |
Varsayımsal bir örnek: Bir distribütör, bayilerinin sipariş verebileceği bir portal için üç teklif alıyor. A en düşük fiyatlı ve en kısa takvimli; ancak ERP entegrasyonunu “müşterinin sağlayacağı hazır API” varsayımıyla kapsam dışında bırakmış. B en yüksek fiyatlı; iki haftalık bir keşifle başlıyor, entegrasyonu kapsıyor ve ilk sürüm için bir aralık veriyor. C sabit fiyatlı ve kapsamı geniş görünüyor, ama kapsam dışı listesi yok ve kod proje sonunda teslim ediliyor.
Tabloya döküldüğünde A ile B’nin aynı işi fiyatlamadığı görülür: belirsizliğin en yüksek olduğu kalem olan ERP bağlantısı A’da size bırakılmıştır. C’nin sabit fiyatı ise her değişiklikte yeniden pazarlığa açılacak bir kapsamı gizler. En doğru adım, üç firmadan aynı varsayım listesine göre güncel teklif istemektir; böylece en ucuz görünen teklif değil, karşılaştırılabilir olan ortaya çıkar. Sabit bedelin ve zaman-malzeme modelinin hangi durumda uygun olduğunu özel yazılım maliyetini anlatan rehberimizde ele alıyoruz. Bayi Sipariş Platformu ürün konsepti ise böyle bir portalın nasıl görünebileceğini kurgusal bir şirket üzerinden gösteriyor.
Sözleşme ve kod sahipliği: neler yazılı olmalı?
Sözleşme, işler iyi gittiğinde değil, ters gittiğinde ne olacağını belirler. Teknik açıdan şu maddeler belirsiz kalmamalı:
- Fikri haklar ve kaynak kod. Projeye özel kodun, tasarımların ve belgelerin mali haklarının size devri; firmanın önceden sahip olduğu araç ve kütüphaneler için kullanım lisansı.
- Hesap sahipliği. Kod deposu, alan adı, bulut ve üçüncü taraf servis hesapları şirketiniz adına açılır; firmaya yalnızca yetki verilir.
- Kabul. Her teslimin hangi ölçütlerle, kaç gün içinde test edilip kabul edileceği.
- Garanti ve destek. Canlıya çıktıktan sonra hataların ne kadar süre bedelsiz giderileceği; destek kapsamı, saatleri ve müdahale süreleri (SLA).
- Veri ve güvenlik. Firma kişisel verilere erişecekse alacağı tedbirler ve verinin nerede işleneceği.
- Çıkış planı. İlişki biterse erişimlerin iadesi, belgelerin ve bilginin devri ve bunun bedeli.
Hak devri, üçüncü taraf lisansları ve sözleşmenin tabi olduğu hukuk birlikte değerlendirilmelidir. İstenen hakları ve devir koşullarını sözleşmede açıkça tanımlatın; sözleşme metnini hukuk danışmanınıza kontrol ettirin.
Riski sınırlamak ve teklifi eleyen işaretler
Hangi firmayı seçerseniz seçin, büyük bir taahhüdü tek seferde vermek zorunda değilsiniz. Özellikle referansı az bir ekiple çalışacaksanız riski şu yollarla sınırlayabilirsiniz:
- Sabit bedelli, kısa bir keşifle başlamak ve çıktılarını başka bir ekiple de kullanılabilecek biçimde istemek
- İlk sürümden önce dar kapsamlı bir pilot yapmak
- Her hafta çalışan yazılım görmek; ödemeleri kabul edilen işe bağlamak
- Kod deposuna ilk günden erişim almak
- Sözleşmeye makul bildirim süreli bir çıkış maddesi koymak
Şu üç işaretten biri, teklifi tek başına elemeye yeter: sistemlerinizi ve kullanıcılarınızı görmeden verilen kesin süre ve fiyat, projede kimin çalışacağını söylememek, kodu göstermemek. Sabit fiyatın kendisi sorun değildir; kapsam gerçekten netse doğru modeldir. Sorun, belirsizliğin fiyatın içine gizlenmesidir.
codariva olarak yeni bir ürüne sabit bedelli bir keşif sprintiyle başlamayı öneririz; kaynak kod ilk günden sizin depolarınızda tutulur. Teslim şartlarını ve çalışma biçimimizi özel yazılım geliştirme hizmeti sayfamızda bulabilirsiniz. Bu rehberdeki soruların hepsini bize de sorabilirsiniz.