[{"data":1,"prerenderedAt":43},["ShallowReactive",2],{"blog-yazilim-teklifi-nasil-karsilastirilir":3},{"html":4,"toc":5,"faq":30},"\u003Cp>Bir yazılım teklifini karşılaştırırken önce fiyata değil, teklifin neyi kapsadığına ve neyi açıkça dışarıda bıraktığına bakın; ardından kodun ve hesapların kimde kalacağını, bakımın nasıl işleyeceğini, değişiklik taleplerinin nasıl fiyatlanacağını ve işi fiilen kimin yapacağını sorun. Aynı kapsamı anlatmayan üç teklifin rakamlarını yan yana koymak hiçbir şey söylemez. Aşağıda teklifleri aynı dile çevirmenin yolunu, sormanız gereken on iki soruyu ve dikkat etmeniz gereken işaretleri bulacaksınız.\u003C\u002Fp>\n\u003Ch2 id=\"once-teklifleri-ayni-dile-cevirin\">Önce teklifleri aynı dile çevirin\u003C\u002Fh2>\n\u003Cp>Teklifler arasındaki fiyat farkının büyük kısmı, firmaların aynı işi farklı anlamasından gelir. Biri sizin anlattığınızı tek bir ekran olarak yorumlar, diğeri onay akışı ve raporuyla birlikte. Bu yüzden karşılaştırmanın ilk adımı tekliflerden önce gelir: herkese aynı yazılı ihtiyaç tanımını gönderin.\u003C\u002Fp>\n\u003Cp>İyi bir ihtiyaç tanımı uzun olmak zorunda değil. Şunları içermesi yeterli: süreci bugün kimin, hangi adımlarla yürüttüğü; yazılımı kaç kişinin ve kaç farklı rolle kullanacağı; bağlanması gereken sistemler; taşınacak veri; varsa kesin bir tarih ve nedeni. Ardından gelen tekliflerde şu soruyu sorun: bu teklif benim yazdığım her maddeyi karşılıyor mu, yoksa bazılarını sessizce atlıyor mu?\u003C\u002Fp>\n\u003Cp>Teklifin kapsam bölümü “sipariş modülü, raporlama modülü, kullanıcı yönetimi” gibi başlıklardan ibaretse, kapsam aslında tanımlanmamış demektir. Aradığınız şey kabul kriterleri: “Depo sorumlusu siparişi hazırlandı olarak işaretler, müşteri temsilcisi durumu anında görür.” Bir maddenin “bitti” sayılması için neyi görmeniz gerektiği yazmıyorsa, proje sonunda “bitti mi?” sorusu bir tartışmaya dönüşür.\u003C\u002Fp>\n\u003Ch2 id=\"teklifte-yazmayanlar-kapsam-disi-listesi\">Teklifte yazmayanlar: kapsam dışı listesi\u003C\u002Fh2>\n\u003Cp>İyi bir teklif neyin dahil olduğunu ne kadar açık yazıyorsa, neyin dahil olmadığını da o kadar açık yazar. Kapsam dışı listesi olmayan bir teklif, sonradan çıkacak her tartışmayı size bırakır.\u003C\u002Fp>\n\u003Cp>Sık rastlanan ve teklifte açıkça konuşulması gereken kalemler şunlar: eski verinin taşınması ve temizliği; muhasebe, e-fatura, banka ya da kargo entegrasyonları; mobil kullanım; e-posta ve SMS gönderim altyapısı; sunucu ve alan adı maliyetleri; kullanıcı eğitimi; kurulum ve işletim dokümanı. Bunlardan biri bir teklifte var, ötekinde yoksa iki rakamı doğrudan karşılaştıramazsınız.\u003C\u002Fp>\n\u003Ch2 id=\"fiyatin-arkasindaki-kosullar\">Fiyatın arkasındaki koşullar\u003C\u002Fh2>\n\u003Cp>İki teklif aynı kapsamı ve aynı rakamı yazıyor olabilir, ama koşulları çok farklı olabilir. Aşağıdaki tabloyu her teklif için doldurmak, farkları görünür kılar:\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Konu\u003C\u002Fth>\n\u003Cth>Teklif A\u003C\u002Fth>\n\u003Cth>Teklif B\u003C\u002Fth>\n\u003Cth>Teklif C\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Kabul kriterleriyle yazılmış kapsam\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Kapsam dışı listesi\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Kaynak kodun telif ve mali hakları\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Kod deposunun açıldığı hesap\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Sunucu ve alan adının sahibi\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Barındırma maliyeti dahil mi\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Veri göçü dahil mi\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Değişiklik talebi süreci\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Yayından sonra bakım ve yanıt süresi\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Ödeme takvime mi teslime mi bağlı\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Kodu yazacak kişiler\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Demo sıklığı\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Boş kalan hücreler, tedarikçiye sormanız gereken soruların listesidir. Cevap alamadığınız hücreler ise başlı başına bir bilgidir.\u003C\u002Fp>\n\u003Cp>Özellikle kod sahipliğine dikkat edin. Yalnızca “kullanım hakkı” verilen bir yazılımı ileride başka bir ekibe geliştirtemeyebilirsiniz. Kod deposunun geliştiricinin hesabında durması da, ilişki bozulduğunda bir pazarlık kozuna dönüşebilir. Sunucu, alan adı ve servis hesaplarının sizin şirketiniz adına açılması aynı mantıkla önemlidir.\u003C\u002Fp>\n\u003Cp>Barındırma ve bakım, tekliflerin en kolay farklılaştığı iki kalemdir. Bir teklif sunucuyu kendi altyapısında “ücretsiz” barındırıyor olabilir; bu ilk bakışta avantaj gibi görünür ama sistemin fiilen kimin elinde durduğunu değiştirir. Bir başkası sunucuyu sizin hesabınızda kurar ve aylık maliyeti doğrudan sağlayıcıya ödersiniz. Bakım tarafında da benzer bir fark var: “bir yıl ücretsiz destek” ifadesi, neyin destek sayıldığı yazılmadıkça ölçülemez. Hata düzeltmesi mi, güvenlik güncellemesi mi, küçük değişiklikler mi? Yanıt süresi ne, hangi saatlerde? Yedekler yalnızca alınıyor mu, yoksa düzenli olarak geri yüklenip test ediliyor mu? Teklifler bu sorulara farklı cevaplar veriyorsa, aynı rakam çok farklı bir hizmet anlamına gelebilir.\u003C\u002Fp>\n\u003Ch2 id=\"degisiklik-talepleri-nasil-yonetilecek\">Değişiklik talepleri nasıl yönetilecek?\u003C\u002Fh2>\n\u003Cp>Her yazılım projesinde kapsam bir miktar değişir. Prototipi gören kullanıcı, kâğıt üzerinde düşünülmemiş bir adımı fark eder; bu normaldir. Önemli olan, değişikliğin nasıl ele alınacağının baştan yazılı olmasıdır.\u003C\u002Fp>\n\u003Cp>Sağlıklı bir süreçte yeni istek yazılı olarak tarif edilir, tedarikçi bunun süreye ve fiyata etkisini işe başlamadan önce bildirir, siz onaylarsınız ve ancak ondan sonra iş başlar. Değişikliklerin “sonra konuşuruz” diyerek yapılıp faturaya eklenmesi ise proje sonunda sürpriz bir rakam demektir. Teklifte bu sürecin nasıl işlediği yazmıyorsa sorun.\u003C\u002Fp>\n\u003Ch2 id=\"isi-kim-yapacak-ne-siklikla-goreceksiniz\">İşi kim yapacak, ne sıklıkla göreceksiniz?\u003C\u002Fh2>\n\u003Cp>Teklif görüşmesini yapan kişiyle kodu yazacak kişi aynı mı? İş başka bir firmaya ya da serbest çalışana devrediliyor mu? Projede kaç kişi çalışacak ve isimleri söylenebiliyor mu? Bu sorulara verilen kaçamak cevaplar, projenin ortasında da kaçamak kalır.\u003C\u002Fp>\n\u003Cp>İlerlemeyi nasıl göreceğiniz de önemli. Durum raporu ilerlemenin yerine geçmez. Haftalık ya da iki haftalık aralıklarla, kendi verinizle tıklayabildiğiniz çalışan bir sürüm görmek; yanlış anlaşılmaları erken, ucuzken yakalamanın en güvenilir yoludur. Yalnızca proje sonunda büyük bir teslim vaat eden teklifler, bütün riski son haftaya yığar.\u003C\u002Fp>\n\u003Ch2 id=\"tedarikciye-sorulacak-12-soru\">Tedarikçiye sorulacak 12 soru\u003C\u002Fh2>\n\u003Cp>Bu soruları kiminle çalışırsanız çalışın sorun. Bir tedarikçinin bu soruları duyduğunda rahatlaması ya da gerilmesi, alacağınız en faydalı sinyallerden biridir.\u003C\u002Fp>\n\u003Col>\n\u003Cli>Kapsamdaki her maddenin kabul kriteri yazılı mı? Bir maddenin bittiğini nasıl anlayacağım?\u003C\u002Fli>\n\u003Cli>Teklifte açıkça kapsam dışı bırakılan neler var?\u003C\u002Fli>\n\u003Cli>Kaynak kodun telif ve mali hakları kime ait olacak, sözleşmede nasıl ifade edilecek?\u003C\u002Fli>\n\u003Cli>Kod deposu ilk günden kimin hesabında açılacak?\u003C\u002Fli>\n\u003Cli>Sunucu, alan adı ve servis hesapları kimin adına olacak, aylık maliyetleri kim ödeyecek?\u003C\u002Fli>\n\u003Cli>Eski verinin taşınması ve temizliği kapsamda mı, temizlikte benden ne bekleniyor?\u003C\u002Fli>\n\u003Cli>Değişiklik talepleri nasıl tarif edilecek, fiyatlanacak ve onaylanacak?\u003C\u002Fli>\n\u003Cli>Kodu fiilen kim yazacak; iş başka bir firmaya ya da kişiye verilecek mi?\u003C\u002Fli>\n\u003Cli>Çalışan bir sürümü ne sıklıkla göreceğim ve testleri kim, nasıl yapacak?\u003C\u002Fli>\n\u003Cli>Ödeme takvime mi, teslim edilen çalışan yazılıma mı bağlı?\u003C\u002Fli>\n\u003Cli>Yayından sonra bakım neyi kapsıyor, neyi kapsamıyor ve yanıt süresi ne?\u003C\u002Fli>\n\u003Cli>İlişki biterse elime ne geçecek: devir dokümanı, ortam değişkenleri listesi, eğitim?\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Bu soruların çoğu teknik değil. Cevapları anlamak için yazılımcı olmanız gerekmez; cevabın net ve yazılı olup olmadığına bakmanız yeterli. Sözlü verilen güzel bir cevap, teklifte ya da sözleşmede yer almıyorsa yokmuş gibi davranın. Bir tedarikçi size jargonla cevap veriyorsa açıklama isteyin; kendi işini iyi bilen biri bunu sade bir dille anlatabilir.\u003C\u002Fp>\n\u003Ch2 id=\"dikkat-edilmesi-gereken-isaretler\">Dikkat edilmesi gereken işaretler\u003C\u002Fh2>\n\u003Cp>Aşağıdaki işaretler tek başına bir firmanın kötü olduğunu göstermez, ama her biri daha fazla soru sormanız gerektiğini söyler:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Süreci görmeden verilen kesin fiyat.\u003C\u002Fstrong> İlk görüşmede, hiçbir şey yazıya dökülmeden verilen rakam büyük ihtimalle bir tahmindir. Ya sonradan büyür ya da kapsam sessizce daralır.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Kapsam dışı listesinin hiç olmaması.\u003C\u002Fstrong> “Her şey dahil” ifadesi, tanımlanmadığı sürece hiçbir şey ifade etmez.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Kod deposunun ve hesapların tedarikçide kalması.\u003C\u002Fstrong> Teslimde devredileceği söylense bile, ilk günden sizin hesabınızda olması daha güvenlidir.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ağırlıklı peşin ya da takvime bağlı ödeme.\u003C\u002Fstrong> İş yavaşladığında elinizde koz kalmaz.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>İsim verilmemesi.\u003C\u002Fstrong> Projede kimin çalışacağı söylenemiyorsa, ekibin değişmesi de size sorulmaz.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bakımın projeye şart olarak bağlanması.\u003C\u002Fstrong> Bakım isteğe bağlı ve ayrı bir anlaşma olmalı; aksi halde tedarikçiyi değiştirme özgürlüğünüz kalmaz.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Kendine özgü, belgelenmemiş bir altyapı.\u003C\u002Fstrong> Yaygın ve iyi belgelenmiş araçlarla yazılmış bir sistemi başka bir ekip devralabilir; kapalı bir çatıyla yazılmış olanı devralmak çok daha zordur.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"nereden-baslamali\">Nereden başlamalı?\u003C\u002Fh2>\n\u003Cp>Teklif istemeden önce ihtiyacınızı bir iki sayfada yazın ve herkese aynı metni gönderin. Teklifler geldiğinde yukarıdaki tabloyu doldurun, boş kalan hücreler için soru sorun ve ancak ondan sonra rakamlara bakın. Rakamların arkasındaki etkenleri anlamak için \u003Ca href=\"\u002Fblog\u002Fyazilim-gelistirme-maliyeti\">yazılım geliştirme maliyeti\u003C\u002Fa> yazımızı, süreç ve sözleşme tarafında neye dikkat edilmesi gerektiğini görmek için \u003Ca href=\"\u002Fyazilim-yaptirma\">yazılım yaptırma rehberimizi\u003C\u002Fa> okuyabilirsiniz.\u003C\u002Fp>\n\u003Cp>Karşılaştırmanın bir parçası olarak bizden de teklif almak isterseniz, \u003Ca href=\"\u002Fhizmetler\u002Fozel-yazilim-gelistirme\">özel iş yazılımı hizmetimizin\u003C\u002Fa> nasıl işlediğini hizmet sayfasında, çalışma modellerimizi ve koşullarımızı \u003Ca href=\"\u002Ffiyatlar\">fiyatlar sayfamızda\u003C\u002Fa> yazılı olarak bulabilirsiniz. Yukarıdaki on iki sorunun cevabı yazılı teklifimizde zaten yer alıyor; yine de görüşmede tek tek sormanızı isteriz. Sürecinizi anlatmak için \u003Ca href=\"\u002Filetisim\">iletişim sayfamızdan\u003C\u002Fa> 30 dakikalık bir görüşme ayarlayabilirsiniz.\u003C\u002Fp>\n",[6,9,12,15,18,21,24,27],{"id":7,"text":8},"once-teklifleri-ayni-dile-cevirin","Önce teklifleri aynı dile çevirin",{"id":10,"text":11},"teklifte-yazmayanlar-kapsam-disi-listesi","Teklifte yazmayanlar: kapsam dışı listesi",{"id":13,"text":14},"fiyatin-arkasindaki-kosullar","Fiyatın arkasındaki koşullar",{"id":16,"text":17},"degisiklik-talepleri-nasil-yonetilecek","Değişiklik talepleri nasıl yönetilecek?",{"id":19,"text":20},"isi-kim-yapacak-ne-siklikla-goreceksiniz","İşi kim yapacak, ne sıklıkla göreceksiniz?",{"id":22,"text":23},"tedarikciye-sorulacak-12-soru","Tedarikçiye sorulacak 12 soru",{"id":25,"text":26},"dikkat-edilmesi-gereken-isaretler","Dikkat edilmesi gereken işaretler",{"id":28,"text":29},"nereden-baslamali","Nereden başlamalı?",[31,34,37,40],{"q":32,"a":33},"En ucuz yazılım teklifini seçmek yanlış mı?","Kendi başına yanlış değil; yanlış olan, aynı şeyi kapsamayan teklifleri yalnızca rakamla karşılaştırmak. Teklifleri aynı kapsam, aynı hariç tutulanlar ve aynı sahiplik koşulları üzerinden hizalarsanız, en ucuzun gerçekten en ucuz olup olmadığını görebilirsiniz.",{"q":35,"a":36},"Kaç farklı firmadan yazılım teklifi almalıyım?","Sabit bir sayı yok, ama karşılaştırma yapabilmek için birden fazla teklif faydalıdır. Daha önemlisi, hepsine aynı yazılı ihtiyaç tanımını göndermek. Herkese farklı anlatılan bir iş için gelen teklifler karşılaştırılamaz.",{"q":38,"a":39},"Teklif aşamasında ücretsiz analiz beklemek doğru mu?","Kısa bir ilk görüşme ücretsiz olabilir. Süreci işi yapan kişilerle oturup gerçekten çıkaran ayrıntılı bir analiz ise emek ister; ücretsiz sunulduğunda ya yüzeysel kalır ya da maliyeti projeye gizlice eklenir. Ücretli keşfin çıktısının size kalması daha şeffaf bir düzendir.",{"q":41,"a":42},"Teklifte süre garantisi olmalı mı?","Süre, sizin tarafınızdaki karar hızına, verinin durumuna ve üçüncü tarafların takvimine de bağlıdır. Mutlak bir garanti yerine fazlara bölünmüş tahmini teslimler, süreyi uzatabilecek risklerin yazılı listesi ve haftalık çalışan sürüm istemek daha gerçekçidir.",1793978421218]