Kaba Mühendislik Tahmini Nedir?

Bir ürün yöneticisi olarak elinizde net bir hedef var: ödeme sayfasındaki dönüşümü yüzde on artırmak. User story'leri yazdınız, çözüm fikirleriniz şekillendi, hatta tasarım taslakları bile masada. Ama tam yol haritasını sprint'lere bölmeden önce içinizde bir ses var: "Acaba bu işin mühendislik tarafı ne diyor? Ne kadar sürer, neyi göremiyorum?" İşte tam bu duraklamanın adı var: kaba mühendislik tahmini.

Peki Tam Olarak Neyden Bahsediyoruz?

Kaba mühendislik tahmini, bir ürün talebinin hayata geçirilebilmesi için gereken efor, süre ve olası risklerin; mühendislik, tasarım ve ürün ekipleri tarafından detaya inmeden yapılan ilk ortak değerlendirmesidir. Bu, kesin bir takvim sözü değildir; bir his yoklamasıdır. Talebin büyüklüğünü, gizli karmaşıklıklarını ve görünmeyen risklerini erkenden masaya yatırmanın yoludur.

Başka bir deyişle, stratejik bir hedefin gerçeklikle ilk temasıdır. Şirket hedefi kâğıt üzerinde ne kadar parlak görünürse görünsün, onu hayata geçirecek olan ekiplerin "bu işin altında ne var?" sorusuna verdiği ilk yanıt buradan çıkar.

Masada Aslında Ne Konuşuluyor?

Kaba tahmin süreci, genellikle ürün yöneticisinin paydaşları bir araya getirmesiyle başlar. Frontend ekibi, backend ekibi, tasarım, bazen de veri veya güvenlik tarafından isimler bu masada olur. Konuşma çok belirli bir yapıyla ilerler:

• Talep ne? Örneğin: "Ödeme sayfasındaki dönüşümü yüzde on artırmak istiyoruz."
• Bunu nasıl yapmayı düşünüyoruz? User story'ler ortaya konur: kart saklama özelliği, formun kısaltılması, akışın sadeleştirilmesi gibi.
• Mühendislik tarafında bu ne anlama geliyor? Ekipler, kendi alanlarındaki efor tahminini paylaşır. "Kart saklama PCI uyumu gerektirir, bu üç haftalık bir iş", "Formun kısaltılması yarım sprint sürer" gibi sezgisel ama deneyime dayanan rakamlar masaya gelir.
• Ne tür riskler var? Belki mevcut ödeme servisinin bir kısıtı vardır, belki bir üçüncü parti entegrasyon beklenmedik bir engel yaratır.

Bu konuşma derinlemesine bir teknik tasarım toplantısı değildir. Hatta tam tersine; çok hızlı, çok pratik ve çoğu zaman tahminleri "küçük, orta, büyük" gibi kaba ölçeklerle ifade eden bir oturumdur. Önemli olan rakamın isabetli olması değil, ekibin işin büyüklüğüne dair ortak bir hisse sahip olmasıdır.

Bir Stratejinin Sprint'e Dönüşme Anı

Bu sürecin neden bu kadar kritik olduğunu anlamak için bir adım geri çekilmek gerek. Şirket hedefiniz vardır, bir yol haritası çıkarmışsınızdır, içinde de stratejik öncelikler. Ancak bu strateji, sprint'lere indirilmediği sürece sadece bir niyet olarak kalır. Stratejinin operasyona dönüşmesindeki ilk adım, kaba mühendislik tahminidir.

Çünkü bir talebin gerçekçi olup olmadığını, ne zaman teslim edilebileceğini, hangi başka işleri geciktireceğini ancak bu ön değerlendirmeden sonra anlayabilirsiniz. Bu adım atlanırsa, ya gerçekçi olmayan sözler verirsiniz ya da ekipler beklenmedik bir karmaşıklığın içinde kaybolur. İki durum da pahalıdır.

Üstelik bu süreç sadece teknik bir filtre değildir. Aynı zamanda paydaşlar arasında ortak bir dil ve ortak bir sahiplik yaratır. Tasarım, ürün ve mühendislik aynı odada aynı problemin büyüklüğünü tartıştığında, sonradan çıkacak "ama biz bunu bilmiyorduk" tartışmalarının önemli bir kısmı daha doğmadan ortadan kalkar.

Sahadan Bir Görünüm

Başa dönelim ve örnekteki ödeme sayfası senaryosunu düşünelim. Diyelim ki ürün yöneticisi olarak masaya "ödeme dönüşümünü yüzde on artırma" hedefiyle geldiniz. Çözüm önerileriniz arasında kart saklama, form kısaltma ve tek tıkla ödeme var.

Kaba mühendislik tahmini oturumunda şu tablo çıkabilir:

• Form kısaltma: Frontend ekibi bunu küçük-orta bir iş olarak görüyor, yaklaşık bir sprint diyorlar. Risk düşük.
• Kart saklama: Backend ekibi burada duraksıyor. PCI DSS uyumu, mevcut ödeme sağlayıcısıyla yeni bir entegrasyon, güvenlik denetimi... "Bu en az iki ay" diyorlar. Risk yüksek.
• Tek tıkla ödeme: Mevcut kart saklama altyapısına bağlı. Yani onsuz yapılamaz; bağımlılık var.

Bu yirmi dakikalık konuşmanın sonunda elinizdeki yol haritası tamamen değişmiş olabilir. Belki ilk sprint'te sadece form kısaltma ile hızlı bir kazanç almayı, kart saklama için daha detaylı bir keşif sürecine girmeyi tercih edersiniz. Hiç o oturumu yapmasaydınız, üç ay sonra "neden hâlâ canlıya çıkmadık" sorusuyla karşı karşıya kalabilirdiniz.

Benzer bir mantık aslında her dijital ürün ekibinde işliyor. Bir e-ticaret platformunda yeni bir filtreleme özelliği, bir SaaS üründe yeni bir entegrasyon, bir mobil uygulamada bildirim sisteminin yenilenmesi... Hepsi, sprint planlamadan önce bu kaba değerlendirmeden geçer ya da geçmesi gerekir.

Rolünüze Göre Ne Anlama Geliyor?

Eğer ürün yöneticisiyseniz, kaba mühendislik tahmini sizin için bir zaman maliyeti değil, bir sigortadır. Mühendislik ekibini erken dahil etmek, sonradan yaşayacağınız sürpriz gecikmelerin önüne geçer. Bir özellik için "ne kadar sürer?" sorusunu sormaktan çekinmeyin; ama bu sorunun cevabını detaylı bir tasarım dokümanı beklemeden, kaba bir hisle istemeyi öğrenin.

Eğer tasarımcı veya UX designer iseniz, bu oturumlar sizin için tasarım kararlarınızın teknik gerçeklikle nerede çakıştığını öğrenmenin en hızlı yoludur. Belki muhteşem bir akış tasarladınız ama mevcut altyapı onu desteklemiyor. Bunu Figma'da haftalar geçirdikten sonra öğrenmek yerine, kaba tahmin masasında öğrenmek size çok zaman kazandırır.

Eğer AI üzerine çalışıyorsanız, bu prensip belki de daha da kritiktir. Çünkü AI projelerindeki belirsizlik geleneksel yazılım projelerinden çok daha yüksektir. Model performansı, veri kalitesi, çıkarım maliyeti gibi değişkenlerin kaba bir tahminle bile masaya yatırılması, projenin yönünü çok erken aşamada düzeltebilir.

Son Söz Yerine

Kaba mühendislik tahmini, geleceği kesin olarak görmenin değil; geleceğin hangi noktalarda sizi şaşırtabileceğini ekipçe sezmenin sanatıdır. Detaylı bir plana ihtiyaç duymadan, bir fikrin gerçekliğe ne kadar yakın olduğunu anlamanın en sade ve en dürüst yoludur.