Web Yazılım Firmasından Eski Sistemi Yenileme Teklifi Nasıl Alınır?

Mevcut sistem incelenmeden güvenilir teklif verilebilir mi?

Mevcut sistem ayrıntılı biçimde incelenmeden verilen teklif ancak ön tahmin niteliğinde olabilir; güvenilir proje teklifi için çalışan yapının teknik sınırlarının görülmesi gerekir. Kaynak kodun erişilebilirliği, kullanılan framework ve kütüphaneler, veritabanı yapısı, barındırma ortamı, kullanıcı rolleri, entegrasyonlar ve kritik iş akışları yenileme kapsamını doğrudan etkiler. Teknik keşif, hangi bileşenlerin korunabileceğini, hangilerinin yeniden geliştirilmesi gerektiğini ve hangi alanlarda henüz kesin karar verilemediğini ortaya koyan ilk teslim aşamasıdır.

Ön fiyat ile kapsamlandırılmış teklifi birbirinden ayırın

İlk görüşmede firma genel bir bütçe çerçevesi veya çalışma modeli paylaşabilir; ancak bağlayıcı kapsam için sistem incelemesinin nasıl yapılacağını açıklamalıdır. web yazılım ajansı ile proje sürecinin nasıl yönetildiğini açıklayan yaklaşım, keşif, geliştirme ve kabul adımlarının teklif öncesinde ayrıştırılmasına yardımcı olur. Alıcı açısından önemli olan, bilinmeyen işlerin fiyatın içine rastgele eklenmesi değil, varsayım ve belirsizliklerin görünür biçimde raporlanmasıdır.

• Kaynak kod ve sürüm geçmişine erişim durumunu belirleyin.
• Kullanılan teknoloji ve bağımlılıkların güncelliğini inceleyin.
• Kritik kullanıcı rollerini ve iş akışlarını çıkarın.
• Veritabanı, dosya depolama ve entegrasyon noktalarını listeleyin.
• Kesinti kabulü ve operasyon önceliklerini dokümante edin.

Bana göre eski kod, basitçe testleri olmayan koddur. - Michael C. Feathers

Teklif öncesinde hangi teknik bilgiler hazırlanmalı?

Teklif öncesinde hazırlanacak bilgiler, firmanın sistemi daha hızlı anlamasını ve aynı kapsam için farklı varsayımlar üretmesini azaltır. Kullanılan programlama dili ve framework, sunucu yapısı, veritabanı motoru, kullanıcı sayıları, temel roller, günlük kritik işlemler, dış servis bağlantıları ve bilinen sorunlar mümkün olduğunca tek dosyada toplanmalıdır. Dokümantasyon eksikse bu durum gizlenmemeli; hangi bilgilerin mevcut olmadığı da teknik keşfin girdisi olarak belirtilmelidir. Böylece firma eksik doküman için ayrıca inceleme eforu gerekip gerekmediğini değerlendirebilir.

İşletme sorunlarını teknik envanterle birlikte paylaşın

Yalnızca teknoloji listesi vermek yeterli değildir. Hangi ekranların yavaş olduğu, hangi işlemlerde manuel müdahale gerektiği, hangi entegrasyonların sık hata verdiği, hangi raporların güvenilmez bulunduğu ve ekiplerin hangi geliştirmeleri yapamadığı da paylaşılmalıdır. Önceliklendirilmiş sorun listesi, yenileme projesinin teknik borç temizliği mi, kapasite artışı mı, kullanıcı deneyimi iyileştirmesi mi yoksa daha kapsamlı yeniden geliştirme mi gerektirdiğini belirlemeye yardımcı olur.

• Teknoloji yığını ve önemli paket sürümlerini listeleyin.
• Veritabanı büyüklüğü ve temel veri kümelerini açıklayın.
• Kullanıcı rolleri ve yetki farklılıklarını belirtin.
• Günlük kritik işlem ve operasyon bağımlılıklarını tanımlayın.
• Entegrasyonları ve dış servis sahiplerini kaydedin.
• Bilinen sorunları iş etkisine göre önceliklendirin.

Yeniden geliştirme mi kademeli dönüşüm mü nasıl seçilir?

Yeniden geliştirme ile kademeli dönüşüm arasında seçim, mevcut kodun yaşına tek başına bakılarak yapılmamalıdır. Sistemin test edilebilirliği, modülerliği, veri bağımlılıkları, entegrasyon yoğunluğu, kritik iş kuralları ve değişiklik yapma maliyeti birlikte değerlendirilmelidir. Bazı sistemlerde belirli modüllerin korunup sorunlu alanların yenilenmesi daha kontrollü olabilir; bazı durumlarda ise mevcut mimari yeni gereksinimleri taşımadığı için daha geniş yeniden geliştirme gerekebilir. Dönüşüm stratejisi, teknik incelemenin gerekçeli sonucu olmalıdır.

Kararı modül ve bağımlılık düzeyinde verin

Aday firmadan sistemi tek parça olarak “eski” veya “yeniden yazılmalı” diye sınıflandırmak yerine modül bazında değerlendirmesi istenmelidir. özel yazılım geliştirme sürecinin nasıl planlandığını açıklayan rehber, gereksinim, mimari, geliştirme, test ve canlıya geçiş aşamalarını ayrı ele almak için yararlı bir çerçeve sunar. Korunacak modüller, geçici köprüler ve yeniden geliştirilecek bileşenler netleştiğinde teklif de daha anlaşılır hale gelir.

• Modüllerin iş kritikliği ve değişim sıklığını değerlendirin.
• Test kapsamı olmayan alanları ayrı risk olarak işaretleyin.
• Sıkı bağlı bileşenleri ve ortak veri bağımlılıklarını belirleyin.
• Korunabilecek servis ve modülleri gerekçeleriyle listeleyin.
• Kademeli geçişte geçici entegrasyon ihtiyacını hesaplayın.

Veri taşıma ve temizleme ayrı teklif kalemleri olmalı mı?

Veri taşıma ve veri temizliği ayrı kapsam kalemleri olarak görünmelidir çünkü aynı işlem değildir. Taşıma; kayıtların eski yapıdan yeni şemaya aktarılmasını, alan eşlemelerini, ilişki bütünlüğünü ve doğrulama kontrollerini kapsarken temizlik; mükerrer, eksik, geçersiz veya artık kullanılmayan kayıtlar hakkında iş kararı gerektirir. Verinin hacmi kadar kalitesi ve geçmişten gelen tutarsızlıklar da eforu değiştirir. Veri geçiş kapsamı, hangi tabloların taşınacağını ve hangi kayıtların dönüşüm kuralına tabi olacağını açıkça göstermelidir.

Taşıma maliyetini veri kalitesiyle birlikte değerlendirin

Yeni yazılımın geliştirme bedeli ile veri geçişi aynı başlık altında bırakılırsa tekliflerin neden farklılaştığını anlamak zorlaşır. özel yazılım geliştirme maliyetini etkileyen unsurları açıklayan içerik, kapsam, entegrasyon ve teknik karmaşıklığın fiyatlandırmadaki rolünü daha geniş çerçevede ele alır. Firma, örnek veri üzerinde dönüşüm kuralı oluşturabiliyor ve taşıma sonrası doğrulama yöntemini tarif edebiliyorsa bu kalem daha ölçülebilir hale gelir.

• Taşınacak veri kümelerini ve hariç tutulacak kayıtları tanımlayın.
• Eski ve yeni alanlar için eşleme kuralları hazırlayın.
• Mükerrer ve eksik veriler için iş kararlarını belirleyin.
• Deneme taşıması ve sonuç doğrulaması planlayın.
• Canlı taşıma sırasında değişen veriler için yöntem oluşturun.
• Veri temizliği ile teknik taşıma eforunu ayrı gösterin.

Entegrasyonların yeniden geliştirilmesi maliyeti nasıl etkiler?

Entegrasyonların yeniden geliştirilmesi maliyeti, bağlantı sayısından çok her entegrasyonun protokolüne, veri akışına, hata yönetimine, güvenlik gereksinimine ve karşı sistemde değişiklik yapılıp yapılmayacağına bağlıdır. Eski sistemde doğrudan veritabanı bağlantısı, dosya aktarımı veya belgelenmemiş servis kullanılıyorsa yeni mimaride bunların yeniden tasarlanması gerekebilir. Ayrıca ERP, CRM, ödeme, kimlik doğrulama veya özel sektör servislerinin test ortamları ve erişim yöntemleri farklı olabilir. Entegrasyon envanteri, teklifin ayrı bir teknik girdisi olmalıdır.

Her bağlantı için sahiplik ve test koşulunu sorun

Entegrasyon kapsamını değerlendirirken yalnızca “API bağlantısı yapılacak” ifadesi yeterli değildir. kurumsal yazılım entegrasyonunun ERP ve CRM ile nasıl planlandığını açıklayan rehber, veri sahipliği ve sistem sınırlarının neden önceden tanımlanması gerektiğini gösterir. Sağlayıcıdan her entegrasyon için kaynak sistem, hedef sistem, veri yönü, kimlik doğrulama yöntemi, hata senaryosu, test erişimi ve sorumluluk sahibini açıklaması istenmelidir.

• Mevcut tüm entegrasyonları kullanım amacına göre listeleyin.
• Belgelenmemiş bağlantıları teknik keşifte ayrı inceleyin.
• Yeni API veya adaptör gereksinimlerini belirleyin.
• Karşı sistem ekiplerinin sorumluluklarını netleştirin.
• Test ortamı ve örnek veri erişimini doğrulayın.
• Hata, yeniden deneme ve kayıt izleme yaklaşımını teklif kapsamına alın.

Canlı sistem çalışırken yenileme geçişi nasıl planlanır?

Canlı sistem çalışmaya devam edecekse geçiş tek bir yayın anından ibaret düşünülmemelidir. Eski ve yeni sistem arasında veri senkronizasyonu, kullanıcı gruplarının aşamalı taşınması, belirli modüllerin paralel çalışması ve kritik hatada geri dönüş senaryosu planlanmalıdır. Hangi noktadan sonra eski sisteme veri yazılmayacağı ve geçiş sırasında oluşan yeni kayıtların nasıl ele alınacağı özellikle önemlidir. Geçiş planı, teknik adımların yanında iş birimlerinin hangi sırayla etkileneceğini de göstermelidir.

Kesinti kabulünü ve geri dönüş eşiğini önceden belirleyin

İşletmenin kesinti toleransı düşükse firma, veri taşıma ve yayın işlemlerini buna göre parçalamalıdır. Paralel kullanım her proje için zorunlu değildir; ancak gerekli olduğunda iki sistemde oluşabilecek veri farklarının nasıl uzlaştırılacağı açıklanmalıdır. Geri dönüş planı da yalnızca eski sunucuyu yeniden açmak anlamına gelmez. Veritabanı değişikliklerinin, yeni kayıtların, dosyaların ve entegrasyon mesajlarının hangi noktaya döndürüleceği teknik olarak tanımlanmalıdır.

• Geçiş öncesi son veri senkronizasyon adımını belirleyin.
• Kullanıcı veya modül bazlı aşamalı geçiş ihtiyacını değerlendirin.
• Paralel kullanım varsa veri sahipliğini açıkça tanımlayın.
• Kesinti penceresi ve operasyon iletişimini planlayın.
• Geri dönüş tetikleyicilerini ve yetkili kişiyi belirleyin.
• Geçiş sonrası kritik iş akışlarını hemen doğrulayın.

Belirsiz işler ve varsayımlar teklifte nasıl gösterilmeli?

Teknik keşif tamamlandığında bile bazı alanlar kesinleşmemiş olabilir; güvenilir teklif bu belirsizlikleri saklamak yerine açıkça göstermelidir. Erişilemeyen üçüncü taraf sistem, eksik kaynak kod, dokümante edilmemiş iş kuralı veya temizlenmemiş veri gibi konular varsayım olarak yazılabilir. Her belirsizlik için fiyatın veya takvimin hangi koşulda yeniden değerlendirileceği tanımlanmalıdır. Varsayım listesi, sonradan kapsam tartışması yaratabilecek konuları teklif imzalanmadan önce görünür hale getirir.

Keşif bulgusunu değişiklik yönetimine bağlayın

Firma, bilinmeyen her işi yüksek risk payıyla fiyatlandırmak yerine hangi inceleme tamamlandığında kapsamın netleşeceğini açıklamalıdır. Özellikle eski sistemlerde üretimde kullanılan fakat kimsenin dokümante etmediği davranışlar bulunabilir. Bu tür davranışlar yeni yazılımda korunacaksa kabul kriterine dönüşmelidir. Keşif sonrası ortaya çıkan yeni gereksinimlerin nasıl onaylanacağı, maliyet etkisinin nasıl sunulacağı ve kim tarafından karar verileceği teklif sürecinin parçası olmalıdır.

• Erişilemeyen sistemleri ve belgeleri varsayım olarak kaydedin.
• Belirsiz iş kurallarını doğrulama sorularına dönüştürün.
• Değişiklik talebinin onay sürecini belirleyin.
• Yeni bulgunun maliyet etkisinin nasıl sunulacağını yazın.
• Kapsam dışı kabul edilen işleri açıkça listeleyin.

Teknik keşif sonunda hangi belgeler teslim edilmeli?

Teknik keşif sonunda yalnızca toplantı notu değil, yenileme teklifinin gerekçesini taşıyan somut belgeler teslim edilmelidir. Asgari olarak mevcut durum özeti, sistem bileşenleri, veri ve entegrasyon envanteri, kritik riskler, önerilen hedef mimari, geçiş yaklaşımı, test kapsamı ve açık varsayımlar görünür olmalıdır. Bu dokümanlar, teklifin neden belirli iş paketlerine ayrıldığını anlamayı sağlar. Keşif çıktısı, alıcının farklı firmaların aynı problemi gerçekten aynı kapsamda fiyatlandırıp fiyatlandırmadığını kontrol edebilmesine yardımcı olmalıdır.

Teklif kalemlerini keşif belgeleriyle ilişkilendirin

Teknik belgeler yalnızca geliştiricilerin kullanacağı ayrıntılı mimari çizimler olmak zorunda değildir; karar vericinin risk ve kapsamı anlayabileceği seviyede hazırlanmalıdır. Her ana teklif kalemi mümkünse bir keşif bulgusuna bağlanmalıdır. Örneğin veri temizliği, belirlenen kalite problemiyle; entegrasyon yenilemesi, mevcut bağlantı kısıtıyla; paralel çalışma ihtiyacı ise operasyonun kesinti toleransıyla ilişkilendirildiğinde fiyatlandırma daha gerekçeli hale gelir.

• Mevcut durum ve teknik borç özeti.
• Uygulama, veritabanı ve entegrasyon envanteri.
• Önerilen hedef mimari ve dönüşüm yaklaşımı.
• Veri taşıma ve test stratejisi.
• Geçiş, rollback ve operasyon riskleri.
• Varsayım, kapsam dışı ve açık karar listesi.

Yazılım bakım devri yenileme teklifine nasıl dahil edilmeli?

Yazılım bakım devri, proje tamamlandıktan sonra başlayan belirsiz bir destek başlığı olarak bırakılmamalı; yenileme teklifinin teslim ve sahiplik planına dahil edilmelidir. Kaynak kod deposu, ortam yapılandırmaları, dağıtım yöntemi, veritabanı yedekleme prosedürü, üçüncü taraf hesapları, teknik dokümantasyon ve izleme erişimleri kimin kontrolünde olacak açıkça belirtilmelidir. Yeni sistemi farklı bir ekip devralacaksa bilgi transferinin formatı ve kabulü de tanımlanmalıdır. Bakım devri, yazılımın kuruma sürdürülebilir biçimde teslim edilmesini sağlar.

Garanti, bakım ve yeni geliştirmeyi birbirinden ayırın

Hata düzeltme, operasyon desteği, sürüm güncelleme ve yeni özellik geliştirme aynı hizmet değildir. Teklifte hangi dönemde hangi hata sınıflarının ele alınacağı, üretim sorunlarının nasıl bildirileceği ve yeni taleplerin nasıl kapsamlandırılacağı ayrı yazılmalıdır. web yazılım ajansı maliyetinin hangi unsurlarla belirlendiğini açıklayan içerik, geliştirme dışındaki bakım ve destek bileşenlerinin de toplam hizmet kapsamı içinde değerlendirilmesine yardımcı olur.

• Kaynak kod ve depo sahipliğini açıkça belirleyin.
• Sunucu ve dağıtım erişimlerinin devir yöntemini yazın.
• Teknik dokümantasyon teslimlerini listeleyin.
• Hata desteği ile yeni geliştirme taleplerini ayırın.
• İzleme, yedekleme ve olay müdahale sorumluluğunu tanımlayın.
• Başka ekibe devir halinde bilgi transferi kapsamını belirleyin.

Eski sistem yenileme teklifleri nasıl karşılaştırılmalı?

Eski sistem yenileme teklifleri yalnızca toplam bedel veya kullanılacak teknoloji üzerinden karşılaştırılmamalıdır. Aynı kapsamı sunduğu düşünülen iki teklif; veri geçişi, entegrasyon yenilemesi, test yaklaşımı, kesintisiz geçiş, belirsizlik yönetimi ve bakım devri açısından önemli ölçüde farklı olabilir. Bu nedenle teklifleri ortak iş paketlerine ayırmak ve her kalemde teslimat, kabul kriteri, sorumlu taraf ve kapsam dışı noktaları görmek gerekir. Karşılaştırılabilir teklif, fiyatın yanında hangi riskin hangi yöntemle yönetildiğini de açıklar.

Firmalardan aynı keşif sorularına dayalı teklif isteyin

Sağlayıcıları değerlendirirken her firmaya farklı bilgi vermek, teklifleri karşılaştırmayı zorlaştırır. yazılım şirketi seçimi ve teklif karşılaştırması için kullanılan kriterler, teknik yeterlilik ile ticari kapsamı aynı çerçevede incelemeye yardımcı olur. Mevcut sistem belgeleri, öncelikli sorunlar, entegrasyon listesi, kesinti beklentisi ve veri gereksinimleri adaylarla aynı biçimde paylaşıldığında tahmine dayalı fiyat yerine gerekçeli proje teklifleri almak kolaylaşır.

• Teklifleri ortak iş paketleri altında karşılaştırın.
• Veri, entegrasyon ve geçiş kapsamlarını ayrı kontrol edin.
• Varsayımları ve kapsam dışı işleri yan yana inceleyin.
• Kabul kriteri ve teslim belgelerini karşılaştırın.
• Bakım, destek ve devir sorumluluklarını değerlendirin.
• Teknik keşif bulgularının fiyatlandırmaya nasıl yansıdığını sorun.