Özellik Listesi Ürün Mimarisi Değildir

Bir ürün fikrini konuşurken liste yapmak kolaydır.

Görevler. Notlar. Takvim. AI. Bildirimler. Paylaşım. Arama. Offline çalışma. Mobil uygulama.

Bu liste, ürünün kapsamını kabaca anlatabilir. Ama ürün mimarisini anlatmaz.

Çünkü iki ekip aynı feature listesini alıp tamamen farklı iki ürün üretebilir. Biri tutarlı ve büyüyebilir bir sistem olur. Diğeri birbirine gevşekçe bağlanmış ekranlardan oluşur.

Aradaki fark genellikle feature sayısı değil, kararların ne kadar erken kilitlendiğidir.

Mimari “hangi teknoloji?” sorusundan önce başlar

Product architecture dediğimde ilk aklıma React, Supabase veya Cloudflare gelmiyor.

Önce şu sorular geliyor:

• Ürünün ana kullanıcı kararı nedir?
• Hangi domain’ler var?
• Bu domain’ler nerede kesişiyor?
• Hangi state kalıcı?
• Hangi state türetilmiş?
• Hangi veri kullanıcıya ait?
• Hangi davranış platformlar arasında ortak?
• Hangi platform farkı bilinçli olarak ayrıştırılmalı?
• Hata, offline ve conflict durumunda ne olur?
• Bir feature hangi başka feature’ların davranışını değiştirir?

Bu sorular cevaplanmadan teknoloji seçmek mümkündür. Ama mimari kurulmuş olmaz.

Ordovia’da feature listesi neden yetmezdi?

Ordovia; görev, not, alışkanlık, ritüel, planlama, takvim ve kişisel bilgi gibi farklı domain’leri tek günlük komuta merkezinde birleştiriyor.

Feature seviyesinde bakınca her biri bağımsız modül gibi görülebilir.

Fakat kullanıcı açısından bunların hepsi aynı güne, aynı hesaba ve aynı kişisel context’e aittir.

Burada asıl mimari sorular şunlardır:

Bir görev planlamaya taşındığında iki ayrı nesne mi oluşur? Not ile görev ilişkisi referans mı, kopya mı? Mobil ve web aynı canonical veriye mi bakar? Offline değişiklik hangi sırayla reconcile edilir? Bir alışkanlığın bugünkü durumu hangi zaman modelinden türetilir?

Bunlar feature kartında görünmez.

Ama ürünün güvenilir olup olmayacağını belirler.

Kurmaca’da “editör + timeline + karakterler” demek de yetmez

Kurmaca örneğinde de aynı durum var.

Uzun metin editörü. Bölüm ve sahne yapısı. Karakterler. İpuçları. Timeline. Continuity kontrolleri.

Bu liste etkileyici görünebilir. Fakat ürünün asıl mimari kararı başka yerde: manuskript merkezi kalmalı.

Narrative logic, AI veya timeline yazma deneyiminin önüne geçmemeli. Yapı, yazarı metinden koparmadan çevresinde çalışmalı.

Ayrıca sahne düzenlemelerinde cloud revision ile local recovery’nin nasıl ilişkilendiği bir UX detayı değil, ürün mimarisidir. Recovery layer ikinci source-of-truth’a dönüşürse yazara güven vermek yerine veri riski üretir.

Build contract neden feature spec’ten farklıdır?

Feature spec genellikle “ne eklenecek?” sorusuna cevap verir.

Build contract ise şunları da kilitler:

Problem Neyi çözmeye çalışıyoruz?

Scope Neyi çözmüyoruz?

Domain Bu davranış hangi modele ait?

Flow Kullanıcı hangi sırayla ilerliyor?

State Loading, success, empty, error, offline, conflict nasıl davranıyor?

Data authority Hangi kaynak canonical?

Platform behavior Web, mobil ve desktop farkı nerede?

Acceptance Çalıştığını hangi davranış kanıtlıyor?

Bunlar yazılmadan kod başlarsa, kararlar implementation sırasında tesadüfen verilir.

AI coding çağında bu daha da kritik. Kod üretmek ucuzladı. Belirsizliği hızlı büyütmek de ucuzladı.

Feature eklemek yerine sınır çizmek

İyi ürün mimarisinin önemli kısmı ne yapılacağını söylemek değil, nerede durulacağını söylemektir.

Örneğin:

• Bir AI özelliği domain kararını kendisi veremez.
• Local cache canonical verinin yerine geçemez.
• Mobil platform farkı shared domain modelini parçalayamaz.
• Bir ayar ekranı ürünün ana flow’unu yeniden tanımlayamaz.
• Yeni modül daily-command modelinden bağımsız bir ada olamaz.

Bunlar feature değil, sınırdır.

Sınırlar kötü anlamda kısıtlama değildir. Ürünün genişlerken kimliğini ve davranışını korumasını sağlar.

“Her şey var” ürün olmaktan “bir sistem” olmaya

Çok özellikli ürünler genellikle iki şekilde büyür.

Birinci yol: Her yeni ihtiyaç için yeni ekran, yeni state ve yeni kural eklenir.

İkinci yol: Yeni ihtiyaç mevcut domain’lere ve ortak sistem davranışına bağlanır.

İlk yol ilk aylarda hızlıdır. Sonra her feature diğerlerinden bağımsız davranmaya başlar.

İkinci yol başlangıçta daha fazla düşünme ister. Fakat ürün büyüdükçe leverage üretir.

Benim için architecture’ın değeri burada.

Mimari, geleceği tahmin etmek değildir. Değişiklik geldiğinde sistemin nereden genişleyeceğini bilmek demektir.

Sonuç

Feature listesi “ne var?” sorusuna cevap verir.

Ürün mimarisi ise:

“Bu şeyler neden birlikte?” “Kim neyin sahibi?” “State nasıl akar?” “Bir şey bozulduğunda nereden bakılır?” “Yeni ihtiyaç geldiğinde sistem nereden genişler?”

sorularına cevap verir.

Bir ürünün gerçekten build-ready olması için özelliklerini değil, kararlarını tamamlamak gerekir.