Bloglara Dön
Girişimcilik & Ürün Yönetimi 27 May 2026

Bir Müşterinin İhtiyaçlarını Doğru Teknik Analize (Technical Scoping) Dönüştürmek

Fatih

Fatih

UI/UX Tasarımcı & Geliştirici

Bir Müşterinin İhtiyaçlarını Doğru Teknik Analize (Technical Scoping) Dönüştürmek

Her şey o tanıdık cümleyle başlar: "Aslında çok basit bir şey istiyoruz; kullanıcılar üye olacak, bir şeyler listeleyecek, bir de küçük bir yönetim paneli olacak."

Yazılım dünyasında bu "basit" cümle, doğru bir teknik analize (Technical Scoping) tabi tutulmazsa; uykusuz gecelere, sürekli değişen kapsamlara (scope creep), bütçe aşımına ve günün sonunda iki tarafın da mutsuz olduğu başarısız projelere dönüşür.

Teknik analiz, müşterinin soyut istekleri ile yazılımın somut gerçekliği arasında bir köprüdür. Kodu kullanıcıya götürmeden önce, fikri koda götürme sürecidir. Gelin, teknik bilgisi olmayan bir müşterinin hayalini, sürdürülebilir bir yazılım mimarisine nasıl dönüştürdüğümüzü adım adım inceleyelim.


💡 TL;DR:


Teknik analiz, yazılım projesinin sigortasıdır. Bu yazıda, müşteri taleplerini analiz ederken doğru soruları sormayı, iş gereksinimlerini teknik mimariye (Next.js, Supabase, API tasarımı) dönüştürmeyi ve projeyi bütçe/zaman ekseninde nasıl güvenceye alacağımızı pratik bir senaryo üzerinden inceliyoruz.


1. İlk Temas: "Müşteri Dili" ile "Mühendis Dili" Arasındaki Çeviri


Müşteriler genellikle çözümleri değil, ihtiyaçları veya hayalleri anlatırlar. Mühendisin görevi, satır aralarını okumaktır.

Klasik mimaride süreç genellikle kulaktan kulağa oynar gibi ilerler. Ancak doğru bir analiz sürecinde akış şu şekilde olmalıdır:


[Müşteri Talebi] → [İş Analizi (Gereksinimler)] → [Teknik Scoping (Mimari & DB)] → [Kodlama]


Müşteriden gelen soyut istekleri teknik gereksinimlere dönüştürürken bir filtre kullanırız. İşte birkaç örnek:

  • Müşteri: "Sistem çok hızlı olsun, binlerce kişi aynı anda girebilsin."
  • Teknik Karşılık: Edge caching stratejisi, optimize edilmiş veritabanı indeksleri, Server-Side Rendering (SSR) veya Static Site Generation (SSG) kararları, connection pool yönetimi.
  • Müşteri: "Kullanıcılar sosyal medya gibi takılsın, anlık bildirim gitsin."
  • Teknik Karşılık: Real-time veri senkronizasyonu (Websockets / Supabase Realtime), background workers (arka plan işçileri) ve push notification servis entegrasyonu.


2. Ekosistem ve Doğru Araç Seçimi: Kapsamı Teknolojik Altyapıya Oturtmak


İhtiyaç listesi netleştikten sonra, projenin geleceğini belirleyecek olan teknoloji yığını (Tech Stack) seçimine sıra gelir. Her projeye aynı araçla yaklaşmak (örneğin her şeye ezbere bir monolith veya her şeye mikroservis yazmak) en büyük mühendislik hatalarından biridir.

Teknik scoping sürecinde modern ekosistemi nasıl konumlandırıyoruz?


Müşteri/Proje TipiTercih Edilen Altyapı (Tech Stack)Tercih NedeniHızlı MVP / SaaS ProjeleriNext.js 15 + Supabase + Tailwind CSSHızlı prototipleme, yerleşik auth/database çözümü, serverless mimari.Kurumsal / Yoğun İş Mantığı.NET Core / ASP.NET MVC + PostgreSQLGüçlü tip güvenliği, katmanlı mimari (Clean Architecture) uygunluğu, uzun vadeli bakım kolaylığı.İçerik Odaklı / Tanıtım SiteleriJamstack (Next.js SSG / Headless CMS)Sıfır sunucu maliyeti, maksimum SEO performansı ve yüksek hız.


3. Madalyonun Diğer Yüzü: Sınırlar ve "Hayır" Diyebilme Sanatı


Doğru bir teknik analiz, müşteriye sadece neyi yapacağınızı değil, neyi yapmayacağınızı veya neyi neden ertelemeniz gerektiğini de söylemektir. Sınırları baştan çizmezseniz, projenin ortasında kendinizi bitmeyen talepler girdabında bulursunuz.

  • Veritabanı Sınırları: "Her veriyi sonsuza kadar tutalım ve her şeyi anlık raporlayalım." Bu istek, production veritabanını kilitleyebilir. Teknik analiz aşamasında, ağır raporlama süreçleri için ayrı bir read-replica veya zamanlanmış (cron-job) veri özetleme yapıları planlanmalıdır.
  • Üçüncü Parti Bağımlılıklar: Müşterinin istediği bir ödeme sistemi veya harici API, projenin performansını doğrudan etkileyebilir. Bu aşamada rate limit'leri, API timeout sürelerini ve hata yönetimini (fallback mekanizmaları) bütçelendirmek kritik önem taşır.
  • Bütçe ve Zaman Sınırı (MVP Felsefesi): Her harika fikir ilk versiyonda yer almak zorunda değildir. Teknik analiz belgesinde projenin "Faz-1 (MVP)" ve "Faz-2" aşamalarını net olarak ayırmak, bittiğinde çalışan bir ürün görmeyi garantiler.


4. Gerçek Bir Senaryo: Veritabanı Şeması ve API İskeleti Tasarımı


Diyelim ki bir müşteri bize geldi ve bir "Freelance İş Yönetim Platformu" istiyor. Talebi şu: "Müşteriler iş ilanı açsın, yazılımcılar teklif versin. Teklif kabul edilince iş başlasın."

Teknik analiz dökümanına ekleyeceğimiz, bu soyut isteği somutlaştıran minimal bir Supabase/PostgreSQL şeması ve TypeScript tipi şu şekilde görünmelidir:


// types/project.ts

// 1. Proje Durum Tanımlamaları (İş Mantığının Kısıtlanması)
export type ProjectStatus = 'DRAFT' | 'OPEN' | 'IN_PROGRESS' | 'COMPLETED';

// 2. Veritabanı İlişkisel Şemasının Kod Tarafındaki Karşılığı
export interface Project {
  id: string;
  created_at: string;
  title: string;
  description: string;
  budget: number;
  status: ProjectStatus;
  client_id: string;      // users tablosuna foreign key
  developer_id?: string;   // İş kabul edilene kadar nullable
}

export interface Proposal {
  id: string;
  project_id: string;     // projects tablosuna foreign key
  developer_id: string;   // users tablosuna foreign key
  bid_amount: number;
  delivery_days: number;
  cover_letter: string;
}


Bu Yapı Bize Ne Sağlıyor?

  • İlişkisel Güvence: Bir projenin durumu IN_PROGRESS olmadan developer_id atanamayacağını kod ve veritabanı seviyesinde kısıtlamış oluyoruz.
  • Performans Öngörüsü: Hangi tablolara (project_id bazlı sorgular için proposals tablosuna) indeks atılması gerektiğini daha kod yazmadan görebiliyoruz.


Sonuç: Kod Yazmadan Önce Düşünmek Kazanır


Teknik analiz (Technical Scoping) bir zaman kaybı değil, aksine projenin ilerleyen aşamalarında harcayacağınız yüzlerce saatin kurtarıcısıdır. Doğru soruları sorarak, mimari sınırları bilerek ve bunu müşterinin de anlayabileceği bir iş/teknik dengesine oturtarak yola çıktığınızda, projenin başarısız olma şansı neredeyse kalmaz.


Bir mühendis olarak benim yaklaşımım, klavyenin başına geçmeden önce sistemin tüm uç noktalarını, olası darboğazlarını ve veri akışını bu dökümantasyon metodolojisiyle netleştirmektir.


Sizin de hayata geçirmek istediğiniz bir fikriniz, web projeniz veya yeniden yapılandırılması gereken bir sisteminiz varsa; süreci doğru bir teknik analizle başlatmak için iletişim sayfamdan bana ulaşabilirsiniz.