Yazılım Danışmanlığı
Mimari, teknoloji ve ekip kararları için bağımsız teknik görüş
Son güncelleme:
Yazılımda en pahalı hata çoğu zaman kodda değil, kod yazılmadan önce verilen kararda.
Yazılım danışmanlığı, bir şirketin yazılım yatırımına dair kararlarını (mimari, teknoloji, ekip, tedarikçi ve süreç) bağımsız bir uzmanla birlikte vermesini sağlayan çalışmadır. Danışman kodu yazan ekibin yerine geçmez; mevcut durumu inceler, seçenekleri maliyet ve risk diliyle karşılaştırır ve kararı yazılı bir yol haritasına çevirir.
Bu sayfaya genellikle üç durumdan biriyle gelinir: yeni bir sistem yazdırılacak ve teklifler birbirini tutmuyor; var olan yazılım büyüdükçe yavaşlıyor ve ekip nedenini söyleyemiyor; ya da teknik kararları verecek kıdemli biri şirkette yok. Türkiye'nin her yerinden gelen işleri uzaktan yürütüyorum.
Yazılım uzmanlığından takım liderliğine, mimarlıktan CTO rolüne uzanan bir yolda telekomünikasyon, havacılık, turizm ve e-ticarette üretim sistemleri kurdum; beş yılım Corendon Dutch Airlines'ta geçti. Bugün Dijital AI'ın kurucu ortağı ve CTO'suyum; kendi SaaS ürünlerimizi geliştirip işletiyoruz.
Durumunuzu konuşalım
Yazılım danışmanı ne yapar, ne yapmaz?
Danışmanın ürünü kod değil karardır: neyin, hangi sırayla ve hangi bedelle yapılacağı. Kodu yazan ekiple arasındaki fark tam olarak bu.
Yaptıklarım
- Kod tabanını, mimariyi ve dağıtım hattını inceler, riskleri düzeltme bedeline göre sıralarım.
- Birbirine benzemeyen tedarikçi tekliflerini aynı ölçütlerle karşılaştırılabilir hâle getiririm.
- Kararları gerekçesiyle yazarım; altı ay sonra "bunu neden yaptık" sorusunun cevabı dokümanda durur.
- Ekip kararı uygularken tasarım toplantılarına ve kod incelemelerine katılırım.
Yapmadıklarım
- Sprint'e girip ekibin günlük geliştirme işini üstlenmem.
- İnceleme bitmeden "baştan yazalım" demem; yeniden yazım en son seçenektir.
- Hukuki ve mali denetim yapmam; KVKK ve sözleşme tarafında uzmanınızla birlikte çalışırım.
- Ekibinizin yerine geçmem; bilgiyi, işi devralabileceğiniz biçimde aktarırım.
Dışarıdan bir göze en çok şu durumlarda ihtiyaç doğuyor:
Teklifler birbirini tutmuyor. Aynı iş için gelen teklifler arasında süre ve bedel farkı katlarla ölçülüyor; hangisinin gerçekçi olduğunu söyleyecek kimse yok.
Sistem büyüdükçe yavaşlıyor. Her yeni özellik bir öncekinden uzun sürüyor, hatalar ancak müşteri şikâyetiyle fark ediliyor.
Kararı verecek kıdemli biri yok. Ekip iyi kod yazıyor, ama mimari, bulut maliyeti ve işe alım kararlarını verecek teknik lider yok.
Devralınan bir sistem var. Bir tedarikçiden ya da ayrılan bir ekipten kalan yazılımın gerçekte ne durumda olduğu bilinmiyor.
Geri dönüşü pahalı bir karar kapıda. Yeni ürün, yeniden yazım ya da buluta taşıma konuşuluyor ve bütçe bu karara bağlanacak.
Şirkette bu kararları verebilecek kıdemli bir teknik lider zaten varsa, çoğu zaman uzun bir çalışma değil, tek bir karar için ikinci görüş yeter.
Hangi durumda hangi danışmanlık?
Yazılım danışmanlığı tek bir hizmet değil; belirtiye göre farklı bir çalışmaya dönüşür. Altı başlığın her birinin kapsamı ve çıktısı kendi sayfasında ayrıntılı.
Mimari inceleme
Belirti: değişiklik yapmak giderek pahalılaşıyor; mikroservis ya da yeniden yazım konuşuluyor.
Çıktı: risk haritası, mimari karar kayıtları ve sıralı iyileştirme listesi. Ayrıntısı yazılım mimarisi danışmanlığı sayfasında.
Teknik liderlik
Belirti: teknoloji kararlarını teknik geçmişi olmayan bir yönetici veriyor ya da her şeyi tek bir kıdemli geliştirici taşıyor.
Çıktı: teknoloji yol haritası, işe alım profilleri, bütçe ve tedarikçi kararlarında düzenli destek. Ayrıntısı yarı zamanlı CTO danışmanlığı sayfasında.
Bulut ve ölçeklenme
Belirti: bulut faturası kullanıcı sayısından hızlı büyüyor ya da sistem yoğun günlerde dağılıyor.
Çıktı: hedef mimari, taşıma sırası ve maliyet kontrolü için kurallar. Ayrıntısı cloud-native geliştirme sayfasında.
Sürüm ve dağıtım hattı
Belirti: sürüm çıkarmak bir gün sürüyor, canlıya çıkan hatayı geri almak bir operasyona dönüşüyor.
Çıktı: otomatik derleme, test ve dağıtım hattı, ortam stratejisi ve geri alma kuralı. Ayrıntısı CI/CD ve DevOps sayfasında.
SaaS ürün
Belirti: bir yazılımı çok sayıda müşteriye abonelikle sunmak istiyorsunuz ve ilk sürümün kapsamı belirsiz.
Çıktı: kiracı yalıtım modeli, abonelik ve faturalama akışı, ilk sürümün sınırı.
Yapay zekâ entegrasyonu
Belirti: ürüne ya da iç süreçlere dil modeli eklenecek ve şirket verisinin nereye gideceği belli değil.
Çıktı: kullanım senaryosu, veri sınırı, değerlendirme seti ve üretime alma planı. Ayrıntısı kurumsal LLM entegrasyonu sayfasında.
Belirtiler çoğu zaman birlikte gelir: yavaşlayan bir sistemin arkasında hem mimari hem dağıtım hattı hem de karar verecek kişinin yokluğu durabilir. Bu yüzden çalışma tek bir başlıkla değil, en pahalı riskle başlar. Mikroservis tartışmasının sahadaki karşılığını mikroservis mimarisinde pratik kararlar yazısında anlattım.
Karar verildikten sonra yeni bir iş uygulaması yazdırılacaksa, geliştirme tarafını kurumsal web yazılım geliştirme sayfasında; yapay zekânın şirket genelinde hangi işe gideceğine karar verilecekse yapay zekâ danışmanlığı sayfasında ele aldım.
Bir danışmanlık çalışması nasıl ilerler?
Dört aşama var; çoğu şirket ilk üçünü alıp uygulamayı kendi ekibiyle yürütüyor. Her aşama yazılı bir çıktıyla ve bir sonraki adımın kararıyla kapanıyor.
Ön görüşme ve kapsam
Hedef, bugünkü durum ve kısıtlar konuşulur; danışmanlığa gerçekten gerek olup olmadığına burada bakılır.
Çıktı: tek sayfalık kapsam: neye bakılacak, neye bakılmayacak, hangi soru cevaplanacak.
Kapanış sorusu: cevaplanacak soru tek cümleyle yazılabiliyor mu?
İnceleme
Kod tabanı, mimari, veri modeli, dağıtım hattı, izleme ve ekip süreçleri incelenir; geliştiricilerle birebir görüşülür.
Çıktı: bulgular raporu; her risk için etki, olasılık ve düzeltme bedeli.
Kapanış sorusu: yönetim en büyük üç riski teknik terim kullanmadan anlatabiliyor mu?
Yol haritası
Bulgular etki ve efora göre sıralanır; kısa, orta ve uzun vadeli işler ekiplerin sprint planına girecek ayrıntıda yazılır.
Çıktı: önceliklendirilmiş yol haritası ve mimari karar kayıtları (ADR).
Kapanış sorusu: ilk üç ayın işi, sahibi ve ölçütü belli mi?
Uygulama desteği
Ekip yol haritasını uygularken kritik tasarım toplantılarına, kod incelemelerine ve tedarikçi görüşmelerine katılırım; gerekirse küçük bir kavram kanıtı (PoC) yazarım.
Çıktı: dönemsel ilerleme notu ve güncellenen karar kayıtları.
Kapanış sorusu: hangi kararları artık ekip kendisi veriyor?
Antalya ve çevresinde ekiple yerinde çalışmak istiyorsanız o düzeni Antalya yazılım danışmanlığı sayfasında ayrıca anlattım.
Yazılım danışmanlığı nasıl ücretlendirilir?
Üç model var. Hangisinin doğru olduğunu danışmanın tercihi değil, işin süresi ve belirsizliği belirler.
| Model | Ne zaman doğru | Neye dikkat edilmeli |
|---|---|---|
| Saatlik ya da oturum bazlı | Tek bir karar için ikinci görüş, bir teklifin ya da tasarımın gözden geçirilmesi | Kapsam büyüdükçe toplam bedel öngörülemez hâle gelir; oturumun sorusu önceden yazılmalı |
| Sabit kapsamlı paket | Mimari inceleme, devralınan sistemin değerlendirilmesi gibi çıktısı belli işler | Kapsam dışında kalanın ne olduğu da sözleşmede yazılı olmalı |
| Aylık sabit ücret (retainer) | Sürekli karar desteği, yarı zamanlı teknik liderlik | Ayda kaç saat ayrıldığı, hangi kanaldan ve ne kadar sürede erişileceği yazılmalı |
Bedeli dört şey belirler: sistemin büyüklüğü ve yaşı, incelenecek alanların sayısı, çıktının türü (rapor mu, uygulama desteği mi) ve çalışmanın temposu. Dokümanı olmayan, on yıllık bir sistemin incelemesi aynı büyüklükteki yeni bir sistemden uzun sürer; çünkü kararların gerekçesi koddan geri çıkarılır.
Yapay zekâ projelerindeki paket bantlarını yapay zekâ danışmanlığı fiyatları sayfasında açıkça yazdım. Yazılım tarafında kesin bedel, kapsam yazılı hâle geldiğinde ilk görüşmenin sonunda netleşir.
Bağımsız danışman, yazılım evi ya da kadrolu teknik lider?
Üçü birbirinin rakibi değil, farklı soruların cevabı: bağımsız danışman ne yapılacağına, yazılım evi nasıl yapılacağına, kadrolu teknik lider ise bunun yıllarca sürdürülmesine hizmet eder.
| Ölçüt | Bağımsız danışman | Yazılım evi | Kadrolu teknik lider |
|---|---|---|---|
| En uygun olduğu an | Karar henüz verilmemişken, teklifler karşılaştırılırken | Kapsam yazılı ve geliştirme hacmi büyükken | Yazılım şirketin çekirdek işiyken ve karar yükü her hafta geliyorken |
| Güçlü yanı | Tarafsız bakış; kısa sürede yazılı çıktı | Geniş ekip ve teslimat kapasitesi | Bağlamı her gün yaşar; bilgi şirkette kalır |
| Zayıf yanı | Kapasitesi sınırlı; büyük bir uygulamayı tek başına taşıyamaz | "Bu işi hiç yapmayın" önerisi gelir modeliyle çelişebilir | İşe alım aylar sürer; tek kişiye bağımlılık yaratabilir |
| Bedelin yapısı | Süreye ya da kapsama göre | Geliştirme emeğine göre | Maaş ve yan haklar, uzun vadeli |
Ben ilk sütundayım ve zayıf yanı benim için de geçerli. Bu yüzden inceleme ve yol haritasını, uygulamayı hangi ekip üstlenirse kullanabileceği biçimde yazıyorum. Şirket ileride kadrolu bir teknik lider işe aldığında da devralabileceği bir karar kaydı kalıyor.
Danışman seçerken hangi soruları sormalı?
Özgeçmiş ve saatlik ücret danışmanın nasıl çalışacağını söylemez. Şu beş sorunun cevabı söyler:
"İlk iki haftanın sonunda elimde hangi yazılı çıktı olacak?" Cevap belirsizse çalışma da belirsiz kalır.
"Bizim ölçeğimizde bir sistemde neyi yanlış yaptınız?" Hata anlatamayan biri deneyimini değil, sunumunu anlatıyordur.
"Hangi durumda bu işi yapmamamızı önerirsiniz?" Her soruya "evet" diyen danışman danışmanlık değil satış yapıyordur.
"Önerdiğiniz teknolojiden ya da tedarikçiden bir geliriniz var mı?" Tarafsızlığın ölçülebilen tek göstergesi budur.
"Çalışma bittiğinde kararların gerekçesi nerede duracak?" Bilgi danışmanla birlikte kapıdan çıkmamalı; karar kayıtları sizin deponuzda durmalı.
Sık sorulan sorular
Yazılım danışmanlığı hangi durumda gereksiz bir masraftır?
Kararı verecek kıdemli bir teknik lideriniz varsa ve sorun karar değil kapasiteyse; o durumda ihtiyacınız danışman değil geliştiricidir. İyi çalışan bir sisteme yalnızca modernleşmek için dokunmak da çoğu zaman gereksiz bir masraftır. Böyle bir durumu ilk görüşmede açıkça söylerim.
Bir danışmanlık çalışması ne kadar sürer?
Tek bir karar için ikinci görüş birkaç saatlik bir oturumdur. Orta büyüklükte bir sistemin incelemesi ve yol haritası genellikle iki ila dört hafta sürer. Uygulama desteği aylarca sürebilir; her dönemin sonunda devam edip etmeme kararı yeniden verilir.
Kaynak kod, dokümanlar ve kararlar kimde kalır?
Hepsi sizde kalır. Kod erişimi sizin belirlediğiniz yetkiyle ve süreyle verilir, çalışma bitince kapatılır. Raporlar, yol haritası ve mimari karar kayıtları sizin deponuza yazılır; sözleşmede bu çıktıların size ait olduğu açıkça yer alır.
Çalışma tamamen uzaktan yürütülebilir mi?
Evet. Kod okuma, inceleme görüşmeleri ve raporlamanın tamamı uzaktan yürütülebiliyor. Yerinde bulunmanın fark yarattığı anlar genellikle ikidir: ekiple ilk tanışma ve yol haritasının yönetimle birlikte karara bağlandığı toplantı.
Hangi teknolojilerle çalışıyorsunuz?
Derinliğim .NET ekosistemi ve Azure üzerinde. Mimari, veri modeli, dağıtım hattı ve ekip süreci gibi soruların çoğu ise dilden ve bulut sağlayıcısından bağımsızdır. Konu uzmanlık alanımın dışında kalıyorsa bunu ilk görüşmede söylerim.
Yazılım danışmanlığı mı, yarı zamanlı CTO mu?
Soru bir ya da birkaç karardan ibaretse yazılım danışmanlığı; kararlar her hafta geliyorsa ve şirkette teknik lider rolü boşsa yarı zamanlı CTO. İlki yazılı bir çıktıyla biter, ikincisi bir rolü belirli bir süre doldurur.
İlk görüşmeye ne hazırlamalıyım?
Cevaplanmasını istediğiniz soruyu tek cümleyle yazmanız yeter. Varsa mimari şema, elinizdeki teklifler, son altı ayın büyük olayları (kesinti, gecikme, bütçe aşımı) ve ekibin yapısı görüşmeyi hızlandırır. İlk görüşmede kod erişimi gerekmez.
Karar önünüzdeyken ikinci bir göz
Aklınızdaki kararı ve elinizdeki durumu anlatın; hangi çalışmanın gerektiğini, belki de hiç gerekmediğini ilk görüşmede birlikte netleştirelim. İlk görüşme ücretsiz ve uzaktan yapılabiliyor.
Ön görüşme talep edinİlgili hizmetler
Bu sayfadaki işle birlikte en sık çalıştığım alanlar.