CTO as a Service

Teknik liderlik boşluğunun bedeli kötü kod değildir. Kötü kod pahalıdır ama geri alınabilir; asıl bedel, kimsenin o an karar olarak görmediği anlarda alınan ve sonradan geri alınamayan kararlardır. Verinin hangi ülkede durduğu, bulut hesabının kimin adına açıldığı, dışarıya verilen ilk API sözleşmesi. Bunların hiçbiri gündeme "karar" başlığıyla girmez, çoğu bir sprint içinde sessizce geçer ve iki yıl sonra şirketin ne yapabileceğini belirler. Bu hizmetin işi kod yazmak değil, o kararların önüne geçmek: hangilerinin geri alınamaz olduğunu ayırmak, gerekçesiyle birlikte yazmak ve kaydı sizde bırakmak.

Rol tanımı ve uygunluk kriterleri

Tam zamanlı bir teknik yönetici istihdam etmeden teknik kararların alınması, gerekçelendirilmesi ve yazılı olarak kaydedilmesi demek. Rolün sınırı baştan çiziliyor: şirketin resmi imza yetkilisi olmuyoruz ve kadronuzdaki mühendislerin hukuki amiri olmuyoruz. Tam zamanlı bir CTO'nun doğru cevap olduğu bir eşik de var; karar akışı sürekli hale geldiğinde, yani her hafta mimariyi etkileyen yeni bir soru çıktığında dışarıdan bir rol yetişmez. Bu hizmet kararların yığın halinde geldiği, aralarında uygulama ve ölçüm dönemleri olan şirketler için kurulu. Tegoly, Finteo ve Terazzi işlerinde danışmanlık tek başına yürümedi; her birinde çalışan ürüne dokunan uygulama işi de yapıldı, yeni ekran ve modüllerden backend ile performans çalışmasına kadar. Danışmanlık burada uygulamadan kopuk bir katman değil.

Bu iş neleri kapsıyor

Aşağıdaki altı başlık bir CTO as a Service anlaşmasında yapılan işin tamamını kapsıyor. İlk ikisi zemin: sistemin bugün gerçekte nerede durduğu ve alınan kararların gerekçesiyle kaydedilmesi. Sonraki ikisi seçim: hangi teknoloji ve tedarikçiyle çalışılacağı, ekibe kimin alınacağı. Beşincisi biriken borcun envanteri, altıncısı aynı bilginin yatırımcının ve yönetim kurulunun okuyabileceği dile çevrilmesi.

Teknik due diligence ve mevcut durum tespiti

Tespit belgeyle değil çalışan sistemle başlar: önce projenin temiz bir makinede sıfırdan ayağa kalkıp kalkmadığına bakılır, çünkü yalnızca birkaç kişinin bilgisayarında çalışan bir kurulum aslında kanıtlanmamış demektir. Ardından depo, bulut, alan adı, DNS, uygulama mağazası ve ödeme sağlayıcı hesaplarının kimin adına açık olduğu incelenir; kodun üretime nasıl çıktığı, bunu kimin yapabildiği ve geri alma adımının yazılı olup olmadığı da bu aşamada kontrol edilir. Yedek alınıp alınmadığı sorusu tek başına yetmez, geri yüklemenin en az bir kez denenmiş olması gerekir, çünkü denenmemiş yedek kanıtlanmamış yedektir. Aynı incelemede sırların depoda mı durduğuna, hangi çalışma zamanının destek almadığına ve hangi parçaya tek bir kişinin dokunabildiğine de bakılır. Sonuçta ortaya çıkan şey bir not değil, maliyet ve etkiye göre sıralanmış yazılı bir listedir.

Mimari karar kaydı ve gerekçelendirme

Her karar tek sayfada durur: cevaplanan soru, değerlendirilen seçenekler, seçilen yol, gerekçe ve bu kararı yeniden açmayı gerektirecek koşul. Son madde en çok atlanandır; geri dönüş koşulu yazılmadığında karar zamanla tartışılmaz bir alışkanlığa dönüşür. Kaydın gerçek sınavı yazıldığı gün değil, bir yıl sonra birinin "bu davranış bilinçli miydi" diye sorduğu gündür. Bilgi borcu üzerine yazımızda ele aldığımız niyet borcu tam olarak budur: kararın neden alındığının kaydedilmemesi. Kod temiz ve testler geçiyor olabilir; ekip yine de hangi davranışın bilinçli hangisinin tesadüfi olduğunu ayırt edemez. Yapay zeka üretimi kod bu borcu hızlandırır, çünkü öneriyi getiren araç gerekçesini sizin adınıza kaydetmez.

Teknoloji seçimi ve tedarikçi değerlendirme

Seçimde sorulan soru "hangisi en iyi teknoloji" değil, "yanılırsak bedeli ne" sorusudur ve bunu üç ölçüt belirliyor: devirden sonra bakımı kimin yapacağı, o teknolojide sizin pazarınızda eleman bulunup bulunmadığı ve barındırmanın sizin hesabınızda kalabilmesi. Çalışan bir sistemde varsayılan cevabımız teknolojiyi değiştirmemek oluyor, çünkü zaten işleyen bir yapıyı yalnızca daha iyi görünen bir alternatif uğruna riske atmanın gerekçesi çoğu zaman zayıf kalıyor. Tegoly, Finteo ve Terazzi işlerinin hiçbirinde çalışan teknoloji değiştirilmedi: Tegoly tarafında iş hali hazırdaki MSSQL ve Azure kurulumu üzerinde yürüdü, Finteo ile Terazzi tarafında da şirketlerin o gün kullandığı platformlar üzerinde. Tedarikçi değerlendirmesinde ise ölçüt referans listesi değil, teslimin şekli ve hesap sahipliğidir.

Ekip kurma ve mühendis değerlendirme

İlk mühendisler yalnızca kod yazmaz; şirketin teknoloji seçimini ve mülakat çıtasını fiilen belirlerler, bu yüzden ilk alımlar üç yıl sonraki organizasyon şemasına göre değil, önümüzdeki on iki ayda alınacak kararlara göre yapılır. Değerlendirmenin ağırlık merkezi de bu süreçte değişti; Yapay zeka çağında junior yazılımcı olmak yazımızın vardığı sonuç şu: yapay zekadan verim alabilmek için neyi sormanız gerektiğini bilmeniz ve gelen cevabın doğru olup olmadığını değerlendirebilecek teknik temele sahip olmanız gerekiyor. Mülakat sorusu bu yüzden "şu fonksiyonu yaz" değil, "şu üretilmiş değişiklikte ne yanlış ve neden" olur. Biz mülakatın teknik bölümünde bulunur ve değerlendirme ölçütünü yazarız; işe alma kararı sizindir.

Teknik borç envanteri ve önceliklendirme

Envanter üç borcu ayırarak yazılır, çünkü üçü farklı işle kapanır. Teknik borç kod tabanındadır ve kodu değiştirmekle kapanır. Bilgi borcu kod tabanı ile onu yöneten insanlar arasındaki anlayış boşluğudur ve yalnızca bilgi aktarımıyla kapanır; kodu yeniden yazmak çoğu zaman onu büyütür. Niyet borcu kararın gerekçesinin kayıtsız kalmasıdır ve yazmakla kapanır. Sonra her madde üç kutudan birine giriyor: büyümeden önce mutlaka değişmesi gerekenler, uzun süre olduğu gibi yaşayabilecekler ve varsayımı elendiği için hiç dokunulmayacaklar. Her maddede bırakmanın ve düzeltmenin karşılığı ayrı yazılır, böylece sıralamayı teknik taraf değil ticari taraf verebilir.

Yatırımcı ve yönetim kurulu iletişimi

Yönetim kurulunun sorduğu soru hangi çatının kullanıldığı değildir; risk ne, bedeli ne ve ne zaman ödenir sorusudur. Teknik durumu bu üç kolona çeviren bir özet yazıyoruz. Yatırım turlarında karşı tarafın teknik incelemesi de aynı listeyi ister: hesap ve alan adı sahipliği, açık kaynak lisanslarının ürününüzle uyumu, verinin hangi ülkede durduğu ve KVKK ile GDPR karşısındaki konumu, geçmiş güvenlik olayları, tek kişiye bağlı kalmış bilgi alanları. Bu maddeler tur açıldığında toplanmaz, önceden hazır olur. Doğrulayamadığımız bir rakamı sizin adınıza yazmıyor ve incelemeyi şirket yetkilisi sıfatıyla imzalamıyoruz.

Hangi kararlar geri alınamaz

Kararları geri alınabilirliğine göre ayırmak bu işin en pratik aracı. Uzun toplantı çoğu zaman geri alınabilir olanlara harcanıyor: arayüz kütüphanesi, CI aracı, kod stili, kütüphane seçimlerinin çoğu, barındırma sağlayıcısı; bunlar canınızı yakar ama sonunda dönülür. Geri alınamayan kararlar ise bunun tam tersine genelde sessizce geçer ve beş tanesi öne çıkıyor. Birincisi kullanıcı kimliğinin ve müşteriler arası veri ayrımının veri modeline mi yoksa uygulama koduna mı gömüldüğü. İkincisi verinin nerede durduğu; taşımak yalnızca teknik bir iş değil, müşteri sözleşmelerini yeniden açan bir iştir. Üçüncüsü hesap sahipliği; bulut, alan adı ve depo hesapları tedarikçinin adına açıldıysa geri almak teknik değil hukuki bir süreçtir. Dördüncüsü ödeme sağlayıcısı ile iade, abonelik ve fatura mantığının veriye gömülme biçimi. Beşincisi dışarıya verdiğiniz ilk API sözleşmesi, çünkü entegre olan her müşteri onu kilitler. Bu beş başlıkta karar öncesi yazılı gerekçe zorunlu tutulur; kalanında tutulmaz, yoksa süreç kendi başına bir yüke dönüşür.

Ajans veya tedarikçi değerlendirme kriterleri

Bu bölümü kendimiz de ajans olduğumuz için yazıyoruz; aynı liste bize de uygulanabilmeli ve bunun için altı soru yeterli oluyor. Depo tüm geçmişiyle sizin hesabınızda mı duruyor, yoksa teslim sıkıştırılmış bir klasör mü? Geçmişi olmayan teslim, kimin neyi ne zaman değiştirdiğini okunamaz kılar. Bulut, alan adı, DNS ve mağaza hesapları kimin adına açık; bugün yollarınız ayrılsa hangi parola sizde yok? Proje tedarikçinin makinesi dışında sıfırdan ayağa kalkıyor mu? Kararların gerekçesi yazılı mı, yoksa birkaç kişinin hafızasında mı? Tedarikçinin kendi ürettiği ve dışarıya taşınamayan kapalı bir katman var mı? Değişiklik talebi hangi birimle fiyatlanıyor ve kapsam büyüdüğünde fatura nasıl değişiyor? Altısına da net cevap veremeyen bir çalışma, işin kalitesinden bağımsız olarak sizi o tedarikçiye bağlar.

Çıkış: bağımsız hale gelmeniz

Bu hizmetin başarı ölçütü anlaşmanın yenilenmesi değil, gereksiz hale gelmesidir. Çıkış üç yoldan biriyle olur: kendi teknik yöneticinizi işe alırsınız, ekipteki kıdemli bir mühendis rolü devralır ya da karar akışı yavaşlar ve sürekli role ihtiyaç kalmaz. Üçünde de aynı devir paketi hazırlanır: karar kaydının tamamı, mevcut durum tespiti, üç kutulu teknik borç envanteri, sahipleriyle birlikte hesap ve erişim listesi, tedarikçi değerlendirme notları. Kaçındığımız şey tek bilgi noktası haline gelmek: kararlar bizim başımızda veya yazışma geçmişimizde değil, ekibinizin açıp okuyabileceği bir yerde durur. Hesaplarınızı kendi adımıza tutmuyor ve dışarıya taşınamayan kapalı bir katman bırakmıyoruz. Bu iki kural olmadan çıkış, bir devir değil bir taşıma projesi olur.

Karar yetkisinin paylaşımı

İş mevcut durum tespitiyle başlıyor; ayrı fiyatlanıyor ve çıktısı alıp kendi ekibinize verebileceğiniz yazılı bir liste. Sonrası açık bir karar listesi üzerinden yürüyor: her maddenin sahibi, açılış tarihi ve durumu var, kapananlar karar kaydına geçer. Bize ait olan teknik tavsiyedir ve tavsiye her zaman adı konmuş bir alternatifle, iki tarafın bedeli birlikte yazılarak verilir. Size ait olanlar ise bütçe, işe alma, tedarikçi seçimi, yayına çıkma zamanı ve hukuki sorumluluktur. Bu hizmetin gerekmediği durumu da söylüyoruz: tek ürün, tek ekip ve kararları verilmiş oturmuş bir sistem varsa yapılacak iş danışmanlık değil bakımdır. Sorun karar değil yükse iş Backend Ölçekleme tarafına, henüz doğrulanmamış bir ürün fikriyse MVP Geliştirme tarafına geçer.

Üç vakada nasıl çalıştı

Aşağıdaki üç iş bu çalışmanın yapıldığı vakalar. Her birinin ayrıntısı Başarı Hikayeleri bölümündeki kendi sayfasında duruyor ve dışarıdan kontrol edilebilir.

• Tegoly: Global pazara yönelik dijital imza ve iş süreçleri platformu. İşlevini gören bir sistem üzerinde yeni kullanıcı ekranları ve modüller, dijital imza ile doküman yönetimi entegrasyonları, önbellek mekanizmaları, Azure üzerinde sunucu yapılandırması, MSSQL ve Azure güvenlik katmanları, teknik SEO çalışıldı.
• Finteo: Fintech ve dijital ödeme platformu. Öne çıkan değişiklik frontend tarafında gerçekleşti: tüm arayüz yeniden tasarlandı, müşteri paneli geliştirmeleri, formlar ve yeni ekranlar eklendi, içerik stratejileri ve teknik SEO uygulandı.
• Terazzi: Yapı ve dekorasyon markasının web platformu. Tasarım sorunları giderildi, müşteri paneli geliştirmeleri ve yeni ekranlar hayata geçirildi, backend ve performans tarafında optimizasyon yapıldı, arama motoru görünürlüğü için içerik stratejileri uygulandı.