[{"data":1,"prerenderedAt":40},["ShallowReactive",2],{"blog-yazilim-gelistirme-maliyeti":3},{"html":4,"toc":5,"faq":27},"\u003Cp>Yazılım geliştirme maliyetini belirleyen şey ekran sayısı ya da harcanacak saat değil; kapsamın ne kadar net olduğu, kaç farklı rol ve yetki seviyesi bulunduğu, kaç dış sisteme bağlanılacağı, eski verinin taşınıp taşınmayacağı ve işin ne kadarının hâlâ belirsiz olduğudur. Bu yüzden aynı cümleyle anlatılan iki iş arasında birkaç kat fark çıkması olağan. Bu yazıda bilerek rakam vermiyoruz; teklifi büyüten ve küçülten etkenleri, fiyatlandırma modellerini ve maliyeti sonucu bozmadan nasıl düşürebileceğinizi anlatıyoruz.\u003C\u002Fp>\n\u003Ch2 id=\"neden-tek-bir-rakam-yok\">Neden tek bir rakam yok\u003C\u002Fh2>\n\u003Cp>“Basit bir sipariş takip programı” cümlesini düşünün. Bir şirket için bu, tek depoda iki kişinin kullandığı, siparişleri listeleyip durumunu güncelleyen bir ekran demek. Bir başkası için üç şubede çalışan, bayilerin de giriş yaptığı, muhasebe programına ve kargo firmasına bağlanan, belirli tutarın üstündeki siparişleri yönetici onayına düşüren bir sistem demek. İkisi de “sipariş takibi”; ikisinin maliyeti arasında ciddi bir uçurum var.\u003C\u002Fp>\n\u003Cp>İnternette dolaşan “ortalama şu kadar tutar” listeleri bu farkı görmezden geldiği için işe yaramaz. Yararlı olan, kendi işinizin hangi etkenlerde ağır olduğunu görmek. Hazır bir ürünün işinizi görüp göremeyeceğinden emin değilseniz, maliyete bakmadan önce \u003Ca href=\"\u002Fblog\u002Fhazir-yazilim-mi-ozel-yazilim-mi\">hazır yazılım mı özel yazılım mı\u003C\u002Fa> sorusunu cevaplamak daha doğru bir başlangıç olur.\u003C\u002Fp>\n\u003Ch2 id=\"maliyeti-belirleyen-dokuz-etken\">Maliyeti belirleyen dokuz etken\u003C\u002Fh2>\n\u003Ch3 id=\"1-kapsam-ve-kabul-kriterleri\">1. Kapsam ve kabul kriterleri\u003C\u002Fh3>\n\u003Cp>Kapsam “hangi ekranlar olacak” değil, “kim, hangi adımı yapıp hangi sonucu görecek” sorusunun cevabıdır. “Depo sorumlusu siparişi hazırlandı olarak işaretler, müşteri temsilcisi bunu anında görür” bir kabul kriteridir; “sipariş ekranı” değildir. Kabul kriterleri ne kadar netse tahmin o kadar dar, teklif o kadar güvenilir olur.\u003C\u002Fp>\n\u003Ch3 id=\"2-entegrasyonlar\">2. Entegrasyonlar\u003C\u002Fh3>\n\u003Cp>Her dış sistem bir bağımlılıktır: muhasebe programı, e-fatura entegratörü, banka, kargo, ödeme sağlayıcısı, e-ticaret altyapısı. Maliyeti belirleyen, bağlantının sayısı kadar o sistemin dokümantasyonunun kalitesi, bir test ortamı sunup sunmadığı ve hata verdiğinde ne olacağıdır. İyi bir entegrasyon yalnızca veriyi göndermez; başarısız olduğunda tekrar dener, kayıt tutar ve sorunu birinin görebileceği bir yerde gösterir.\u003C\u002Fp>\n\u003Ch3 id=\"3-roller-ve-yetkiler\">3. Roller ve yetkiler\u003C\u002Fh3>\n\u003Cp>Belirleyici olan kullanıcı sayısı değil, rol sayısıdır. Elli kişinin aynı yetkiyle kullandığı bir araç, beş kişinin beş farklı yetkiyle kullandığı bir araçtan çoğu zaman daha ucuzdur. Şube bazlı görünürlük, onay zincirleri ve “bu alanı sadece finans görsün” kuralları her biri ayrı iş demek.\u003C\u002Fp>\n\u003Ch3 id=\"4-raporlama\">4. Raporlama\u003C\u002Fh3>\n\u003Cp>Rapor istekleri genelde en sona kalır ve en çok sürprizi onlar çıkarır. Bir liste ekranını dışa aktarmak kolaydır; dönemler arası karşılaştırma, birden çok kaynaktan beslenen özetler ve geriye dönük düzeltilebilen veriler üzerinde tutarlı rakamlar üretmek ise ayrı bir tasarım işidir. Hangi raporlara gerçekten her hafta bakıldığını baştan yazın.\u003C\u002Fp>\n\u003Ch3 id=\"5-tasarim-ve-kullanim-yeri\">5. Tasarım ve kullanım yeri\u003C\u002Fh3>\n\u003Cp>Ofiste masaüstü ekranda kullanılacak bir iç araç ile sahada, eldivenle, zayıf bağlantıda telefondan doldurulacak bir form aynı iş değildir. Yazılımı müşterileriniz ya da bayileriniz de kullanacaksa, metinler, hata mesajları ve ilk kullanım deneyimi de kapsamın parçası olur.\u003C\u002Fp>\n\u003Ch3 id=\"6-veri-gocu\">6. Veri göçü\u003C\u002Fh3>\n\u003Cp>Eski veri taşınacak mı, ne kadar temiz? Yıllar içinde elle düzeltilmiş, aynı müşterinin üç farklı yazımla durduğu bir Excel dosyasını yeni sisteme aktarmak, çoğu zaman yeni ekranı yazmaktan daha fazla dikkat ister. Temizliğin kimin işi olduğu teklifte yazmalı.\u003C\u002Fp>\n\u003Ch3 id=\"7-barindirma-ve-altyapi\">7. Barındırma ve altyapı\u003C\u002Fh3>\n\u003Cp>Yazılım nerede çalışacak: kendi sunucunuzda mı, kendi bulut hesabınızda mı? Yedekleme, izleme, e-posta gönderimi, dosya depolama gibi kalemler hem kurulumda hem her ay maliyet üretir. Bu kalemlerin kimin adına açıldığı ve kimin ödediği ayrıca konuşulmalı.\u003C\u002Fp>\n\u003Ch3 id=\"8-bakim\">8. Bakım\u003C\u002Fh3>\n\u003Cp>Yayına çıkan yazılım durmaz: bağımlılıklar güncellenir, güvenlik yamaları gelir, bağlandığınız servisler arayüzlerini değiştirir. Maliyetin önemli bir kısmı yayından sonra oluşur. Bakımı hesaba katmayan bir bütçe eksik bir bütçedir.\u003C\u002Fp>\n\u003Ch3 id=\"9-belirsizlik\">9. Belirsizlik\u003C\u002Fh3>\n\u003Cp>Süreç sizin tarafta net mi, yoksa yazılım yazılırken mi keşfedilecek? Belirsizlik ne kadar büyükse, sabit fiyat veren tedarikçi o kadar büyük bir pay ekler ya da kapsamı o kadar dar tutar. Belirsizliği azaltmanın en ucuz yolu, kod yazılmadan önce süreci yazıya dökmektir.\u003C\u002Fp>\n\u003Ch2 id=\"uc-fiyatlandirma-modeli-ve-bedelleri\">Üç fiyatlandırma modeli ve bedelleri\u003C\u002Fh2>\n\u003Cp>Fiyatın kendisi kadar, hangi riskin kimde kaldığı da önemlidir. Yaygın üç model şöyle ayrışır:\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Model\u003C\u002Fth>\n\u003Cth>Ne zaman uygun\u003C\u002Fth>\n\u003Cth>Risk kimde\u003C\u002Fth>\n\u003Cth>Dikkat edilecek nokta\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Sabit fiyat\u003C\u002Ftd>\n\u003Ctd>Kapsam kâğıt üzerinde netleşebiliyorsa\u003C\u002Ftd>\n\u003Ctd>Tahmin riski tedarikçide\u003C\u002Ftd>\n\u003Ctd>Değişiklik talebinin nasıl fiyatlanacağı yazılı olmalı\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Zaman ve malzeme (gün ya da saat bazlı)\u003C\u002Ftd>\n\u003Ctd>Kapsam gerçekten açık uçluysa, öncelikler sık değişiyorsa\u003C\u002Ftd>\n\u003Ctd>Büyük ölçüde sizde\u003C\u002Ftd>\n\u003Ctd>Haftalık görünürlük ve çalışan sürüm şart\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Aylık anlaşma\u003C\u002Ftd>\n\u003Ctd>Yayından sonraki bakım ve küçük geliştirmeler\u003C\u002Ftd>\n\u003Ctd>Paylaşılır\u003C\u002Ftd>\n\u003Ctd>Dahil olan ve olmayan işler ayrı ayrı yazılmalı\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Sabit fiyat kulağa en güvenli model gibi gelir ve kapsam netse gerçekten öyledir. Kapsam net değilse ise iki şeyden biri olur: tedarikçi belirsizliği fiyata ekler ya da proje boyunca her istek “kapsam dışı” tartışmasına döner. Zaman ve malzeme modeli esneklik sağlar ama ilerlemeyi her hafta görmüyorsanız bütçe sessizce kayar. Saatlik faturalamanın bir sorunu daha var: yavaş çalışmanın parasını öder. Biz bu yüzden kapsam netleşebiliyorsa sabit fiyat, netleşemiyorsa gün bazlı ücret, yayından sonrası için aylık bakım anlaşması kullanıyoruz.\u003C\u002Fp>\n\u003Cp>Modeller birbirini dışlamaz. Sık görülen ve sağlıklı bir düzen şöyle: kapsamı çıkaran kısa bir keşif, ilk sürüm için sabit fiyat, sonraki küçük geliştirmeler için aylık anlaşma. Ödemenin takvime değil, teslim edilen çalışan yazılıma bağlanması da modelden bağımsız olarak isteyebileceğiniz bir koşuldur; iş yavaşladığında elinizdeki tek koz odur.\u003C\u002Fp>\n\u003Ch2 id=\"ekran-basina-fiyat-neden-yaniltir\">“Ekran başına fiyat” neden yanıltır\u003C\u002Fh2>\n\u003Cp>Bazı teklifler işi ekran sayısına böler: on iki ekran, ekran başı şu kadar. Bu yaklaşım anlaşılır görünür ama maliyetin nereden geldiğini gizler. Bir liste ekranı ile içinde onay kuralı, stok düşümü ve muhasebe entegrasyonu tetikleyen bir “sipariş onayla” düğmesi aynı ekran sayılır. Ekranın arkasındaki iş kuralları, yetki kontrolleri, hata durumları ve raporlar ise hiçbir ekran sayımında görünmez.\u003C\u002Fp>\n\u003Cp>Ekran başı fiyatın ikinci sorunu, sizi daha az ekranla daha çok şey isteyen bir tasarıma iter. Sonuç, kalabalık ve kullanması zor bir arayüz olur. Teklifleri karşılaştırırken ekran sayısını değil, kabul kriterlerini ve dahil edilmeyen işleri yan yana koyun.\u003C\u002Fp>\n\u003Cp>Aynı mantık “modül başına” ya da “özellik başına” fiyat listeleri için de geçerli. Bir listedeki “raporlama modülü” satırı, sizin her ay bakılan üç raporunuzu da kapsayabilir, hiçbirini de. Satırın karşısındaki rakama değil, o satırın sizin sürecinizde tam olarak neyi yapacağının yazılı olup olmadığına bakın.\u003C\u002Fp>\n\u003Ch2 id=\"maliyeti-sonucu-bozmadan-dusurmenin-yollari\">Maliyeti sonucu bozmadan düşürmenin yolları\u003C\u002Fh2>\n\u003Cp>Bütçeyi düşürmenin kötü yolu testleri, dokümanı ve bakımı kesmektir; fatura ilk yıl küçülür, sonraki yıllarda büyür. Daha iyi yollar şunlar:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>İlk sürümü, Excel'i ya da e-postayı gerçekten devre dışı bırakan en dar akışa indirin; gerisini ikinci faza yazın.\u003C\u002Fli>\n\u003Cli>Kararı verebilen tek bir kişiyi belirleyin. Üç departmanın onayına bağlı kapsam hem süreyi hem maliyeti büyütür.\u003C\u002Fli>\n\u003Cli>Veriyi göçten önce kendi tarafınızda temizleyin ya da temizliği ayrı ve ölçülebilir bir iş olarak tanımlayın.\u003C\u002Fli>\n\u003Cli>Hazır ürünün iyi yaptığı işi yeniden yazdırmayın; entegrasyonla bağlanın.\u003C\u002Fli>\n\u003Cli>Raporları “hepsi” yerine her hafta gerçekten bakılan üç beş raporla sınırlayın.\u003C\u002Fli>\n\u003Cli>Test edecek bir kullanıcının haftada bir saat ayırmasını sağlayın. Geç fark edilen hata, erken fark edilenden pahalıdır.\u003C\u002Fli>\n\u003Cli>Bütçe aralığınızı baştan söyleyin. Kapsam ona göre kesilir, iki tur boşa gitmez.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"teklif-almadan-once-hazirlanacaklar\">Teklif almadan önce hazırlanacaklar\u003C\u002Fh2>\n\u003Cp>Bir teklifin isabeti, ona verdiğiniz bilgiyle sınırlı. Görüşmeye şunlarla gelin: süreci bugün fiilen yürüten kişi, kullandığınız Excel dosyasının temizlenmemiş gerçek hali, günde ya da ayda kaç kayıt geçtiği, kaç kişinin hangi yetkilerle kullanacağı, bağlanması gereken sistemler ve varsa kesin bir tarihin nedeni. Bu bilgiler olmadan verilen her rakam, iyi giyinmiş bir tahminden öteye geçmez.\u003C\u002Fp>\n\u003Ch2 id=\"nereden-baslamali\">Nereden başlamalı?\u003C\u002Fh2>\n\u003Cp>Kapsam henüz netleşmemişse, doğrudan büyük bir teklif istemek yerine kısa ve sınırlı bir keşif adımıyla başlamak çoğu zaman en ucuz yoldur: süreç yazıya dökülür, kabul kriterleri çıkar ve sabit fiyat bunun üzerine verilir. Sürecin nasıl işlediğini ve süreyi neyin uzattığını \u003Ca href=\"\u002Fyazilim-yaptirma\">yazılım yaptırma rehberimizde\u003C\u002Fa>, çalışma modellerimizi ve paketlerimizi \u003Ca href=\"\u002Ffiyatlar\">fiyatlar sayfamızda\u003C\u002Fa> bulabilirsiniz.\u003C\u002Fp>\n\u003Cp>Kendi işinizin hangi etkenlerde ağır olduğunu birlikte görmek isterseniz, \u003Ca href=\"\u002Fhizmetler\u002Fozel-yazilim-gelistirme\">özel iş yazılımı hizmetimizin\u003C\u002Fa> nasıl işlediğine göz atıp \u003Ca href=\"\u002Filetisim\">iletişim sayfamızdan\u003C\u002Fa> 30 dakikalık bir görüşme ayarlayın. Bu görüşmede fiyat vermiyoruz, ama işin hangi modele oturduğunu ve teklifinizi neyin büyüteceğini açıkça söylüyoruz.\u003C\u002Fp>\n",[6,9,12,15,18,21,24],{"id":7,"text":8},"neden-tek-bir-rakam-yok","Neden tek bir rakam yok",{"id":10,"text":11},"maliyeti-belirleyen-dokuz-etken","Maliyeti belirleyen dokuz etken",{"id":13,"text":14},"uc-fiyatlandirma-modeli-ve-bedelleri","Üç fiyatlandırma modeli ve bedelleri",{"id":16,"text":17},"ekran-basina-fiyat-neden-yaniltir","“Ekran başına fiyat” neden yanıltır",{"id":19,"text":20},"maliyeti-sonucu-bozmadan-dusurmenin-yollari","Maliyeti sonucu bozmadan düşürmenin yolları",{"id":22,"text":23},"teklif-almadan-once-hazirlanacaklar","Teklif almadan önce hazırlanacaklar",{"id":25,"text":26},"nereden-baslamali","Nereden başlamalı?",[28,31,34,37],{"q":29,"a":30},"Yazılım geliştirme maliyeti için ortalama bir rakam var mı?","Anlamlı bir ortalama yok. Aynı cümleyle anlatılan iki iş, rol sayısı, entegrasyonlar ve veri göçü yüzünden birkaç kat farklı tutabilir. Güvenilir bir rakam ancak kapsam yazıya döküldükten sonra verilebilir.",{"q":32,"a":33},"İlk görüşmede fiyat isteyebilir miyim?","İsteyebilirsiniz ama kimse süreci görmeden verilen fiyata güvenmemeli. Daha doğru yol, kısa ve ücretli bir keşif adımıyla kapsamı yazdırıp sabit teklifi onun üzerine almaktır. Bütçe aralığınızı baştan söylemek de kapsamın ona göre kesilmesini sağlar.",{"q":35,"a":36},"Sabit fiyatlı projede kapsam değişirse ne olur?","İyi kurulmuş bir sabit fiyatlı projede yazılı kapsamın fiyatı değişmez; yeni istekler ayrı bir yazılı teklifle, işe başlanmadan önce onaylanır. Sözleşmede değişiklik talebinin nasıl fiyatlanacağı baştan yazılmalı.",{"q":38,"a":39},"Bakım maliyeti geliştirme teklifine dahil mi olmalı?","Teklifte ayrı bir satır olarak görünmeli ama projeye şart olarak bağlanmamalı. Neyin dahil olduğu, yanıt süresi ve dahil olmayan işler yazılı olmalı ki yayından sonra sürpriz çıkmasın.",1793978421495]