Yazılım maliyet kalemleri, bir programın teklifinde hangi işlerin ve giderlerin bulunduğunu anlamanızı sağlar. Tek bir toplam rakam görmek, projede neyin yapılacağını ve hangi sorumlulukların işletmeye kalacağını açıklamayabilir. İki teklif benzer ekranları içerdiği halde veri hazırlığı, test, kurulum veya destek açısından farklı olabilir. Bu farkları görmeden yalnızca toplamları karşılaştırmak eksik bir karar oluşturur. Doğru bütçe çalışması, her ayrıntıya ayrı fiyat yazılması demek değildir; önemli işlerin nerede karşılandığını ve hangilerinin dışında kaldığını bilmektir.

İçindekiler

Yazılım maliyet kalemleri hakkındaki bu yazı güncel piyasa fiyatı veya her projeye uygulanacak tutar sunmaz. İhtiyaç, veri yapısı, bağlantılar ve teslim beklentisi bilinmeden güvenilir bir rakam üretilemez. Bunun yerine teklifinizi dokuz başlıkta kontrol etmenize yardımcı olacak yöntem açıklanır. Her başlığın ayrı faturalandırılması gerekmez. Bir hizmet paketi içinde birlikte karşılanabilirler. Önemli olan aynı işin iki yerde sayılmaması, gerekli işin unutulmaması ve devam eden giderlerin tek seferlik geliştirmeyle karıştırılmamasıdır.

Yazılım maliyet kalemleri araştırmasına başlamadan önce ilk sürümün hangi ihtiyacı karşılayacağını açıklayın. Program yaptırmak isteyenler için ihtiyaç listesi bu başlangıçta kullanılabilir. Belirsiz iş listesi üzerinden hazırlanan bütçe, çok ayrıntılı görünse bile varsayımlara dayanabilir. Özellikle eski kayıtların durumu ve dış sistemlerle bağlantılar bilinmiyorsa önce araştırma gerekebilir. Teklifin hangi bilgilere dayanarak hazırlandığını öğrenmek, rakamı öğrenmek kadar önemlidir. Bilinmeyen kalemlerin nasıl netleşeceği de başlangıçta konuşulmalıdır.

Yazılım maliyet kalemleri neden proje kapsamından ayrı okunamaz?

Bir işin bedeli, neyin teslim edileceğiyle birlikte anlam kazanır. Müşteri yönetimi başlığı yalnızca kayıt açma ekranını da kapsayabilir, teklif ve görev takibini de içerebilir. Aynı isim altında farklı işler bulunabilir. Bu nedenle maliyet tablosunun yanında işlev açıklaması veya kapsam belgesi olmalıdır. Kullanıcı sayısı, erişim rolleri, verinin nereden alınacağı ve hangi raporların beklendiği görülebilmelidir. Çok ayrıntılı teknik açıklama gerekli olmayabilir; fakat tarafların aynı işten söz ettiği anlaşılmalıdır.

Yazılım maliyet kalemleri değerlendirilirken kapsam dışı işler özellikle önemlidir. Eski programdan veri alınması, kayıtların temizlenmesi veya kullanıcıların eğitilmesi işletmenin sorumluluğunda bırakılmış olabilir. Bu yanlış bir yaklaşım olmak zorunda değildir. Ancak işletmenin o işi yapabilecek zamanı ve kaynağı bulunmalıdır. Sorumluluğu bilinmeyen bir kalem, takvimde de görünmez hale gelir. Başlangıçta bedeli düşük görünen teklif, işletmenin kendi zaman yükü hesaba katıldığında farklı değerlendirilebilir. Bu nedenle yapılacak işi ve sorumluyu beraber kaydedin.

Tek seferlik giderlerle devam eden giderleri ayırın

Yazılım maliyet kalemleri açısından geliştirme, belirli veri aktarımı ve ilk kurulum tek seferlik çalışma olarak ele alınabilir. Barındırma, lisans veya dış hizmet kullanımı ise devam eden gider oluşturabilir. Hangi giderin hangi dönemi kapsadığı anlaşılmalıdır. İlk yıl dahil olan hizmetin sonraki koşulları ayrıca sorulabilir. Bir uygulamanın teslim edilmiş olması, onu çalıştıran bütün hizmetlerin süresiz ücretsiz olduğu anlamına gelmez. Buna karşılık her projede aynı hizmetlerin gerekli olduğu da varsayılmamalıdır. Kullanılan çözüm ve çalışma ortamı belirleyicidir.

Yazılım maliyet kalemleri tablonuzda ödeme sıklığını ve bedeli kimin aldığı bilgisini tutabilirsiniz. Sağlayıcıya ödenen geliştirme bedeliyle doğrudan başka firmaya ödenen barındırma bedeli ayrı görünsün. Para birimi, yenileme koşulu ve kullanım sınırı gibi ayrıntılar teklifin anlaşılmasına yardımcı olabilir. Bu yazı vergi veya muhasebe sınıflandırması önermez; ilgili konular uzman desteğiyle ayrıca değerlendirilir. Amaç, yazılım çalışmasının günlük işletiminde hangi giderlerle karşılaşılabileceğini iş açısından görünür hale getirmektir.

Teklifte kontrol edilecek 9 maliyet başlığı

1. Keşif ve analiz çalışması

İlk görüşme ile ayrıntılı analiz aynı kapsamda olmayabilir. Süreçlerin incelenmesi, kullanıcılarla konuşulması ve belirsiz bağlantıların araştırılması ayrı çalışma gerektirebilir. Bu çalışmanın sonunda ne üretileceğini sorun. Süreç haritası, gereksinim açıklaması, örnek iş akışı veya açık sorular listesi gibi çıktılar olabilir. Analiz yapılacak ifadesi tek başına yeterli değildir. Hangi sorunun nasıl netleşeceği ve sonraki teklifi nasıl etkileyeceği anlaşılmalıdır. Her projede aynı ayrıntıda analiz gerekmeyebilir; kapsam ihtiyaca göre belirlenir.

Yazılım maliyet kalemleri içinde analiz ayrı gösterilmiyorsa bunun hiç yapılmadığını varsaymayın. Geliştirme paketinin içinde ele alınmış olabilir. Önemli olan yöntemin ve çıktının açıklanmasıdır. Bazı işlerde mevcut belgeler yeterli başlangıç sağlayabilir; bazılarında araştırma olmadan fiyatın kesinleşmesi zordur. Bilinmeyen işin sabit rakama zorlanması yerine önce hangi belirsizliğin giderileceği konuşulabilir. Bu aşamada yapılacak çalışma, bütün projenin mutlaka devam edeceği anlamına gelmez. Sonuç farklı çözüm seçeneğini de gösterebilir.

2. Ekran ve kullanım tasarımı

Tasarım yalnızca renk ve düğme seçimi değildir. Kullanıcı hangi adımla işlem yapacak, hata olduğunda ne görecek ve en sık kullandığı bilgiye nasıl ulaşacak? Bu soruların ele alınması zaman gerektirebilir. Temsili ekran hazırlanacaksa hangi sayıda ve hangi ayrıntıda olacağını sorun. Mobil kullanım, farklı ekran boyutları ve kullanıcıların iş ortamı da değerlendirmeyi etkileyebilir. Her ekranın tamamen özel çizileceği varsayılmamalıdır. Hazır bileşenlerden yararlanılacaksa bunun tasarım kapsamına etkisi açıklanabilir.

Yazılım maliyet kalemleri karşılaştırmasında tasarım düzeltmelerinin nasıl ele alındığını öğrenin. İlk gösterimden sonra kullanıcı geri bildirimi toplanacak mı? Hangi değişiklik tasarım değerlendirmesinin parçası, hangisi yeni iş olacak? Bu ayrım özellikle iş akışını değiştiren taleplerde önemlidir. Bir düğmenin yerinin değişmesiyle sipariş onay sürecinin yeniden kurulması aynı çalışma değildir. Tasarımın onaylanması sırasında henüz test edilmemiş iş kuralları da bulunabilir. Görsel onay, bütün uygulamanın kabul edildiği şeklinde yorumlanmamalıdır.

3. Geliştirme ve iş kuralları

Uygulamanın ekranları, veri işlemleri, roller ve raporlar bu başlıkta ele alınabilir. Teklifte sadece modül adları varsa temel işlemlerin açıklamasını isteyin. Sipariş oluşturma, iptal etme, kısmi teslim ve geçmişi görüntüleme farklı davranışlar gerektirebilir. Hangi işlemlerin ilk sürümde bulunduğu belli olmalıdır. Teknik altyapı işi de görünür ekranlar kadar zaman alabilir. Kullanıcının görmediği bir yapı otomatik olarak gereksiz sayılmamalıdır; fakat neden gerekli olduğu anlaşılır şekilde açıklanmalıdır.

Yazılım maliyet kalemleri içinde geliştirme bedelinin hangi varsayımlara dayandığını sorun. Kullanıcı rollerinin sayısı, verinin büyüklüğü veya dış sisteme bağımlılık sonucu etkileyebilir. Her ayrıntının baştan kesin olması beklenmeyebilir. Önemli olan değişirse yeniden değerlendirilecek konuların adının konmasıdır. Bütün olası özelliklerin ilk sürüme eklenmesi şart değildir. İşletme için değer üreten sınırlı başlangıç kapsamı oluşturulabilir. Daha sonra düşünülen modüller ayrı tutulduğunda hem karşılaştırma hem takvim daha anlaşılır hale gelir.

4. Dış sistem bağlantıları

Muhasebe, pazaryeri, kargo veya başka hizmetle veri alışverişi ayrı iş gerektirebilir. Bağlantının yapılabilmesi için mevcut sistemin güncel belgeleri ve erişim koşulları incelenmelidir. Sadece API var denmesi bütün işin kolay olduğunu göstermez. Hangi verilerin hangi yönde aktarılacağı, hataların nasıl izleneceği ve kullanım sınırları değerlendirilir. Sağlayıcının test hesabı veya ücretli erişim gerektirip gerektirmediği sorulabilir. Bir bağlantının geliştirme bedeliyle dış hizmetin kendi kullanım bedeli birbirinden ayrılmalıdır.

Yazılım maliyet kalemleri tablosunda her bağlantının adını ve kapsamını ayrı not etmek yararlıdır. Örneğin siparişleri almakla sipariş durumlarını geri göndermek aynı iş değildir. İlk eşitleme ve günlük güncellemeler farklı davranabilir. Başka sağlayıcıdan cevap beklenmesi takvimi de etkileyebilir. Bu beklemelerin kim tarafından takip edileceği belli olsun. İşletmenin mevcut anlaşmasında bağlantı izni bulunup bulunmadığı kesinleşmeden bağlantının garanti olduğu kabul edilmemelidir. Belirsizliği görünür bırakmak, sonradan sürpriz yaşanmasından daha yararlıdır.

5. Veri hazırlığı ve aktarımı

Eski kayıtların yeni programa taşınması yalnızca dosya yüklemekten oluşmayabilir. Alanların eşleştirilmesi, tekrarların ayrılması ve eksik bilgilerin değerlendirilmesi gerekir. Hangi verinin taşınacağı, hangi dönemi kapsayacağı ve ilişkilerin nasıl korunacağı açıklanmalıdır. Müşteri kaydı taşınırken geçmiş işlemlerin dışarıda kalması işletme açısından önemli olabilir. Veri temizliğini kimin yapacağı da ayrı sorudur. İşletmenin karar vermesi gereken belirsizlikler geliştirici tarafından tahminle doldurulmamalıdır. Örnek aktarım ve sonuç kontrolü planlanabilir.

Yazılım maliyet kalemleri içinde aktarımın bulunması, bütün eski dosyaların sınırsız işleneceği anlamına gelmez. Kaynak dosya biçimi ve veri kalitesi değiştiğinde çalışma kapsamı etkilenebilir. Aktarım sonunda hangi sayımların veya örnek kontrollerin yapılacağını sorun. Kayıt sayısının eşit olması tek başına ilişkilerin doğru taşındığını göstermeyebilir. Eksik ve tekrar kayıtların nasıl raporlanacağı açıklanmalıdır. Canlıya geçiş sırasında yeni eklenen kayıtların hangi sistemde tutulacağı da düşünülmelidir. Geçiş planı olmadan aynı veri iki yerde değişebilir.

6. Test ve kabul hazırlığı

Teknik kontroller, kullanıcı denemeleri ve bulunan sorunların düzeltilmesi için zaman gerekir. Bu işlerin teklif kapsamında nasıl ele alındığını sorun. Her test türünü teknik ayrıntısıyla bilmeniz gerekmez; hangi riskin nasıl kontrol edileceğini öğrenmeniz yeterlidir. İşletmenin değerlendireceği senaryolar hazırlanmalıdır. Normal işlemin yanında iptal, eksik bilgi ve yetki sınırları uygulamaya göre denenebilir. Test ortamının hazırlanması ve örnek verinin düzenlenmesi de görünmeyen çalışma kalemleri olabilir. Sadece son gösterim bütün kontrollerin yerine geçmez.

Yazılım maliyet kalemleri değerlendirmesinde kullanıcıların ayıracağı zamanı unutmayın. İşletme denemelere katılmadığında günlük kullanıma ilişkin önemli eksikler geç fark edilebilir. Bununla birlikte teknik test sorumluluğu tamamen kullanıcıya devredilmemelidir. Bulgunun kaydı, önceliği ve düzeltme kontrolü anlaşılır olsun. Her yeni fikir hata olarak değerlendirilmemelidir. Başlangıç kapsamındaki davranışla yeni istenen davranış ayrılır. Bu ayrım doğru yapılırsa test sırasında maliyet tartışması yerine önce gerçek sorunun anlaşılmasına odaklanılabilir.

7. Kurulum ve geçiş

Geliştirilen uygulamanın kullanılacağı ortama kurulması, erişimlerin hazırlanması ve geçişin yapılması ayrı görevler içerebilir. Deneme ortamıyla canlı ortam farklı olabilir. Geçişte hangi kişinin hangi adımı yapacağı ve sorun çıkarsa ne yapılacağı planlanmalıdır. Her projede karmaşık geçiş gerekmez; ancak günlük işin ne zaman yeni sisteme alınacağı bilinmelidir. Kullanıcıların eski ve yeni kayıtları birlikte nasıl okuyacağı da konuşulabilir. Kurulumun tamamlanması, bütün kullanıcıların çalışmaya hazır olduğu anlamına gelmeyebilir.

Yazılım maliyet kalemleri arasında barındırma kurulumu ve barındırma kullanımını ayırın. Bir defalık ortam hazırlığı ile devam eden kaynak bedeli farklı giderler olabilir. Alan adı, e-posta veya güvenli erişim gibi başlıkların kime ait olduğu açıklansın. Gerekli hesapların hangi adla açılacağı ve kimlerin yöneteceği belli olmalıdır. Üretim erişimlerini tek kişinin kişisel hesabına bağlamak ileride devir konusunu zorlaştırabilir. Uygulanacak yöntem kullanılan hizmete göre ayrıca değerlendirilir; bütün projeler için tek kurulum şekli yoktur.

8. Eğitim ve kullanım belgeleri

Kullanıcıların yeni işleyişi öğrenmesi için gösterim, kısa yönerge veya örnek senaryo gerekebilir. Bunun teklif içinde bulunup bulunmadığını sorun. Eğitim denildiğinde kaç kişinin, hangi yöntemle ve hangi konularda bilgilendirileceği anlaşılmalıdır. Bir kez yapılan genel gösterim bütün görevler için yeterli olmayabilir. Satış, depo ve yöneticinin kullanacağı işlemler farklıysa içerik de farklılaşabilir. Belge hazırlanacaksa uygulama değiştikçe nasıl güncelleneceği konuşulmalıdır. Eski ekranları anlatan yönerge zamanla kullanıcıyı yanlış yönlendirebilir.

Yazılım maliyet kalemleri karşılaştırmasında eğitim ve destek aynı başlıkta geçiyorsa ayrıntısını öğrenin. Teslimden sonra kullanıma ilişkin soru sormakla yeni çalışanlara kapsamlı eğitim vermek farklı işler olabilir. Kullanıcıların hata bildirimini nasıl yapacağını öğrenmesi de önemlidir. Hangi işlem, hangi kayıt ve hangi beklenen sonuç bilgileriyle başvuracaklarını bilmeleri incelemeyi kolaylaştırır. İşletmenin içindeki deneyimli kullanıcıların yeni kişilere aktaracağı bilgiler için basit bir düzen oluşturulabilir. Bu rolün kimde olacağı başlangıçta konuşulabilir.

9. Bakım ve düzenli hizmetler

Uygulama kullanıma girdikten sonra dış hizmetler, çalışma ortamı ve işletme ihtiyaçları değişebilir. Hangi bakımın hangi koşullarda yapılacağını sorun. Güvenlik güncellemesi, hata düzeltme ve yeni özellik geliştirme aynı hizmet değildir. Destek süresinin başlangıcı ve bitişi anlaşılır olmalıdır. Sınırsız bakım gibi geniş ifadeler varsa neleri kapsadığı açıklanmalıdır. Bir hizmetin ilk dönem dahil olması gelecekteki koşullarını kendiliğinden belirlemez. Uygulamanın kullanım yoğunluğu ve önemine uygun çalışma düzeni değerlendirilmelidir.

Yazılım maliyet kalemleri içinde devam eden giderleri ayrı bir takvimde gösterebilirsiniz. Hangi hizmet aylık veya yıllık yenileniyor, kullanım arttığında hangi sınır devreye giriyor? Bunları kesin fiyat vermeden de listelemek mümkündür. Güncel tutarlar ilgili sağlayıcının resmi tarifesinden veya teklifinden doğrulanmalıdır. Bir üçüncü taraf ücretinin değişmeyeceği varsayılmamalıdır. İşletme tarafından doğrudan yönetilen hesaplar ve sağlayıcının yönettiği hizmetler ayrılırsa ileride neyin neden ödendiği daha kolay anlaşılır.

Altyapı giderlerini tahmin ederken ne sorulmalı?

Uygulamanın nerede çalışacağı, hangi kaynakları kullanacağı ve kullanımın nasıl büyüyeceği maliyet değerlendirmesini etkileyebilir. Başlangıçtaki kullanıcı sayısı tek değişken değildir. Dosya boyutları, eşzamanlı işlemler ve veri saklama ihtiyaçları da önemlidir. Kesin teknik çözüm belirlenmeden kalıcı altyapı bedeli söylenmemelidir. Hangi varsayımlarla tahmin yapıldığı kaydedilsin. Kullanım arttığında giderin hangi koşulda değişeceği sorulabilir. Her işletmenin kendi sunucusunu alması veya belirli bulut hizmetini seçmesi gerektiği sonucu çıkarılmamalıdır.

Yazılım maliyet kalemleri üzerine altyapı konuşurken Microsoft’un çok kiracılı çözümlerde çalışma kaynağı yaklaşımını inceleyebilirsiniz. Resmi rehber, paylaşılan kaynakların maliyet ve yalıtım gibi farklı etkileri bulunduğunu açıklar. Bu, sizin uygulamanızda aynı mimarinin kullanılacağı anlamına gelmez. Burada önemli olan seçilen çalışma ortamının ticari ve teknik sonuçlarının birlikte değerlendirilmesidir. Sağlayıcıdan önerisinin sizin kullanımınıza neden uygun olduğunu anlaşılır biçimde açıklamasını isteyin.

Varsayımsal örnek: Benzer toplamların farklı içeriği

Yazılım maliyet kalemleri örneği olarak iki sağlayıcının aynı işletme için teklif verdiğini düşünelim. Bu tamamen varsayımsal örnekte ilk teklif yeni müşteri ve sipariş ekranlarını kapsıyor. İkinci teklif aynı ekranlarla birlikte eski kayıtların örnek aktarımını ve kullanıcı gösterimini de içeriyor. Toplam bedeller birbirine yakın olsa bile işletmeye kalan iş farklıdır. İlk teklifin yanlış olduğunu söylemek için yeterli bilgi yoktur. İşletme veriyi kendisi hazırlayabilir ve eğitimi içeride verebilir. Ancak bunun gerçekten mümkün olduğu kontrol edilmelidir.

Yazılım maliyet kalemleri bu örnekte soruları görünür kılar: aktarılacak kayıtlar kim tarafından temizlenecek, son kontrolü kim yapacak ve kullanıcılar hangi belgeyi okuyacak? İlk sağlayıcıdan bu işler için açıklama istenir. İkinci sağlayıcının dahil ettiği çalışmanın sınırı da öğrenilir. Aynı kapsam üzerinde karşılaştırma ancak bundan sonra yapılabilir. Burada gerçekleşmiş fiyat, müşteri veya sonuç bulunmamaktadır. Örnek, bir toplam rakamın arkasındaki iş dağılımının neden incelenmesi gerektiğini göstermek içindir.

Belirsizlik payını gizli bütçe gibi kullanmayın

Yazılım maliyet kalemleri hazırlanırken her iş baştan tam açıklıkta olmayabilir. Bu nedenle bazı kalemler tahmini veya araştırma sonrası kesinleşecek olarak gösterilebilir. Bu durum açıkça belirtilmelidir. Belirsizliğin nedeni ve nasıl azaltılacağı anlaşılmıyorsa bütçe takibi zorlaşır. Ek çalışma için ayrılan pay da hangi kararlarla kullanılacağının açıklanmasına ihtiyaç duyar. Rastgele oran belirlemek yerine projedeki gerçek belirsizlikleri listelemek daha yararlıdır. Eski sistem bağlantısının araştırılmamış olmasıyla ekran rengi tercihinin belirsiz olması aynı etkiyi doğurmaz.

Yazılım maliyet kalemleri güncellendiğinde başlangıç bütçesiyle farkını kaydedin. Değişikliğin nedeni yeni ihtiyaç, teknik bilgi veya dış sağlayıcı koşulu olabilir. Bu nedenler birbirine karıştırılmamalıdır. Her yeni toplamın hangi onaya dayandığı görülebilmelidir. İlerleme raporunda yalnızca harcanan para değil, tamamlanan çıktılar ve kalan iş de bulunmalıdır. Ödeme yapılması işin tamamlandığını, bir ekranın gösterilmesi bütün teslimin kabul edildiğini kendiliğinden kanıtlamaz. Bütçe değerlendirmesi somut çıktılarla birlikte yapılmalıdır.

Bütçe tablosunu günlük takipte kullanmak

Yazılım maliyet kalemleri yalnızca teklif gününde okunacak liste olarak kalmamalıdır. Proje ilerlerken tamamlanan işin başlangıç beklentisiyle ilişkisi görülebilmelidir. Her ödeme döneminde aynı soruları sorun: hangi çıktı alındı, hangi kontrol yapıldı ve hangi iş henüz bekliyor? Bir faturanın gelmesiyle bütün teslimin tamamlandığını varsaymayın. Ödeme düzeni tarafların anlaşmasına bağlıdır; fakat işletme açısından ilerlemenin anlaşılması ayrıca gerekir. Kontrolün kim tarafından yapılacağı baştan belirlenirse bu takip kişisel hatırlamaya dayanmaz.

Yazılım maliyet kalemleri tablosuna durum sütunu ekleyebilirsiniz. Planlandı, açıklama bekliyor, başladı ve tamamlandı gibi basit seçenekler yeterli olabilir. Fiyatı henüz kesinleşmemiş başlıkları da işaretleyin. Sayfa çok karmaşık hale gelirse yalnızca önemli teslimler ve devam eden giderler gösterilebilir. Amaç muhasebe sisteminin yerine yeni bir sistem kurmak değildir. Projedeki iş dağılımını ve karar ihtiyacını yönetilebilir biçimde takip etmektir. Her satırın sorumlusu ve dayandığı belge belli olmalıdır.

Dış hizmet faturalarını gözden geçirmek

Yazılım maliyet kalemleri içinde dış sağlayıcı giderleri varsa bunların kullanım koşulları kontrol edilmelidir. Başlangıç paketi belirli işlem miktarını kapsayabilir; kullanım arttığında farklı koşullar geçerli olabilir. Güncel tarife ilgili sağlayıcıdan doğrulanır. Teklif hazırlanırken kullanılan bilgi tarihi de kaydedilebilir. Geçmişteki fiyatın bugün de aynı olduğu varsayılmamalıdır. İşletmenin doğrudan ödeyeceği hizmetle geliştirme sağlayıcısının kendi paketi içinde yönettiği hizmet ayrı anlaşılmalıdır. Yenileme bildirimlerini kimin takip edeceği de belli olsun.

Yazılım maliyet kalemleri listesindeki her dış hizmet için kapatıldığında ne olacağını sorun. Kullanım durursa verilere erişim sürer mi, uygulama hangi işlevi kaybeder ve dışa aktarma gerekir mi? Bu cevaplar bedel kadar kararınızı etkileyebilir. Hizmeti sırf düşük rakam nedeniyle seçmek, daha sonra taşıma veya kullanım sınırlarını gözden kaçırmanıza yol açabilir. Bu sorular bütün hizmetlerin kötü veya riskli olduğu anlamına gelmez; bağımlılıkların anlaşılması için sorulur. Sağlayıcının resmi açıklamalarıyla doğrulama yapılmalıdır.

Tekrar eden işlerin nedenini ayırmak

Yazılım maliyet kalemleri güncellenirken aynı isimli işin tekrar görünmesi otomatik olarak çift ücret anlamına gelmez. Örneğin ilk veri aktarımı deneme amacıyla, ikinci aktarım canlı geçiş için yapılabilir. Buna karşılık aynı teslimin iki farklı başlık altında sayılıp sayılmadığını sormak da doğaldır. Hangi işlemin ne zaman ve neden tekrarlandığını öğrenin. Benzer adların arkasındaki çıktı farklı olabilir. Açıklama bulunmadığında fiyat tartışmasından önce işin kendisini netleştirmek daha yararlıdır.

Yazılım maliyet kalemleri açısından yeniden yapılan işin kaynağı da önemlidir. Başlangıç verisinin değişmesi, kullanıcı kararının güncellenmesi veya teknik hatanın düzeltilmesi farklı durumlardır. Hepsini ek geliştirme olarak toplamak yerine nedeni kaydedin. Tarafların sorumluluğu üzerinde anlaşılmış kapsama göre değerlendirilir. Bu yazı belirli bir durumda hangi tarafın ödeme yapacağına karar vermez. Ancak nedenin görünür olması, görüşmenin kişisel yorum yerine somut bilgi üzerinden yapılmasına yardımcı olur. Değişiklik onayları da ilgili kayda bağlanabilir.

İşletme zamanını görünür kılmak

Yazılım maliyet kalemleri dışında kaldığı düşünülen çalışan zamanı bütçeyi dolaylı etkileyebilir. Kullanıcıların iki gün veri kontrolü yapması gerekiyorsa bunu günlük iş planına yerleştirmek gerekir. Aynı kişiden yoğun iş döneminde hem normal görevini hem geçiş hazırlığını eksiksiz yapması beklenmemelidir. Ayrılacak süre kesin bilinmiyorsa tahmin olduğu belirtilir. İşletme içindeki emeğin parasal hesabını yapmak zorunlu değildir; kimin ne zaman çalışacağını bilmek bile planı iyileştirir. Eksik kapasite teslim kontrolünü geciktirebilir.

Yazılım maliyet kalemleri ile sorumlulukları aynı tabloda görmek, bazı işleri erteleme kararını da kolaylaştırabilir. Gerekli olmayan bir rapor sonraki sürüme bırakılabilir; fakat bu ertelemenin günlük işte nasıl karşılanacağı bilinmelidir. Ertelenen iş bedelden çıkarken başka bir geçici iş yükü yaratabilir. Bu etkiyi değerlendirmeden sadece başlangıç rakamını küçültmek yeterli olmaz. Öncelik, sınırlı kaynakla hangi faydanın önce sağlanacağıdır. Kararın gerekçesi ve sonraki değerlendirme zamanı kaydedilirse unutulan ihtiyaçlarla bilinçli ertelemeler birbirine karışmaz.

Maltepe ve çevresinde teklif görüşmesine hazırlanmak

Yazılım maliyet kalemleri konusunda görüşmek isteyen Maltepe, İdealtepe ve Anadolu Yakası işletmeleri, mevcut dosyalarını ve ilk sürüm beklentilerini kısa bir paket halinde hazırlayabilir. Yakın konum ihtiyaçların anlatılmasını kolaylaştırabilir; fakat aynı iş için herkesin aynı bütçeye sahip olacağı anlamına gelmez. İşletmenin süreçleri ve verileri farklıdır. Yüz yüze veya uzaktan görüşmenin yöntemi ayrıca kararlaştırılır. Sadece bölge bilgisiyle fiyat, süre veya yerinde destek taahhüdü çıkarılmamalıdır.

HD Bilgisayar ile özel yazılım geliştirme kapsamını değerlendirirken hangi işlerin ilk sürümde gerektiğini konuşabilirsiniz. İletişim numarası 0532 396 34 71, adres Altayçeşme, Oba Çıkmazı No:3, Maltepe, İstanbul’dur. Bu rehber belirli bir iş için fiyat teklifi değildir. Yapılacak çalışma, teslimler ve sorumluluklar ihtiyaca göre ayrıca netleştirilir. Görüşmeye gelmeden önce zaman ve yöntem için iletişim kurmak, ilgili belgelerin hazırlanmasını da kolaylaştırabilir.

Teklifi okumadan önce kısa kontrol listesi

Yazılım maliyet kalemleri tablonuzun son halinde her satırın karşılığı anlaşılır olsun. Ayrı bedeli olmayan kalemlerin hangi pakette yer aldığını not edin. Dahil değil yazan işin işletmede kimin sorumluluğunda olduğunu belirleyin. Dış sağlayıcı koşullarını kesin bilgi ve araştırılacak konu olarak ayırın. Böylece fiyat görüşmesi yalnızca indirim talebine dönüşmez. Hangi işin neden gerekli olduğunu ve ilk sürümde nelerin ertelenebileceğini konuşmak daha somut bir değerlendirme sağlar.

• İlk sürümün kapsamı ve kapsam dışı işler açık mı?
• Analizin hangi çıktıyı üreteceği biliniyor mu?
• Tasarım ve geliştirme beklentileri ayrı açıklanmış mı?
• Dış bağlantıların ve veri aktarımının sınırları belli mi?
• Test ve kullanıcı denemesi için zaman ayrılmış mı?
• Kurulum ve geçiş sorumluları belirtilmiş mi?
• Eğitim ve kullanım belgeleri tanımlanmış mı?
• Tek seferlik ve devam eden giderler ayrılmış mı?
• Ek çalışma için onay yöntemi kararlaştırılmış mı?

Sık sorulan 6 soru

Her maliyet başlığına ayrı rakam yazılmalı mı?

Şart değildir. Bazı işler ortak paket içinde fiyatlandırılabilir. Önemli olan hangi işlerin dahil olduğunun anlaşılmasıdır. Yazılım maliyet kalemleri ayrı tutarlarla gösterilmese bile kapsam açıklaması bulunabilir. Her şeyi tek toplamda bırakmak belirsizlik yaratıyorsa önemli teslimleri ve dışarıda kalan işleri açıklatın. Bir kalemin bedeli görünmüyor diye ücretsiz olduğu veya hiç yapılmadığı sonucuna varmayın. Karşılaştırma, fiyat biçimiyle birlikte iş kapsamını da dikkate almalıdır.

En ucuz teklif daha mı avantajlıdır?

Bu ancak aynı işin karşılaştırılmasıyla anlaşılabilir. Veri hazırlığı, eğitim veya destek işletmeye bırakılmış olabilir. İşletmenin zamanı da kaynak gerektirir. Yazılım maliyet kalemleri tablosunda bu farklar görünür olduğunda seçenekler daha sağlıklı değerlendirilir. Yüksek bedelin de otomatik olarak daha kapsamlı hizmet sunduğu varsayılmamalıdır. Önce kapsamı eşitleyin, sonra teslimleri ve sorumlulukları karşılaştırın. Kararınızı yalnızca toplam rakamın büyüklüğüne dayandırmayın.

Veri aktarımı neden ayrıca konuşuluyor?

Mevcut kayıtların yapısı ve kalitesi projeden projeye değişir. Alan eşleme, tekrarların ayıklanması ve sonuç kontrolü gerekebilir. Tek dosyanın yüklenebilmesi bütün ilişkili bilgilerin taşındığını göstermez. Müşteri geçmişi ve ek dosyalar gibi başlıklar ayrıca incelenebilir. Hangi kayıtların aktarılacağına karar verilmeden çalışma büyüklüğü tahmin edilemeyebilir. İşletmenin temizleyeceği bilgiler ve sağlayıcının yapacağı teknik işlemler ayrı açıklanmalıdır.

Destek bedeli her projede zorunlu mu?

Çalışma koşulları projeye ve tarafların anlaşmasına bağlıdır. Ancak teslimden sonra hangi soruların kime yöneltileceği bilinmelidir. Destek, bakım ve yeni özellik geliştirme aynı iş değildir. Yazılım maliyet kalemleri değerlendirmesinde bunların birbirine karışmadığından emin olun. Devam eden bir hizmet öneriliyorsa kapsamını ve yenileme koşullarını sorun. Gerekmeyen hizmeti almak kadar, gerekli desteği hiç planlamamak da işletmenin kullanımını zorlaştırabilir.

Başlangıç bütçesi daha sonra değişebilir mi?

Yeni kapsam, veri hakkında yeni bilgi veya dış hizmet koşulları değişiklik gerektirebilir. Etkinin açıklanması ve onaylanması önemlidir. Her fark doğrudan hata veya kötü planlama olarak görülmemelidir; nedeni incelenmelidir. Başlangıç varsayımları kayıtlıysa değişikliğin kaynağı daha kolay anlaşılır. Onay verilmeden ek işe başlanıp başlanmayacağı da konuşulmalıdır. Bütçe takibi sadece harcanan tutarı değil, kalan işi ve beklenen çıktıları da kapsamalıdır.

Görüşmede ilk hangi soruyu sormalıyım?

Yazılım maliyet kalemleri hakkında en yararlı başlangıç sorusu, bu teklif sonunda hangi işi yapabilir hale geleceğiz olabilir. Ardından bu sonucu elde etmek için işletmenin hazırlayacağı veriyi, vereceği kararları ve alacağı sorumluluğu sorun. Böylece konuşma tek rakam yerine gerçek çıktıya bağlanır. Belirsiz konuların nasıl araştırılacağını ve ne zaman netleşeceğini kaydedin. Anlaşılır kapsam, hem teklif değerlendirmesinin hem daha sonraki bütçe takibinin temelidir.