Yazılım Ortağı Seçerken Sormanız Gereken 10 Soru

Bir yazılım ortağı seçmek, bir tedarikçi seçmekten çok bir ekip kurmaya benzer. Aylarca, çoğu zaman yıllarca birlikte çalışacaksınız; işiniz büyüdükçe onların kurduğu sistemin üzerine yeni katlar çıkacak. Bu yüzden karar, en düşük teklifi ya da en gösterişli sunumu bulmakla değil, doğru soruları sormakla verilir.

İşin özünde basit bir ayrım var: kabuk bir web sitesi mi, yoksa arkasında çalışan gerçek bir sistem mi? Dışarıdan ikisi de aynı görünebilir — düzgün bir arayüz, birkaç ekran, akıcı bir demo. Ama biri sadece vitrindir; diğeri, yük altında ayakta kalan, veriyi güvenle taşıyan, siz büyüdükçe sizinle büyüyen bir mühendislik ürünüdür. Aradaki farkı demo ekranından anlayamazsınız. Ancak doğru soruları sorarak anlayabilirsiniz.

Aşağıdaki 10 soru tam da bunun için. Her birinin altında neden sorulması gerektiğini ve iyi bir cevabın neye benzediğini bulacaksınız. Amaç, karşınızdakini sıkıştırmak değil; birlikte çalışacağınız ekibin, sözünü verdiği işi arkasında duracak mühendislikle destekleyip desteklemediğini görmek.

1. Keşif ve analiz sürecini nasıl yürütüyorsunuz?

Neden önemli? Yanlış yazılan bir satır kodu düzeltmek dakikalar alır; yanlış anlaşılan bir iş sürecini düzeltmek ise aylar. Projelerin çoğu kod yazımında değil, "ne yapılacağının" hatalı anlaşılmasında rayından çıkar. Keşif ve analiz aşaması, tam olarak bu riski daha ilk günden küçültmek içindir.

İyi bir cevap neye benzer? Karşınızdaki ekip, kod yazmadan önce sizi ve işinizi anlamak için ayrı ve yapılandırılmış bir süreç tarif etmeli: kullanıcılarla ve paydaşlarla görüşmeler, mevcut süreçlerin haritalanması, gerçek ihtiyaç ile "iyi olur" arasındaki ayrımın netleştirilmesi. İyi bir ortak, "hemen başlayalım" demez; önce doğru problemi çözdüğünden emin olmak ister. Kerberos'ta süreç bilinçli olarak Keşif → Mimari → Geliştirme → Sürekli Destek sırasıyla ilerler; yani keşif tesadüfi bir ön görüşme değil, işin ilk ve ayrı bir mühendislik adımıdır. Cevapta "önce dinleriz, sonra kurgularız, en son kodlarız" ritmini duyuyorsanız doğru yerdesiniz.

2. Benzer sektör ve ölçekte deneyiminiz ve referanslarınız var mı?

Neden önemli? Her sektörün kendi dili, kendi kısıtları ve kendi görünmez tuzakları vardır. Bir e-ticaret altyapısı kuran ekip, bir üretim planlama sistemi ya da bir finansal mutabakat modülü kurarken sıfırdan öğrenmek zorunda kalabilir — ve bu öğrenme masrafını çoğu zaman siz ödersiniz. Benzer ölçekte deneyim ise farklı bir şeyi gösterir: ekibin gerçek yük, gerçek kullanıcı ve gerçek sorumluluk altında çalışmış olduğunu.

İyi bir cevap neye benzer? Somut olmalı. "Çok proje yaptık" değil; hangi tür problemleri, hangi ölçekte çözdüklerini, nerede zorlandıklarını ve nasıl aştıklarını anlatabilmeliler. Referans istediğinizde çekinmemeli — ama aynı zamanda müşteri onayı olmadan isim paylaşmama hassasiyetini de göstermeliler; bu, sizin verinize de aynı özenle yaklaşacaklarının işaretidir. 20+ yılda 150+ proje ve 50+ kurumsal müşteri gibi bir birikim, tek başına bir garanti değildir; ama "bu tür işleri daha önce, gerçek koşullarda görmüşüz" diyebilen bir ekip, sizinle birlikte ilk kez öğrenen bir ekipten her zaman daha güvenlidir.

3. Kod ve fikri mülkiyet kime ait olacak?

Neden önemli? Bu, sözleşme imzalanmadan netleşmesi gereken en kritik maddelerden biridir ve maalesef en sık atlananıdır. Eğer yazdırdığınız yazılımın kaynak kodu size ait değilse, teknik olarak kendi işinizi rehin vermiş olursunuz: ortağınızı değiştiremez, sistemi bağımsız denetletemez, hatta bazen kendi verinize tam erişemezsiniz.

İyi bir cevap neye benzer? Net ve tereddütsüz olmalı: teslim edilen kod, ilgili haklarıyla birlikte size aittir. İyi bir ortak bunu bir pazarlık kozu değil, doğal bir ilke olarak görür; kaynak kodu, dokümantasyonu ve dağıtım için gereken her şeyi eksiksiz teslim eder. "Kod bizde kalır, siz kullanım hakkı alırsınız" gibi bir yapı duyuyorsanız, bu bir bağımlılık modelidir ve alarm zilidir. Kerberos'ta ilke basittir: kurduğumuz sistem sizindir — biz onun arkasında duran mühendislik ortağıyız, sahibi değil.

4. Mimari ve teknoloji seçimini nasıl yapıyorsunuz?

Neden önemli? Bugün verilen teknoloji kararları, önümüzdeki yıllarca sizinle kalır. Yanlış ya da modaya dayalı seçimler, ya sizi belirli bir tedarikçiye kilitler (vendor lock-in) ya da birkaç yıl sonra baştan yazılması gereken bir yük bırakır. "En yeni" her zaman "en doğru" değildir; önemli olan, seçimin sizin ihtiyacınıza ve sürdürülebilirliğe göre yapılması.

İyi bir cevap neye benzer? İyi bir ekip, teknoloji seçimini bir moda değil bir gerekçe meselesi olarak anlatır: "Bu işi neden bu araçla çözüyoruz, alternatifleri neydi, hangi ölçekte bu tercih mantıklı." Overengineering'den — yani ihtiyaç yokken karmaşıklık eklemekten — kaçınırlar; küçük bir işe devasa bir altyapı önermezler. Aynı ölçüde, açık ve yaygın teknolojilerle çalışıp sizi kapalı bir ekosisteme hapsetmemeye özen gösterirler. Kısaca: kararın arkasında bir "neden" varsa ve o "neden" sizin çıkarınızı gözetiyorsa, doğru yoldasınız.

5. Güvenlik ve KVKK/veri koruma yaklaşımınız nedir?

Neden önemli? Bir veri ihlali, sadece teknik bir arıza değil; itibar, hukuki sorumluluk ve müşteri güveni açısından ölçülemez bir maliyettir. KVKK gibi düzenlemeler bunu artık yasal bir zorunluluğa da dönüştürdü. Güvenlik, projenin sonuna eklenen bir cila değil, ilk günden mimariye işlenmesi gereken bir temeldir.

İyi bir cevap neye benzer? Güvenliği sonradan düşünülecek bir madde gibi değil, tasarımın parçası gibi anlatan bir ekip arıyorsunuz: kişisel verinin nasıl saklandığı ve şifrelendiği, erişim yetkilerinin nasıl yönetildiği, KVKK'nın veri minimizasyonu ve saklama süresi gibi ilkelerinin mimariye nasıl yansıdığı. İyi bir ortak, "her şey güvenli" gibi içi boş bir güvence vermez; hangi riske karşı hangi önlemi aldığını somut anlatır. Kerberos'ta güvenlik ve KVKK uyumu, geliştirme sürecinin ayrılmaz bir parçasıdır — sistemin arkasındaki mühendisliğin görünmeyen ama en kritik katmanı.

6. Test ve kalite güvence süreciniz nasıl işliyor?

Neden önemli? "Çalışıyor gibi görünmek" ile "gerçekten çalışıyor olmak" arasındaki fark, çoğu zaman canlıya çıktıktan sonra ortaya çıkar — ve en kötü anda. Sistematik bir test süreci olmayan bir ekip, hataları sizin kullanıcılarınız keşfetsin diye canlıya bırakıyor demektir. Kalite güvencesi, işin hızını değil, güvenilirliğini belirler.

İyi bir cevap neye benzer? Test, "geliştirici bir bakar, sorun yoksa göndeririz" gibi gündelik bir adım olmamalı. İyi bir ekip; ayrı bir kalite güvence adımından, farklı test türlerinden (fonksiyonel, kenar durumlar, yük) ve her teslimden önce çalışan bir kontrol kapısından söz eder. Kritik olan şu: teslim, birileri "geçti" demeden kapanmamalı. Kerberos'ta hiçbir yapım işi, kalite kontrolünden onay almadan tamamlanmış sayılmaz; teslim kapısı bilinçli olarak bu doğrulamaya kilitlidir. Cevapta bu tür bir "onaysız geçilmez" disiplini duyuyorsanız, işin arkasında gerçek bir güvence var demektir.

7. Teslim sonrası bakım, destek ve SLA nasıl işliyor?

Neden önemli? Yazılım, teslim edildiği gün bitmez; asıl orada başlar. Kullanıcılar arttıkça, işletim sistemleri güncellendikçe, iş kuralları değiştikçe sistemin bakıma ihtiyacı olur. "Projeyi teslim edip kaybolan" bir ortak, sizi en çok ihtiyaç duyacağınız anda yalnız bırakır.

İyi bir cevap neye benzer? İyi bir ortak, ilişkiyi teslimle bitirmez; sürekli destek aşamasını sürecin doğal bir parçası olarak konumlandırır. Bir sorun oluştuğunda kime, nasıl ulaşacağınız; ne kadar sürede yanıt ve çözüm alacağınız (SLA); bakımın nasıl planlandığı önceden nettir. Kerberos'un süreç tanımının son adımının Sürekli Destek olması tesadüf değil: kurulan sistemin arkasında, teslimden sonra da çalışan bir ekip olduğu anlamına gelir. Cevapta "teslim ederiz, gerisi size kalmış" tınısı varsa, uzun vadede sorun yaşarsınız.

8. Proje yönetimi, iletişim ve şeffaflığı nasıl sağlıyorsunuz?

Neden önemli? Yazılım projelerinde en sinir bozucu şey belirsizliktir: haftalar geçer, ne yapıldığını bilmezsiniz, sonunda beklediğinizden farklı bir şey çıkar. İyi bir iletişim düzeni, sürprizleri küçük ve erken tutar; kötü bir düzen ise sorunları ancak iş işten geçtikten sonra görünür kılar.

İyi bir cevap neye benzer? İlerlemenin nasıl görünür kılınacağını somut anlatabilmeliler: düzenli durum güncellemeleri, ara teslimlerle ilerlemenin gösterilmesi, kararların ve değişikliklerin kayıt altında tutulması, tek bir muhatap noktası. İyi bir ekip, iyi haberi de kötü haberi de zamanında verir; "her şey yolunda" deyip son anda sürpriz çıkarmaz. Şeffaflık, güvenin günlük hâlidir — ve birlikte çalışacağınız ekibin size nasıl davranacağının en erken işaretidir.

9. Ölçeklenme ve gelecekteki değişikliklere nasıl uyum sağlıyorsunuz?

Neden önemli? Bugün kurduğunuz sistem, işiniz büyüdüğünde de ayakta kalmalı. Bugünün ihtiyacına göre kurulmuş ama yarını hiç düşünmemiş bir yazılım, başarılı olduğunuz anda darboğaza dönüşür — yani tam da en kötü zamanda. Ölçeklenebilirlik, bir lüks değil, büyümenin sigortasıdır.

İyi bir cevap neye benzer? İyi bir ekip, bugünü çözerken yarını da düşünür: sistemin daha fazla kullanıcı ve veriyle nasıl büyüyebileceği, yeni bir modülün mevcut yapıyı bozmadan nasıl ekleneceği, iş kuralları değiştiğinde değişikliğin nereden yapılacağı. Bunu yaparken de bugün gerekmeyeni bugün kurmama dengesini gözetir — yani hem ileriyi düşünür hem de gereksiz karmaşıklıktan kaçınır. Aradığınız cevap, "sonra bakarız" değil; "büyümeyi baştan hesaba kattık" olmalı.

10. Ekip yapınız ve devamlılığınız nasıl? Bilgi kimde kalıyor?

Neden önemli? "Otobüs faktörü" diye bilinen bir risk vardır: eğer sizin projenizi bilen tek kişi ekipten ayrılırsa ne olur? Tek bir kişiye bağlı, dokümante edilmemiş bir proje, o kişiyle birlikte yok olabilir. Kurumsal devamlılık, tam da bu riski ortadan kaldırmakla ilgilidir.

İyi bir cevap neye benzer? İyi bir ortak, bilginin kişide değil kurumda kaldığını gösterebilmeli: yazılan kodun dokümante edilmesi, kararların kayıt altında olması, birden fazla kişinin projeye hâkim olması, teslim edilen işin başka bir mühendis tarafından da devralınabilir olması. Kerberos'ta 30+ mühendislik ekibinin arkasında duran şey tam olarak budur — teslim edilen her işin, tek bir kişiye değil kuruma bağlı, sürdürülebilir bir sistem olması. İşte "Kerberos Certified Technology" mührünün asıl anlamı da burada: teslim edilen işin arkasında, isimden bağımsız olarak çalışmaya devam eden gerçek bir sistem olduğunu ifade eder.

Doğru soru, doğru ortağı bulur

Bu 10 soruyu bir sınav gibi değil, bir pusula gibi düşünün. Amaç kimseyi zora sokmak değil; işinizi yıllarca taşıyacak sistemin arkasında gerçek bir mühendislik olup olmadığını, kabuk bir vitrinle çalışan bir sistem arasındaki farkı erkenden görmek. İyi bir ortak bu sorulardan rahatsız olmaz; tam tersine, çoğunu siz sormadan zaten yanıtlamış olur.

Kerberos olarak 2002'den bu yana yaptığımız işin özü de bu: keşifle başlayan, mimariyle sağlamlaşan, testle güvence altına alınan ve teslimden sonra da desteklenen özel yazılımlar üretmek. Yukarıdaki soruların cevaplarını bir broşürde değil, birlikte çalışırken hissetmenizi tercih ederiz.

Aklınızdaki projeyi bu çerçevede konuşmak isterseniz, en iyi başlangıç bir keşif görüşmesidir. Ne sattığımızı değil, sizin neye ihtiyacınız olduğunu konuşarak başlarız.

Keşif görüşmesi planlayın →

Doğru soruları sorun; gerisini birlikte kuralım.