Özel Yazılım Geliştirme

Doğru Fiyat Teklifi Aldıran Yazılım Proje Brifi Nasıl Yazılır?

Paylaş!
Doğru Fiyat Teklifi Aldıran Yazılım Proje Brifi Nasıl Yazılır?

Üç ayrı firmaya aynı iki paragrafı yolladınız ve geri gelen rakamlar birbirini tutmuyor. Bu yazı, o farkın nereden çıktığını ve teklif istemeden önce oturup yazacağınız birkaç sayfanın fiyatı nasıl aşağı çektiğini anlatıyor. Teknik bir metin değil, bir işletme sahibinin kendi bütçesini kendisinin kontrol etmesi için bir yöntem, çünkü yazdığınız her cümlenin karşılığı sonunda iş gününe ve paraya dönüşüyor.

Aynı proje neden üç firmadan üç ayrı fiyatla geri dönüyor

Sahne çoğu okuyucuya tanıdık gelir: kısa bir e-posta yazdınız, "randevu ve tahsilat takibi yapan bir sistem istiyoruz" dediniz, üç yere birden gönderdiniz ve gelen tekliflerden biri diğerinin dört katı çıktı. İlk akla gelen düşünce de hep aynıdır, ya biri fahiş fiyat veriyordur ya da biri işi hiç bilmiyordur. Oysa çoğu zaman ikisi de doğru değildir, çünkü üç firma da dürüst davranmış, önlerindeki eksik resmin boşluklarını kendi tecrübesiyle doldurmuştur.

Bir tarif ne kadar boşluk bırakırsa, teklifi hazırlayan kişi o boşlukları o kadar çok kendi kafasında tamamlar. Biri "tek kullanıcılı, sade bir kayıt ekranı isteniyor herhalde" diye düşünüp küçük bir sistemi fiyatlar, bir diğeri "bunlar altı ay sonra muhasebe bağlantısı ve yetki yönetimi ister, şimdiden koyayım" deyip büyük bir sistemi fiyatlar. İki teklif de kendi içinde tutarlıdır; sadece iki ayrı ürünün fiyatıdır ve siz ikisini yan yana koyup karşılaştırmaya çalıştığınız için ortada bir tuhaflık varmış gibi görünür.

Pratikte gördüğümüz aralık şu: tek paragrafla tarif edilmiş bir fikirde en yüksek teklif, en düşüğün genellikle üç ila beş katı olur. Bu yazıdaki soruları, yani rolleri, kuralları, mevcut veriyi ve dış sistem bağlantılarını cevaplayan bir metinle gittiğinizde ise aynı fark yüzde 20 ile 30 bandına iner. Üstelik bu daralma size paraya değil, yalnızca brifi yazmaya ayıracağınız birkaç saate mal olur.

Onun için bu belgeyi tedarikçi hatırı için doldurulan bir evrak gibi görmeyin. İyi yazılmış bir proje brifi, yani ne istediğinizi anlatan o birkaç sayfalık ihtiyaç dokümanı, bir alıcının kendi bütçesini kontrol etmek için elindeki en ucuz araçtır. Linkysoft olarak aynı iş fikrinin tarifi bize farklı ağızlardan geldiğinde bunu çok net görüyoruz: fiyatı asıl hareket ettiren şey işin teknik zorluğu değil, tarifin netliğidir. Bitmiş işlerin nasıl göründüğünü merak ediyorsanız tamamladığımız projelerin örnekleri fikir verir, ama asıl işi bu yazıdaki sorulara vereceğiniz cevaplar yapacak.

Bir teklif aslında neyi fiyatlar: özellik değil, iş günü

Her teklifin arkasında tek bir çarpma işlemi vardır ve o işlemi bildiğiniz anda rakamlar gizemli olmaktan çıkar: fiyat, harcanacak iş günü sayısı çarpı bir günlük ücrettir. Geri kalan her şey, yani teknoloji seçimi, ekranların sayısı, kullanılan araçlar, sadece bu iki sayıyı belirleyen detaylardır.

Somut bir örnekle gidelim. Kendi para biriminizde 60.000'lik bir teklif aldınız ve firmanın karma günlük ücreti, yani işe dokunacak kıdemli ve yeni geliştiricilerin ortalama günlük ücreti, 500 ise, elinizdeki rakam 120 geliştirici günü demektir. 120 gün tek bir kişinin yaklaşık altı ayıdır; üç kişilik bir ekiple bu süre en iyi ihtimalle sekiz hafta, test ve gözden geçirme de hesaba katıldığında gerçekçi olarak dokuz on haftadır. Bu çevirmeyi yapabildiğiniz anda "60.000 pahalı mı" sorusu yerini çok daha yararlı bir soruya bırakır: benim işim gerçekten altı ay tam zamanlı emek gerektiriyor mu?

Bu yüzden teklif elinize geçtiğinde sorulacak tek soru şudur: bu kaç gün ve bu günler kalemlere nasıl dağılıyor? Cevabı yarım saat içinde veremeyen bir firma aslında bir tahmin yapmamıştır, aklındaki bir rakamı yuvarlamıştır ve o rakam işin ortasında değişir. Gün sayısını yazılı olarak veren firma ise hem kendini bağlar hem de size karşılaştırma yapabileceğiniz ortak bir birim verir.

Gün dağılımını istediğinizde çoğu alıcının ilk defa fark ettiği bir gerçek daha ortaya çıkar: ödediğiniz paranın ancak yarısı ekranda görünür. Tipik bir özel yazılım projesinde günlerin yaklaşık yüzde 50'si yeni ekranların ve iş mantığının yazılmasına, yüzde 18'i test etmeye ve çıkan hataları düzeltmeye, yüzde 12'si sunucu, ortam kurulumu ve yayına alma işlerine, yüzde 10'u koordinasyon ve toplantılara, kalan yüzde 10'u da siz işi görüp fikir değiştirdikten sonraki revizyonlara gider. Bu son kalem size ne kadar iyi tarif ederseniz o kadar küçülür.

Ödediğiniz iş günleri nereye gidiyor
Ödediğiniz emeğin ancak yarısı ekranda görünür, diğer yarısı görünen kısmın ayakta kalmasını sağlayan işlerdir.

Bu dağılım aynı zamanda ucuz tekliflerin nerede kısıldığını da gösterir, çünkü sıkışan firma önce testi ve kurulumu keser. Sıfırdan özel bir sistem yaptırmayı düşünüyorsanız, teklifte test ve yayına alma kalemlerinin ayrı ayrı yazılı olmasını isteyin; olmadıklarında iş bitmemiş olmaz, sadece o günleri sonradan siz ödersiniz.

Özellik listesiyle değil, ulaşmak istediğiniz sonuçla başlayın

Brifin ilk paragrafı ekranlardan, butonlardan ve modüllerden bahsetmemeli; işletmenizin bugün yapamadığı ama yarın yapabilecek olduğu şeyi anlatmalı. Yanına da bunu nasıl ölçeceğinizi koyun, mesela bir randevunun onaylanma süresinin yirmi dakikadan iki dakikaya inmesi gibi. Bu tek cümle, karşınızdaki firmaya işin amacını verir.

Bunun ticari karşılığı çok somuttur. İşini bilen bir tedarikçi çoğu zaman aynı sonuca giden daha ucuz bir yol önerir, ama bunu ancak sonucu bildiğinde yapabilir; sizin tahmin ettiğiniz özelliği bildiğinde yapamaz, çünkü o zaman elinde sadece yerine getirilecek bir sipariş vardır. "Grafiklerin olduğu bir yönetim paneli istiyoruz" cümlesi tam da bu yüzden pahalıya patlar: grafiğin hangi kararı desteklediğini kimse bilmediği için firma her ihtimale karşı geniş fiyatlar ve kendini garantiye alır.

İyi bir açılış paragrafı şuna benzer ve neredeyse kelimesi kelimesine taklit edebilirsiniz: "Üç şubeli bir diş kliniğiyiz, günde ortalama 60 hasta görüyoruz ve randevular şu an telefonla alınıp kağıt ajandaya yazılıyor. İstediğimiz şey, bir hastanın randevusunu kendi telefonundan alabilmesi ve o randevunun otomatik olarak doğru hekimin gününe düşmesi. Başarılı saydığımız sonuç şu: resepsiyonun randevu için harcadığı günlük üç saatin bir saatin altına inmesi ve gelmeyen hasta oranının yüzde 20'den yüzde 10'a düşmesi." Bu dört cümle, on maddelik bir özellik listesinden çok daha iyi bir fiyat getirir.

İşin bugün nasıl yürüdüğünü adım adım yazın

Brifin en değerli sayfası burasıdır, çünkü hiçbir firma sizin işinizi sizden iyi bilmez. Müşterinin ilk temasından paranın hesaba geçtiği ve dosyanın kapandığı ana kadar olan akışı numaralı maddeler halinde yazın, her maddede işi kimin yaptığını ve hangi aracı kullandığını söyleyin. Örneğin şöyle:

  1. Müşteri Instagram'dan mesaj atıyor, satış temsilcisi cevaplıyor.
  2. Temsilci fiyatı Excel'deki liste üzerinden hesaplıyor ve WhatsApp'tan yolluyor.
  3. Müşteri onaylayınca temsilci depoya soruyor, depo telefonla stok bakıyor.
  4. Muhasebe faturayı ayrı bir programda kesiyor, dekontu e-posta ile bekliyor.
  5. Kargo çıkışı bir deftere elle yazılıyor, takip numarası müşteriye tekrar WhatsApp'tan gidiyor.

Bu liste sıkıcı görünür ama içinde projenin bütün pahalı sürprizleri saklıdır: kağıt formlar, sadece bir kişinin anladığı o tek Excel dosyası, istisnalar ve resmi olmayan onaylar. Bunları brifte gören firma fiyatına koyar, göremeyen firma ikinci ayda keşfeder ve o keşif her zaman ek bütçe olarak size döner.

Adımların yanına hacimleri de yazın, çünkü on tane ile on bin tane aynı ekranla çözülse bile aynı mühendislik değildir. Günde kaç sipariş, kaç hasta, kaç fatura giriyor ve yoğun günde bu sayı kaça çıkıyor, bunları yazmanız yeterli. Şunu da rahatlıkla söyleyebiliriz: düz cümlelerle yazılmış bir akış ve mevcut kağıt formun telefonla çekilmiş bir fotoğrafı, çizmek zorunda hissettiğiniz herhangi bir şemadan çok daha işe yarar.

Ekranlarınızı ve sisteme girecek kişi tiplerini sayın

Sayma yöntemi basittir: bir insanın bakacağı her ekranı tek tek listeleyin ve her birinin yanına sadece bilgi mi gösterdiğini, yoksa kayıt ekleme, düzenleme ve onaylama da yaptırıyor mu olduğunu yazın. Maliyet farkının büyük bölümü bu ayrımdan çıkar, çünkü veri gösteren bir ekranla veri değiştiren bir ekran arasında hem geliştirme hem de test açısından ciddi fark vardır.

Pratikte kullandığımız kaba oranlar şöyle:

  • Listesi, ekleme ve düzenleme formu ve birkaç kuralı olan bir ekran, testi dahil tipik olarak 2 ile 5 geliştirici günü.
  • Filtreleri ve dışa aktarma özelliği olan bir rapor ekranı 3 ile 5 gün.
  • Sadece bilgi gösteren düz bir sayfa bir günün altında.
  • Küçük bir yönetim sistemi genelde 12 ile 25 ekran arasına oturur.

Bu çarpımı kendi başınıza yaptığınızda, henüz kimseyle konuşmadan gerçek bir tahmine yaklaşık yüzde 30 yakınlıkta bir rakama ulaşırsınız. Yüzde 30 hata payı size hangi firmayı seçeceğinizi söylemez ama çok daha önemli bir şeyi söyler: bu işe hiç başlamalı mısınız, yoksa rakam sizin ölçeğinizin dışında mı?

Kullanıcı rollerini de aynı nefeste düşünün. Gerçekten farklı yetkileri olan her ek rol, yani yönetici, muhasebeci, saha personeli gibi, yapım maliyetine kabaca yüzde 8 ile 15 arası ekler; 120 günlük bir projede bu 10 ila 18 fazladan gün demektir. Sebebi şu: her ekran bir kez yazılır, sonra ikinci rolün gözünden bir daha gözden geçirilir ve bir daha test edilir. Dolayısıyla iki rolün yeteceği bir yerde dört rol yazmak, kağıt üzerinde masum görünen ama faturaya yansıyan gereksiz bir maliyettir.

Burası küçük olanın çoğu zaman doğru olduğunu açıkça söylememiz gereken yer: insanların gerçekten kullandığı üç düzgün ekran, kimsenin açmadığı on beş ekrandan daha iyidir ve ikinci yıl eklemek her zaman mümkündür.

Entegrasyonlar ve veri taşıma: en kısa cümleler, en uzun faturalar

Önce kelimeyi tarif edelim, çünkü brifte en çok yanlış anlaşılan şey budur. Entegrasyon, yeni sisteminizin başka bir sistemle otomatik konuşması demektir; muhasebe programınız, ödeme altyapınız veya bir devlet portalı gibi. Yani bir insanın bir yerden bir yere veri kopyalamasına gerek kalmamasıdır.

Bu işin birbirinden çok farklı iki fiyat bandı vardır. Dokümantasyonu olan ve test ortamı, yani gerçek verilere dokunmadan deneme yapabileceğiniz bir prova kopyası sunan modern bir servise bağlanmak tipik olarak 3 ile 8 geliştirici günüdür. Buna karşılık dokümantasyonu ve test ortamı olmayan eski bir program, bir banka veya bir devlet portalı 10 ile 30 gün arasına çıkar ve pratikte projelerin bütçeyi aşmasının en yaygın tek sebebidir. Aradaki fark teknik yetenek değil, karşı tarafın hazır olup olmamasıdır.

Bu yüzden brifte "muhasebeyle entegre olsun" yazmak yerine şunları yazın: sistemin adı ve sürümü, giriş bilgilerinin kimde olduğu, bir test ortamı bulunup bulunmadığı ve sizin tarafınızda kimin o sistemin teknik yetkilisini telefonla bulabileceği. Bu dört satır, teklifteki belirsizlik payını doğrudan siler. Aynı konuyu farklı açılardan ele aldığımız entegrasyon yazılarımız da neyin sorulması gerektiği konusunda yol gösterir.

Eski veriyi de dürüstçe konuşalım. Excel dosyalarındaki 5.000 ile 50.000 arası kaydı temiz bir yapıya taşımak genelde 4 ile 10 gündür; ama mükerrer kayıtlar, birbiriyle tutmayan birkaç ayrı dosya ya da tarih olması gereken yerde serbest metin varsa bu süre rahatlıkla ikiye katlanır. Güvenli planlama rakamı, yapım maliyetinin yüzde 5 ile 10 arasını veri taşımaya ayırmaktır. Brifte mutlaka kaç yıllık geçmişin gerçekten taşınması gerektiğini yazın, çünkü çoğu işletmede son iki yıl yeterlidir ve geri kalanı arşiv olarak durabilir.

Brifteki tek bir cümle kaç iş günü demek
Brifteki tek bir cümle bir aylık emekten daha pahalı olabilir, bu yüzden en kısa cümleler en çok detayı hak eder.

Kurallar, onaylar ve tahmini bozan istisnalar

Yazılım, çalışanlarınızın kafasında taşıdığı her kuralı satır satır öğrenmek zorundadır, çünkü kendi başına sağduyu üretemez. Kim ne kadar iskonto verebilir, müşteri paranın yarısını yatırırsa ne olur, belli bir tutarın üzerindeki iade için hangi müdürün onayı gerekir; bunlar sizin için gündelik alışkanlıktır ama sistem için ayrı ayrı yazılması gereken kurallardır.

İstisnaların pahalı olmasının sebebi de budur. Sıradan durum hızlı yazılır, ama etrafındaki beş özel durum çoğu zaman sıradan durumdan daha çok tutar. Bunları brifte sıralamak maliyeti artırmaz, sadece sürpriz maliyeti görünür ve fiyatlanmış maliyete çevirir ki aradaki fark projenin huzurudur. On dakikada cevaplayabileceğiniz şu sorularla başlayın:

  • Bir sipariş veya randevu iptal edilirse ne oluyor, para iade mi ediliyor, alacak olarak mı duruyor?
  • Ürün iade gelirse stok ve fatura tarafında ne değişiyor?
  • Ödeme geç yapılırsa kim uyarılıyor ve ne kadar sonra?
  • Müşteri tutarın bir kısmını öderse kayıt nasıl görünüyor?
  • Aynı kayıt iki kere girilirse bunu kim fark ediyor?
  • İşi yapan kişi işten ayrılmışsa onun kayıtları kime devrediliyor?

Bunun parasal karşılığı da ölçülebilir. Bir sayfadan kısa briflerle başlayan projelerde ilk üç ay içinde gelen değişiklik talepleri tipik olarak ilk teklifin yüzde 25 ile 40'ı kadar tutar. Sonucu, mevcut süreci, ekranları, rolleri, kuralları, veriyi ve entegrasyonları kapsayan bir brifle başlayan projelerde ise aynı kalem yüzde 5 ile 15 arasında kalır ki bu sağlıklı bir orandır, çünkü hiçbir proje sıfır değişiklikle bitmez.

Ölçek, hız ve dayanabileceğiniz kesintiyi sayıya dökün

Mühendislik kararlarının çoğunu sessizce belirleyen dört sayı vardır ve hepsini iki dakikada yazabilirsiniz: en yoğun saatte sistemi aynı anda kaç kişi kullanacak, bugün kaç kayıt var ve üç yıl sonra kaç olacak, yüklenen dosyalar ne kadar büyük, ve sistemin ofis dışında ya da internetsiz çalışması gerekiyor mu? Bu dördü olmadan yapılan her tahmin bir ihtimal listesidir.

Kesintisizlik konusunu da insan diliyle konuşalım. Yüzde 99,5 çalışma garantisi ayda yaklaşık 3,6 saat kesintiye izin verir, yüzde 99,9 ise yaklaşık 43 dakikaya iner. İkinci rakamın arkasındaki izleme, yedekleme ve yedek kapasite düzeneği barındırma ve kurulum maliyetine tipik olarak yüzde 15 ile 25 arası ekler. Bu yüzden bunu ancak bir saatlik kesinti size gerçekten para kaybettiriyorsa isteyin; bir muhasebe iç sistemi için istemek, ödemenize gerek olmayan bir sigortadır.

Hassas veri konusunu da baştan açın. Sistem sağlık kaydı, kimlik belgesi ya da kart bilgisi tutacaksa bunu brifte tek cümleyle söyleyin, çünkü bu bilgi testi, barındırmayı ve erişim kurallarını daha ilk günden değiştirir. Sonradan bir denetimde ortaya çıkması ise çok daha pahalıdır ve bazen yapılan işin bir kısmını çöpe atmak gerekir; veri güvenliği ve erişim kuralları tarafını en başta konuşmak her zaman daha ucuzdur.

Son olarak yayına alındıktan sonra sistemi kimin ayakta tutacağını yazın. Barındırma, güncelleme, izleme ve destek yılda tipik olarak yapım maliyetinin yüzde 15 ile 20'si kadar tutar. Bu kalemi hiç yazmayan bir teklif daha ucuz bir teklif değildir, sadece daha kısa bir tekliftir ve o para birinci yılın sonunda yine sizden çıkar.

Bütçenizi ve teslim tarihinizi yüksek sesle söyleyin

Alıcıların bütçeyi saklamasının sebebi bellidir: rakamı söylerlerse firmanın o rakamın tamamını harcayacağına inanırlar. Pratikte olan tam tersidir, çünkü bütçeyi bilmeyen firma ya kendini garantiye almak için yüksekten fiyatlar ya da sizin ödeyemeyeceğiniz bir çözüm tasarlar ve iki taraf da iki haftasını boşa harcar.

Bütçeyi bir sır değil, bir tasarım kısıtı olarak düşünün. "30.000 ile 45.000 arasında bir bütçemiz var" cümlesi, işini bilen bir tedarikçiye bu paranın içine gerçekten neyin sığdığını ve neyin ikinci faza kalması gerektiğini söyleme imkanı verir ki bütün süreçteki en yararlı konuşma budur. Aynı mantıkla ele aldığımız maliyet yazılarımızda da bu aralık mantığının nasıl kurulduğunu anlatıyoruz.

Tarih konusunda da aynı açıklık geçerlidir. Teslim tarihinin neye bağlı olduğunu yazın: bir sezon, bir kira sözleşmesi, bir denetim ya da bir lisansın bitişi. Gerçek bir sebebe göre plan yapılabilir, uydurulmuş bir aciliyet ise sadece fiyata güvenlik payı ekletir.

Beklentiyi de netleştirelim. Tam bir brifle giden bir alıcıya ciddi bir firma 3 ile 5 iş günü içinde kalem kalem yazılmış bir teklif dönebilir. Muğlak bir tarifle giden alıcı ise ya iki üç haftalık soru cevap e-postası satın alır ya da belirsizliğin içine gömüldüğü şişirilmiş bir rakam alır; ikisi de zaman ve para kaybıdır.

Brife koymamanız gereken şeyler

Bir belge neyi içermediğiyle de iyi olur, o yüzden şunları dışarıda bırakın. İşin doğasında gerçekten zorunlu kılan bir şey yoksa teknoloji seçimlerini yazmayın; bir yerde okuduğunuz bir programlama çatısının ya da veritabanının adını brife koymak, size hiçbir fayda sağlamadan aday firma sayısını daraltır ve bazen fiyatı ikiye katlar. Ne istediğinizi söyleyin, nasıl yapılacağını firmalara bırakın.

Teklif aşamasında bitmiş tasarımlara ve piksel düzeyinde ekran çizimlerine de gerek yok, çünkü beğendiğiniz bir sitenin ekran görüntüsü ya da kağıda çizilmiş kaba bir taslak aynı şeyi beş dakikada anlatır. Çok büyük ürünlerle karşılaştırma yapmaktan da kaçının: "şu büyük pazaryeri uygulaması gibi olsun" cümlesi yüzlerce kişinin yıllarca yaptığı işi tarif eder ve sizin işletmenizin neye ihtiyacı olduğu konusunda hiçbir şey söylemez.

İki popüler eklenti konusunda da açık konuşalım. Yanına bir mobil uygulama istemek, eşdeğer bir web projesinin üzerine tipik olarak yüzde 40 ile 70 arası ekler; oysa iyi yapılmış, telefonda düzgün çalışan bir web sistemi ilk yıl için çoğu işletmede daha doğru harcamadır. Benzer şekilde, veriniz henüz temiz ve tek yerde toplanmış değilken yapay zeka özellikleri istemek erken yapılmış bir harcamadır, çünkü bu özellikler ancak düzgün veriyle işe yarar.

Uzunluk konusunda da bir sınır koyun: brif 3 ile 6 sayfa olsun. On beş sayfayı geçen belgeler genellikle kendini tekrar etmeye başlar ve fiyatı asıl belirleyen bölümler kalabalığın içinde kaybolur.

Doksan dakikada yazabileceğiniz bir brif

Aşağıdaki sekiz başlığı sırayla doldurursanız elinizde teklif istemeye hazır bir belge olur:

  1. Ulaşmak istediğiniz sonuç, tek paragraf ve ölçülebilir bir cümleyle.
  2. İşin bugünkü akışı, numaralı adımlar halinde ve günlük hacimleriyle.
  3. Ekran listesi, her birinin yanında sadece gösteriyor mu yoksa veri de mi değiştiriyor bilgisiyle.
  4. Kullanıcı rolleri ve her rolün gerçekten neyi yapıp neyi yapamayacağı.
  5. Bağlanılacak sistemler, sürümleri, test ortamı var mı ve sizin tarafınızda kim sorumlu.
  6. Mevcut veri, kaç kayıt, hangi dosyalarda ve kaç yıllık geçmişin taşınacağı.
  7. Kurallar ve istisnalar, iptal, iade, eksik ödeme ve onay eşikleri dahil.
  8. Bütçe aralığı, hedef tarih ve o tarihin arkasındaki gerçek sebep.

Sonuna üç pratik madde daha ekleyin: teklif süresince soruları sizin tarafınızda kim cevaplayacak, ne kadar sürede cevap verebilir ve gelen teklifler arasında neye bakarak karar vereceksiniz. Bu üç satır, tedarikçiye ciddiyetinizi gösterdiği için cevap kalitesini de yükseltir.

Süre tahminini de dürüst verelim: ilk taslak için yaklaşık doksan dakika, işi her gün yapan bir çalışanınız okuyup düzelttikten sonra bir saat daha. Proje büyükse ya da gerçekten belirsizse, ücretli bir keşif çalışması da mantıklıdır; bu tipik olarak beklenen yapım maliyetinin yüzde 5 ile 10'u kadar tutar, bir ile üç hafta sürer ve artı eksi yüzde 50 doğrulukta bir tahmini artı eksi yüzde 15'e indirir. Aynı mantığın uzun anlatımını planlama yazılarımızda bulabilirsiniz.

Gelen teklifleri nasıl okursunuz

Elinize üç teklif geldiğinde şu dört kontrolü yapın, çoğu karar burada netleşir:

  • Gün sayısı yazıyor mu, yoksa sadece bir toplam mı var?
  • Neyin kapsam dışı olduğu açıkça sayılmış mı?
  • Bir iş beklenenden uzun sürerse ne olacağı yazılmış mı?
  • Yapım maliyetinin yanında ilk yılın işletme gideri de fiyatlanmış mı?

En düşük rakama da dostça ama dikkatli yaklaşın. Diğerlerinin belirgin şekilde altında kalan bir teklif genellikle aynı işi daha ucuza değil, daha küçük bir işi fiyatlıyordur. Bunu anlamanın en hızlı yolu şu tek soruyu sormaktır: brifimdeki ekranların, rollerin ve entegrasyonların hangilerini bu fiyata dahil ettiniz? Gelen cevap aradaki farkı çoğu zaman tek e-postada açıklar ve o firma gerçekten uygunsa da ortaya çıkar.

Karşılaştırmayı adil tutmak için aynı brifi bütün firmalara aynı gün gönderin ve hepsine aynı cevap tarihini verin, çünkü farklı bilgiyle hazırlanmış tekliflerden anlamlı bir kıyas çıkmaz.

Son olarak şunu teklif edelim: elinizdeki brif kaba bir taslak bile olsa bize gönderin, Linkysoft olarak başkalarına yollamadan önce hangi bilgilerin eksik olduğunu ve o eksiklerin fiyatı nasıl şişireceğini size yazalım. Bize buradan ulaşabilirsiniz, benzer konulardaki diğer rehberler için de blog sayfamıza göz atın.

Anahtar kelimeler

Tam olarak bu konudaki diğer harika yazıları okuyun.

Yazılım Teslim Edildikten Sonra: Sistemi Ayakta Kim Tutar?

Sistem teslim edildi, fatura kesildi ve ertesi sabah gerçek işler başladı. Peki bundan sonra bu sistemden her ay kim sorumlu olacak? İlk yılın destek yükünü, yıllık bakımın yapım maliyetine oranını, barındırmadan mağaza ücretlerine kadar bütün kalemleri ve sistemi ayakta tutmanın dört ayrı yolunu rakamlarıyla yazdık; küçük olanın doğru seçenek olduğu durumları da atlamadan.

1 dakikalık okuma

Yazılım Projeniz Gerçekten Yolunda mı? Kendiniz Yapabileceğiniz Beş Kontrol

Güncelleme üç aydır yüzde seksen diyorsa, elinizde bunu sınayacak bir ölçü yok demektir. Bu yazıda teknik bilgi gerektirmeyen ve bir saatte bitirebileceğiniz beş kontrolü, kalan süreyi kendi başınıza hesaplamanızı sağlayan basit bir aritmetiği ve gecikmelerin gerçekte nerede biriktiğini anlatıyoruz. Geride kaldığınızı gördüğünüzde elinizde kalan dört seçeneği de açıkça yazdık, durmak dahil.

1 dakikalık okuma