Ankara Yazılım Şirketi Seçerken Teknik Teklif Nasıl İncelenir?

Teknoloji listesinden önce iş sonucunu okuyun

Bir yazılım teklifinde çok sayıda teknoloji adı görmek, çözümün ihtiyacınıza uygun olduğunu göstermez. Kullanılan araçların neden seçildiği ve hangi işi mümkün kıldığı daha önemlidir. Ankara'da bir dağıtım şirketi için stok ve sevkiyat görünürlüğü, bir eğitim işletmesi için kayıt ve program yönetimi öne çıkabilir. İki projede aynı altyapının kullanılması mümkündür; ancak iş kuralları ve kabul ölçütleri farklı olmalıdır. Teklif bu farkı açıkça anlatmalıdır.

İncelemeye kendi probleminizi bir paragrafta yazarak başlayın. Hangi ekip hangi işi yaparken zorlanıyor, mevcut yöntem neden yetersiz ve yazılım sonrasında hangi davranış değişmeli? Ardından teklifin her ana bölümünü bu paragrafla ilişkilendirin. Problemle bağlantısı açıklanmayan özellikler ilk sürüm için gereksiz olabilir. Buna karşılık görünmeyen fakat zorunlu olan veri aktarımı, yetki düzeni ve hata yönetimi gibi işler teklifte ayrı görünmelidir. Eksik görünürlük, sonradan sürpriz iş yükü yaratabilir.

Kapsamı ekran adlarıyla değil görevlerle değerlendirin

“Müşteri ekranı, yönetici ekranı, rapor ekranı” gibi başlıklar kapsamı kabaca gösterir; kullanıcıların ne yapabileceğini açıklamaz. Müşteri kaydı açma, mükerrer kaydı birleştirme, bir görevi başka kişiye devretme ve geçmiş değişiklikleri görme farklı işlerdir. Teklifte temel görevler anlatılmalı, hangi rollerin hangi işlemleri yapabildiği belirtilmelidir. Böylece ekranın varlığı ile işin tamamlanması birbirine karıştırılmaz. Gösterim sırasında da aynı görevler denenebilir.

Kapsam dışını okumak en az kapsam içini okumak kadar önemlidir. Mevcut verinin temizlenmesi, mobil uygulama, muhasebe bağlantısı veya çok dilli kullanım dahil olmayabilir. Bu bir eksiklik olmak zorunda değildir; kararın bilinçli verilmiş olması gerekir. Sonradan yapılacak işler için bağımlılıklar belirtilmelidir. Örneğin bayi portalı ileride planlanıyorsa bugünkü müşteri ve yetki yapısının buna nasıl hazırlanacağı konuşulabilir. Henüz yapılmayacak bütün özelliklerin ayrıntılı tasarımını istemek de gereksiz maliyet doğurabilir.

Verinin nerede oluştuğunu ve kimin değiştirdiğini sorun

Yazılım projelerinde karmaşıklık çoğu zaman ekran sayısından değil, verinin ilişkilerinden doğar. Aynı firma hem müşteri hem tedarikçi olabilir. Bir fırsat birden fazla teklif içerebilir. Sipariş sonrasında teslimat parçalı yapılabilir. Teknik teklif bu ilişkileri işinize uygun biçimde ele almalı, bütün işletmeleri tek bir basit listeye sıkıştırmamalıdır. Gerekli örnek veriyle küçük bir model gösterimi istemek, uzun bir teknik açıklamadan daha anlaşılır olabilir.

Veri taşıma planında yalnızca “Excel içe aktarımı” yazması yeterli olmayabilir. Hatalı alanlar nasıl bulunacak, tekrar eden kayıtlar nasıl değerlendirilecek ve eski sistemle yeni sistem arasında hangi tarihte geçiş yapılacak? Temizleme sorumluluğu kullanıcıda mı ekipte mi olacak? Deneme aktarımından sonra sayım ve örnek kontrol yapılması planlanmalıdır. Özel yazılım kapsam rehberi bu kararların kabul ölçütlerine çevrilmesine yardımcı olabilir. Veri kalitesi, geliştirmeden bağımsız bir hazırlık işi olarak ele alınmalıdır.

Entegrasyon için başarı ve hata yollarını birlikte okuyun

API, iki sistemin tanımlı kurallarla veri alışverişi yapmasına yarayan bir arayüzdür. Teklifte entegrasyon adı kadar hangi verinin hangi yönde taşınacağı önemlidir. MDN'nin istemci ve sunucu açıklaması, istek ve yanıt ayrımını anlatır. Projenizde de isteği hangi sistemin başlattığı, yanıt gecikirse ne olduğu ve kaydın nerede doğrulandığı belli olmalıdır. Sadece bağlantının kurulması bütün akışı tamamlamaz.

Dış sistemin test hesabını kim sağlayacak, erişim bilgilerini kim yönetecek ve servis değişirse sorumluluk nasıl paylaşılacak? Bunları sorarken kesinlikle her hatayı önceden tahmin etmeyi beklemeyin; ekibin hata koşullarını nasıl düşündüğünü anlamaya çalışın. Tekrar deneme, kullanıcıya bildirim ve manuel müdahale yolu gibi kararlar işletmenin çalışmasını etkiler. İşin kritikliği arttıkça bu konuların teklif ve teslim belgelerinde daha açık yer alması gerekir. Entegrasyonun süre bağımlılığı da takvime yazılmalıdır.

Test planını gerçek kabul örnekleriyle değerlendirin

“Testler yapılacaktır” ifadesi, neyin deneneceğini ve kimin kabul edeceğini anlatmaz. İşinizden birkaç örnek senaryo seçin: onaylı teklifin siparişe dönüşmesi, eksik belgeli başvurunun geri gönderilmesi veya yetkisiz kullanıcının maliyet alanını görememesi gibi. Senaryoların normal ve hatalı durumları bulunmalıdır. Her senaryonun beklenen sonucu açık olduğunda hem geliştirici hem işletme aynı işi kontrol edebilir. Teknik testlerle kullanıcı kabulü birbirini tamamlar.

Kabul sürecinde işletme tarafında karar verecek kişi belirlenmelidir. Her departmanın farklı tarihte yeni beklentiler eklemesi, teslimi belirsizleştirebilir. Hatalarla kapsam değişikliklerini ayıracak yöntem konuşulmalıdır. Onaylanan iş kuralının çalışmaması bir hata olabilir; daha önce bulunmayan yeni bir iş akışı ise ek kapsam olabilir. Bu ayrımı proje başladıktan sonra tartışmak yerine teklif sırasında örnekler üzerinden netleştirmek, çalışma ilişkisini daha öngörülebilir hale getirir. Karar kaydının nerede tutulacağı da belirtilmelidir.

Teslimden sonra işletilebilir bir sistem isteyin

Kaynak kodunun durumu, hesap sahipliği, alan adı, barındırma ve üçüncü taraf lisanslar teknik teklifin sonunda küçük bir dipnot olarak kalmamalıdır. Sistemi kim yayınlayacak, yedekleri kim kontrol edecek ve erişim değişikliği nasıl yapılacak? İşletme içindeki teknik yetkinlik düzeyi bu soruların cevabını etkiler. Kendi ekibi olmayan bir firma için belgelenmiş destek ve müdahale yöntemi özellikle önemlidir. Yazılımın çalışmasıyla sürdürülebilir biçimde işletilmesi aynı teslim değildir.

Bakım paketinde güncelleme, hata düzeltme, izleme ve yeni geliştirme ayrı tanımlanabilir. Öncelik seviyeleri ve iletişim kanalları da açıklanmalıdır. Her talebin aynı hızda karşılanması beklenmemeli; işin etkisine göre bir düzen kurulmalıdır. Web sitesi bakım rehberindeki sorumluluk yaklaşımı daha büyük yazılım projelerine de uyarlanabilir. Sözlü güvence yerine somut görev dağılımı, yayın sonrası belirsizliği azaltır. Devralma gerektiğinde hangi dosyaların ve bilgilerin paylaşılacağı da sorulmalıdır.

Seçimi bir senaryo görüşmesiyle tamamlayın

Kısa listedeki ekiplere aynı örnek işi anlatıp çözüm yaklaşımını dinleyin. Hazır bir ekran istemek yerine hangi soruları soracaklarını, hangi belirsizlikleri önce ele alacaklarını ve ilk teslimi nasıl sınırlandıracaklarını görün. Bu görüşme, ekibin yalnızca talimat alan mı yoksa iş problemini çözmeye çalışan mı olduğunu anlamanıza yardımcı olur. Referans projelerdeki katkılarını da aynı açıklıkla sorabilirsiniz. Başkasının logosu, tek başına teknik yaklaşımın kanıtı değildir.

91 Ajans'ın yazılım hizmetini veya başka bir ekibin teklifini değerlendirirken ortak bir kapsam dosyası kullanın. Kapsam, veri, entegrasyon, test ve bakım sorularına verilen yanıtları aynı tabloda karşılaştırın. Kararı yalnızca başlangıç tutarına ya da en uzun özellik listesine bağlamayın. İşletmenizin günlük görevlerini anlayan, belirsizliği görünür kılan ve teslimi doğrulanabilir örneklerle tarif eden teklif, sağlıklı bir çalışma zemini oluşturur. Bu zeminin açıklığı, teknoloji adlarından daha kalıcı bir değerlendirme ölçütüdür.